Application Intrusion Detection

Application Intrusion Detection

Anita JonesRobert Sielken

University of Virginia

August 99 Application Intrusion Detection 2

Introduction• Intrusion Detection

– determining whether or not some entity, the intruder, has attempted to gain, or has gained unauthorized access to the system

• Intruder Types– External– Internal -- our greater concern


State of Practice

• Assume the Operating System as the basis• Use what an OS knows about -- OS semantics

– users, processes, devices– controls on access and resource usage

• Record events in the life of the OS• Use OS audit records

OS Intrusion Detection Systems -- OS IDS


OS IDS - the two Approaches• Anomaly Detection

– assume that behavior can be characterized• statically -- by known, fixed data encoding• dynamically -- by patterns of event sequences or by

threshold limits on event occurrences (e.g. system calls)

– detect errant behavior that deviates from expected, normal behavior

• Misuse Detection– look for known patterns (signatures) of intrusion,

typically as the intrusion unfolds


OS IDS - the two Approaches• Anomaly Detection

– Static: e.g. Tripwire, Self-Nonself– Dynamic: e.g. NIDES, Pattern Matching (UNM)

• Misuse Detection– e.g. NIDES, MIDAS, STAT

• Networks are handled as “extensions”– I.e. Use same two approaches listed above– Centralized: e.g. DIDS, NADIR, NSTAT– Decentralized: e.g. GrIDS, EMERALD


OS IDS -- a Particular Problem• OS IDS has problems when

– anomalous & normal behavior can’t be distinctly characterized

– OS IDS has no pattern for a newly invented intrusion (misuse)

• But, the greatest problem is– to distinguish abusive internal (legit user)

activity

An OS IDSis inherently limited

by the semantics of the OS

You can’t talk about somethingfor which you have no words!

A Complementary ApproachAssume that the OS IDS does its job.

Use the semantics of the application as a further basis

for detection of intruders

Application Intrusion DetectionApp IDS


App IDS -- What’s Possible?• How do you define intrusion in the context of (in the

semantics of) an application? • Can an intrusion be “seen”?

– Seen in progress?• Can intrusive behavior be linked to users?• Is there a richer notion of history (of intrusion)?• Is there a richer notion of “abused system state”?


App IDS -- Guiding Questions• Opportunity – what types of intrusions can

be detected by an AppIDS?• Effectiveness – how well can those

intrusions be detected by an AppIDS?• Cooperation – how can an AppIDS

cooperate with the OS IDS to be more effective than either alone?


Case Studies• Electronic Toll

Collection– hierarchical – numerous devices

distributed– complementary device

state values – monitors external

behavior– accounting component

• Health Record Management– non-hierarchical; modular– no devices beyond

controlling computer– limited access in app’n– bound by known physical &

medical realities – no financial component – complex scheduling

components


Electronic Toll Collection (ETC)• Devices

– Toll Lane• Tag Sensor • Automated Coin Basket• Toll Booth Attendant• Loop Sensor • Axle Reader• Weigh-In-Motion Scale• Traffic Signal• Video Camera - Vehicle

Tag (Active/Passive)


ETC - Hierarchy

T o ll L a ne T o ll L a ne

T o ll P la za T o ll P la za

T o ll L a ne T o ll L a ne T o ll L a ne

T o ll P la za O th e r De v ices

T o ll M a n ag e m en t Ce n te r


Need Analysis Technique• What intrusions make sense in app’n terms?• How do you derive them?• Is there a disciplined analysis approach that

ensures that “all” intrusions are found?• Once an intrusion is defined, is there a way to

monitor for it within the application?• Is there a relation to the OS, and information

that it has?


ETC - One Approach

• Start with the known threat categories• How can they be manifested in app’n terms• Define app’n specific intrusions• Determine method that abuser would use• Define relations based on app’n state values that

can be the basis for monitoring method

Threat Categories

Specific Intrusions Methods Relations


Threat Categories• Denial of Service• Disclosure• Manipulation• Masqueraders• Replay• Repudiation• Physical Impossibilities• Device Malfunctions


ETC - Appl’n Specific Intrusions

• Annoyance (3 methods)• Steal Electronic Money (10 methods)• Steal Vehicle (4 methods)• Device Failure (1 method)• Surveillance (2 methods)

Threat Categories



ETC Intrusion - Steal Service

Rel# Relation Relation

DescriptionExecutionLocation Steal Service

No tagand

coverplate

Copytag

Packet filterthat discards

all a tag'spackets

1 Tag vs. Historical (Time) (stat) TBP/TMC X4 Tag vs. Historical (Sites) (stat) TMC X5 Tag vs. Time (rule) TMC X9 Tag vs. Axles (rule) TBL X X X25 Unreadable Tags (stat) TBP/TMC X

3 methods5 relations


Health Record Management (HRM)

• Components– Patient Records– Orders – lists of all requests for drugs,

tests, or procedures– Schedule – schedule for rooms for patient

occupancy, laboratory tests, or surgical procedures (does not include personnel)

• Users– doctors, laboratory technicians, and nurses


HRM - App’n Specific Intrusions

• Annoyance (4 methods)• Steal Drugs (1 method)• Patient Harm (6 methods)• Surveillance (2 methods)

Threat Categories



HRM - Patient Harm IntrusionRel# Relation Relation

Description Patient Harm

Adm

in. W

rong

Dru

g

Adm

in. T

oo M

uch

of D

rug

Adm

in. a

n A

llerg

icD

rug

Adm

in. I

mpr

oper

Die

tO

rder

Nee

dles

sD

rugs

Per

form

Nee

dles

sP

roce

dure

2 Drug vs. Allergy (rule) X X

5 Drug vs. Diet (rule) X X

8 Drug vs. Historical (dosage) (stat) X X

24 Patient Test Results vs. TestResults (Historical) (stat) X X X X

4 relations 6 methods


Relate OS IDS to App IDS• Similarities

– detect intrusions by evaluating relations to differentiate between anomalous and normal behavior

– centralized or decentralized (hierarchical)

– similar threat categories

• Differences– anomaly detection using

statistical and rule-based app’n relations

– internal intruders/abusers – event causing entity

• outside system

– resolution -- finer grain– tightness of thresholds


Relate OS IDS to App IDS (cont’d)

• Dependencies– OS IDS on App IDS

• None

– App IDS on OS IDS• basic security services• prevent abuser from

bypassing application control to access application components

• Cooperation– correlate audit/event record– communication

• bi-directional• request-response

– complications• terms of communication• resource usage - lowest

common denominator


Conclusion -- App IDS• Opportunity

– app’n semantics are a rich basis for detecting internal intruders (abusers)

– can detect intrusions not visible to OS– intrusions relate to real world!– monitors similar: rule-based & statistical relations

• Effectiveness– grain and units of resolution much richer– tighter of thresholds– less ambiguity of anomalous and normal behavior


Conclusion -- Next• Have developed an analysis technique that permits

systematic derivation of intrusions; apply more broadly– heuristic; no guarantee of completeness

• Create definition of attacks; contrast to OS attacks– Are there new categories of attacks -- beyond what we

see in OS’s/networks -- especially latent/lurking attacks– Focus on critical national infrastructure applications– Describe in CISL or other extant languages for attack

description


Conclusion -- Next (cont)

• Explore basis for a “generic” App IDS– Define generic architecture and a set of tools– To what extent can OS techniques/tools be extended

• Determine how and when OS IDS & App IDS can exchange questions & answers– Resolve semantic mismatch

Documents

Application Intrusion Detection