GLOBAL GUARD
May 6, 1999
12-1:30pm
3085 ENG II
In attendance:
Jeff Rowe (JR), Jason Schatz (JS), David Klotz (DK), Karl Levitt (KL),
David O'Brien (DOB)
TOPICS:
Connection Spoofing
Code Book
Slide Assignments
-
Connection Spoofing
-
Stage 1: Probe
-
SYN & SYNAK between target & attacker
-
Stage 2: Sequence Guessing
-
SYN's in restricted sequence range
-
Resets from server
-
Packets with invalid source address at router
-
Stage 3: Client DOS
-
Successful wedge
-
Stage 4: Exploit
-
ACK from server to wedged client
-
Traffic from wedged machine
-
Code Book
-
DK: Stage 3 just has to be on one specific port. JR: There are queues for
each port.
-
JR: We build up our table of
symptoms and problems. One table describes problems and symptoms, second
table describes symptoms in more detail. Code book approach allows you
to handle missing data.
-
KL: How to determine if attack is successful. If we see a connection wedge,
it exists. Is that really an attack? It's not as bad as connection hijacking.
Each symptom is an attack in its own right. JR: False alarms from wedge
trigger.
-
KL: What if we don't see specific symptom or we just missed it? JR: Build
up a table of as many symptoms as we can. KL: Does Yemini handle disjunctions?
Yes, the symptom is either there or not. Don't want to look for symptoms
all the time. JR: Can poll for some info; get other info asynchronously.
Include a row in our table called suspicious connection spoofing. Will
have to poll some of our sensors in our language, but this problem doesn't
seem complex enough to do our own language. Interest is in how far we can
take code book and correlation. JS: Come up with 3 or 4 more attacks for
validation.
-
DOB: Theorize about missing data propagating to next table.
-
KL: Just saw sequence number guessing and the ACK. That is pretty convincing.
JR: We don't know if the attack came from the spoofed attacker or the real
machine.
-
JR: We could add weighting for probabilities to our code book.
-
JR: Code book correlation and GrIDS that can model network and turn it
into problems.
-
Build up a hierarchy of aggregators that isn't necessarily a hierarchy
of GrIDS aggregators. Symptoms would be easily encoded as two nodes and
an edge. Worm becomes symptom 2 in code book. All warnings can become symptoms
in our grand correlator. Other coordinators -- CYC, IDIP have symptoms for
code book on a higher level.
-
JR: Limit to 4 variants for each stage. One is an attempt, without stage
4.
-
JS: What ways is our correlator going to different from Yemini's code book?
OR clause for symptoms, hierarchy is different, spoofed clause can be out
of service instead of attack.
-
JR: Suppose it is a background to DOS.
-
JS: It could be off-line for maintenance. In this symptom scheme -- nice
to write signatures with OR clauses.
-
DK: Just trying to deal with 1 or 0s, then can have connection spoofing
1 -- wedge 2 -- machine is down -- Number of ORs may not be that great.
-
DOB: Any compromised host on network -- not trusted on server. JR: Sniff
the sequence number. For all permutations of symptoms in table -- get a
different attack.
-
KL: Yemini talked about generating a code book. JR: Did it through causality
diagrams JS: That approach is not enough for us. JR: My goal is to fill
in a code book.
-
KL: Is our final conclusion that we have an attack or that data was lost?
-
JR: Put together more coordinators than just code book -- CYC.
-
JR: Figure from proposal that show hierarchy of architecture when employed.
If you get a problem from code book that is password guessing, describe
in a way that GrIDS can understand it. Just correlate upward or you just
stop.
-
DK: Is there any cross-over? JR: Not within a level. DK: Some of the symptoms
that I see at one level are symptoms that GrIDS uses. JR: GrIDS sees same
thing as our correlator. Symptoms will start to overlap -- part of many
attacks.
-
JR: Use CIDF as our language (s-expressions). KL: Can express anything
in XML. DOB: CIDF is not XML. CIDF is a protocol more than a language.
Re-implement CIDF using XML. KL: We'll tell Sami that we're going to think
about using CIDF. Good project/paper -- looking at expressing CIDF is terms
of some semantic notations
-
DK: At the highest code book, problems like Iraqis launch Cyber attack?
KL: Situation assessment. JR: Goal -- take background that might come from
stage 1-3, won't happen if it can't happen in combination.
-
JR: Polling -that will be tricky -- how it will be done.
-
KL: Cost model -- something more expensive to do. Polling -- places to look
for and not look for. Specify things individually. Cost of looking at something
at a certain point, how likely it is to be worthwhile. Looking for traffic
from an individual machine. Don't want to look at every machine in the
world. You build up these signatures -- it looks like program synthesis.
Take specification of individual operations.
-
JS: Build signatures on the fly -- ACK from wedged client is not a signature.
After you see sequence number guessing, then you can build up a meaningful
signature -- scripted triggered mechanism.
-
KL: Model seems to be emerging
-
Symptoms that you might miss -- could happen too quickly. Traffic on wedged
machine -- likely to hang on for awhile. High probability the connection
will last for seconds. JR: Whenever you see DOS, start sniffing traffic
of that machine to see if spoofing or just DOS. Generalize spoofing. Sniffing
network see exactly what they need -- don't have to sequence guess.
-
KL: CYC for use off-line -- don't want to be liable.
-
Slide Assignments
-
JR: DOB could do slide on DCA, causality and code book. KL: Sequence slide
that shows the attack
-
Jason, - cloud diagram, recognizable symptoms, talk about variants.
-
Describe Jason's attack, worm and DCA; bring up scenarios for other attacks.
-
JR: Try to look at writing guidos on Monday.