report on common intrusion detection framework by ganesh godavari

23
Report on Common Intrusion Detection Framework By Ganesh Godavari

Post on 22-Dec-2015

214 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Report on Common Intrusion Detection Framework By Ganesh Godavari

Report on Common Intrusion Detection Framework

By

Ganesh Godavari

Page 2: Report on Common Intrusion Detection Framework By Ganesh Godavari

Outline of the talk

• CIDF

• GIDO

• Negotiation protocol

• scenarios

Page 3: Report on Common Intrusion Detection Framework By Ganesh Godavari

Goal

• Goal of IDIAN– Develop a negotiation protocol that is dynamic– Allow distributed collection of heterogeneous

ID components– Provide inter-operate ability to reach

agreement on ID information processing capability

Page 4: Report on Common Intrusion Detection Framework By Ganesh Godavari

Motivation

• Understand– Common Intrusion Detection Framework– Common Intrusion Specification Language

(CISL)

Page 5: Report on Common Intrusion Detection Framework By Ganesh Godavari

Common Intrusion Detection Framework (CIDF)

• CIDF architecture– Divides IDS into Components– Component consists of software code with

configuration information– Components can be added/removed– Components interact in real time and

exchange data using GIDO

Page 6: Report on Common Intrusion Detection Framework By Ganesh Godavari

Generalized Intrusion Detection Objects (GIDO)

• GIDO consists of two components– Fixed Format header

• CIDF version, timestamp, and length of body

– Variable Length Body• data

Page 7: Report on Common Intrusion Detection Framework By Ganesh Godavari

GIDO body(ByMeansOf

(Attack(Observer (ProcessName `StackGuard') )(Target (HostName `somehost.someplace.net') )(AttackSpecifics

(Certainty `100')(Severity `100')(AttackID `1' `0x4f') )

(Outcome (CIDFReturnCode `2') )(When

(BeginTime `14:57:36 24 Feb 1999')(EndTime `14:57:36 24 Feb 1999') ) )

(ByMeansOf(Execute

(Process (ProcessName `fingerd') )(When(BeginTime `14:57:36 24 Feb 1999')(EndTime `14:57:36 24 Feb 1999') ) ) ) )

data

Semantic Identifier (SID)

Where the attack occurred

Which process detected

Where is the attack targeted at?

StackGuard is a compiler that emits programs hardened against "stack smashing" attacks.

Page 8: Report on Common Intrusion Detection Framework By Ganesh Godavari

• SID is associated with each piece of data in the body

• SID associated with data are called Atom SID• Atom SID cannot completely describe an event.• Verbs describe events

– e.g. Attack SID

• Verb SID has set of Role SIDs which provide additional information about the event.– e.g. Observer Role provides information about the

observer of an event.

Page 9: Report on Common Intrusion Detection Framework By Ganesh Godavari

Example

V is a verb SIDR1 and R2 are role SIDsA1 through A3 are Atom SIDsS-expression (V

(R1 (A1 data1) (A2 data2)

) (R2

(A3 data3) )

) Tree Representation

Page 10: Report on Common Intrusion Detection Framework By Ganesh Godavari

CIDF components

• Components – Event generators ("E-boxes")

• Produce GIDOs

– Event analyzers ("A-boxes") • Consume GIDOs • Conclusions are turned out as GIDOs

– Event databases ("D-boxes")• store events for later retrieval

– Response units ("R-boxes") • Consume GIDOs • Take action like kill process, reset connections

Page 11: Report on Common Intrusion Detection Framework By Ganesh Godavari

CIDF Component Interaction

Page 12: Report on Common Intrusion Detection Framework By Ganesh Godavari

Add/remove an IDS Component

• New components need to notify others

• Negotiation protocol– Publish the capabilities of new components

• Ability to describe and disseminate the description to other components

– Collection of components need to interact with each other

• To determine which components provide specific set of capabilities that the others can utilize

Page 13: Report on Common Intrusion Detection Framework By Ganesh Godavari

Categorization of overload situations

• Resources are limited• Demand driven overloads

– IDS is asked to provide additional detection facilities– Fluctuation in the amount of data to be processed

• Flooding !!

• Supply driven overloads– Computer/network down!!– Compromised components unavailable– Number crunching jobs competing with IDS for jobs

Page 14: Report on Common Intrusion Detection Framework By Ganesh Godavari

Adapting to overload situations

• Solution– Supply of resources/components is increased

• Human assistance, killing processes/files competing for resources

– Reduction in the demand• Modify the packet filtering rules to eliminate flooding the

system from outside;• Killing processes that generate massive floods of OS audit

records

– Adapt to ensure important jobs are met• Reduce the number and kinds of attacks detected, number of

systems/network covered by IDS

Page 15: Report on Common Intrusion Detection Framework By Ganesh Godavari

New Attack Signatures and Responses

• Install new signatures – computational cost

• Cost– Determine if the capability exists in the IDS to

respond to the attack signature– Cost of response i.e. degradation in performance,

loss of functionality• E-box needs to specify the cost of sensor data• R-box needs to specify the cost executing

requested actions• A-box needs to asses (stress) the cost of

deploying a new attack signature

Page 16: Report on Common Intrusion Detection Framework By Ganesh Godavari

New producer

• E-box – can I supply the capabilities with in cost limits?– If true send acceptance message to A-box– If false

• send rejection message to A-box• If the minimum cost is relatively close to the upper

bound set by A-box. Send a counter proposal to A-box

The counter proposal can be accepted or rejected by A-box

Page 17: Report on Common Intrusion Detection Framework By Ganesh Godavari

New ConsumerEnhanced/diminished capability

• New Consumer– R-box advertises its capabilities to existing A-

Boxes

• Enhanced/diminished capability– Upgraded/degraded E-box advertises to A-

box. – A-box renegotiates its utilization of the

capabilities of E-box

Page 18: Report on Common Intrusion Detection Framework By Ganesh Godavari

How does one know what are the existing capabilities?

– generate new proposals that contain more arbitrary lists of capabilities

– For example, suppose that an R-box R announces a list of capabilities L0. An A-box A requests a list L1 that is a subset of L0. R comes back with a list L2 that is a subset of L1. Unsatisfied, A proposes an entirely new list M that is a subset of L0 but that may share only some capabilities with L1.

Page 19: Report on Common Intrusion Detection Framework By Ganesh Godavari

Scenario 1: a new capability

new host machine with detection component is added to LAN.

Network under connection laundering attack

Page 20: Report on Common Intrusion Detection Framework By Ganesh Godavari

solution

• E-box supplies system-call audit trail

• A-box might correlate all inbound TCP/IP connections with outbound connections.

Page 21: Report on Common Intrusion Detection Framework By Ganesh Godavari

Scenario 2: flooding IDS

Stolen company laptop with VPN Connection to the company that has detection component and is used to launch an attack.

Hacker generate lot of spurious audit data to deflect suspicion. Second host is also compromised. Generate more audit data and crash the central IDS?

Page 22: Report on Common Intrusion Detection Framework By Ganesh Godavari

Solution

• Request the event generator to switch to a pre-negotiated fallback setting in which only critical audit data is sent.

• Request that other event generators reduce their output so the analyzer can concentrate on the attack.

Page 23: Report on Common Intrusion Detection Framework By Ganesh Godavari

References

• Intrusion Detection Inter-component Adaptive Negotiation– Richard Feiertag et al 2000 IEEE Computer

Networks special issue on intrusion detection

• A Common Intrusion Specification Language, CIDF working group document.

• Communication in the Common Intrusion Detection Framework, CIDF working group document.