JSG Meeting, October 4, 2004
www.eu-egee.org
Grid Security Incident
definition and format
Yuri Demchenko, AIRG UvA
<demch@science.uva.nl>
EGEE is a project funded by the European Union under contract IST-2003-508833
Outline
•
•
•
•
•
Background
Grid Security Incident definition
Proposed Incident Description Format
Summary and next steps
Additional information
Goal: Provide initial information and establish common
language/terminology as a basis for further cooperative development
JSG meeting October 4, 2004 - 2
Background EGEE JRA3.4 documents
• Framework for establishing Incident Response Capability
 Joint document with OSG/JSG/LCG/EGEE (presented by Bob
Cowles)
• Grid Security Incident definition and exchange format
 Ongoing development, current version presented as milestone
https://edms.cern.ch/document/501422/1
• Dictionary of the Computer Security and Incident Response
terms (more than 100 terms)
http://portals.ii.uib.no/EGEE-JRA3/Dev/Task5/Doc/IncResp/dictionary-security-incidentresponse-00.doc
JSG meeting October 4, 2004 - 3
Grid Security Incident (GSInc)
 Computer Security Incident – general definition
 Grid Security Incident - specifics
 Grid/OGSI/OGSA threats analysis
• Based on Web Services threats analysis
– Summary is provided at the end of this presentation
– Extended analysis is available in the JRA3.4 Milestone document
 Format for Grid Security Incident description
• As an extension to the IODEF (Incident Object Description and
Exchange Format) developed by IETF INCH WG
JSG meeting October 4, 2004 - 4
From Vulnerability to Incident
Vulnerability -> Exploit -> Threat -> Attack/Intrusion -> Incident
• Vulnerability is a flaw or weakness in a system's design,
implementation, or operation and management that could be exploited
to violate the system's security policy
• Exploit is a known way to take advantage of a specific software
vulnerability
• Threat is a potential for violation of security, which exists when there is
a circumstance, capability, action, or event that could breach security
and cause harm
• Attack is an assault on system security that derives from an intelligent
threat
• Incident is a result of successful Attack
JSG meeting October 4, 2004 - 5
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-ofservice 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.
JSG meeting October 4, 2004 - 6
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
• Requirements to Events logging and Intrusion detection
 Common format is a basis for community wide statistics and
coordinated response
 Incident statistics provides feedback for the Security Policy
improvement
JSG meeting October 4, 2004 - 7
Grid Security Incident vs
Grid Security Event
• Security Incident is a result of successful attempt/attack
 Attempt generates security event
• Examples of Grid specific security events
 Few sequent failed logins – far too common event everywhere
• What is the threshold?
 WSDL probing and SOAP port scanning
 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
JSG meeting October 4, 2004 - 8
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
JSG meeting October 4, 2004 - 9
Types of GSInc and audit events (2)
•
Attempt to access sensitive data/information with lower level of
privileges
 Access log, system log
•
Credit limit on resource exhausted
 Few unsuccessful attempts to run actions with unmatched credit
 Access log
• Web Services based Security Incidents
 Application server log
 Security services log
 Etc.
JSG meeting October 4, 2004 - 10
GSInc description format
• Can be based on IODEF currently being developed by IETF
INCH WG - http://www.ietf.org/html.charters/inch-charter.html
 XML based format compatible with IDMEF (for IDS)
 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
JSG meeting October 4, 2004 - 11
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?)>
JSG meeting October 4, 2004 - 12
Principal Element
<!ELEMENT Principal (uid?, Name?, Credentials+, Attribute+)>
<!ELEMENT Credentials (uid?, Name?, Certificate+, AdditionalData*)>
<!ELEMENT Certificate (CertIssuer?, CertData?, CRL?)>
JSG meeting October 4, 2004 - 13
XMLWebService Element
<!ELEMENT System (Node, Service*, Principal*, XMLWebService*)>
<!ELEMENT XMLWebService (url, PortType?, wsdl?, Binding?, MessagePart*)>
JSG meeting October 4, 2004 - 14
Summary and next steps
• Current Grid Security Incident definition provides a basis for
discussion and cooperation between software developers
and operational security teams
 Continue with Grid/OGSI/OGSA threats analysis
 Provide requirements for logging to most software modules
• Proposed GSInc description format based on IODEF can
provide a common Incident reporting format for OCST and
GOC’s/ROC’s
 Continue with GSInc format definition based on documented Grid
Security Incidents
• Need contribution from and cooperation with GOC’s/ROC’s
JSG meeting October 4, 2004 - 15
Additional information
•
•
•
•
Tools for Intrusion Detection and Incident Reporting
Top ten Web applications Vulnerabilities from OWASP
Web Services threats
IODEF top level elements datamodel
JSG meeting October 4, 2004 - 16
Tools for Intrusion Detection and
Incident Reporting
• 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
• More information - http://www.securityfocus.com/ids
• 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
JSG meeting October 4, 2004 - 17
Top ten Web applications
Vulnerabilities from OWASP
•
•
•
•
•
•
•
•
•
•
A1 - Unvalidated Input
A2 - Broken Access Control
A3 - Broken Authentication and Session Management
A4 - Cross Site Scripting (XSS) Flaws
A5 - Buffer Overflows
A6 - Injection Flaws
A7 - Improper Error Handling
A8 - Insecure Storage
A9 - Denial of Service
A10 - Insecure Configuration Management
Reference -http://www.owasp.org/documentation/topten.html
JSG meeting October 4, 2004 - 18
Web Services threats
•
•
•
•
•
•
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
Extended analysis is provided in the JRA3.4 Milestone
document - https://edms.cern.ch/document/501422/1
JSG meeting October 4, 2004 - 19
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
JSG meeting October 4, 2004 - 20
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.
JSG meeting October 4, 2004 - 21
IODEF top level elements
<!ELEMENT Incident (IncidentID,
AlternativeID?, RelatedActivity?,
Description*, Contact+, ReportTime,
DetectTime?, StartTime?, EndTime?,
EventData*, Method*, Expectation*,
Assessment+, History?,
AdditionalData*)>
JSG meeting October 4, 2004 - 22
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*)>
JSG meeting October 4, 2004 - 23
RecordData Element
<!ELEMENT RecordData (Description*, DateTime?,
Analyzer?, RecordItem?, Pattern?, PatternLocation*,
Counter?)>
JSG meeting October 4, 2004 - 24