JRA3 - Incident Response Issues to decide on and next steps Yuri Demchenko <demch@science.uva.nl>

1. MWSG3 August 25, 2004 www.eu-egee.org JRA3 - Incident Response Issues to decide on and next stepsYuri Demchenko<demch@science.uva.nl> EGEE is a project funded by the European Union under contract IST-2003-508833

2. Outlines • Goals • Creating Incident Response Capability/Service in EGEE • Discussion • Grid Security Incident definition and description format • Suggestion on further work

3. Goal The goal of this presentation is to start discussion to define next steps in creating Incident Response Capability for EGEE • Discuss and decide on an organisational structure for IRC • How to proceed with organisation and implementation • Who will do this job/activity? • Define coordination and cooperation framework • Grid Security Incident description format (informational)

4. Suggestions from the last meeting • Inventory and Taxonomy – ongoing/done • Decide on organisational structure for EGEE Incident Response Capability/Infrastructure • Contact with GOC/ROC • Prepare 1st CSIRT Workshop for EGEE

5. Incident Response 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

6. Types of CSIRT • Security Group • Not formally a CSIRT but may be a first step to create a CSIRT • Normally emerges from NOT (Network Operation Team) • 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 – (vuln.) • Coordinating CSIRT • Coordinates wide range of Incident Response activities • Creates and maintains common Security and Incident Response policy • Publish Advisories, Warnings, Reports, Recommendations – (vuln.)

7. Subject for discussion -two possible scenarios/models • Scenario 1 – Coordinating CSIRT or Security Group • GOC/ROC – Security contacts • Cooperation – Network related Security Incidents • Outsourcing services – Large scale or critical Security Incidents • Scenario 2 – Central or Distributed CSIRT • GOC/ROC – local CSIRTs or shared-time CSIRT members • Cooperation – Network related Security Incidents • Outsourcing services – GOC/ROC and/or IRC

8. 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 is required • Outsourcing services (?) Discussion

9. IRC organisation in EGEE • [Currently left blank]

10. Grid Security Incident • Computer Security Incident – general definition • Any specifics of the Grid Security Incident? • Web Services threats analysis • To be extended with Grid/OGSI/OGSA threats analysis • Format for Grid Security Incident description

11. 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.

12. Incident – any specifics for Grid? • Grid Security Incident defintion • 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 • GSInc definition is a base for GSInc description format • What information must be collected and how to exchange and handle it

13. Web Services threats analysis (0) • Web Service interface (WSDL) probing • Brute force attack on XML parsing system • Malicious XML Content • External Reference attacks • SOAP/XML Protocol attacks • Underlying transport protocol attacks

14. Web Services threats analysis (1) • Web Service interface (WSDL) probing • WSDL describes the methods and parameters used to access a specific Web Services, and in this way exposes Web Service to possible attacks • Brute force attack on XML parsing system • XML parsing is a resource and time consuming process. Maliciously constructed XML files may overload XML parsing system • Malicious XML Content • XML documents may contain malicious parsing or processing instructions (XML Schema extensions, XPath or XQuery instructions, XSLT instructions, etc) that may alter XML parsing process • Malicious content that may carry threats to the back-end applications or hosting environment

15. Web Services threats analysis (2) • External Reference attacks • This group is based on the generic ability of XML to include references to external documents or data types. Poor configuration, or improper use of external resources can be readily exploited by hackers to create DoS scenarios or information theft. • SOAP/XML Protocol attacks • SOAP messaging infrastructure operates on top of network transport protocols, uses similar services for delivering and routing SOAP messages, and therefore can be susceptible to typical network/infrastructure based attacks like Denial of Service (DoS), replay or man-in-the-middle attacks. • Underlying transport protocol attacks • These are actually not related to XML Web Services but directly affecting reliability of SOAP communications.

16. Grid Security Incident vs Grid Security Event • Security Incident is a result of successful attempt • Attempt generates security event • Examples of Grid specific security events • few sequent failed logins – far too common event everywhere • What is the threshold? • SOAP port scanning • HTTPS DoS attack – is it related to Grid? • patterns of suspected private key compromise • patterns of suspected AuthN/AuthZ security tokens compromise • attempt to access sensitive information • credit limit probing • Event is an issue for Intrusion Detection – Incident is an issue for Incident Response

17. Types of GSInc and audit events (1) Private key compromise • patterns of key usage • broken chain of PKC/keys/credentials • copy is discovered in not a proper place Audit/log events together with related data are also referred to as an Evidence

18. Types of GSInc and audit events (2) • Other/general credentials compromise • patterns of credential usage • broken chain of PKC/keys/credentials • copy is discovered in not a proper place • originated not from default location • sequent fault attempt to request action(s) • PDP/PEP logging/audit • Remaining problems • How to define at the early stage that a private key has been compromised? • Any external experience? • May require credentials storing (not caching) and adding history/evidence chain to credentials format • X.509 credentials are not capable of this

19. Types of GSInc and audit events (3) • Attempt to access sensitive data/information with lower level of privileges • Access log • Etc. • Credit limit on resource exhausted • Few unsuccessful attempts to run actions with unmatched credit

20. GSInc description format • Can be based on IODEF currently being developed by IETF INCH WG - http://www.ietf.org/html.charters/inch-charter.html • Top level element – Incident • Incident data in EventData element - Incident/EventData • Elements extended or added • EventData/Record/RecordData - extended • EventData/System/XMLWebService - new • EventData/System/Principal - new

21. IODEF top level elements

22. EventData where the Grid Security Incidents data can be placed

23. Principal Element - draft

24. XMLWeb Service Element

25. RecordData Element

26. Summary – next steps • Decision on EGEE IRC organisational structure • Contact with GOC/ROC • Contacting CSIRT community - Coordination is essential • Continue on GSInc definition and format, providing also requirements to logging

27. Additional information

28. 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/EGEE? • 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

29. 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

30. Incident Response Procedures Should be documented in full or in critical parts • Initial Incident Reporting and Assessment • Progress Recording • Identification and Analysis • Notification – initial and in the progress • Escalation – by Incident type or service level • Containment • Evidence collection • Removal and Recovery

31. 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.