Standards and Practices in Operational Security Yuri Demchenko, AIRG UvA <demch@science.uva.nl>

1. GGF12 OpSec Workshop September 20, 2004 www.eu-egee.org Standards and Practices in Operational Security Yuri Demchenko, AIRG UvA<demch@science.uva.nl> EGEE is a project funded by the European Union under contract IST-2003-508833

2. Outlines • Standards and practices • CSIRT community and projects • Grid Security Incident definition and description format • Summary Format: Short overview and extensive additional material

3. Goal The goal of this presentation is to provide a short overview of existing standards and practices in the area of Operational security and Security Incident Response • Reference information - for future developers • CSIRT communities and projects information – for possible cooperation • Grid Security Incident definition and description format - for further discussion and contribution

4. Standards and Practices • Incident Response and Incident Handling • Standards and Recommendations on Incident Response procedures and CSIRT operation • IETF, NIST, OGSF, OASIS • Security risk management • ISO, NIST, ISACA • 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 Incident • Incident Response practices • CERT/CC Recommendations and Advisories • Trusted Introducer (TERENA/TF-CSIRT) CSIRT certification procedure

5. Standardisation bodies • ISO/IEC - Wide scope of coverage, focusing on standardization, more general framework. 17799-1 and 13335 most relevant • IETF – Focuses on Internet related technical Security requirements • NIST-CSRC (http://www.nist.gov/) – Wide scope of coverage for both government and enterprise needs. Many relevant documents that can be leveraged • OASIS (http://www.oasis-open.org/) - Application Vulnerability Description Language (AVDL) • OGSF (Open Group Security Forum, http://www.opengroup.org/security/) - specifications, tools, guidelines and best practices for businesses, responsibilities, liabilities and trust relationships; started Intrusion Attack and Response Workshop Best practices and recommendations • CERT/CC (http://www.cert.org/) – a center of Internet security expertise; recommendations, advisories, practices, research • SANS (System Administration, Networking, and Security) Institute –http://www.sans.org/, focuses on SysAdmin, Audit, Network, and Security research and education. • ISACA (http://www.isaca.org/) – Most noted for CoBIT, provides a comprehensive framework for IT Governance, including security • ISSA (http://www.issa.org/) – comprehensive coverage of security issues and solutions for InfoSec practitioners, GAISP (Generally Accepted Information Security Principles)

6. ISO/IEC 17799:2000 – Code of Practice for Information Security Management • High level, general description of the areas considered important when initiating, implementing or maintaining information security in an organization • Establishing organizational security policy • Organizational security infrastructure • Asset classification and control • Personnel security • Physical and environmental security • Communications and operations management • Access control • Systems development and maintenance • Business continuity management • Legal Compliance • ISO17799provides a basis for different audit checklists, risk analysis methodologies, compliant security policies • Additional: BS 7799-2: 2002 - Specification for Information Security Management Systems (ISMS).

7. IETF Working Groups and documents • GRIP (concluded) - Guidelines and Recommendations for Security Incident Processing • IDMEF (concluded) – Intrusion Detection Message Exchange Format • INCH – Extended Incident Handling WG (http://www.ietf.org/html.charters/inch-charter.html) • IODEF and RID development • OPSEC - Operational Security Requirements (OPSEC) Working Group • Requirements to secure deployment and operation of managed network elements at OSI layers 2 and 3; targets ISP’s and vendors • RFC 3552 - Guidelines for Writing RFC Text on Security Considerations • Discusses Internet threat model, including active and passive attacks, DoS,

8. Incident Response and Operational Security Product of GRIP WG • RFC 2196 - Site Security Handbook (replacing RFC1244) • RFC 2350 - Expectation for Security Incident Response Teams • RFC 2505 - Users' Security Handbook • RFC 3013 - Recommended Internet Service Provider Security Services and Procedures • RFC 3227 - Guidelines for Evidence Collection and Archiving • RFC 2828 - Internet Security Glossary

9. Incident Response Components(according to RFC 2350) • CSIRT’s • 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 – provides templates for Incident Response Policy and other documents

10. CSIRT Community and Projects • CSIRT community • Incident Response infrastructure is based on mutual trust and established channels • New developments via projects and community initiatives • FIRST – Forum for Incident Response Teams • List of member CSIRT teams - http://www.first.org/team-info/ • TF-CSIRT – TERENA Task Force for CSIRT Coordination in Europe - http://www.terena.nl/tech/task-forces/tf-csirt/ • List of European CSIRTs - http://www.ti.terena.nl/teams/ • CSIRT’s: National, governmental, NREN’s, corporate, etc. • Designated point of contacts in case of Computer/Cyber Security Incident

11. TF-CSIRT • Services for CSIRTs • Trusted Introducer for CSIRTs in Europe - http://www.ti.terena.nl/ • IRT Object in the RIPE Database (ripe-254) - http://www.ripe.net/ripencc/pub-services/db/irt/faq.html • TF-CSIRT activities • CHIHT - Clearinghouse of Incident Handling Tools - http://chiht.dfn-cert.de/ • TRANSITS – Training for new CSIRT’s (supported by EU project) - http://www.ist-transits.org/ • IODEF – Initial definition and implementation (transferred to IETF INCH WG)

12. European Initiatives and Projects • European Network and Information Security Agency (ENISA) - http://www.enisa.eu.int/ • ENISA aims at ensuring particularly high levels of network and information security and will contribute to the development of a culture of network and information security within the Community • eCSIRT.net (European CSIRT Network) – http://www.ecsirt.net/ • Deployment of new techniques and practices to efficiently exchange incident related data, collect statistical information and cooperate in Incident prevention. Operational network of IDS sensors across Europe that allows collection of the data about attacks for further analysis. • TRANSITS (Training of Network Security Incident Teams Staff) • European project to promote the establishment of the new CSIRTs and the enhancement of existing CSIRTs by means of training. Extended training materials are created.

13. EGEE JRA3.4 documents • Framework for establishing Incident Response Capability • Joint document with OSG/JSG/LCG/EGEE • Dictionary of the Computer Security and Incident Response terms (more than 100 terms) • Grid Security Incident definition and exchange format

14. Grid Security Incident (GSInc) • Computer Security Incident – general definition • Any specifics of the Grid Security Incident? • Step (1): Web Services threats analysis • Step (2): To be extended with Grid/OGSI/OGSA threats analysis • Format for Grid Security Incident description • As an extension to the IODEF

15. Computer Security 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.

16. Incident – any specifics for Grid? • Grid Security Incident definition • 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 should be collected and how to exchange and handle it • Grid Security Incident vs Grid Security Event • Security Incident is a result of successful attempt • Attempt generates security event • Event is an issue for Intrusion Detection– Incident is an issue for Incident Response

17. Web Services threats analysis • 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

18. Types of GSInc and audit events (1) • Security credentials compromise (e.g., private key, proxy cred) • 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? • May require credentials storing (not caching) and adding history/evidence chain to credentials format • X.509 credentials are not capable of this • Note: Audit/log events together with related data can be also referred to as an Evidence

19. Types of GSInc and audit events (2) • 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 <!ELEMENT Incident (IncidentID, AlternativeID?, RelatedActivity?, Description*, Contact+, ReportTime, DetectTime?, StartTime?, EndTime?, EventData*, Method*, Expectation*, Assessment+, History?, AdditionalData*)> • EventData Element where the Grid Security Incidents data can be placed in <!ELEMENT EventData (Description*, Contact*, ReportTime?, DetectTime?, StartTime?, EndTime?, System*, Method*, EventData*, Expectation?, Assessment?, History?, Record?, AdditionalData*)> • RecordData Element <!ELEMENT RecordData (Description*, DateTime?, Analyzer?, RecordItem?, Pattern?, PatternLocation*, Counter?)>

22. Principal Element - draft <!ELEMENT Principal (uid?, Name?, Credentials+, Attribute+)> <!ELEMENT Credentials (uid?, Name?, Certificate+, AdditionalData*)> <!ELEMENT Certificate (CertIssuer?, CertData?, CRL?)>

23. XMLWeb Service Element <!ELEMENT System (Node, Service*, Principal*, XMLWebService*)> <!ELEMENT XMLWebService (url, PortType?, wsdl?, Binding?, MessagePart*)>

24. Summary • There is an extensive standard base for Operational Security • There is a well organised CSIRT community in Europe and in the world • Cooperation is inevitable and beneficial, however to make it effective the Grid community needs to understand its needs and specifics • Grid risks analysis and Grid Security Incident definition are important steps on this way • Ongoing EGEE developments • Continue on GSInc definition and format, providing also requirements to logging

25. Appendix • ISO/IEC Security Standards • IETF Security RFC summary • NIST CSRC Security Publications • Incident Response components • GSInc datamodel components

26. ISO/IEC JTC1 SC27 Security Standards

27. IETF Security RFC • RFC 2196. Site Security Handbook (replaces the now obsolete RFC1244)This handbook is a guide to setting computer security policies and procedures for sites that have systems on the Internet (however, the information provided should also be useful to sites not yet connected to the Internet).  This guide lists issues and factors that a site must consider when setting their own policies.  It makes a number of recommendations and provides discussions of relevant areas • RFC 2350. Expectation for Security Incident Response TeamsThis document describes the general Internet community's expectations of Computer Security Incident Response Teams (CSIRTs). It is not possible to define a set of requirements that would be appropriate for all teams, but it is possible and helpful to list and describe the general set of topics and issues which are of concern and interest to constituent communities • RFC2504. Users' Security HandbookThis document provides guidance to the end-users of computer systems and networks about what they can do to keep their data and communication private, and their systems and networks secure. Part Two of this document concerns "corporate users" in small, medium and large corporate and campus sites.  Part Three of the document addresses users who administer their own computers, such as home users. System and network administrators may wish to use this document as the foundation of a site-specific users' security guide; however, they should consult the Site Security Handbook first • RFC3013. Recommended Internet Service Provider Security Services and ProceduresThe purpose of this document is to express what the engineering community as represented by the IETF expects of Internet Service Providers (ISPs) with respect to security. It is not the intent of this document to define a set of requirements that would be appropriate for all ISPs, but rather to raise awareness among ISPs of the community's expectations, and to provide the community with a framework for discussion of security expectations with current and prospective service providers • RFC3227. Guidelines for Evidence Collection and ArchivingThe purpose of this document is to provide System Administrators with guidelines on the collection and archiving of evidence relevant to such a security incident. If evidence collection is done correctly, it is much more useful in apprehending the attacker, and stands a much greater chance of being admissible in the event of a prosecution.

28. NIST Computer Security Resource Center (CSRC) Relevant NIST CSRC publications (http://csrc.nist.gov/publications/nistpubs/) • Draft SP 800-66 - An Introductory Resource Guide for Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule – May 2004 • SP 800-61 - Computer Security Incident Handling Guide - January 2004 • SP 800-50 - Building an Information Technology Security Awareness and Training Program,October 2003 • SP 800-34 - Contingency Planning Guide for Information Technology Systems,June 2002 • SP 800-27 Rev. A -Engineering Principles for Information Technology Security (A Baseline for Achieving Security), Revision A,June 2004 • SP 800-64 - Security Considerations in the Information System Development Life Cycle,October 2003 • SP 800-30 - DRAFT Special Publication 800-30 Rev A, Risk Management Guide for Information Technology Systems • December 2003 - Security Considerations in the Information System Development Life Cycle

29. 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 • Different responsibilities • 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

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

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

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

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

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

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

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

37. IODEF top level elements <!ELEMENT Incident (IncidentID, AlternativeID?, RelatedActivity?, Description*, Contact+, ReportTime, DetectTime?, StartTime?, EndTime?, EventData*, Method*, Expectation*, Assessment+, History?, AdditionalData*)>

38. EventData where the Grid Security Incidents data can be placed <!ELEMENT EventData (Description*, Contact*, ReportTime?, DetectTime?, StartTime?, EndTime?, System*, Method*, EventData*, Expectation?, Assessment?, History?, Record?, AdditionalData*)>

39. RecordData Element <!ELEMENT RecordData (Description*, DateTime?, Analyzer?, RecordItem?, Pattern?, PatternLocation*, Counter?)>