Enterprise Class Vulnerability Management Like A Boss
- 1. Enterprise Class Vulnerability Management Like A Boss Rockie Brockway Business Risk Director Black Box Network Services
- 2. Bio 23 Year veteran in InfoSec/Risk All certs have expired (including those I’ve taught) Business Systems and Impact Analyst (Risk) Enterprise Security Architect Penetration/Red Team Tester Speaker/Trainer/BSidesCLE Musician/Woodworker/Landscaper/Hacker rockie.brockway@blackbox.com https://www.linkedin.com/pub/rockie-brockway/9/634/641 @rockiebrockway
- 4. The Compliance Conundrum Sure are lots of them Sure are a lot of tools that map out overlaps Many are focused on protecting certain data types Others are best practice frameworks But at the end of the day …
- 5. Information is Beautiful Breach Business Impact Continues to Grow http://www.informationisbeautiful.net/visualizations/worlds-biggest-data-breaches-hacks/
- 6. IT Spend vs. Breaches IT/InfoSec spend increasing, breaches continue to increase As an Industry we are most likely at least two years behind the innovative and lucrative industry of stealing the data we are trying to protect Gartner Verizon DBIR 2.9 3 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 2007 2008 2009 2010 2011 2012 2013 2014 Spend (T) 0 500 1000 1500 2000 2500 2007 2008 2009 2010 2011 2012 2013 2014 Breaches
- 7. Project and/or Compliance = Incorrect Breach Business Impact Continues to Grow Reasons: While most orgs understand data protection is a crucial strategic business issue, they continue to approach it on either • A project by project basis and/or • From a Compliance perspective The reality is that data security inherently relates to financial business risk and must be treated as a function of the business itself
- 8. Complexity in the Enterprise From the Enterprise to the Application, more complexity means less security Simple, individual projects do not need “Architecture” “Architecture” is required to successfully fit an individual project into a larger, more complex set of projects
- 9. Organizing Complexity Through Architecture The SABSA Information Systems Architecture paper lays out the following (paraphrasing): Like the design of buildings and cities, information architecture must take into consideration: • Organizational goals to be achieved by the systems • The environment where the systems will be built and used • The technical capabilities required to build and operate the systems
- 10. Enterprise Security Architecture Benefits of Enterprise Security Architecture • Brings focus to the key areas of concern for the business • Allows business owners to make educated security/risk decisions without having to be an infosec professional • Enables disparate Enterprise Security groups to understand their role in the business • METRICS! • Encourages repeatable processes • Organizes your Enterprise’s complexity • Focuses on Security, not Compliance (but still maps to compliance, we still have auditors :P) • Reduce the likelihood your organization will contribute to informationisbeatiful.net
- 11. Enterprise Security Architecture Security inherently relates to business risk and must be treated as a board supported function of the business Enterprise Security Architecture aligns organizational business strategy and goals with the protection of the organization’s business critical data
- 12. Process Vulnerability Management The set of all processes for discovering, reporting and mitigating known vulnerabilities at any layer Vulnerability Management is typically broken down into Intelligence/Patching activities and Scanning activities It is critical to have vulnerability accountability and ownership throughout the enterprise, with the associated metrics
- 13. Process Vulnerability Management Challenges • Moore’s Law – Malware evolves at equal speed • Reactionary – In order for vulnerability scanning tools to be effective, they must already know about the vulnerability • Intelligence – Having knowledge of the latest attacks and trends and if/how they affect your assets is crucial • Communication – Effectively transferring the knowledge of vulnerability data to the service owners • Accountability – Ensuring that the discovered vulnerabilities are remediated/mitigated and communicated back out to the service owners • Metrics – IS needs to be able to communicate the value of the vulnerability management program back to the business
- 14. Process Vulnerability Management Goals • Improved intelligence for quicker decision making and response • Buy in from all service owner/stakeholders • All primary asset types being regularly scanned • Servers • Web Applications • Network assets • User endpoints • Network enabled printers/UPS/NAS/etc. • Integration of existing Vulnerability Management tools with existing business ticketing systems • Service Owner and Stakeholder reporting with associated metrics
- 15. Inspiration OWASP Application Security Verification Standard (ASVS) 2014 http://www.irongeek.com/i.php?page=videos/bsidescolumbus2015/defense0 0-got-software-need-a-security-test-plan-got-you-covered-bill-sempf
- 16. Inspiration OWASP Application Security Verification Standard (ASVS) 2014 Level 0 Cursory – Indicates that some type of organizationally defined review has been performed on the application, and that the verification requirements were not provided by ASVS
- 17. Inspiration OWASP Application Security Verification Standard (ASVS) 2014 Level 1 (ASVS L1) Opportunistic – Indicates that the application can adequately defend itself against application security vulnerabilities that are easy to discover Such vulnerabilities are typically discovered with minimal to low effort, and cannot be considered a thorough inspection of the application Threats to the application will most likely come from attackers using simple techniques and automated tools
- 18. Inspiration OWASP Application Security Verification Standard (ASVS) 2014 Level 2 (ASVS L2) Standard – Indicates that the application can adequately defend itself against prevalent application security vulnerabilities of moderate to serious risk Such vulnerabilities include the OWASP Top 10 and Business Logic vulnerabilities The majority of business applications should work towards this level Threats to the application will most likely come from opportunistic attackers, and possibly some motivated actors
- 19. Inspiration OWASP Application Security Verification Standard (ASVS) 2014 Level 3 (ASVS L3) Advanced – Indicates that the application can adequately defend itself against all advanced application security vulnerabilities and shows principles of good security design Level 3 requires an inspection of an application’s design Level 3 is appropriate for critical applications that protect life, critical infrastructure and/or defense functions Threats to the application will be from motivated actors and nation-states
- 20. Inspiration We can build on and improve this
- 21. Application Applying ASVS 2014 to Vulnerability Management Level 0 (ASVS Vuln L0) Cursory – Indicates that some type of organizationally defined vulnerability analysis has been performed on the organization’s application space, and that the verification requirements were not provided by this hybrid framework • Org understands vulnerabilities should be patched • May have some loose patching process • Not using vulnerability scanning tools
- 22. Application Applying ASVS 2014 to Vulnerability Management Level 1 (ASVS Vuln L1) Opportunistic – Indicates that the organization can adequately defend itself against application security vulnerabilities that are easy to discover Such vulnerabilities are typically discovered with minimal to low effort, and cannot be considered a thorough inspection of the applications Threats to the application will most likely come from attackers using simple techniques and automated tools
- 23. Application Applying ASVS 2014 to Vulnerability Management Level 1 (ASVS Vuln L1) • No dedicated Infosec/Risk group • Reliance on MS patch Tuesday alerts • Process in place for monthly MS patches on user workstations and servers within a reasonable time frame (~45 days) • User workstation non-MS applications based on app alerts and user willingness (Java, Flash, etc.) • Sporadic additional “threat intelligence” (infoworld, the register, etc.) • May have an open source vulnerability scanning tools
- 24. Application Applying ASVS 2014 to Vulnerability Management Level 2 (ASVS Vuln L2) Standard – Indicates that the organization can adequately defend itself against prevalent application security vulnerabilities of moderate to serious risk Such vulnerabilities include the SANS Top 20 and OWASP Top 10 The majority of business applications should work towards this level Threats to the application will most likely come from opportunistic attackers, and possibly some motivated actors
- 25. Application Applying ASVS 2014 to Vulnerability Management Level 2 (ASVS Vuln L2) • Dedicated InfoSec/Risk group • Vulnerability Intelligence feed/subscriptions • Formal monthly review of previous 30 days worth of MS and non-MS known vulnerabilities • Centralized CMS for vulnerability intelligence data (probably manual, could be automated) • InfoSec/Risk group may manually enter vuln events into enterprise ticketing system • Defined standard for reviewing intelligence with escalation processes
- 26. Application Applying ASVS 2014 to Vulnerability Management Level 2 (ASVS Vuln L2) • Commercial/Open Source tools used for enterprise scanning • Standard for business asset scanning (off hours, no DOS, authenticated vs. unauthenticated, etc.) • Focused on primarily WIN/*NIX and network assets
- 27. Application Applying ASVS 2014 to Vulnerability Management Level 3 (ASVS Vuln L3) Advanced – Indicates that the organization can adequately defend itself against all advanced application security vulnerabilities and shows principles of good security design Level 3 requires inspections of in house application’s design and 3rd party risk standards Level 3 is appropriate for critical applications that protect life, critical infrastructure and/or defense functions Threats to the organization will be from motivated actors and nation-states
- 28. Application Applying ASVS 2014 to Vulnerability Management Level 3 (ASVS Vuln L3) • Vulnerability intelligence feeds tied to enterprise inventory systems • InfoSec/Risk team analyzes/flags intelligence alerts in CMS systems that auto-create tickets in enterprise ticketing system • Support teams work tickets as part of normal workflows • Sample sets of workstation vulnerability scans • Phones/Printers/UPS/NAS devices scanned • All scan reports are auto-posted to internal vulnerability management CMS • InfoSec/Risk team reviews scan reports and flags for ticket creation
- 29. Application Applying ASVS 2014 to Vulnerability Management Level 3 (ASVS Vuln L3) • Flagged scan reports trigger ticket auto- creation in enterprise ticketing system • Support teams work on tickets as part of normal workflows • Stakeholder and service owner reporting Also …
- 30. Metrics!!!
- 31. Metrics!!! Vulnerability Management Metrics Accurate Asset Inventory Scan Periods • How often are assets scanned? • Internal servers • DMZ servers • Public Facing servers • User endpoints • Network infrastructure • Network enabled printers/UPS/NAS/etc
- 32. Metrics!!! Vulnerability Management Metrics Scope of Scan • Discovery • Unauthenticated • Authenticated with User credentials • Authenticated with Admin credentials Number and Types of Hosts Scanned • Percentages vs. entire asset population Number of Vulnerabilities Discovered • Critical • High • Moderate • Low
- 33. Metrics!!! Vulnerability Management Metrics Vulnerabilities by Status • New • Active • Reopened • Verified • Excepted • Pending Remediation • Fixed
- 34. Metrics!!! Vulnerability Management Metrics Time to Remediation
- 35. Examples
- 36. Examples
- 37. Examples
- 38. Examples
- 39. Examples
- 40. Examples
- 41. Examples
- 42. Examples
- 43. Wrap Up ASVS/Vulnerability Management Application Gains Security Focused, business aligned ESA element Implementable Framework Based on Business Need L3 CMS/Ticketing Integration Vulnerability Ownership and Accountability Metrics
- 44. Q&A and References ARCTEC PAPER http://www.arctecgroup.net/pdf/ArctecSecurityArchitectureBlueprint.pdf Application Security Verification Standard 2014 https://www.owasp.org/images/5/58/OWASP_ASVS_Version_2.pdf Contact: rockie.brockway@blackbox.com @rockiebrockway
Editor's Notes
- #4: Gunnar Peterson, then of ARCTEC, wrote this document in 2006/2007. This framework is still absolutely valid today and will be used as the core of this refresher talk
- #7: This absolutely tells me that we are investing in the wrong areas.
- #8: What do the security nerds always say? “if you’re compliant, you’re not secure, but if you’re secure you will also be compliant”
- #9: Infosec folk will always preach that the more complex a system is the less secure it inherently is. And while simple projects do not typically require architecture, it is required in more complex environments
- #10: Just like your typical definition of architecture: What are the goals? What is the environment where it will be built? What is required to build it?
- #12: This ESA framework is Peterson’s from the 2007 ARCTEC paper Security is a function of the business Typically treated on project by project basis or from compliance perspective Must align business goals with protection of business critical data
- #13: NOT threat management – vulnerabilities are just gaps that can be exploited, nothing about actor, etc.
- #14: NOT threat management – vulnerabilities are just gaps that can be exploited, nothing about actor, etc.
- #15: NOT threat management – vulnerabilities are just gaps that can be exploited, nothing about actor, etc.
- #16: I got introduced to ASVS in January 2015 at Bill Sempf’s BSidesColumbus talk ASVS replaces OWASP top 20 as a framework that can actually be implemented
- #17: ASVS replaces OWASP top 20 as a framework that can actually be implemented
- #18: ASVS replaces OWASP top 20 as a framework that can actually be implemented
- #19: ASVS replaces OWASP top 10 as a framework that can actually be implemented
- #20: ASVS replaces OWASP top 20 as a framework that can actually be implemented
- #21: ASVS replaces OWASP top 20 as a framework that can actually be implemented
- #22: So, applying ASVS to vulnerability management
- #23: ASVS replaces OWASP top 20 as a framework that can actually be implemented
- #24: I think that’s reasonable
- #25: ASVS replaces OWASP top 20 as a framework that can actually be implemented
- #26: Defined standard – remote, unauthorized code execution, escalation of privs = escalation PATCH NOW!
- #27: Defined standard – remote, unauthorized code execution, escalation of privs = escalation PATCH NOW!
- #28: ASVS replaces OWASP top 20 as a framework that can actually be implemented
- #29: ASVS replaces OWASP top 20 as a framework that can actually be implemented
- #30: You know what else is included in level 3? …
- #31: ASVS replaces OWASP top 20 as a framework that can actually be implemented
- #32: ASVS replaces OWASP top 20 as a framework that can actually be implemented
- #33: ASVS replaces OWASP top 20 as a framework that can actually be implemented
- #34: ASVS replaces OWASP top 20 as a framework that can actually be implemented
- #35: ASVS replaces OWASP top 20 as a framework that can actually be implemented
- #36: Typical L1/2 assistance
- #37: L2 intelligence alerts
- #38: L2 CMS
- #39: L2 vuln scanner
- #40: L2 vuln scanner
- #41: L2 vuln scanner
- #42: L2 vuln scanner
- #43: L2 vuln scanner
- #44: Final thoughts