Process in Collaborative Analysis Center

Collaborative analysis center will collect uncertain cases from local VODKAs like Example 4.3.

As we know, worm attacking is a network behavior. Therefore, the uncertain case from local VODKA can be clearly explained in collaborative analysis center. If we collect more evidences, we have more confidence to recognize a new variant worm.

4.3.1 The Framework of Collaborative Analysis Center

The framework of collaborative analysis center for computer worms is listed as follows. It consists of three stages, Evidence Collecting Stage, Worm Analysis Stage and Knowledge Updating Stage.

Figure 4.5 : Stage of Global Analysis Center for Computer Worms Stage I：Evidence Collecting

The Log and System Profile are transferred to our collaborative analysis center directly. The log from each VODKA is reported periodically to collaborative analysis center. However, System Profile would not be changed periodically. We receive the report of System Profile when the configuration of local host is changed. We have the following format of log and system profile.

Table 4.9：Log Profile of Yaha

Time ID Ri,j A1 A2 A3 A4 A5 CF(Ri,j)

T1 140.113.87.175 R2,5 Email flood Project.exe True {25} Tcpsvs32.exe 0.4

Table 4.10：System Profile for Computer Worms

ID OS (Application <-> Vulnerability) 140.113.87.175 Windows XP RPC<->CAN-2003-0352

Figure 4.6 shows the communication between local and collaborative analysis center. And the files are transferred asynchronously. Log is reported periodically and system profile is event-driven.

Figure 4.6：Communication between Local and Collaborative Analysis Center

StageII：Worm Analysis Stage

In this Stage we will use expert system to help us systematically analyzing reports. It also can reduce the confirmation effort from experts. We apply extended VODKA to worm domain and we can add more criterions based on the nature of worms. In addition to three basic criterions described in Chapter 3, we know that worms will continually infect other machines, and infecting is the nature for them. So

we can add a new criterion for worms about single or multiple reports. If we only receive reports of single host, we do not have enough evidence to verify a variant worm. Of course, domain experts may have their decision ideas about to discover variant worms. At this time they can dynamically add more criterions to fit their requirements.

Now we describe the additional criterion for worm domain.

Additional criterion : Single or multiple reports

As mentioned above, worm attack is network behavior. The reports of variant worms would not be only one. If we only receive reports of single host, our decision confidence is the same as local host. It means the confidence will not be accumulated.

Therefore this criterion is to know the reports to accumulate our confidence are from single host or multiple hosts.

Notation :

Object.ID : the IP of this report

Object.HostIP : the IP set of reporting the same object

Flagobject.host : Initialized to 0, set to 1 when receiving different IP MR: IF Object.ID <> Object.HostIP

Then set Flagobject.host=1

According to this criterion, we must modify Criterion3 to correctly discover variant worms. It means if reports from only one host are not considered.

We add “Flagobject.host=1” to fit our requirement.

MR5: IF Confobject > VOthreshold AND Flagobject.host=1 Then discover variant worms

StageIII : Knowledge Updating Stage

When we discover a variant worm, we will acquire the attribute and attribute values and generate relative Repertory Grid and AOT. And feed them to EMCUD to generate defending rules. At the same time we will update our knowledge base.

4.3.2 Run through An Example

In this example, Yaha is an uncertain case described in Example 4.3. Besides Yaha, we also receive reports of Sobig and Gaobot. The example will trace how to analyze with collaborative rules.

Example 4.4 : An Example to Trace Collaborative Analysis Rules Table 4.11 is the repertory grid of Yaha, Sobig and Gaobot.

Table 4.12 is the AOT of Yaha, Sobig and Gaobot.

Table 4.13 is the partial detecting rules generated by EMCUD.

Table 4.11 : The Repertory Grid of Yaha, Sobig and Gaobot Object

Attribute Yaha (O1) Sobig(O2) Gaobot(O3)

DoS_Type (A1) Email Flood Email flood X

Backdoor (A2) X True X

Email_Attachment(A3) Loveletter.doc.pif Sample.pif X

Antivirus_Firewall_Abnormal(A4) True X True

TCP_Port (A5) {25} {25} {80,135,445}

New_File(A6) <****>b.dll Winmgm32.exe Bla.exe Table 4.12 : The AOT of Yaha, Sobig and Gaobot

Table 4.13 : Partial Detection Rules Generated by EMCUD

IF Part Then Part CF

Rule #

A1 A2 A3 A4 A5 A6 Object

R1,0 Email flood - Loveletter.doc.pif True {25} <****>b.dll Yaha 0.8 R1,1 Email flood - ┐Loveletter.doc.pif True {25} <****>b.dll Yaha 0.7 R1,2 Email flood - Loveletter.doc.pif True {25} ┐<****>b.dll Yaha 0.6 R1,3 Email flood - Loveletter.doc.pif True {25} <****>b.dll Yaha 0.5 R1,4 Email flood - Loveletter.doc.pif False {25} <****>b.dll Yaha 0.4 R2,0 Email flood True Sample.pif - {25} Winmgm32.exe Sobig 0.8 R2,1 Email flood True Sample.pif - {25} ┐Winmgm32.exe Sobig 0.7 R2,2 Email flood True ┐Sample.pif - {25} Winmgm32.exe Sobig 0.6 R2,5 Email flood True ┐Sample.pif - {25} ┐Winmgm32.exe Sobig 0.4 R3,0 - - - True {80,135,445} Bla.exe Gaobot 0.7 R3,1 - - - True {80,135,445} ┐Bla.exe Gaobot 0.6 R3,2 - - - True ┐{80,135,445} Bla.exe Gaobot 0.5

According to the importance of attributes, we map {D, 5, 4} to major attributes M, {3,2} to secondary attributes S. After mapping, we can get Table 4.14

Table 4.14 : Mapping Table of Yaha, Sobig and Gaobot

A1 A2 A3 A4 A5 A6 object

M - - M M S Yaha M M S - M - Sobig

- - - M M - Gaobot

Table 4.15 : System Profile of Three Hosts

ID OS Application<->Vulnerability

140.113.87.175 Windows XP RPC<->CAN-2003-0352 140.113.87.174 Windows 2000 none

140.113.167.101 WindowsXP RPC<->CAN-2003-0352

Constructing collaborative rules from all criterions

In this example, we will use formula to calculate Confobject of each rule and set (Confhigh=0.2), (Conflow=0.1), (ConfSystemProfile=0.3), ( flagobject=0) and (Confobject= 0).

Collaborative analysis rules for Yaha

IF (DoS=Email Flood) AND (Antivirus Firewall abnormal=True) AND (TCP port={25}) AND (New file=svchook.dll)

Then (ConfYaha= ConfYaha + 0.2) AND (flagYaha=1) IF (flagYaha=0) AND (DoS=Email Flood) AND

(Antivirus Firewall abnormal=True) AND (TCP port={25}) Then (ConfYaha= ConfYaha + 0.1)

IF (flagYaha=1) Then (flagYaha=0)

Collaborative analysis rules for Sobig

IF (DoS=Email Flood) AND (Backdoor=True) AND (TCP port={25}) AND (Attachment=Sample.gif)

Then (ConfSobig= ConfSobig +0.2) AND (flagSobig=1)

IF (flagSobig=0) AND (DoS=Email Flood) AND (Backdoor=True) AND (TCP port={25})

Then (ConfSobig= ConfSobig +0.1) IF (flagSobig=1) Then (flagSobig=0)

Collaborative analysis rules for Gaobot

IF (Antivirus Firewall abnormal=True) AND (TCP port={80,135,445}) Then ConfGaobot= ConfGaobot +0.1

IF ID.SystemProfile = { CAN-2003-0352 ; CAN-2003-0003}

Then ConfGaobot= ConfGaobot + 0.3

Collaborative rules for discovering variant worms Initialize flagobject.host=0

IF (ConfYaha>=0.8) AND (flagYaha.host=1)Then (VariantWorm=Yaha) IF (ConfSobig>=0.8) AND (flagSobig.host=1)Then (VariantWorm=Sobig) IF (ConfGaobot>=0.8) AND (flagGaobot.host=1)Then (VariantWorm=Gaobot)

The flag, flagobject.host means the confidence is accumulated from single host(=0) or multiple host(=1).

Collaborative rules for timeout period IF (Timeperiod=3T)

Then (ConfYaha= 0.5 * ConfYaha) AND (ConfYaha= 0.5 * ConfYaha) AND (ConfYaha= 0.5 * ConfYaha)

After generating collaborative analysis rules of Yaha, Sobig and Gaobot, the inference engine is driven with reports from local hosts.

Data collecting

The reports are collected from local VODKAs (Take three hosts as examples).

We select useful attributes from log database to trace our example. And they are Time, ID and six attributes.

Event Time ID A1 A2 A3 A4 A5 A6

E1 T1 140.113.87.175 Email flood - Ravs.scr T {25} WinServices.exe E2 T1 140.113.87.174 Email flood - Patch.exe T {25} - E3 T1 140.113.167.101 Email flood T Password.gif - {25} mscch32.exe E4 T2 140.113.87.175 - - - T {80;135;445} msgconf.exe E5 T2 140.113.87.174 Email flood T Peace.scr - {25} WinServices.exe

E6 T2 140.113.167.101 - - - T {80;135;445} MSRUN.exe

Now, we trace each report to see the change of confidence.

E1：matching first collaborative rules of Yaha ConfYaha=0+0.2=0.2

E2：matching second collaborative rules of Yaha ConfYaha=0.2+0.1=0.3

E3：matching first collaborative rules of Sobig Confsobig=0+0.2=0.2

E4：matching collaborative rules of Gaobot ConfGaobot=0+0.2=0.2

This case will consider system profile of local host We can discover E4 has vulnerability.

We increase ConfGaobot=0.2+0.3=0.5

E5：matching first collaborative rules of Yaha ConfYaha=0.3+0.2=0.5

E6：matching collaborative rules of Gaobot ConfGaobot=0.5+0.2=0.7

ConfGaobot=0.7+0.3=1.0 > 0.8 => Alert Gaobot Variant

Knowledge updating phase

When discovering a new variant, we generate the new acquisition table of Gaobot.B.

Table 4.16 : The Acquisition Table of Gaobot Object

Attribute Gaobot.B

Antivirus_Firewall_Abnormal(A4) True TCP_Port (A5) {80,135,445}

New_File(A6) {msgconf.exe;

MSRUN.exe}

Hence, an original rule and and embedded rule are listed as follows.

“IF (Antivirus Firewall abnormal=True) AND (TCP port={80,135,445}) AND (New file={msgconf.exe; MSRUN.exe}) THEN Gaobot.B CF=0.7

“IF (Antivirus Firewall abnormal=True) AND (TCP port={80,135,445}) AND

┐(New file={msgconf.exe; MSRUN.exe}) THEN Gaobot.B CF=0.4