How to build a security assessment program Dan Boucaut
Agenda 1 Problem statement 2 Business case 3 How to avoid creating more problems
Problem statement Security assessments are hard, costly and may take down my systems
Is it worth it? Vulnerability management is considered a best practice defensive measure 1 You need to know your network and keep knowing it 2 Prioritise and manage your risk effectively, you can t change everything in a day Yes 3 Simplify your compliance and response effort Forum 2015 Dan Boucaut March 2015 Page 5
Why do it? OR Practice makes perfect 1 Changing vulnerability landscape 2 ASD top 4 3 Instead of risking patching lets play it safe by continuing into our slow decline of patched systems Forum 2015 Dan Boucaut March 2015 Page 6
Business case Benefits and ROI
Knowledge is power Vulnerability knowledge can be used widely it shouldn t be stuck into a report Patching priorities 1 5 Risk assessments SOC 2 6 NAC tools SIEM 3 7 Incident response tools Firewall rule analysis 4 Forum 2015 Dan Boucaut March 2015 Page 8
Implementation How to avoid creating more problems Petr Chrapavy
1 Risk Security assessments may take down my production systems
2 Mitigation Preparation, skills, planning, approvals, exceptions and communication
Risk vs reward: Can I avoid all risks? In vulnerability assessment scanning, preparation and planning can make the difference between an accurate and illuminating scan and a big IT headache* Risk free assessments and/or testing There is no such thing unless performed in a test LAB (on disposable equipment), completely isolated from any production or other sensitive systems Expected risk vs nasty surprise It is preferable to encounter issues during controlled conditions, as opposed to when attackers are testing the target systems at a time of their own choosing (especially on internet facing systems) *Source: Information Week s Dark Reading Forum 2015 Petr Chrapavy March 2015 Page 12
System resilience: Can anything fall over? A reasonably up to date, well configured, enterprise type device or software from a major vendor is not likely to crash during a non-aggressive vulnerability scan Low risk Medium to high risk High risk Common host Operating Systems Network switches Firewalls IPS appliances etc Outdated, unpatched systems Any system with limited hardware resources (low memory and processing power, e.g. embedded web servers) Some printers Note that during aggressive scans, connection entries in firewall state tables can get exhausted ICS / SCADA devices Custom designed hardware and software Many legacy systems (do not play with Nmap on AS/400 or a building management system) Forum 2015 Petr Chrapavy March 2015 Page 13
Risk mitigation: Preparation 1 2 3 4 5 6 7 8 Build a small test LAB (client PC, typical file and print sever, web sever, network switch, etc.) Designate sample devices in existing UAT or DEV environment Run scans in the LAB first, get to know the scanning tool(s) Gather information about known unstable systems Understand your network (firewall rules, IPS, rate limiting on network switches) Understand the differences of unauthenticated vs authenticated scan Start out with a small scope Small scope limits potential issues and helps all stakeholders to get used to the new process Forum 2015 Petr Chrapavy March 2015 Page 14
Risk mitigation: Skills No in-house skills? Call in the experts! If internal resources are available, ensure they have (or gain) some experience with scanners Many options: training courses, online videos, webinars, blogs, etc Ensure any hands-on learning is done in the test LAB Ensure staff have some understanding of the target systems (technical and business function) Forum 2015 Petr Chrapavy March 2015 Page 15
Risk mitigation: Skills Ensure network and host monitoring tools are deployed and actively monitored For a server farm, cluster or HA appliances, scan just one of the nodes 7 8 Skills 9 1 2 Develop test plan to scan UAT or DEV Segment scans into multiple jobs do not scan all at once Do not scan too many UDP ports (scan can go for hours, days or get stuck) 6 Repeat steps 1-7 above for production environment 3 Enable safe checks only option, where available Do not scan too wide port number ranges (1-65,000 can be a very bad idea) 5 4 Do not enable all signatures (Nessus has over 70,000 plugins) Forum 2015 Petr Chrapavy March 2015 Page 16
Risk mitigation: Approvals Incorporate test plans into change control processes Adhere to change control (e.g do not restart failed scan when the approved time-slot is almost over) Murphy s Law: This light scan never caused any issues, I ll just quickly run it outside of approved time = something WILL fall over Avoid critical times (EoFY processing, monthly pay run, etc) even if someone is happy to approve it Beware of time difference if targets are in multiple time-zones Beware of assets being hosted by a 3rd party their approval will be required Ensure system business owners have signed off the scans against their systems Ensure test plans and Change Control highlight that each scan poses some level of risk Forum 2015 Petr Chrapavy March 2015 Page 17
Risk mitigation: Exceptions 1 2 3 4 5 6 Some systems should not be scanned at all Common sense applies do not scan MRI Scan machines, PLCs on prison door locks Ensure these are documented as exceptions and are on company s Risk Register Manual, hands-off vulnerability assessment can be done (version can be checked against vulnerability database, passive network packet sniffing can identify traffic and therefore active services on the device) Do not remove the asset from the scanner, just make sure it is listed as an excluded target (there will be some exceptions) Some devices might not have any ethernet interfaces Forum 2015 Petr Chrapavy March 2015 Page 18
Risk mitigation: Communications Change control (again) Ensure everyone who has need-to-know does know, before the scans Ensure scan reports are being generated and delivered to relevant parties Communicate when issues are encountered as well if one of the targets goes down during a scan and nobody else notices (they should ) let the operations team know Vulnerability scans can cause issues, however on many occasions they have also discovered some underlying, non-security related problems well before the system owners noticed them Accountability do not use a shared login credentials for scanner management Forum 2015 Petr Chrapavy March 2015 Page 19
3 Secure the scanner and reports It more or less contains instructions on how to compromise your systems
Thank you