on the distribution of responsibility for network security l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
On the Distribution of Responsibility for Network Security PowerPoint Presentation
Download Presentation
On the Distribution of Responsibility for Network Security

Loading in 2 Seconds...

play fullscreen
1 / 37

On the Distribution of Responsibility for Network Security - PowerPoint PPT Presentation


  • 198 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - 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