Security Best Practices : Applying Defense-in-depth Strategy to Protect the NGI_PL

1. Security Best Practices:Applying Defense-in-depth Strategyto Protect the NGI_PL Bartlomiej Balcerek1, Gerard Frankowski2, Agnieszka Kwiecień1, Adam Smutnicki1, Marcin Teodorczyk1 1WCSS, 2PCSS CracowGridWorkshop 2011 Conference Cracow, 7 November, 2011

2. IT Security Threats Ubiquitous services = ubiquitous threats There are many assets to be stolen “General” – hosts as botnet members, processor time for computations etc. “Specific” – especially certain data, trust etc. Why PL-Grid may be especially in danger? Large amount of resources (ca. 15k CPUs, 215 TFlops, 2500TB of storage space The users operate on their research data The users (researchers) might not be sufficiently security aware A set of custom software has been developed The infrastructure is distributed and heterogeneous

3. Countermeasure: Defense-in-depth Defense-in-depth: many security measures on different layers, one complementing the others If one fails, the other may be able to stop the threat Drastically increases the cost of a successful attack Currently appreciated as actually the only (general) countermeasure against Advanced Persistent Threats How we have applied this approach in PL-Grid?

4. The Task Organization PL-Grid represents NGI_PL in EGI security activities Dedicated security working package created – Infrastructure Security Dedicated team: Security Center (SC) established with Security Coordinator as a Leader

5. Security Center Performs active and proactive actions preventing incidents, not only handling them Review the current security status of infrastructure Review the security level of new infrastructure elements Prepare and deploy suitable security policies and procedures Maintains Certificate Authority Now we will describe the SC tasks in more details

6. Procedures Configuration security requirements for local clusters Security validation of all deployed software Incident handling procedure compliant with EGI CSIRT Software vulnerability reporting procedure compliant with EGI CSIRT Unified email contact with the SC: security@helpdesk.plgrid.pl

7. Security is a process, not a state There is no such thing as secure system

8. Operational Actions A set of task performed on day-to-day basis (unlike other tasks) Extensiveinfrastructure monitoring Patching Vulnerabilitymitigation Incidents handling PL-Grid as a large project needs efficient monitoring tools Pakiti checks known CVE's Very close cooperation with other security groups EGI CSIRT (SC representatives) Pionier CERT (Polish NREN) EGI SVG Dedicated advanced security tools: ACARM-ng meta IDS/IPS (separatepresentationTuesday 17:00 Session 8) SARA – System for Automatic Reporting and Administration

9. SimpleCA Simple Certification Authority: Provide easy and quick way to obtain X.509 Certificate for grid users Dedicated presentation: "Making X.509 certificates simple to use in PL-Grid project" M. Teodorczyk and B. Balcerek Tuesday 17:15, Session 8 (16:15 - 17:30)

10. Penetration Testing The aim: check the system security in a real case scenario – a simulated attack Performed from the attacker's point of view – what a real attacker would do? Different scenarios possible (e.g. with different credentials) 2 main classes: Blackbox How a real attacker would do it No initial information about the system If a tester won't find a vulnerability, it doesn't mean that it doesn't exist If a tester can't go beyond some parts of the system, it doesn't mean that further parts of it are not vulnerable Strong human factor Whitebox Sometimescalled auditing The whole knowledge about the system, not to miss anything All parts of the system are checked Much more detailed checking than in blackbox, but requires more resources

11. Pentesing in NGI_PL Blackbox Find as much Grid machines as possible (using dedicated fingerprinting) Identify all services and their versions Find potentially vulnerable software Identifypotentialrisks At the end: dedicated report for each machine sent to the administrator The second run to check whether all has been patched Whitebox Check the configuration of the Linux system and grid services Dedicated scripts gathering information about all hosts from the infrastructure A very simple process from the administrator's point of view Analysisdone by the SC Almost fully automated process At the end: the detailed report with configuration „bugs” sent to the administrator This process can be used to verify site security status during certification process

12. Source Code Reviews Another, “whitebox” method for identifying security threats in the software In theory, allows to find all software security flaws... ...but it costs too much time, so the scope has to be limited Two methods for making source code reviews Automatic The tools are extremely fast, but: Will not detect bugs that are deeply hidden Will generate lots of false positives Manual Extremely reliable and... slow We usually combine both approaches (manual validation of tools output plus reading critical parts of the code) Performed for custom project software, but also for that used in PL-Grid About 20-30 bugs per custom developed modules Security bugs found in Liferay and Torque PBS

13. Additional Security Tools - SARA Aimed to provide extra protection layers SARA – System for Automatic Reporting and Administration Solution for inventory and static security control Combines information from NVD database with data about the infrastructure Uses CVE database, CPE and CVSS formats Was presented on CGW '2010, so no dedicated presentation this year

14. What Still Could Be Improved? The project resources are limited, we could not afford for everything we wanted To complete the proposed model, the following new items ( ) could be introduced: • On-demand securityconsultancy service • Detailed securitydesign assessments • Security trainings forthe project members • Security best practicesfor the users

15. Questions? Thank you for your attention!gerard.frankowski@man.poznan.pl adam.smutnicki@pwr.wroc.pl