Polska InfrastrukturaInformatycznego Wspomagania Naukiw Europejskiej Przestrzeni Badawczej

Security Best Practices:Applying Defense-in-depth Strategy

to Protect the NGI_PL

Bartlomiej Balcerek1, Gerard Frankowski2,Agnieszka Kwiecień1, Adam Smutnicki1,

Marcin Teodorczyk1

1WCSS, 2PCSS

Cracow Grid Workshop 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) 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

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

• 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

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

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 security consultancy service

Detailed security design assessments

Security trainings for the project members

Security best practices for the users

15

Questions?

Thank you for your attention!

gerard.frankowski@man.poznan.pl adam.smutnicki@pwr.wroc.pl