Standards and Practices in Operational Security Yuri Demchenko, AIRG UvA <[e-mail]>

1
Standards and Practices in Operational Security
Yuri Demchenko, AIRG UvAltdemch_at_science.uva.nl
gt
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 177992000 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
• 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).

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.ht
  ml)
• 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 ISPs 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)

• 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 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/
• CSIRTs National, governmental, NRENs,
  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/fa
  q.html
• TF-CSIRT activities
• CHIHT - Clearinghouse of Incident Handling Tools
  - http//chiht.dfn-cert.de/
• TRANSITS Training for new CSIRTs (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.charter
  s/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

• lt!ELEMENT Incident (IncidentID, AlternativeID?,
  RelatedActivity?, Description, Contact,
  ReportTime, DetectTime?, StartTime?, EndTime?,
  EventData, Method, Expectation, Assessment,
  History?, AdditionalData)gt
• EventData Element where the Grid Security
  Incidents data can be placed in
• lt!ELEMENT EventData (Description, Contact,
  ReportTime?, DetectTime?, StartTime?, EndTime?,
  System, Method, EventData, Expectation?,
  Assessment?, History?, Record?, AdditionalData)gt
• RecordData Element
• lt!ELEMENT RecordData (Description, DateTime?,
  Analyzer?, RecordItem?, Pattern?,
  PatternLocation, Counter?)gt

22
Principal Element - draft

• lt!ELEMENT Principal (uid?, Name?, Credentials,
  Attribute)gt
• lt!ELEMENT Credentials (uid?, Name?, Certificate,
  AdditionalData)gt
• lt!ELEMENT Certificate (CertIssuer?, CertData?,
  CRL?)gt

23
XMLWeb Service Element

• lt!ELEMENT System (Node, Service, Principal,
  XMLWebService)gt
• lt!ELEMENT XMLWebService (url, PortType?, wsdl?,
  Binding?, MessagePart)gt

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

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 organisations Security Policy
• Availability of information and ordered list of
  information being considered for release both
  personal and vendors
• 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.h
  tml
• 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
• lt!ELEMENT Incident (IncidentID, AlternativeID?,
  RelatedActivity?, Description, Contact,
  ReportTime, DetectTime?, StartTime?, EndTime?,
  EventData, Method, Expectation, Assessment,
  History?, AdditionalData)gt

38

• EventData where the Grid Security Incidents data
  can be placed
• lt!ELEMENT EventData (Description, Contact,
  ReportTime?, DetectTime?, StartTime?, EndTime?,
  System, Method, EventData, Expectation?,
  Assessment?, History?, Record?, AdditionalData)gt

39
RecordData Element

• lt!ELEMENT RecordData (Description, DateTime?,
  Analyzer?, RecordItem?, Pattern?,
  PatternLocation, Counter?)gt