1 / 37

On the Distribution of Responsibility for Network Security

On the Distribution of Responsibility for Network Security. Scott Dexter Dept. of Computer and Information Science Brooklyn College. Overview. My Perspective My Argument Dramatis Personae Their Roles (and Malfeasances) and Their Eventual Rehabilitation. My Perspective.

ryanadan
Download Presentation

On the Distribution of Responsibility for Network Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. On the Distribution of Responsibility for Network Security Scott Dexter Dept. of Computer and Information Science Brooklyn College

  2. Overview • My Perspective • My Argument • Dramatis Personae • Their Roles (and Malfeasances) • and Their Eventual Rehabilitation

  3. My Perspective • Theoretician by training and inclination • Dissertation: formal/logical analysis of security protocols • Implementation details sometimes regarded as abhorrent • Interested in relationship between individual empowerment and collective behavior • Deeply committed to (public) education

  4. My Argument • Network/computer security is really interesting... • …mostly because of its social intractability: • Any actor, at any level, may (easily) cause a “security breach” • Probably due only to ignorance, human error, laziness, or even kindness • But could impact many others • No easy fix • Need some technical solutions • Need lots of different kinds of education

  5. Network Technologies • “The Internet” • One of many technologies • (and can be said to be composed of many itself) • Designed for robustness and reliability (which is one aspect of “security”) • Designed to accommodate innovation • Also need • Proprietary/closed networks (e.g. bank machines) • Network applications “on top of” Internet

  6. Actors • Designers • Implementers • Administrators • Users • (“Hackers”)

  7. Design I: Internet Core Protocols • Info transmitted in sequence of datagrams • Data ‘payload’ plus complex array of control info • Achieves robustness and reliability in non-hostile environment • Possible to ‘craft’ illegal/bogus datagrams • Get information from nature of response • Circumvent firewalls & intrusion detectors • This is integral aspect of Internet!

  8. Design II: Cryptographic Security • Appropriate use of cryptography has potential to solve many security problems • Can support many services: • Confidentiality (hide content from others) • Integrity (assure that content hasn’t changed) • Authenticity (demonstrate/confirm identity) • But appropriate is incredibly difficult….

  9. One Scenario: “Key Distribution” Alice Bob

  10. One Scenario: “Key Distribution” Alice Bob

  11. One Scenario: “Key Distribution” K Alice Bob

  12. Mallory One Scenario: “Key Distribution” K Alice Bob KA KB Solomon

  13. Passive Attacks Eavesdropping Public Information Agent Identities Algorithms Protocol Design “Legitimate” Identity Active Attacks Modification Redirection Suppression Fake Messages Mallory’s Machinations

  14. Defenses • Cryptography • Encryption {m}kencrypt message m with key k • Time • Nonces M,N random numbers “used only once” • “Handshake” function • (e.g. decrement) f(m) relates to “strong encryption”: assumption that {x}k and {g(x)}k (for any function g) are not easily computed from each other

  15. The Needham-Schroeder Protocol AS: A, B, N A B S

  16. The Needham-Schroeder Protocol AS: A, B, N SA: {N, B, K, {K,A}KB}KA A B S

  17. The Needham-Schroeder Protocol AS: A, B, N SA: {N, B, K, {K,A}KB}KA AB: {K,A}KB A B S

  18. The Needham-Schroeder Protocol AS: A, B, N SA: {N, B, K, {K,A}KB}KA AB: {K,A}KB BA: {M}K A B S

  19. The Needham-Schroeder Protocol AS: A, B, N SA: {N, B, K, {K,A}KB}KA AB: {K,A}KB BA: {M}K AB: {f(M)}K A B S

  20. The Needham-Schroeder Protocol AS: A, B, N SA: {N, B, K, {K,A}KB}KA AB: {K,A}KB BA: {M}K AB: {f(M)}K AB: {P}K once protocol completes, BA: {Q}K A and B can send messages over secure channel A B S

  21. But . . . AS: A, B, N SA: {N, B, K, {K,A}KB}KA AB: {K,A}KB BA: {M}K AB: {f(M)}K What if Mallory • learns {K,A}KB • learns K ?

  22. Mallory Attacks! AS: A, B, N SA: {N, B, K, {K,A}KB}KA AB: {K,A}KB BA: {M}K AB: {f(M)}K (M)B: {K,A}KB

  23. Mallory Attacks! AS: A, B, N SA: {N, B, K, {K,A}KB}KA AB: {K,A}KB BA: {M}K AB: {f(M)}K (M)B: {K,A}KB B(M): {M}K

  24. Mallory Attacks! AS: A, B, N SA: {N, B, K, {K,A}KB}KA AB: {K,A}KB BA: {M}K AB: {f(M)}K (M)B: {K,A}KB B(M): {M}K (M)B: {f(M)}K

  25. Mallory Attacks! AS: A, B, N SA: {N, B, K, {K,A}KB}KA AB: {K,A}KB BA: {M}K AB: {f(M)}K (M)B: {K,A}KB B(M): {M}K (M)B: {f(M)}K . . . and now Bob thinks Mallory is Alice

  26. Design Revisited • Such mistakes are common even today • Protocols disarmingly simple • Error may not be discovered (by the “good guys”) for a long time

  27. Implementation • Perfect protocol design is worse than useless if implemented incorrectly • Myriad opportunities for that: • “Back doors” [ improper software engineering ] • Buffer overflow [ unsafe programming ] • Hobbled random number generators • Improper use of crypto algorithms • [ under-rated ] • [ fundamentals ]

  28. Administration • (Where to start?) • Enforcing security policy, e.g. • Password policy • Rogue modems • Internal threats • Intrusion prevention and detection • Information Gathering • Information Analysis • Response

  29. Information Gathering • ‘Normal’ Profiles • ‘Abnormal’ Signatures • Inbound Traffic Analysis • Audit Trail • On-the-Fly • Daily operational analysis (‘intuitive’)

  30. Information Analysis • What is an intrusion? • Traffic Analysis Indicators • Analysis Techniques

  31. Traffic Analysis Indicators • Repetition • Vulnerability Exploits • Mysterious Behavior / Problems • Unexpected/Inconsistent Activity

  32. Analysis Techniques • Pattern-matching & Signatures • Dynamic Association • Statistical Profiling • Audit Reduction

  33. Response • False Positives • Traceback & Anonymity • Offensive Action & Traps

  34. Intrusion Detection Revisited • Technical component: • Hardware to scan traffic • Software to process traffic • Crafty component: • Clear understanding of normal traffic • Finger on the pulse • Sensitive viscera • Constant re-education

  35. Users • Increasingly must be network admins at home • Personal privacy/security • Often must trust integrity of arcane infrastructure • Major target of “social engineering” • Critical thinking • Analytic problem-solving

  36. Conclusions… • Improving security is fundamentally not technical • Must provide access to resources and knowledge • Must not let technology of security undermine permissive structure of Internet

More Related