May 6, 1999
3085 ENG II
In attendance:
Jeff Rowe (JR), Jason Schatz (JS), David Klotz (DK), Karl Levitt (KL), David O'Brien (DOB)


Connection Spoofing
Code Book
Slide Assignments
    1. Connection Spoofing
      1. Stage 1: Probe
        1. SYN & SYNAK between target & attacker
      2. Stage 2: Sequence Guessing
        1. SYN's in restricted sequence range
        2. Resets from server
        3. Packets with invalid source address at router
      3. Stage 3: Client DOS
        1. Successful wedge
      4. Stage 4: Exploit
        1. ACK from server to wedged client
        2. Traffic from wedged machine
    2. Code Book
      1. DK: Stage 3 just has to be on one specific port. JR: There are queues for each port.
      2. 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.
      3. 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.
      4. 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.
        1. DOB: Theorize about missing data propagating to next table.
          1. 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.
          2. JR: We could add weighting for probabilities to our code book.
      5. JR: Code book correlation and GrIDS that can model network and turn it into problems.
        1. 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.
          1. JR: Limit to 4 variants for each stage. One is an attempt, without stage 4.
      6. 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.
        1. JR: Suppose it is a background to DOS.
        2. JS: It could be off-line for maintenance. In this symptom scheme -- nice to write signatures with OR clauses.
        3. 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.
        4. 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.
        5. 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.
      7. KL: Is our final conclusion that we have an attack or that data was lost?
        1. JR: Put together more coordinators than just code book -- CYC.
        2. 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.
          1. 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.
      8. 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
      9. 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.
        1. JR: Polling -that will be tricky -- how it will be done.
        2. 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.
        3. 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.
          1. KL: Model seems to be emerging
          2. 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.
      10. KL: CYC for use off-line -- don't want to be liable.
    3. Slide Assignments
      1. JR: DOB could do slide on DCA, causality and code book. KL: Sequence slide that shows the attack
      2. Jason, - cloud diagram, recognizable symptoms, talk about variants.
      3. Describe Jason's attack, worm and DCA; bring up scenarios for other attacks.
      4. JR: Try to look at writing guidos on Monday.