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<Name:"Backdoor.Win32.bo.a"; |
| Type:"Backdoor"; |
| SIP:"202.118.16.23"; |
| TIP:" 202.118.16.26"; |
| Sport:"80"; |
| TPort:"4677"; |
| Time:"2010-11-17 18:57:14"; |
| Protocol:"HTTP"; |
| Action:"transmission"; |
| [Rule:""; |
| Times:""; |
| TimeRang:""; |
| IPRange:""; |
| IPChain:""] |
| > |
| |
+------------------------------------------------+
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<Name:"Backdoor.Win32.bo.a";Type(1);SIP(1);TIP(1);Time(1)> |
| Event<Name:"Backdoor.Win32.bo.a";Type(1);SIP(1);TIP(1);Time(2)> |
| Event<Name:"Backdoor.Win32.bo.a";Type(1);SIP(1);TIP(1);Time(3)> |
| Event<Name:"Backdoor.Win32.bo.a";Type(1);SIP(1);TIP(1);Time(4)> |
| and |
| Time(1)<Time(2)<Time(3)<Time(4) |
| than |
| Event<Name:"Backdoor.Win32.bo.a"; |
| [Rule:"Parallel";Times:"4";TimeRange:"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<Name:"Worm.Win32.Dvldr";Type(1);SIP(1);TIP(1);TPort(1)> |
| Event<Name:"Worm.Win32.Dvldr";Type(1);SIP(1);TIP(2);TPort(1)> |
| Event<Name:"Worm.Win32.Dvldr";Type(1);SIP(1);TIP(3);TPort(1)> |
| Event<Name:"Worm.Win32.Dvldr";Type(1);SIP(1);TIP(4);TPort(1)> |
| and |
| TIP(1),TIP(2),TIP(3),TIP(4)constitute a consecutive IP rang |
| than |
| Event<Name:"Trans.Worm.Win32.Dvldr"; |
| [Rule:"Radiation";IPRange:"TIP(1)->TIP(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<Name:"RPC_Exploit";SIP(1);TIP(1); Time(1)> |
| Event<Name:"RPC_Exploit";SIP(2);TIP(2); Time(2)> |
| and |
| TIP(1)= SIP(2) |
| and |
| Time(1)<Time(2) |
| than |
| Event<Name:"Trans.Worm.Win32.Dvldr"; |
| [Rule:"Conduction"; IPRange:"SIP(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<Name(1);Type(1);SIP(1);TIP(1);TPort(1)>
Event<Name(1),Type(1);SIP(2);TIP(1);TPort(1)>
than
events can be merged
Figure 5 illustrates a sample deduction result of aggregation merge
rule:
+-----------------------------------------------------------------+
| |
| If exist |
| Event<Name:"IRC.Repro.b[IRC]";Type(1);SIP(1);TIP(1),Time(1)> |
| Event<Name:"IRC.Repro.b[IRC]";Type(1);SIP(2);TIP(1),Time(2)> |
| than |
| Event<Name:"IRC.Repro.b[IRC]"; |
| [Rule:"Aggregation";IP_Chain:"SIP(1),SIP(2)"]> |
| |
+-----------------------------------------------------------------+
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)<Time(2)
than
events can be merged
A sample of this rule is the same one illustrated in Figure 4.
5. Security Considerations
(none)
6. IANA Considerations
This document has no actions for IANA
7. References
7.1. Normative References
(none)
7.2. Informative References
[RFC5385] Touch, "Version 2.0 Microsoft Word Template for Creating
Internet Drafts and RFCs", RFC 5385, February 2010.
8. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
Seak&Cathy Expires June 26, 2011 [Page 10]
Internet-Draft Detection Event Description Language December 2010
Authors' Addresses
Seak
Antiy Labs
Beijing China
Email: Seak@antiy.net
Cathy Wang
Antiy Labs
Beijing China
Email: wsyfuture@antiy.net
Seak&Cathy Expires June 26, 2011 [Page 11]