1. Polska Infrastruktura Informatycznego Wspomagania Nauki w Europejskiej Przestrzeni Badawczej Security Best Practices: Applying Defense-in-depth Strategy to Protect the NGI_PL Bartlomiej Balcerek 1, Gerard Frankowski 2, Agnieszka Kwiecień 1, Adam Smutnicki 1, Marcin Teodorczyk 1 1 WCSS, 2 PCSS Cracow Grid Workshop 2011 Conference Cracow, 7 November, 2011

2. 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. 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. 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. 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. 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. 7 Security is a process, not a state There is no such thing as secure system

8. 8 Operational Actions  A set of task performed on day-to-day basis (unlike other tasks)  Extensive infrastructure monitoring  Patching  Vulnerability mitigation  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 (separate presentation Tuesday 17:00 Session 8)  SARA – System for Automatic Reporting and Administration

9. 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. 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 Sometimes called 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. 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  Identify potential risks  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  Analysis done 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. 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. 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. 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 security consultancy service  Detailed security design assessments  Security trainings for the project members  Security best practices for the users

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