1. VULNERABILITY MANAGEMENT Moving Away from the Compliance Checkbox Towards Continuous Discovery

2.  Derek Thomas  Security Consultant  VM, SSO/AM, SIEM  Active in local INFOSEC groups  Misec  OWASP  ISSA

3. Common Problems What are Vulnerabilities Objectives of Vulnerability Management Program Approach Questions 5 5 4 4 3 3 2 2 1 1

4. Limited Scope External Network Centric Unauthenticated Scans Infrequent Assessments Compliance Driven Common Themes

5. Insider Environmental Target Mobile Devices Malware Hackivist Improper Configs

6.  Regulations are setting the standard  Example: NERC CIP  Requires R8. Cyber Vulnerability Assessment “A review to verify that only ports and services required for operation of the Cyber Assets within the Electronic Security Perimeter are enabled”  A simple network command like “Netstat” would satisfy this generic requirement http://www.nerc.com/files/CIP-007-1.pdf

7. When your goal is meeting a minimum standard you run the risk of missing valuable insight into the security posture of many aspects of your organization

8. Patch Management Outdated software exists on newer assets and assets not on the domain. Change Management Ineffective Change Management allows for rogue servers to appear on network Security Monitoring Detection is slow, tedious, or non-existent because there are an overabundance of false positives Incident Response Data breach has lead to costly damages

9. Lightside Darkside Minimum Requirements Minimal Insight Vulnerabilities Exploits Suffering

10.  Follow a defined lifecycle  Proactively identify vulnerabilities  Technical  Process  Evaluate effectiveness with testing

11. What’s the first thing that comes to your mind when you think of a vulnerability?  Outdated software and insecure configurations is often the answer  Non-technical vulnerabilities exist in security processes as well  Understanding how each can be addressed is the key to a successful program

12. Confidentiality Integrity Availability

13.  Security controls can fall into 3 categories Prevention DetectionCorrection

14.  Incident Reduction  Risk Reduction  Minimize threat vectors  Risk Reporting  Tracking

15.  Define a Plan  Assign Responsibilities  Define Scope  Define Critical Controls  Utilize a Sustainable Lifecycle  Strive for Predictable and Repeatable Results

16. Name John Doe Penetration Testing Vulnerability Management Name Jenny Smith Patch Engineer Name Jane Doe Manages VM team Coordinates remediation VM Project Lead Assign roles and responsibilities Who is responsible for what Most roles are already suited for a particular person Patch Management Lead Red Team

17.  What is going to be managed?  Start with discovery scans  Incorporate as many assets as possible  Security controls should be added as well In Scope Out of Scope Critical Servers Medical Devices Firewall X Application Y

18.  Vulnerabilities exist in controls  What controls should be added  SANS Top 20 Critical Controls

19. Test Find Fix 1.Find Proactively search for weaknesses within the scope 2.Fix Remediate known vulnerabilities 3.Test Verify vulnerabilities have been remediated

20.  How are vulnerabilities found?  2 basic approaches:  Automated  (Semi)Manual  Many tasks can be automated  Manual assessments still need to be performed

21.  Automated tool performs the heavy lifting  The most famous is the vulnerability scanner  7 out of 20 SANS Critical Controls can be automated in some way with a vulnerability tool  Another 8 can be automated using additional tools  Automate as much as possible to save time for the fun

22.  Remaining security controls can be manually tested  Controls can be tested through various Red Team exercises  The Red Team simulates attacks from a malicious party  Incident Detection  Incident Response  People

23.  How are vulnerabilities going to be fixed  Present data in actionable form  6000 page.pdf is not very actionable  Generate patch reports for patch management team  Reports filtered for server IP’s can be sent to the server team

24.  Easier said then done  Use built in tools if possible  Need buy in from application, system, and network team  Without buy-in remediation becomes difficult

25.  Verification of remediation efforts  Verify that patches have been applied  Ideally right after application  Can also be performed next scan interval

26.  Once the program has reached a mature level the results shouldn’t be surprising  The processes will mature to the point that you can accurately predict the outcomes  Patches will be applied on time  Malware will be detected and cleaned  assets will be introduced with secure configurations

27.  Vulnerability Management needs to be assessed  Metrics can gauge your improvement  NIST SP 800-40 provides excellent metrics

28.  Host Susceptibility to Attack  Number of patches, vulnerabilities, or network services per computer  Vulnerability Mitigation Response Time  Response time for vulnerability identification, patch application, or configuration change  VM Program Cost  Cost of Vulnerability Management group, support, or tools

29. NIST SP 800-40

30.  3 minimum  8 maximum NIST SP 800-40

31.  Approach VM as a continuous lifecycle  Move beyond minimum standards to enhance visibility and insight into the current state of security  Clear objectives and proper approach is fundamental to VM