Chapter 14: Intrusion Detection Need capability to detect:

Chapter 14: Intrusion Detection • Need capability to detect: • Network scans - activities intended to identify networks, hosts, • and available service - identifies potential targets. • 2. Vulnerability scans - activities intended to identify network, host, • and services that are susceptible to specific attacks - reduces the • target list to systems with known (to the attacker) weaknesses. • 3. Denial of Service - attacks that deny or limit legitimate users • ability to access a network or a host computer. • 4. Penetration - attacks intended to gain control of a network or • computer. Chapter 15 Intrusion Detection

Intrusion Detection An emerging technology, little is automated, much left to the hard work of manually digging through reams of data - but a priority. Purpose: Detect attacks/penetration - the obvious reason. Recover from successful attacks (need to know what has to be fixed). Damage assessment (how bad - # of systems, etc.). Despite limitations, detection in depth (layered) is the best course. Level 0 - System Logs - audit trail approach. Level 1 - Firewall detection and alert - audit trail + threshold. Level 2 - Host detection - anomaly detection. Level 3 - Dedicated Intrusion detection System - misuse detection. Combinations of the above are often used. Chapter 15 Intrusion Detection

Intrusion Detection - Definitions • Taxonomy of methods - based on the source of intrusion data: • Host-based - data from a single host computer. • Multi-host-based - data from multiple hosts. • Network-based - data based on content of network packets. • Combinations – host & network methods. • Intrusion detection models: • Anomaly-analysis - activity different from the norm or expected • behavior of a system - usually host-based. • Signature-based - activity that corresponds to known intrusion • signatures and/or system vulnerabilities - usually network-based. • Protocol-based – activity that corresponds to known intrusion • signatures – like signature, but more in-depth analysis. Chapter 15 Intrusion Detection

Characteristics of Effective Systems 1. The IDS runs continuously without human intervention. 2. The IDS resists subversion - self monitoring or hiding. 3. Minimal overhead - unobtrusive low performance penalty. 4. Difficult to fool: Few false positives - doesn’t cry wolf Few false negatives - doesn’t miss bad guys 5. Easy to use - install, configure, operate. 6. Frequent updates with latest information (like virus problem) Few products have all these characteristics – in most cases they don’t even come close. This is a very immature technology area! Chapter 15 Intrusion Detection

Intrusion Detection One of the issues is where to set priorities. First detection is often possible at the external network router and/or the firewall - good case for more diligence here. Some attacks are very obvious - half-open SYN port scan for one IP address over a range of port numbers. Some are not – the same scan spread out over several days with spoofed port and IP addresses - usually is below the firewall detection threshold (low and slow scans) - only requires patience on the part of the adversary - still can get all the data. This illustrates the difficulty for the IDS designer. Chapter 15 Intrusion Detection

Intrusion Detection - Logs Technically easy - socially difficult (who wants to look at logs?). Exist at many levels - router, firewall, server, workstation (NT). Problem: Logs are highly variable in content, format, and viewing – in most cases they are not well formatted or easy to use. In addition, logs can be erased by the attacker following a successful intrusion. Serious logs should be written to non-erasable media (CD) or hidden (non-standard names, stored at another location). Log retention is also problematic since logs become large very quickly and can consume lots of storage space. May need to go way back in time to detect the onset of a scan that became an attack and later an exploit. Chapter 15 Intrusion Detection

Intrusion Detection - Firewall • Some are easily Detected: • Port Scans -- many connect attempts on a wide variety of ports. • Service scans -- many connect attempts on a single destination • port but across many IP addresses (frequently every address • in the network address space). • Example Firewall Log – walking the IP address range Date/Time Act Pro Source Dest IP SrcPort DstPort Reason * / * drop tcp 195.68.23.180 172.16.101.37 18162 sunrpc rule 17 * / * drop tcp 195.68.23.180 172.16.101.38 18163 sunrpc rule 17 * / * drop tcp 195.68.23.180 172.16.101.39 18164 sunrpc rule 17 * / * drop tcp 195.68.23.180 172.16.101.40 18165 sunrpc rule 17 * / * drop tcp 195.68.23.180 172.16.101.61 18210 sunrpc rule 17 Chapter 15 Intrusion Detection

Intrusion Detection - Firewall • Some are much harder to detect: • Low and slow attacks with spoofed IP & port addresses • Reverse connection attacks - like XDM: • XDM is an X-Windows display manger that accesses a server • to provide display and negotiates port numbers. • This means users can send outbound traffic on any port and • opens up the possibility of an attacker having compromised an • internal XDM server and then use it attack you when you log in. • It is a good idea to deny and log all attempts to use outbound ports • except for known protocols to avoid hijacked sessions. Chapter 15 Intrusion Detection

Intrusion Detection - Host Often uses anomaly detection that compares observed activity to expected normal usage patterns based on organizational policy (rules) and historical statistical data. For example: Threshold monitoring: # failed login attempts/time, # logins at unusual times (e.g., day of the week, hour of the day). User profiling: specific behavior of a user. Resource profiling: accounts used, servers used, protocols, executables used (e.g., Word, Excel, Powerpoint) Main idea is to develop a pattern of use and on a significant deviation increase logging and/or set alerts. Very difficult to do well - not widely used. Chapter 15 Intrusion Detection

Intrusion Detection - Network By far, the most common method - many COTS packages Current issue – pattern search versus protocol analysis. Pattern search is based on pure signature detection - a database of signature strings is created and an analysis engine is used to examine the traffic and search for offending signatures – like virus scanning. Protocol analysis digs deeper by parsing the traffic string by protocol and then looking for offending signatures. Both have problems, but tradeoffs include: complexity versus speed. false positives versus missed events (false negatives). Chapter 15 Intrusion Detection

Intrusion Detection – Pattern Searching • Simple in concept: • Capture packets (e.g., tcpdump) • Pipe output to search engine (e.g., grep “string”) • Look for “bad” strings – called rules in SNORT (an IDS) • SNORT example: • alert TCP $EXTERNAL and  $INTERNAL 80 (msg: “PHF”; • flags: AP; content: “/cgi-bin/phf”;) • Causes an alert whenever a port 80 HTTP request is made to the • URL containing “/cgi-bin/phf”. • PHF was a program shipped with many early web servers that was • vulnerable to attack. Sending the offending string caused PHF to • execute and passed control to the intruder Chapter 15 Intrusion Detection

Pattern Searching – PHF continued Detection simply sniffs all packets to see if they contain the string “/cgi-bin/phf”. Trouble is - false positives are possible. Consider the HTTP request: GET /index.html HTTP/1.0 Host: www.blivet.com Referrer: http://www.blivet.com/cgi-bin/phf User agent: Mozilla/2.0 SNORT would alert on this string, but it is a false positive. It is false since cgi-bin/phf is the string from the referring URL. That is, it is not the target. Consider how the HTTP protocol is parsed on the next slide. Chapter 15 Intrusion Detection

Pattern Searching – PHF continued GET /index.html HTTP/1.0 Host: www.blivet.com Referrer: http://www.blivet.com/cgi-bin/phf User agent: Mozilla/2.0 Method = GET Target URL = /index.html Version = HTTP/1/0 Fieldname = Host HTTP_HOST = www.blivet.com Fieldname – Referrer HTTP_REFERER = http://www.blivet.com/cgi-bin/phf Fieldname – User-Agent HTTP_USERAGENT = Mozilla/2.0 FALSE POSITIVE Chapter 15 Intrusion Detection

Pattern Searching – PHF continued Conclusion: The simple search string method alerts on a ‘safe” packet. If the protocol had been parsed and only the target URL tested, then the false positive would not have occurred. Lesson: Protocol analysis intrusion detection reduces false positives. BUT, are they worth the effort in terms of speed, complexity, etc. We shall see later. Consider another complexity – adversaries hiding their tracks. Chapter 15 Intrusion Detection

Detection Evasion I – Hiding in Plain Sight Don’t expect intruders to cooperate – they will evade you if they can. Method # 1: form-url-encoding of the target URL For “/cgi-bin/phf” substitute the UNICODE encoding: %2F%63%67%69%2D%62%69%6E%2F%70%68%66 This is the Unicode Translation Format 8 (UTF-8) for cgi-bin/phf where: / = %2F; c = %63; i = %69, etc. To detect the IDS must translate UTF-8 encoded data back to standard ASCII before sending it to the pattern matching engine. SNORT has such a plug-in (developed in response to the attack). Chapter 15 Intrusion Detection

Detection Evasion I – Hiding in Plain Sight Method # 2: Padding - Simple Network Management Protocol. SNORT signature for intrusive access NT user account information: alert udp !$HOME_NET any  $HOME_NET 161 (msg:”NETBIOS- SNMP-NT-UserList”; content:”|2b 06 01 04 01 4d 01 02 19|” Problem: SNMP allows padding that it strips (example, pad with 80). 2b 80 06 80 01 80 04 80 01 80 4d 80 01 80 02 80 19 Called smudging – SNORT will miss unless, it has an SNMP parser that removes the pad before testing – the parser is protocol-specific. Chapter 15 Intrusion Detection

Detection Evasion II – Fragmentation IP is capable of fragmenting datagrams and all vendors support it. Used to allow traffic to cross networks that have packet size limits. (i.e., IP will support packet lengths to 65kB, Ethernet is limited to about 1500 B, and FDDI to 4470 B). Any packet may be subject to fragmentation. In fragmentation a packet is divided into smaller parts, the IP header is replicated (IP identifier copied) and the offset field points to the fragment (i.e., the 1st fragment has offset = 0, next has offset = 0 + fragment length, and so on). Like saying page 1 of 3, but the offsets are Bytes instead of pages and supply the destination computer with the information needed to re-assemble the packets in the proper order. Chapter 15 Intrusion Detection

Detection Evasion II – Fragmentation The bad guys use this capability to evade IDS detection. Here’s how: Assume: A site has an IDS and firewall. A site allows port 80 (web) traffic through the firewall. IDS looks at port numbers – alerts on all non-80 traffic. Bad guy: Builds fragmented packets. First TCP in the IP stream specifies port 80 as the destination – IDS says OK, lets it through. Second packet is created so it overlaps the first and the overlap changes the port number. The IDS doesn’t look at the second packet – it looks at destination address and packet ID, knows it belongs to the same fragment stream as the previous packet and allows it through. Chapter 15 Intrusion Detection

Detection Evasion II – Fragmentation TCP Header Payload IP Header Port # | -------------------Fragment # 1 ------------------------------| Correct fragment offset = 21 Bytes Port # | --------------------- Fragment # 2 --------------------| Incorrect fragment offset = 19 Bytes The destination assembles the fragment. Instead of the second fragment following the port #, it overwrites the port number. If that port is open – the rest of the packets could be an exploit! IDS never sees the real exploit. Chapter 15 Intrusion Detection

Performance – Pattern versus Protocol Analysis Conditions: Code for pattern matching is simple – a few lines. Code for protocol analysis is much more complex – many lines. Common reasoning: Pattern matching is faster, easier to code. Reality: Pattern searches use linear code – each operation is simple, but as the number of patterns increases, the search database gets very large. As # of signatures increases this becomes a problem: 1. Get string, Compare string to signature x, On match alert 2. Increment x (signature entry) 5. Go to 2 One pass is fast, but many passes are required. 2 x signatures = ½ Speed. Order n ~ O(n) complexity where n = # signatures. Chapter 15 Intrusion Detection

Pattern versus Protocol Analysis (continued) Protocol analysis is different – it can be represented by a decision tree – the tree is parsed, or walked, from top to bottom. At each branch a binary decision is made to go left or right. Only one path from the root to the last leaf is traversed. Faster since complexity is halved at every branch. The means the Order of complexity is log n ~ O(log n) where n = # protocols. Chapter 15 Intrusion Detection

Protocol Analysis – Strengths & Weaknesses Faster than pattern matches for large numbers of signatures (reality today). Reduces # of false positives compared to simple signatures Performance is sensitive to traffic & protocol variations. Since the detector processes headers, small payloads protocols can overload the system (e.g., UDP traffic, small web pages, SNMP). Large payload packets mean fewer headers to process for a particular line speed. Commercial systems are going to protocol analysis because they are reaching the limits of signature-only analysis. Chapter 15 Intrusion Detection

Intrusion Detection – Weaknesses • Like all security measures – not a panacea – but some pundits are • predicting the death of IDS – WHY? • Evasion where IDS rejects the packet, host accepts the packet. • Insertion of packets seen by IDS, rejected by end host computer. • Encryption at the IP layer nullifies – can’t read TCP header – same problem faced by virus detectors for encrypted e-mail – no read/no detect! • Speed of networks = IDS can’t keep up - drops packets. Chapter 15 Intrusion Detection

Intrusion Detection – Evasion IDS Weakness Assume an attacker wants to send a string to a host that allows Intrusion. For example, QR ( a fictional bad string). Assume the IDS is tuned to detect the QR string as bad and alert. Bad host send a SYN with non-zero payload = Q. IDS sees SYN, doesn’t parse payload until after 3-way handshake. Host gets SYN, responds and retains the payload Q, finishes handshake. Bad host sends data packet containing R. IDS sees R, has no bad signature, does not alert, and good host accepts R, which opens a vulnerability. Bad host has evaded detection by the IDS. Chapter 15 Intrusion Detection

Intrusion Detection – Insertion IDS Weakness Same scenario as evasion – Bad host wants to send QR string and IDS detects QR as a bad string. Bad host establishes a connection with the 3-way handshake. Bad host sends data packet containing Q. IDS sees Q – it is OK alone. Bad host sends A, but with a bad TCP checksum. IDS does not compute TCP checksum, tests QA for bad signature, does not alert. Host gets A packet, computes checksum and discards the packet. Bad host sends R, IDS now has QAR, does not alert. Good host gets R packet, accepts it, now has bad guy QR string! Chapter 15 Intrusion Detection

Intrusion Detection – Result • Death no, change yes. IDS will parse deeper and get faster, but no easy • Solution for the encryption and speed problems. • IDS will have to move out to the end machines. • That is where the message is decrypted. • That is where the protocols are totally parsed anyway. • Doesn’t slow down the network (slows down the host). • This means adding IDS as a part of the base machine that checks after • decryption and parsing for unsafe activity – great research project. Chapter 15 Intrusion Detection

Intrusion Detection – Host vs. Network • Which is better? – WHY? – It is a trade-off • For Host (anti-network) • Network may be too fast – can’t keep up (esp. large sites) • Network may be switched – limits scope of sniffing • Traffic may be encrypted – if strong – can’t read • Basic insertion/evasion weaknesses • May miss backdoors – like dial-out modems • For Network (anti-host) • Can focus on perimeter – where most attacks originate • Host deployment issue – nibbled to death by the ducks (cost & • management of large numbers is problematic) • Bandwidth issue addressed by moving sensors downstream (more • sensors at lower bandwidth locations – before traffic aggregation) • Logs are more manageable & more likely to be read Chapter 15 Intrusion Detection

Intrusion Detection – Host vs. Network OK – your mileage may vary – What is the bottom line? As bandwidth increase & sensors move to lower bandwidth locations you are moving closer to the host – at the limit you are at the host. Encryption has the power to kill network IDS. Decryption occurs at the host and is the only place the final end activity can be observed. Implies that there needs to be some sort of central aggregation of host IDS logs, looked at automatically with event notification. Why? – Too many users can’t (not capable) or won’t look at logs (like the seat belt problem) Presently, this effort is beginning, but is rudimentary at this time. Chapter 15 Intrusion Detection

Intrusion Detection - Host Packages - Unix • TCP Wrappers, Purdue, freeware – comes with many Unix distributions • Monitors, logs, & filters incoming TCP/IP traffic under user control • Psionic Port Sentry – TCP wrappers on steroids • Block in real-time, keeps history, detect scans, re-direct traffic • Syslog – Standard Unix utility – good detector if configured right • Tripwire, Tripwire Security Systems, Inc. (free and COTS versions) • - Uses cyrptographic hashes for some/all systems files, detects changes • SMARTWatch, WetStone Technologies, Inc. • Intruder Alert, Axtent Technologies Chapter 15 Intrusion Detection

Intrusion Detection - Host Packages - Windows • Standard Tools – NT/2000/XP • Event Viewer – To look at all logs • Netstat – Active and listening TCP port listing • (fport is similar freeware with enhanced features) • - Microsoft has a Resource Kit with more tools – in bookstores & cheap • Tripwire for NT – especially useful to watch registry changes • SMARTWatch, WetStone Technologies, Inc. • - Similar to Tripwire, an integrity watch tools • Intruder Alert, Axtent Technologies • - Watches logs and performs analysis, also has Tripwire functionality Chapter 15 Intrusion Detection

Intrusion Detection - Network COTS Packages Network-Based RealSecure - Internet Security Systems, Inc. Flight Jacket - Antzen Computing, Inc. Net Ranger, Cisco Systems, Inc. Network ICE – network ICE Corp. SNORT – freeware Host-Based TCP Wrappers Port Sentry Tripwire, Tripwire Security Systems, Inc. SMARTWatch, WetStone Technologies, Inc. Intruder Alert, Axtent Technologies Chapter 15 Intrusion Detection

Intrusion Detection - RealSecure Method: Net-based, packet sniffer, signature-based. Monitors: Java applets, specific key-words, specific URLs. Interfaces: Ethernet, FDDI, Token Ring (no GigE, T3, ATM, ISDN) Protocols: DNS, HTTP, FTP, SMB, NFS, SNMP, TELNET, SMTP, UDP, TCP, ICMP, IP, NetBIOS Updates: posted to the web Initial Release: 1991, three versions have released Cost: ~$16,000 Chapter 15 Intrusion Detection

Intrusion Detection - Flight Jacket Method: Net-based, packet sniffer, signature & protocol-based. Monitors: e-mail content, specific URLs, system behavior. Interfaces: Ethernet, FDDI, (no Token Ring, GigE, T3, ATM, ISDN) Protocols: DNS, HTTP, FTP, NFS, SNMP, TELNET, SMTP, RSH X-Win, SSL/SSH, UDP, TCP, ICMP, IP, IPX, NetBIOS Updates: posted to the web Initial Release: 1997, two versions have released Cost: ~$15,000 Chapter 15 Intrusion Detection

Intrusion Detection - Net Ranger Method: Net-based, packet observer, signature-based. Monitors: Key-words. Interfaces: Ethernet, FDDI, T3, Token Ring (no GigE, ATM, ISDN) Protocols: DNS, HTTP, FTP, NFS, SNMP, TELNET, SMTP, UDP, TCP, ICMP, IP Updates: With new release, working on web update. Initial Release: 1996, two versions have released Cost: ~$25,000 Chapter 15 Intrusion Detection

Intrusion Detection - SNORT Method: Net-based, packet sniffer, signature-based with protocol extensions. Monitors: Signature strings, Key-words. Interfaces: Ethernet, SLIP, and PPP (ATM under development) Protocols: DNS, HTTP, FTP, NFS, SNMP, TELNET, SMTP, TCP, ICMP, IP Updates: Variable. Initial Release: ???, several versions have released Cost: Free at www.snort.org Chapter 15 Intrusion Detection

Intrusion Detection - Tripwire Method: Host-based, file system protector, signature-based. Monitors: file integrity. Interfaces: N/A Protocols: N/A Updates: N/A Initial Release: ? Developed at Purdue, 1998, went commercial Cost: free version for Unix, supported version = $260 Chapter 15 Intrusion Detection

Intrusion Detection - SMARTWatch Method: Host-based, NT OS & file system observer, signature-based. Monitors: files, directories, registry, web pages for changes (integrity). Interfaces: N/A Protocols: N/A Updates: with new release Initial Release: ? Cost: ~$? Chapter 15 Intrusion Detection

Intrusion Detection - Intruder Alert Method: Multiple host-based, file, OS, application observer, signature-based. Monitors: Watches logs for suspicious behavior. Interfaces: N/A Protocols: N/A Updates: posted to the web every 2-3 weeks. Initial Release: 1992, three versions have released. Cost: ~$1,995 master, $995 each server, 495 per workstation. Chapter 15 Intrusion Detection

Establish an Incident Response Capability • Six stages of incident response: • Preparation – plan of action – who does what, when, & how. • Detection – Categorize the event. • Containment • Eradication • Recovery • Follow-up Chapter 15 Intrusion Detection

Incident Response - Preparation • Establishes a detailed response plan – rules of engagement • Event reporting policy – who reports and to whom. • Event declaration – Who declares an event & forms a response team • Authorities and actions – Who is in charge, what actions are taken. • Reporting - Chapter 15 Intrusion Detection

Incident Response - Detection • Event categories • Privileged Access – Root level compromise. • Limited Access – User level compromise. • Scanning – IP or port mapping, OS fingerprinting. • Denial of Service – Loss of performance, availability, or functionality. • Virus or worm – • Misuse – Acceptable use policy violation Chapter 15 Intrusion Detection

Distributed Denial of Service Attacks - DDoS Not necessarily new, but rapidly maturing and expanding - now available for WINTEL machines. Mid-late 1999, several sites experienced distributed DoS attacks. First attacks identified were “Tribal Flood Network (TFN)” and “trinoo”. By 2/00 other variants were detected (TFN2K) and STACHELDRAHT On 2/7/00 the Yahoo web site was attacked with these tools and taken down for 3 hours. On 2/8/00 additional sites including cnn.com, amazon.com, buy.com, ebay.com, stamps.com, exodus.com, etrade.com, and zdnet.com were attacked. Chapter 15 Intrusion Detection

DDoS Attack Model Attacker Masters Daemons Target Chapter 15 Intrusion Detection

DDoS Attack Model Target - Site under attack Daemons (also now being called Zombies) - From a few to several hundred systems. Preference is that these be powerful machines, but that is not necessary. In some cases these have been found to be home computers connected by cable modem or digital subscriber line (DSL). Masters - Essentially the same as daemon machines, but run a master control program that can cause daemons to launch attacks on a specific target. Step 1: Break in to a host machine Step 2: Install a master or daemon program (this initial break-in process has been largely automated with scripts) Step 3: Continue to acquire masters/hosts. Step 4: Launch an attack by commanding the masters, and thereby the daemons, to launch DDoS attacks on a specific target. Chapter 15 Intrusion Detection

DDoS - Significant Problems 1. Attacker exploits a vulnerability, most often well known. 2. Attacker spoofs the source IP address to hide the original source. 3. Attacker uses other masking techniques: A. Using multiple hops to reach the system the master or daemon will be installed on. C. Cleans up files and hides the presence of the master and/or daemon. D. When the attacker is on-line, notify if a legitimate user logs onto the system being used to host the master or daemon. Chapter 15 Intrusion Detection

DDoS - Vulnerability Prevention Close all known vulnerabilities on all Internet attached systems. Very hard to accomplish. One way is by a host firewall, like BlackIce. Even if 99% are protected, that leaves lots of systems available. At the highest level, there is little a particular site can do to prevent these DDoS attacks. While a site can take steps to harden systems so they are not compromised and masters or daemons installed, there is nothing a site can do with current technology to prevent becoming a victim of a coordinated attack. In short, the potential impact on a particular site is a function of the security at other sites. Chapter 15 Intrusion Detection

DDoS - Spoofing Prevention Since IP addresses are originally spoofed, it is almost impossible to trace them back to their sources, but the following can be done to avoid spoofing. All hosts must go through a firewall and/or a router to get to the Internet. Assume a firewall - it should: 1. Never allow a packet into the network that has a source address that is interior to the network - since only interior machines can have these addresses 2. Never allow a packet to leave a network with a source address other than an address assigned to the network - then can only spoof another legal internal address. 3. Never allow an illegal source address to go in or out of a firewall. Chapter 15 Intrusion Detection

DDoS - Tracking the Source Draft rfc by Bellovin, AT&T Proposed Internet Control Message Protocol (ICMP) traceback message. ICMP is a protocol used primarily by routers to exchange information. (that is not important to the concept) What is needed is information about the path packets follow from the source to the destination - would like to have the whole path defined! So… create a new ICMP message type = traceback Chapter 15 Intrusion Detection

DDoS - ICMP Traceback As a router forwards messages, it will, with some small probability, say 1:20,000 packets, issue an ICMP message and send it to the destination address contained in the packet. The message contains: 1. Back Link - defining where it came from (e.g., the IP address of the previous hop - router) 2. Forward link - information on the next hop - to where it is going 3. Timestamp 4. Packet content - part or all of the packet associated with the trace 5. Authentication - to avoid false traceback messages intended to confuse the destination. The destination gets these packets and they are ordinarily discarded, but they can be retained - and would be if under attack. Chapter 15 Intrusion Detection

ICMP Traceback Source ISP Router Internet Router Internet Router Firewall Dest. Assume the source launches a DoS attack at the destination address. Over time, each router in the path will send messages to the destination. If each router send its backwards & forward address, by the time all have sent an address, the destination will have enough information to fully specify the path from the source to the destination. This is a new draft - 3/2000 - at the moment it is just a discussion paper - it may/may not be supported to take to the next step - to begin to make it an official rfc. Chapter 15 Intrusion Detection

Chapter 14: Intrusion Detection Need capability to detect: