standards and practices in operational security yuri demchenko, airg uva

EGEE is a project funded by the European Union under contract IST-2003-508833

Standards and Practices in Operational Security

Yuri Demchenko, AIRG UvA<[email protected]>

GGF12 OpSec Workshop September 20, 2004

www.eu-egee.org

GGF12 OpSec Workshop September 20, 2004 - 2

Outlines

• Standards and practices

• CSIRT community and projects

• Grid Security Incident definition and description format

• Summary

Format: Short overview and extensive additional material


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


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


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)


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

1. Establishing organizational security policy2. Organizational security infrastructure3. Asset classification and control4. Personnel security5. Physical and environmental security6. Communications and operations management7. Access control8. Systems development and maintenance9. Business continuity management10. Legal Compliance

• ISO17799 provides a basis for different audit checklists, risk analysis methodologies, compliant security policies

• Additional: BS 7799-2: 2002 - Specification for Information Security Management Systems (ISMS).


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,


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


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


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


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)


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.


EGEE JRA3.5 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


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


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.


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


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


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


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


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


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?)>


Principal Element - draft

<!ELEMENT Principal (uid?, Name?, Credentials+, Attribute+)>

<!ELEMENT Credentials (uid?, Name?, Certificate+, AdditionalData*)>

<!ELEMENT Certificate (CertIssuer?, CertData?, CRL?)>


XMLWeb Service Element

<!ELEMENT System (Node, Service*, Principal*, XMLWebService*)>

<!ELEMENT XMLWebService (url, PortType?, wsdl?, Binding?, MessagePart*)>


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


Appendix

• ISO/IEC Security Standards

• IETF Security RFC summary

• NIST CSRC Security Publications

• Incident Response components

• GSInc datamodel components


ISO/IEC JTC1 SC27 Security Standards

ISO/IEC 17799-1 – Code of Practice for Information Security Management

Revision in progress; Part-2 being justified.

ISO/IEC 13335 – Management of ICT Security From guidelines to standards – draft status

ISO/IEC 15408 – Common Criteria New parts being drafted

ISO/IEC 15443 – Framework for IT Security Assurance New extension to 14508

ISO/IEC 18028 – IT Network Security From Guideline to Standards

ISO/IEC 18043 – Guidelines for Implementation, Operation, and Management of IDS

New addition to 18028

ISO/IEC 18044 – Information Security Incident Management New addition to 18028

ISO/IEC 18045 – Methodology for IT Security Evaluation New addition to 15408

ISO/IEC 19791 – Security Assessment of Operational Systems New addition to 15408

ISO/IEC 19792 – Framework for Security Evaluation & Testing of Biometric Technology

Collaboration with SC17


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 Archiving The 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.


NIST Computer Security Resource Center (CSRC)

Relevant NIST CSRC publications 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


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


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.


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


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


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


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


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.


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


IODEF top level elements

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


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*)>


RecordData Element

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

standards and practices in operational security yuri demchenko, airg uva

Documents

security research

security institute http

area of operational

us afctrace security

incident handlingstandards

isaca http

incident response procedures

recommendationscertcc