GLOBAL GUARD MEETING
November 17, 1998
3085 ENG II
9:00 – 10:00
In attendance:
Karl Levitt (KL), David O’Brien (DOB), Jeff Rowe (JR), and Steven Templeton
(ST)
Topics:
Summary of Previous Meeting
Continued Discussion on Causality
How to Translate Causality into the Codebook
-
Summary of Previous Meeting (on Nov 16th)
-
ST: If action is taken because of something, it’s a causal relationship.
It comes down to what level of granularity you’re willing to work with.
The coarser the granularity, the larger the potential for error.
-
ST: In Redux model there are subsets of features that are discernable
between classes but indiscernible within the class.
-
Set of rules based on Redux, each rule votes once and may have a weighted
value.
-
DOB: Compression – as you go up the tree chart, compress everything you’ve
seen before for faster lookup tables.
-
Encoding the causal relationship – with given symptoms, you can identify
the cause.
-
DOB: You can detect attacks at first router. Causality is only interesting
if you want to know where the attack is coming from.
-
ST: The attack doesn’t affect the carrier – the carrier doesn’t have any
symptoms generated, but there is an effect (sniffer and other alarms are
triggered)
-
ST: Correlation – an indirect cascade of things happen before you get a
fever, for example. Don’t worry about the intermediate steps.
-
If the goal is to identify the source, then you need to know the causality
chain
-
If the goal is to know how the attack is done, then the causality chain
is irrelevant.
-
The proprietary response to an attack is:
-
Stop the effects of an attack
-
Shoot back at the attacker (secondary)
-
With the current infrastructure, it’s difficult to trace back to the attacker
-
Global Guard List of people involved is huge and includes Columbia University
(SMARTS system) and USC.
-
Intrusion Detection System – existing system with network operators
-
Network Management – denial of service attack augment their matrix
-
JR: You have to reduce it down to Yes/No Questions
-
ST: There are an infinite set of features that can’t be turned into binary.
-
DOB: In network management, they want to tell you that you have a problem
and where it is.
-
We need enough features to discern attacks from network problems
-
We’d like to determine the next attack before it happens.
-
Within vulnerabilities, find the next closest category of attack (i.e.,
buffer overflow, SINFLOOD
-
Determine the past behavior of the attacker to help predict what happens
next
-
ST: Denial of service of other attacks – monitor and defend
-
Prediction definition - events that are expected to occur or are reasonable
and likely based on past behavior of the attacker or our current knowledge
of attacks
-
DOB: Need a higher meaning for the attack. Is it a single attack constructed
of two events or are there two separate attacks?
-
DOB: Definition of an attack: There is an attack if the local security
policy says there is an attack. The policy will define an attack as misuse,
access to proprietary data, etc
-
Security Policy vs. Acceptable Use Policy (doesn’t include security specifications)
-
Security is too multi-faceted
-
Denial of service
-
Integrity, Confidentiality, Availability, Non repudiation of identity/receipt,
Authenticity
-
How do you determine if SPAM is an attack or just some idiot?
-
JR: Intent of the SPAM
-
ST: Taxonomy of attacks
-
DOB: Focus on network-based attacks, not on host-based attacks
-
JR: You have to detect all attacks whether it’s a false alarm or not –
willingness/intent
-
We’re building the cop, the investigative mechanism, not the judge.
-
How does causality come into the codebook?
-
If there’s an attack on IP, with symptoms on TCP and applications
-
Model what symptoms network management should have caused, for example
-
Next week Topics:
-
How to include an attack in the codebook (binary).