GLOBAL GUARD MEETING
April 29, 1999
11:00am - 3:00 pm
3085 ENG II

In attendance:
Karl Levitt (KL), Jeff Rowe (JR), Jason Schatz (JS), David Klotz (DK), David O'Brien (DOB)

BRAINSTORMING SESSION TOPICS:

Tim Bass Papers
Examples for Global Guard
Methodology
Questions to ask of Attacks
Hijacking Connections (Spoofing Address) How Attack is Accomplished
How to Detect Attack
Attack Language
Was Attack Sucessful? Worm Example
Future Directions (Next Week)
    1. Tim Bass Papers
      1. Tim Bass's papers are at a higher level and deal with situation assessment. They work in the military field; we have a bigger domain.
      2. JR: As we get info in from sensors, we can focus smaller and smaller.
    Examples
    Goals
    Methodology
    TCP attacks, spoofing Fewer false alarms Architecture
    Smurf attack Information to make a decision Types of Correlation 
    Several types of worms   Attack grammar/language
    IDIP, Strategic situation assessment   Build on CIDF SIDs
    Fred Cohen Distributed Coordinated attack   Classifying symptoms to determine attacks
    Mapping of networks   Info from network routers and other sources
  1. Examples for Global Guard
    1. TCP attacks, spoofing
    2. Smurf attack
    3. Several types of worms
      1. Sneaky worm that is covering its tracks, seeking something out, stealthy
      2. Random worm through system
      3. Sami attack: worm sets up time bombs for detonation on many machines at a later time.
      4. Jeff's worm Multi-stage worm using different protocols and different ports along the way
    4. IDIP, Strategic situation assessment
    5. Fred Cohen Distributed Coordinated attack
    6. Mapping of networks
  2. Methodology
    1. KL Correlation methodology -- what does it mean? How do we decide if two things are related? Do they have the same cause? Does one precede the other some of the time, all the time?
      1. JS: By making that correlation, what is the benefit?
        1. JS: Fewer false alarms
      2. JR: Two different levels of correlation -- packets on network à connection hijacking; putting other thing together to determine who is attacking. Attack language and grammar.
    2. Base knowledge for putting things together -- symptoms
    3. JS: Architecture for correlators? What kind of data we’re going to take in, sensors from network, use attack description to convert symptoms/data into plausible attacks.
      1. JS: Current attack grammar -- some agreed upon string.
      2. DOB and JS discuss whether uniform sensor info means filling out a form or just speaking the same language à modified form with option to leave fields blank.
    4. CIDF and SIDs (semantic identifiers) - A CIDF side can’t tell me how to detect a new type of attack, but we may want to build on CIDF.
    5. JR: Classify symptoms to determine attacks.
      1. A box input from E box. Data box for storage. Nothing that says there’s not another A box with its own D. Our realm is still the A box. Looking to get reports from sensors or other A boxes..
        1. DOB: Lisp looking expression, parse it.
      2. KL: Assume that all this can be done in CIDF, get sensor reports that can be used. DOB: Assume you can have any byte stream added.
      3. JS: If I’m going to do inferencing from separate IDS, to be able to say this is a Winnie-the-Pooh attack, use that name uniformly or give properties or damage of the attack.
    6. JR: Info from network routers -- list of symptoms we could see even without IDS running on symptom. Write software to query routers, DNS etc.
  3. Questions to ask of attacks?
    1. Is it the Winnie-The-Pooh attack with some confidence level?
    2. Is it a combination of attacks or separate components of one attack?
      1. Are components related to one attack or unrelated separate attacks?
    3. What/Who is the source?
    4. What is affected? Impacted components?
      1. How will it affect our mission?
    5. Next step(s) in attack?
    6. Has any data gone back to source? Confidentiality disrupted.
      1. JR: We're just trying to stop attack. Measure cost of attack vs. various pieces.
      2. KL: If sniffer is installed, may have lost passwords etc. JR: If one machine has root compromised and I am only concerned about data loss and no data has been moved to outside, the attack doesn't matter to me.
    7. What info would we need?
    8. Would additional info help us?
  4. Hijacking Connections (Spoofing Address)
    1. How Attack is Accomplished
      1. JS: See sequence number guessing à Hijacking connections. Abnormal sequence numbers rejected.
        1. DOB: Open TCP detection like Echo, Daytime, know what sequence number you started with. JS: Take minutes or hours to guess. Ping, take next guess, start over if not correct. I send SYN, get back SYNAK. DOB: Source destination port, TCP -- sequence number -- way of knowing I have a valid established connection - JS: Do ping , sequence number could have done, increment starting number by an amount. JR: My path to outside UCD goes through 5 routers.
        2. DK: Sends out 200 AK packets, is one going to work? DOB: Malformed packet? Drop it on floor or JS: Send reset.
        3. JS: We don’t know detail of ordering. The example I read they took a day to get it right. DK: TCP can go out of order. May look normal but slow connection if packets out of order. 9 SYN packets in a row is an anomaly.
        4. KL: Need a count for a threshold. How unusual for client to put in wrong sequence number in a packet in a connection of establishment?
          1. DOB: Very rare, because you couldn’t get a connection up. JS: Increment it to see what’s next.
    2. How to Detect Attack
      1. Can get some info from HP Open View, an IDS, or a network tool that says the client isn’t responding or that it is wedged.
      2. KL: IDS -- see source address that doesn’t belong there. Work in Scot's thesis.
      3. JR: Packets on attacker’s network -- as close as you can get. May not be able to tell it’s spoofed. DOB: Linux box running IMAC, root compromise, launch attack from there. Break into another box on clients attack. Starting from a different place.
      4. KL: Potential for three sensors or fewer. Cases of data from all sources
        1. JS: Best case: Sequence number guessing is 60% false alarm, wedging is 40% alarm, but wedging and sequence number guessing may be related. If when sequence number guessing is detected, check client for wedging.
        2. DOB: What if I didn’t wedge the client, sending it to a black hole?
        3. JS: Possible to lower false alarms with a conditional probability. DOB: Correlate something with a probe.
        4. DOB: SYN Flooding from web server is high. Looks similar. Hit reload a bunch of times. I need more info to correlate and make a decision. KL: It’s a popular web site (server) that’s getting set -- losing traffic from server, packets, SYNAKs.
        5. JS: Event model -- if you see sequence number guessing, poll for wedging.
          1. JS: Scaling difficulties when everybody’s sending everything
          2. JR: As part of attack language, have enough info to query other clients. DOB: Design some A box that only looks for sequence number guessing, spoofing, or worms? Then you need something uniform. If attack is wedging client for denial of service, our model should see this common attack.
            1. KL: Whether an A or E box, doesn’t matter.
            2. DOB: Need to deal with scaling to start out.
      5. KL: Signatures for handling attack? DOB: I think we can find them. JR: Peter's work included sequence number guessing.
      6. KL: Summary: So we have sensors at number of places, detecting some guesses about what's happening, wedging, sequence number guessing, assuming they can send reports to everyone or perhaps they should wait for asked reports, strong correlation.
      7. JS: P(IP spoofing | sequence number guessing ^ wedging)
        1. P(IP | seq. Guess).
        2. JR: Can get additional info from routers and other sources
        3. KL: Sequence number guessing without wedging won’t work.
        4. DK: It's conceivable that there are high-level attacks that can live with polling or require polling for scaling issues; requires constant stream. Issue of conflicting designs. Compartmentalize attack that require polling.
      8. JS: Call second-order signatures -- write signature based on attack IDS sees.
    3. Attack Language
      1. KL: Ad hoc correlation; If we see sequence number guessing, query the client, look for where packets coming from. Has client been wedged? If yes, more like IP spoofing.
        1. DOB: Distributed bits of info, what do with them?
          1. JR: Put them through language of rule sets
      2. JS: Lower false positive by noting multiple ID events; signatures of signatures -- sequence of packets -- net radar signatures.
      3. DOB: Data Fusion -- framework for wedging?
        1. KL: tracking projectile going through space, tracking packet through space. Too simplistic. Use as framework, diagram
      4. KL: Glorified signatures. Reports from two different sources drawing an inference. IP spoofing, sequence number guessing, no wedging.
      5. KL: We want to be CYC plus an attack knowledge base. Think about next step -- to get some confirmation that connection was successfully hijacked. Can find out who did it with IDIP enabled routers.
    4. Was Attack Successful?
      1. JS: SYNAK back to spoofed client -- is successful. Add to signature, did you ever see it work? Now have successful and failed connections.
      2. DOB: Look for any traffic going back through clients -- if wedged, something wrong. Method of wedging is SYN flooding -- still able to send out UDP that is being SYN flooded.
        1. JS: What’s the event that triggered that? Add how events are triggered -- client or server-centric.
        2. JS: Glorified signature would enclose event model.
      3. DK: Appears that we are wedged fairly often through SYN flooding, KL: Don’t want to report all SYN flooding to everyone, but may want to report it to somebody -- subscription based upon interest -- CIDF will address this.
      4. DOB: Second order signature that contain these events. How do we do that? Build trees [S1 U S2: S1.IP=S2.IP] è SS2. What are the common fields?
      5. KL: Trying to model attacks, sequence number guessing as an attack. Reasons why client isn’t responding, depends where sensor is. Router may be down. If SYN flooded or wedged, may not be able to find that. Intermediary piece that we could use -- apparent sources and sequence guessing. Universal to all attacks or unique. Taxonomy of attacks.
      6. JR: Source and destination of packets but also true source (not spoofed). KL: Sequence number unique to sequence guessing. Microtheory for attacks. Inheritance. Hierarchy of microtheories -- JR: Microtheory for wedging, IP spoofing for wedging and sequence number guessing. JS: Layers of signatures DK: Huge taxonomy of attacks JS: Synthesize taxonomy.
      7. All possible symptoms whether we see them or not, whether we have to poll for them, send to someone else KL: Procedural knowledge.
      8. KL: Take a while to characterize attacks. One host or more than one host. Sit down and list of all aspects of attacks that we can think of. DK: Constant stream of security terms, KL: Strategic intrusion detection.
  5. Worm Example
    1. DK: In a situation where machines are well attended, a worm that propagates by vulnerability will propagate by a small number of vulnerabilities. There’s certainly worms whose path can be inferred because they only go for a couple of operating systems. Increase in attempt to find out which OS is running. SGI, RedHat Linux Demon, more prone to pop. More telnets. Increase of info gathering.
      1. DOB: One more than you codify.
    2. KL: First discover if it’s a worm. What is the worm trying to accomplish?
      1. If Jeff’s worm, harder to track down. Stealth is a key to that attack. Not going to have shot gun portscans. Two goals -- 1) worm going after something; 2) worm for worm’s sake. Significant difference in behavior.
      2. KL: Stealth worm propagates more slowly. Doesn’t try to reinfect, removes itself from machines. JS: Individual flag raised for each vulnerability.
    3. GrIDS Interpretation
      1. JR: GrIDS won’t pick this up until it sees this traffic. It will send out an alarm, depending on the rule set you’re using and you r configuration. DK: Lots of telnet without logins (anomaly); a telnet with no login. Easy to detect, but no one keeps track of it. Keep track of a packet by packet account of Telnet session until it is successful. Doing trust scanning like Jeff was doing -- another possible symptom. No attempt to login is required.
      2. JS: In GrIDS does it need an IDS device? JR: Yes, you’d have to specify edge in GrIDS -- incomplete telnet. Basic definition of a worm are connections between machines where the destination becomes source of further connections -- traffic that in time, goes from one machine to another and spreads.
      3. DK: Before getting past first node, see a number of incomplete telnets. JS: First example with something behind measure of certainty. 3 of the 4 or 12 conditions.
      4. KL Worm could propagate without knowing the OS. DK: Then you’ll still get trust scanning, increase in failed one-login attempts. Decreasing false alarms. JR: Integrate host-based info with network based info. DK: Network level see failed telnet login attempts? JR: Sure, but worm won’t care about which OS is running. DK: At some point it must know which OS it’s attacking. KL: If running blind, it will have failures. JR: Notice nodes in graphs that becomes sources of further propagating -- Leaf nodes being Linux and interior nodes being non-Linux perfect signature of broadcast worm.
    4. KL: Signatures of signatures -- way of looking for more confirmation of worm.
      1. JS: Try to attach a list of propagating systems to a worm. KL: Demo detected a worm, normal activity that we don’t detect -- worm-like behavior in mail servers. JR: Include mail server in rule set. If propagating in port 25, you’ll miss part of worm in port 25, but not going everywhere else. Have to visit mail server every other hop -- limited in the number of machines you can propagate to.
        1. DK: Demo talk with Jason. Demo that can show sequence number guessing, false alarms. Signature of signatures -- code that up.
    5. JR: What about time-service updates?
      1. DOB: Assuming that there’s no vulnerability in that server. JR: Doesn’t our time server connect to other? DOB: Star effect -- all our machines hits a time server. JR: Over time looks like worm. KL: Worm to distribute a patch for a system. DOB: Broadcast and push technology. Channel broadcasters that can contribute at a global enterprise level. DK: Only on a very large scale. Three levels from my machine to world. JR: Anti-worm. NIS and News? DOB: So few that you’re not getting star effect beyond. NFS traffic will look like a worm where successive mounts are. See a burst of connections JR: See if a worm if more than 2 hops. Loosest rule set Mail, time, news, NSF, all machines going to one instead of vice versa. KL Number of nodes in graph. JR: Accounting of how many level deep. DOB: Worm due to trust mechanism, goes to one server. JR: True exponential fan-out is true problem with worm. Multiple machines against a server. DOB: Looked at 6 months ago. Close enough to target -- get into position. Worm looking at endpoint. KL: Take a linear non-expanding path through graphs.
  6. Future Directions (Next Week)
    1. Head toward an ad hoc model factor in more notions of attacks. Fit new attack more easily.
    2. Some other way of a client not responding. Just send a lot of email.
      1. DK: Might know bunch of machines down because of some virus.
      2. JR: How do you know it’s not responding? If it’s spoofing -- fake spoof ping. JS: Can’t really see what server is doing to the client. KL: HP Open View -- tell us if site is down. DK: Take machine down enough that tool doesn’t know it’s down.
        1. JR: Heard bad things from HP Open View. Hard to use, $30-40,000 , settled to TKINET Freeware.
        2. KL: Detect the server is sequence number guessing, client not responding, try pinging it to enumerate all ways we could discover info about client. JS: Procedural deal where signature catches sequence number, check to see if there’s a SYN flood or not. JR: Dynamic machine wedged. KL: Find out that we have some instrumentation on client, fork bomb on client, nothing to do with sequence number guessing. Seem to be disconnected. JR: Want a network wedge, internal wedge. Our Global Guard agent that manages the clients’ enclave is going to have an agent. A dynamic agent in client that can determine whether wedged or not. JS: Certainty idea -- agent notion of whether it’s good or not. In some other enclave, only have a network sniffer. Is it down? No, but I’m weak. Deal with that disparate ability in enclaves -- highly tooled and instrumented.
    3. KL: For next week, try to think about what we want to say about attacked useful for correlation. Think about generality we can come up with. CYC stuff -- ad hoc -- dealing with more abstract stuff.
      1. DK: Rules we come up with are ad hoc. JS: Deep knowledge base, not ad hoc.
      2. DOB to talk about distributed coordinated attack. JR: Worms fit more as a building block. DK: Series of attacks to move code onto machines. IP spoofing is completely built up from the components, sequence guess and wedging. Worm built up from trust scanning and this piece of code that launches it (worm). The tangible and intangible. Worm is partially tangible. Information bearing things. If worm code is partially tangible, then worm is the pattern of network traffic. Program itself is not the worm. Can’t have worm without the script.