1. EGEE is a project funded by the European Union under contract IST-2003-508833 JRA3 - Incident Response General Issues Yuri Demchenko MWSG2 June 16, 2004 www.eu-egee.org

2. MWSG2, June 16, 2004 - 2 Outlines Goal and motivation Incidents and Incident Response – Definitions Creating Incident Response Capability/Service Incident Response in EGGE Possible steps - Discussion

3. MWSG2, June 16, 2004 - 3 Goal and Motivation The goal of this presentation is to introduce into and rise awareness about the Incident Response problem area How to create an Incident Response Capability? What to respond? What standards and practices to follow? What may be the first steps?

4. MWSG2, June 16, 2004 - 4 Incident Response – Definitions  Incident  Specifics of perceived Grid Incidents  Incident Response  Incident Response vs Intrusion Detection

5. MWSG2, June 16, 2004 - 5 Incident A computer/ITC security incident is defined as any real or suspected adverse event in relation to the security of a computer or computer network. Typical security incidents within the ITC area are: a computer intrusion, a denial-of- service attack, information theft or data manipulation, etc.  An incident can be defined as a single attack or a group of attacks that can be distinguished from other attacks by the method of attack, identity of attackers, victims, sites, objectives or timing, etc. An Incident in general is defined as a security event that involves a security violation. This may be an event that violates a security policy, UAP, laws and jurisdictions, etc.  A security incident may be logical, physical or organisational, for example a computer intrusion, loss of secrecy, information theft, fire or an alarm that doesn't work properly. A security incident may be caused on purpose or by accident. The latter may be if somebody forgets to lock a door or forgets to activate an access list in a router.

6. MWSG2, June 16, 2004 - 6 Incident – any specifics for Grid? Depends on the scope and range of the Security Policy, ULA, or SLA Should be based on threats analysis and vulnerabilities model Should be based on Grid processes/workflow analysis  Is there a definite model and clear vision of these processes?  LCG definition of the Grid Job/Task submission Job submission will normally progress from a User Interface (UI) machine, through a Resource Broker (RB) to a Computing Element (CE) and hence to the compute resource (usually a batch system). In some cases the RB is not used and the UI submits the job directly to the CE. Data access is through a Storage Element (SE) service Q: Should we distinguish between Incidents with the Grid applications and processes and those with the underlying infrastructure?  Who will handle either of them?

7. MWSG2, June 16, 2004 - 7 Grid risks and threats analysis LCG Risk Analysis – is a good starting point  http://proj-lcg-security.web.cern.ch/proj-lcg-security/RiskAnalysis/risk.html  Classified by Misuse, Confidentiality and Data integrity, Infrastructure disruption and Accidental categories Known analyses of Grid Security Incidents nature mostly focus on vulnerabilities of AuthN/Z and Certificate compromise  E.g., Dane Skow’s “A walk through a Grid Security Incident”  However, question remains: How to define at early stage that PKC compromised?

8. MWSG2, June 16, 2004 - 8 Incident response Incident response includes three major groups of actions/services Incident Triage  Assessing and verification incoming Incident Reports (IR) Incident Coordination  Categorisation Incident information, forwarding IR around and arranging interaction with other CSIRTs, ISPs and sites Incident Resolution  Helping a local site (victim) to recover from an incident - in most cases offered as optional services.

9. MWSG2, June 16, 2004 - 9 Incident Response and Intrusion Detection Intrusion Detection normally is a component of the network infrastructure/services  Intrusion Detection Systems (IDS) or Sensors are installed on or close to Firewalls, Routers, Switches or run as a special program on logfiles  ID produces alerts to prevent suspected activity escalation to Incident  ID is rather proactive service Incident Response is a complex of designated people, policies and procedures  Incident Response is a reactive function Q: Do we need to tackle Intrusion Detection in JRA3?  ID/Network protection is a responsibility of Network Operator or Team May be outsourced to network provider or hosting organisation  CSIRT often has an influence on network security policy and IDS policy/criteria

10. MWSG2, June 16, 2004 - 10 Incident Response Infrastructure/Components  CSIRTs Organisational form depends on type of organisation and required level of support to community  Security Policy Define what is required/allowed/acceptable  Incident Response Policy What is provided, who receives it and who provides support  Incident Response Plan Which incidents will be responded and how RFC 2350 – defines template for Incident Response Policy

11. MWSG2, June 16, 2004 - 11 Types of CSIRTs Security Group  Not formally a CSIRT but may be a first step to create a CSIRT Distributed (Internal) CSIRT  Has well defined constituency, central office and (minimum) designated staff  Most of staff is sharing responsibility or on duty  Maintains common Security and Incident Response policy  Publish Advisories, Warnings, Reports, Recommendations Coordinating CSIRT  Coordinates wide range of Incident Response activities  Creates and maintains common Security and Incident Response policy  Publish Advisories, Warnings, Reports, Recommendations

12. MWSG2, June 16, 2004 - 12 Incident Response Policy Types of Incidents and Level of Support  Ordered by severity list of Incident categories Co-operation, Interaction and Disclosure of Information  Based on organisation’s Security Policy  Availability of information and ordered list of information being considered for release both personal and vendor’s Communication and Authentication  Information protection during communication  Mutual authentication between communicating parties Also depending on information category

13. MWSG2, June 16, 2004 - 13 Incident Response Procedures Should be documented in full or in critical parts 1. Initial Incident Reporting and Assessment 2. Progress Recording 3. Identification and Analysis 4. Notification – initial and in the progress 5. Escalation – by Incident type or service level 6. Containment 7. Evidence collection 8. Removal and Recovery

14. MWSG2, June 16, 2004 - 14 Incident Response in EGEE Actual Incident Response will be done at GOC  By Security Groups or Internal/External CSIRTs Incident Coordination for EGEE  Coordinating Central or Distributed CSIRT servicing EGEE infrastructure To start this activity (1) Inventory and Taxonomy (2) Contacting GOC/sites and building awareness (3) Training and Education  First CSIRT Training workshop at 2 nd EGEE (or even around GGF12?) (4) Establishing central EGEE coordinating CSIRT  Staffing  Defining policies and procedures, formats and forms  Promoting and building network of contacts

15. MWSG2, June 16, 2004 - 15 What do we have? LCG documents for sites – good starting point and initial framework Organisation of security on LCG-1  To implement the LCG-1 security procedures and to respond to security incidents, each LCG-1 Regional Centre and each LCG-1 site must designate a security officer  Rem: Need to be structured according to common CSIRT practices LCG Security Policy specifies (not detailed)  Physical Security  Network Security  Access Control  Rem: Refers to site Policies but are they defined?

16. MWSG2, June 16, 2004 - 16 Standards and Practices Incident Response and Incident Handling  Standards and Recommendations on Incident Response procedures and CSIRT operation IETF, NIST, TI/TF-CSIRT (TERENA), CERT/CC Formats and Protocols  IDMEF – Intrusion Detection Message Exchange Format  IODEF – Incident Object Description and Exchange Format  Emerging RID – Real-time Internetwork Defense (supported by US AFC) Trace Security Incidents to the Source Stop or Mitigate the Effects of an Attack or Security Incident CSIRT community and CSIRT certification  Important component of creating world-wide Incident Response infrastructure

17. MWSG2, June 16, 2004 - 17 Tools Intrusion Detection automation  Snort with IDMEF support (by Silicon Defense) Benefits in simple integration, information exchange and easy outsourcing Implemented also by CERT/CC in their AirCERT distributed System Incident Handling  Mostly proprietary systems with growing move to standardisation of exchange format based on IODEF  IODEF Pilot implementation CERT/CC AirCERT Automated Incident Reporting - http://www.cert.org/kb/aircert/ and http://aircert.sourceforge.net/ JPCERT/CC: Internet Scan Data Acquisition System (ISDAS) - http://www.jpcert.or.jp/isdas/index-en.html eCSIRT.net: The European CSIRT Network - http://www.ecsirt.net

18. MWSG2, June 16, 2004 - 18 Summary – next steps Inventory and Taxonomy Contact with GOC/ROC Decide on organisational structure for EGEE Incident Response Capability/Infrastructure Prepare 1st CSIRT Workshop