Automating networksecurityassessment


Published on

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • It is not Host analysis Classic Hardening Guides; CVE; CVSS; CPE It is not Network Device analysis Manual Firewall ACL Scrub; Vulnerability Patching Network Devices are (slightly) different “ Vulnerabilities” more often mis-configurations, not software defects
  • Automating networksecurityassessment

    1. 1. Владимир Илибман , Cisco Automating Network Security Assessment
    2. 2. What we will cover <ul><li>Traditional approach </li></ul><ul><li>What ’s new: Automation </li></ul><ul><li>Case study: Network modeling </li></ul><ul><ul><li>- Cisco ’s global infrastructure </li></ul></ul><ul><li>Case study: Zone defense </li></ul><ul><ul><li>- Scrub down of border PoP ’s </li></ul></ul><ul><li>Case study: Defending critical assets </li></ul><ul><ul><li>- Isolating PKI </li></ul></ul><ul><li>Case study: “Surprise!” </li></ul><ul><ul><li>Handling new infrastructure </li></ul></ul><ul><li>Case study: Managing change day to day </li></ul><ul><ul><li>- The Carnac moment </li></ul></ul>
    3. 3. Today ’s network security audits <ul><li>Typically, network and hosts treated separately </li></ul><ul><li>Network: </li></ul><ul><ul><li>Elbow grease and eye strain </li></ul></ul><ul><ul><li>Gather configs; print configs; read configs </li></ul></ul><ul><ul><li>Similar to proof-reading the phone book </li></ul></ul><ul><li>Hosts: </li></ul><ul><ul><li>Level 1: Leave the admins to patch </li></ul></ul><ul><ul><li>Problem: hope is not a strategy </li></ul></ul><ul><ul><li>Level 2: Scan for unpatched systems </li></ul></ul><ul><ul><li>Problem: more data than you can handle </li></ul></ul><ul><ul><li>Level 3: Drive cleanup based on risk </li></ul></ul><ul><ul><li>Problem: prioritization easier said than done </li></ul></ul>
    4. 4. Why network assessment is different <ul><li>It ’s not host analysis </li></ul><ul><li>It ’s not config analysis </li></ul><ul><ul><li>You can ’t detect a route around the firewall by reading the firewall </li></ul></ul>
    5. 5. Case study: “Project Atlas” <ul><li>Objective: </li></ul><ul><ul><li>Map the entire global Cisco environment </li></ul></ul><ul><ul><li>Review major site interconnections </li></ul></ul><ul><ul><li>Audit access to sensitive locations </li></ul></ul><ul><ul><li>27,000 configuration files </li></ul></ul><ul><li>How long would this take manually? </li></ul><ul><ul><li>Reads a device configuration in 1 hour </li></ul></ul><ul><ul><li>Checks a firewall rule in 1 minute </li></ul></ul><ul><ul><li>4 person‐years (working 24x7x365) </li></ul></ul><ul><li>Resources: </li></ul><ul><ul><li>Installed RedSeal software </li></ul></ul><ul><ul><li>Two weeks </li></ul></ul>
    6. 6. Raw network (aka “The Bug Splat”) <ul><li>Lesson #1: You need a config repository </li></ul>
    7. 7. Organizing Cisco ’s worldwide network <ul><li>Zoning from location codes, without input from Cisco </li></ul>Lesson #2: Naming conventions are your friend
    8. 8. Final “circumpolar” zoned view <ul><li>US </li></ul>Europe India APAC US
    9. 9. Connectivity to six sensitive servers Sensitive servers
    10. 10. Automatic calculation of connectivity <ul><li>Blue lines show open access paths to sensitive servers </li></ul><ul><li>Clearly shows the need for segmentation </li></ul>Lesson #3: Pictures easily explain difficult concepts
    11. 11. Access specifics – “Is it just ping?” <ul><li>Detailed drill-down from one blue arrow </li></ul><ul><li>Well, at least we blocked telnet </li></ul><ul><ul><li>(Specifics hidden, for obvious reasons) </li></ul></ul>
    12. 12. Case Study: Zone defense <ul><li>Cisco has 15 major PoP ’s for external connections </li></ul><ul><li>Typical manual assessment: 90 days per PoP </li></ul><ul><li>Target: </li></ul><ul><ul><li>Build map </li></ul></ul><ul><ul><li>Record major zones </li></ul></ul><ul><ul><ul><li>Internet, DMZ, Inside, Labs, etc </li></ul></ul></ul><ul><ul><li>Analyze for Best Practice violations </li></ul></ul><ul><ul><li>Add host vulnerabilities from scans </li></ul></ul><ul><ul><li>Run penetration test </li></ul></ul>
    13. 13. San Jose Campus Network Map <ul><li>Map of one PoP </li></ul><ul><li>Zoning done “semi-automatically” </li></ul>Internet DMZ Main Site Labs
    14. 14. Offline penetration testing <ul><li>Next level of analysis is penetration testing </li></ul><ul><li>Combine network map with host scans </li></ul><ul><li>Add access calculation </li></ul><ul><li>Software automatically evaluates attack paths </li></ul><ul><li>Identify high risk defensive weaknesses </li></ul>
    15. 15. Risk from Network-Based Attacks High Risk Low Risk Blocking Rule Blocking Rule High Risk Low Risk Blocking Rule Pivot Attack Blocking ACL Pivot Attack
    16. 16. Sample attack chain – Before Internet DMZ Main Site
    17. 17. Step 1 – Vulnerabilities exposed in DMZ <ul><li>Attackers can reach these Internet-facing servers </li></ul>
    18. 18. Step 2 – Some attack paths sneak in <ul><li>Just a few pivot attacks are possible </li></ul>
    19. 19. Step 3 – Attack fans out <ul><li>An attacker can get in if they find this before you fix it </li></ul>
    20. 20. Penetration test results <ul><li>Sample result: </li></ul><ul><ul><li>External attackers can reach red hosts </li></ul></ul><ul><ul><li>Then pivot to attack yellow hosts </li></ul></ul><ul><ul><li>But no attack combination reached green hosts </li></ul></ul>Lesson #6: Network data + Vuln data + Attack path = GOLD
    21. 21. Case Study: Defending critical assets <ul><li>PoP audits work outside in </li></ul><ul><ul><li>Broad scope, hunting major gaps </li></ul></ul><ul><ul><li>Problem: lots and lots of access to review </li></ul></ul><ul><ul><li>Can ’t quickly capture all rules for all incoming access </li></ul></ul><ul><ul><li>Some assets deserve focused attention </li></ul></ul><ul><li>For critical assets, work inside out </li></ul><ul><ul><li>Start from known target </li></ul></ul><ul><ul><li>Limit scope, increase focus </li></ul></ul><ul><ul><li>Continuous re-assessment </li></ul></ul>
    22. 22. Distributed public key infrastructure <ul><li>Main site, plus disaster recovery site </li></ul><ul><ul><li>Building the “crossbar” was easy – we sampled from Atlas </li></ul></ul>Internet Cert Authority WAN (sample) DR Site Lesson #7: A reference atlas is your friend
    23. 23. Distributed public key infrastructure <ul><li>Access strictly controlled </li></ul><ul><ul><li>Untrusted 3 rd party manufacturers need to request certs </li></ul></ul><ul><ul><li>Only cert admins should have general access </li></ul></ul>Internet Cert Authority Cert Admins WAN to Extranet DR Site
    24. 24. Investigate unexpected access <ul><li>Note: no flow into primary </li></ul><ul><li>Only DR site had unexpected Internet access </li></ul><ul><ul><li>Even that was for limited sources, but still unexpected </li></ul></ul>Lesson #8: Cruft is so important we mention it twice
    25. 25. Case Study: “Surprise!” <ul><li>Ad hoc network support </li></ul><ul><li>Sudden addition of complete network to secure </li></ul><ul><li>M&A, or in this case, short-lived Expo network </li></ul><ul><li>Requires very rapid assessment </li></ul><ul><li>Continuous tracking during high visibility phase </li></ul><ul><ul><li>Until end of expo, or for M&A, integration into normal ops </li></ul></ul>
    26. 26. China Expo Center Topology
    27. 27. <ul><li>Weak Community String </li></ul>
    28. 28. Best Practice Checks Lesson #9: Computers are better at reading phone books than you are. Get over it.
    29. 29. Case Study: Managing daily change <ul><li>Business change requests come thick & fast </li></ul><ul><li>Security teams are asked to approve </li></ul><ul><li>No standard basis to approve </li></ul><ul><li>Can ’t position security team as “Dr No” </li></ul><ul><ul><li>Need clear, unequivocal reasons when rejecting changes </li></ul></ul><ul><li>Causes “the Carnac moment” </li></ul>
    30. 30. RTP Campus Network Map Sensitive servers DMZ Internet Cisco Campus
    31. 31. Client Connection Request <ul><li>Create Network Model </li></ul><ul><li>Input Vulnerability Data </li></ul><ul><li>Business need: Open </li></ul><ul><li>one Class C network :80 </li></ul>Inside Outside <ul><li>Connection exposes </li></ul><ul><li>32 vulnerabilities </li></ul>Downstream Effect? Exposes 7,549 Vulnerabilities
    32. 32. Client Connection Exposure <ul><li>Blue lines show open access paths to sensitive servers </li></ul><ul><li>Clearly shows the need for segmentation </li></ul>
    33. 33. Acceptable Risk Assessment Outside Inside <ul><li>Access is BLOCKED </li></ul><ul><li>No hosts vulnerable; nothing Leapfroggable </li></ul>
    34. 34. Automating network audit <ul><li>Before: </li></ul><ul><li>After: </li></ul><ul><ul><li>Map the entire global network environment </li></ul></ul><ul><ul><li>Audit access to sensitive locations </li></ul></ul><ul><ul><li>Correlate access rights and threat risk </li></ul></ul>
    35. 35. Полезно ! <ul><li>Видеозапись презентации http :// 2010 </li></ul><ul><li>The Security Content Automation Protocol (SCAP) </li></ul><ul><li>is a method for using specific standards to enable automated vulnerability management, measurement, and policy compliance evaluation </li></ul><ul><li>http :// index.html </li></ul><ul><li>The Security Content Automation Protocol (SCAP) combines a number of open standards that are used to enumerate software flaws and configuration issues related to security. </li></ul><ul><li>Cisco Proactive Automation of Change Execution (PACE) </li></ul><ul><li> index.html </li></ul>