Network Working Group Seak Internet Draft Cathy.Wang Intended status: Standards Track Antiy Labs Expires: June 2011 December 26, 2010 Detection Event Description Language (DEDL) draft-seak-malware-dedl-00.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html hThis Internet-Draft will expire on June 26, 2009. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Seak&Cathy Expires June 26, 2011 [Page 1] Internet-Draft Detection Event Description Language December 2010 Abstract This document describes the detection event description language (DEDL). DEDL is common standards languages proposed for describing the network security detection event, with which the network security event detection device can handle the detection result effectively. It describes the detection event in a standard format by using the descriptor and support general condition deduction. Table of Contents 1. Introduction................................................2 1.1. Requirements...........................................2 1.2. Goals..................................................3 1.3. The Role of DEDL on the Web............................3 2. DEDL Overview...............................................3 2.1. DEDL...................................................3 2.2. Detection Event........................................3 2.3. Detection Event Handling Rules.........................4 3. Detection Event.............................................4 3.1. Event Header...........................................4 3.2. Event Option...........................................5 3.3. Event Action...........................................7 4. Detection Event Handling Rule...............................8 4.1. Parallel Merge Rule (Parallel).........................8 4.2. Radiation Merge Rule (Radiation).......................8 4.3. Aggregation Merge Rule (Aggregation)...................9 4.4. Conduction Chain Merge Rule (Conduction)...............9 5. Security Considerations....................................10 6. IANA Considerations........................................10 7. References.................................................10 7.1. Normative References..................................10 7.2. Informative References................................10 8. Acknowledgments............................................10 1. Introduction 1.1. Requirements Worm incident has occupied the mainstream of network security incident. Network security incident detection equipments face serious flood records problems. In order to avoid the record flood effects and also show the relationship between detection records, network security event detection equipments need to merge the detection records according to the certain rules. Therefore, we need a Seak&Cathy Expires June 26, 2011 [Page 2] Internet-Draft Detection Event Description Language December 2010 description language which can well describe the detection event in a standard format and support general condition deduction. 1.2. Goals In order to meet the need of network security event detection devices in handling the detection records, DEDL has be proposed with the following ultimate goals in mind. Plain text displays Descript a almost network security event information Support general condition deduction Easily read by program and human Facilitate the process of the scientific statistics Scalability 1.3. The Role of DEDL on the Web DEDL can be used to describe the network security event, with which the network security event detection device can handle the detection result simply and effectively. 2. DEDL Overview 2.1. DEDL Detection Event Description Language (DEDL) is a simple, flexible description language. It describes the detection event in a standard format by using the descriptor and support general condition deduction. 2.2. Detection Event The detection events are written in DEDL can be divided in two logical sections, the event header and the event options. The event header contains the event's name, type, source IP, target IP, source port, target port, time, action, protocol. The event option section contains extension information which records the result after the conduction deduction. Figure 1 illustrates a sample detection event written in DEDL: Seak&Cathy Expires June 26, 2011 [Page 3] Internet-Draft Detection Event Description Language December 2010 +------------------------------------------------+ | | | Event | | | +------------------------------------------------+ Figure 1 Sample Detection Event Written in DEDL The text after the first and up to the first parenthesis is the event header and the section enclosed in parenthesis contains the event options. The words before the colons in the event's header section and options section are called keywords. 2.3. Detection Event Handling Rules In order to avoid the record flood effects, DEDL supports general condition deduction. Based on a well defined condition deduction rule set, the detection event written by DEDL can be merged and also retain the same relationship. 3. Detection Event 3.1. Event Header The event header section contains nine key elements of a detection event that reflects when, where, and what happened: 1. Name - the network security event name that were detected by the equipment. 1. Type - the type of detection event. 2. SIP - source IP address. Seak&Cathy Expires June 26, 2011 [Page 4] Internet-Draft Detection Event Description Language December 2010 3. TIP - target IP address. 4. SPort - source port. 5. TPort - target port. 6. Time - the time when event was detected. 7. Protocol - transfer protocol of the event. 8. Action - the action that causes the event was detected. The details about the action are specified in the section 3.3. 3.2. Event Option The event option section contains extension information which records the result after the conduction deduction. It is not specifically required by any detection event. They are just used for records the result when the event were merged with others based on a predefined condition deduction even rule set. Event options are separated from each other using the semicolon character. Event option keywords are separated from their arguments with a colon character. 1. Rule - the condition deduction rule that used to handling this detection event. 2. Times, TimeRange - the times that same events happened in a continuous time range. They are optional parameters of the deduction result. Figure 2 illustrates a sample deduction result with Times, TimeRange Seak&Cathy Expires June 26, 2011 [Page 5] Internet-Draft Detection Event Description Language December 2010 +-------------------------------------------------------------------+ | | | If exist | | Event | | Event | | Event | | Event | | and | | Time(1)time(4)"] | | > | | | +-------------------------------------------------------------------+ Figure 2 Sample deduction result with Times, TimeRange 3. IPRange - the range of IP address. It is one of the optional parameters in the deduction result. Figure 3 illustrates a sample deduction result with IPRange: +------------------------------------------------------------------+ | | | If exist | | Event | | Event | | Event | | Event | | and | | TIP(1),TIP(2),TIP(3),TIP(4)constitute a consecutive IP rang | | than | | EventTIP(4)"]> | | | +------------------------------------------------------------------+ Figure 3 Sample deduction result with IPRange 4. IPChain - the IP conduction chain. It is one of the optional parameters in the deduction result. Figure 4 illustrates a sample deduction result with IPChain Seak&Cathy Expires June 26, 2011 [Page 6] Internet-Draft Detection Event Description Language December 2010 +-------------------------------------------------------------------+ | | | If exist | | Event | | Event | | and | | TIP(1)= SIP(2) | | and | | Time(1)TIP(1)-> TIP(2)"]> | | | +-------------------------------------------------------------------+ Figure 4 Sample deduction result with IPChain 3.3. Event Action It is the action that cause the event was detected. We classify the action into ten categories: 1. Scan - an action that attempts to get the information (e.g. version) of remote host or service. This action does no harm to that host or server. 2. Attack - attack the network equipment or host to make it congested or make a computer resource unavailable to its intended users. 3. Intrude - the action that gets the OS authorization by OS Vulnerability and subsequently executes entity code in the intruded remote host. 4. Control - controlled action of backdoor or botnet. 5. Update - an action that virus, spyware or other malware update their version. 6. Steal - an action that malware steal the data stored in some host. 7. Dangerous Access - an action that visit website or some resource that contains fishing, Trojan or cheating information. 8. Cheat - an action that malware disseminate cheat information. Seak&Cathy Expires June 26, 2011 [Page 7] Internet-Draft Detection Event Description Language December 2010 9. Unusual behavior - an unusual behavior is such as network connection or network traffic increasing suddenly, using or running sensitive network application. 10.Transmission - The transmission of protocol data. 4. Detection Event Handling Rule It is a predefined condition deduction rule set, by which the detection event can be merged and also retain the same relationship. We use the conditional-testing statement (if and than) to illustrate these rules: 4.1. Parallel Merge Rule (Parallel) The events with same name, same type, source IP and target IP can be merged into one record. Typical examples are the email worm sending event of the computed infected with email worm and the email worm sending event sent between mail servers. If exist Event< Name(1);Type(1);SIP(1); TIP(1);Time(1) > Event< Name(1);Type(1);SIP(1); TIP(1);Time(2) > and Time(1)< Time(2) than event can be merged A sample of this rule is the same one illustrated in Figure 2. 4.2. Radiation Merge Rule (Radiation) The events can be merged together if they are with same name, same type, same source IP, same target port and different target IP that constitute a consecutive IP address range. Typical example is the scan action of worm or hacker. If exist Event< Name(1),Type(1);SIP(1);TIP(1);TPort(1)> Seak&Cathy Expires June 26, 2011 [Page 8] Internet-Draft Detection Event Description Language December 2010 Event< Name(1),Type(1);SIP(1);TIP(2);TPort(1)> than events can be merged A sample of this rule is the same one illustrated in Figure 3. 4.3. Aggregation Merge Rule (Aggregation) The events can be merged together if these events are with same name, same type, same target IP, same target port and different source IP. Typical examples are the DDos attack, the online update of worm, and IRC connection. If exist Event Event than events can be merged Figure 5 illustrates a sample deduction result of aggregation merge rule: +-----------------------------------------------------------------+ | | | If exist | | Event | | Event | | than | | Event | | | +-----------------------------------------------------------------+ Figure 5 Sample Deduction Result of Aggregation Merge Rule 4.4. Conduction Chain Merge Rule (Conduction) The events can be merged together if there is infection relationship between them. Seak&Cathy Expires June 26, 2011 [Page 9] Internet-Draft Detection Event Description Language December 2010 If exist Event< Name(1),SIP(1);TIP(1); Time(1)> Event< Name(1),SIP(2);TIP(2); Time(2)> and {TIP(1),SIP(2)}belong to intranet Net(a) and Time(1)