Interoperability and Architecture

1 IDIC – SANS GIAC LevelTwo ©2000, 2001 1 First Principles Continued Interoperability and Architecture Hello, and welcome to the second half of the First Principles section. In the previous hour, we went over a sample tool, Pepsi, the UDP flooder, that attackers may be using to attack our networks. We discussed the role of firewalls in intrusion detection. Now, we will move on to discuss several efforts to promote interoperability among intrusion detection systems, and examine various methods of processing alerts and reacting to suspicious events. 2 IDIC - SANS GIAC LevelTwo ©2000, 2001 2 Intrusion Detection Interoperability (CVE, CIDF, IDWG) Let us begin by introducing several acronyms that will be used in the next few slides: Common Vulnerabilities and Exposures (CVE), a thesaurus for vulnerabilities. Common Intrusion Detection Framework (CIDF) is a proposed standard to allow interoperability between intrusion detection components. Intrusion Detection Working Group (IDWG) is the Internet Engineering Task Force (IETF) Security working group for intrusion detection. Since we draw information from the RFC the copyright is shown below. “Copyright (C) 2000 The Internet Society. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.” 3 IDIC - SANS GIAC LevelTwo ©2000, 2001 3 AusCERT Auto Extract These trailers are designed to facilitate automated extraction of information by AusCERT. Source: 210.177.64.1 Ports: tcp 111 Incident type: network scan re-distribute: yes timezone: GMT + 1300 reply: no Date: 30th Jan 2000 at 22:01 (UTC) The trace above is most likely a probe for portmap, (TCP port 111). This is one of the most common and successful attacks on the Internet. Its format gives us all the basic information we need from a trouble ticket standpoint. By this I mean it is great for a site that is reporting well known attacks to a CIRT. If we needed to do analysis or provide answers , however, this simply would not do. In that case we would need access to more information. This is a working system is very useful for statistical analysis and understanding trends. You will see the format many times on GIAC. In AusCert’s own words, “these trailers are designed to facilitate automated extraction of information by AusCert.” They represent a method of adding information to the AusCERT database without manual human intervention. 4 IDIC - SANS GIAC LevelTwo ©2000, 2001 4 Griffin List A simple data exchange format similar to the AusCERT format will allow sites to create a Griffin list, or watch list, of the IP addresses that have been used to attack and probe and also the ports involved. A Griffin list is a powerful tool used by casinos to identify well known cheaters and hustlers. Photos from the Griffin files are compared with a target on the security camera. Facial features and characteristics that do not change over time are used as a metric for matching a suspected cheater with the Griffin file photo. Every site should consider both using Griffin lists and contributing to them. There are several available from GIAC at http://www.sans.org/current.htm. In the same way that you might want to compare all traffic that comes to your site to a list of proxy servers, you might also want to run a Griffin list against your traffic. It serves as an indicator to investigate certain traffic more closely, and it can help you find things you might otherwise miss, or dismiss. If you are willing to submit a list of the IP addresses that attacked your site to GIAC or another CIRT, but sure to send it to only ONE SITE that constructs a Griffin list or you’ll risk introducing serious errors into the routines that evaluate how many times an attacker has been seen. 5 IDIC - SANS GIAC LevelTwo ©2000, 2001 5 INTERNET Single system, single site - the only interoperability needed is between the event generator, analysis console, database and response. In this scenario, an attempted penetration of the firewall is detected; the response system (firewall) drops the connection. S A M R What is a possible IDS architecture that would facilitate automated response to an incident? Take a look at the diagram on this slide. The “S” represents the sensor. The “A” represents the analysis box. The “R” represents the response system, and the “M” represents the management station of the system. In this case, if a penetration attempt is detected, the response system (firewall) drops the connection. Some people put both sensors and analysis boxes on the same computer, but this might not be a wise architecture. Intrusion detection systems outside the firewall are in a hostile location and should know as little about the internal security architecture as possible. If an intrusion detection system is compromised, the attacker may learn too much about the site from its rule set. So, be sure to keep a close eye on an IDS that is placed in front of a firewall! The paradigm on this slide’s diagram is that using auto-response, we could get reports to CIRTs within 10 to sixty seconds of the actual detect. This turnaround time might allow them to do a traceback. This slide represents one of the primary choices in auto response, such as blocking the perceived attacker from your network. If you want to implement auto response, then be sure that your system has a capability for putting your friends and business partners on a “slo blo” system. Otherwise, an attacker can disrupt your operations by spoofing your partner’s IP and attacking you, which in turn sets off the defense system that would render your partner unable to do business with you. 6 IDIC - SANS GIAC LevelTwo ©2000, 2001 6 INTERNET In an attack situation, multi-homed sites or partners may need to exchange response information. To do this they need a common thesaurus, transport, and data model. S S S M M One of the strengths of a standard like CIDF/CVE/IDWG is demonstrated by this slide. Consider the case of a merger between two companies with different networking and intrusion detection strategies. In such a situation, a single company solution could be a real pain. The requirement is simply to be able to exchange information. Another compelling reason for interoperability is in the notion of specialized analysis engines. Detection and response are both easier than analysis. For instance, as viruses and Trojans continue to be a bigger and bigger nuisance, many sites are moving towards content scanning at their firewall. This is often done by a specialized content scanner. We expect that this will be the same thing in intrusion detection, that as the number of signatures approach the number of the anti-virus world, with some significant overlap between, there may be specialized analysis and response boxes. Currently, each approach has its strengths. CVE’s is its thesaurus; IDWG’s is its transport and data exchange. CIDF, though all but obsolete at this point, is most useful as a conceptual framework. However, don’t let the slide fool you into believing in the interoperability of CIDF/CVE/IDWG. In the end, the most likely winner will be the IDWG. 7 IDIC - SANS GIAC LevelTwo ©2000, 2001 7 The problem of Babel Because there is no standard taxonomy for the checks these scanners perform, directly comparing the comprehensiveness of their databases is difficult. We found that Internet Scanner and CyberCop name the same vulnerabilities differently …. InfoWorld, Feb 1999 CVE is a common thesaurus, not a taxonomy CVE grew out of MITRE’s internal work. David Mann and Steven Christey were working on a vulnerability database. They sought to map tool results for system information to alerts or fix information. Then, they hit the naming problem. For instance, the CGI phf program allows remote command execution through shell meta characters. We have all seen this attack from the classic exploit attempts that cat the /etc/passwd file. CERIAS calls this httpd_escshellcmd and CERT calls this CA-96-06.CGI_Example_code, and on it goes. So how do you know each of these is the same attack? They did a web literature search on vulnerability taxonomies, which led them to the work at CERIAS. They found out that everybody had the same problem they did. In November 1998, Dave and Steve started looking at how other scientific disciplines handle naming. This led to a paper entitled ‘Towards a Shareable Vulnerability Database’, which was presented at the 1999 CERIAS Workshop on Vulnerability Databases. They developed the concept of a common language for vulnerabilities. Since everyone suffered from the same problem, this idea resonated with the attendees. Note that taxonomy is the science of classification. CVE is a common thesaurus, not a taxonomy. CVE endeavored to name the attacks, as opposed to formally classifying them. 8 IDIC - SANS GIAC LevelTwo ©2000, 2001 8 Overlaps and holes CVE Name Tool A Tool B DB 1 DB 2 Hacker Site CVE-XXXX-0001 X X X CVE-XXXX-0002 X X X CVE-XXXX-0003 X X CVE-XXXX-0004 X X X X HTTP://CVE.MITRE.ORG The problem described on the previous slide is exemplified in this table. The X’s show which tool, database, hacker site supports a CVE vulnerability. Not only are there different names, but also tools with holes that are not covered. In intrusion detection we have found that there are very good reasons to use more than one tool to get better coverage. Shadow, for instance, is a good broadband scanner and will detect a wide variety of connection events. It is not optimized for content matching, however. If you take an IDS that is good at content and focus it on areas where you have concern, you will get excellent coverage. Now this is the intuitive approach. What if you want to use two IDS systems that are similar? For instance, false positives are a really big problem. What about using each IDS for the detects it is best at? That could make life better for the analyst. If, and only if they both have a common vocabulary, you can use their strengths while avoiding their weaknesses. 9 IDIC - SANS GIAC LevelTwo ©2000, 2001 9 CVE Compatibility • Tool or database takes CVE names as input. • Tool or database can be configured to produce CVE names as output. Say you have completed GIAC LevelTwo vulnerability assessment training. You would then know the common vulnerabilities that were most often used in attacking systems. This is an example of the use of CVE as output. Next you would want to scan your organization for these common vulnerabilities, say with ISS Security Scanner, a CVE compliant tool. You could feed the scanner this list of vulnerabilities as input and scan for these particular holes. If your choice of a vulnerability scanner is not CVE compatible then you would have to manually decide if these were the correct ones since there are multiple names for vulnerabilities. It can be hard to be sure that the vulnerabilities found are, in fact, the common vulnerabilities that you were scanning for. 10 IDIC - SANS GIAC LevelTwo ©2000, 2001 10 Summary – CVE facilitates Data Sharing • Intrusion detection systems • Assessment tools • Vulnerability databases • Researchers • Incident response teams We have discussed a number of aspects of CVE, but if we could characterize it in a single sound bite, CVE is a tool that facilitates data sharing among diverse components. Data sharing is necessary among computer-based components such as: intrusion detection systems, assessment tools, and vulnerability databases, as well as human participants in the security field – researchers, incident response teams, and intrusion analysts. Now, let’s move on to the next piece of the interoperability puzzle. You next slide is titled “CIDF as a Language.” [...]... requirements and lay the groundwork for later efforts CVE is perhaps the most widely-adapted piece of the puzzle at the moment CVE seeks to standardize the names that are used to refer to vulnerabilities Standards developed by IDWG may facilitate interoperability by defining a language and protocols for exchanging data between intrusion detection systems and components 19 Signatures,time and detect flow... IDMEF “is intended to be a standard data format that automated intrusion detection systems can use to report alerts about events that they have deemed suspicious The development of this standard format will enable interoperability among commercial, open source, and research systems, allowing users to mix-andmatch the deployment of these systems according to their strong and weak points to obtain an... Interoperability Summary • Interoperability standards slowly maturing • CVE defines names for vulnerabilities • CIDF defines language for ID components communication • IDWG formalizes data exchange procedures IDIC - SANS GIAC LevelTwo ©2000, 2001 19 Let’s summarize what we discussed so far in relation to interoperability between intrusion detection components The standards for ID interoperability are maturing... Group is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems, and to management systems which may need to interact with them.” Things are starting to pick up here and there are going to be a lot of significant changes Currently, a number of groups are attempting to develop prototype implementations and are learning a lot from the... sensors, firewalls, system logs and other sources of information is focused on the contents of the packet Most burglar alarms are primarily content based tools As we go over some attack signatures in the next slides, keep in mind the distinctions between traffic and content analysis You next slide is titled “Signatures Example” 24 Signature Examples • TCP 139 and Out of Band • SYN and FIN flag set • GET cgi-bin... flow and process of detecting and reacting to intrusions 20 INTERNET IDS Most Intrusion Detection Systems avoid the issue of knowing the firewall policy and simply look for indicators of known attacks called signatures This is OK until we look at issues related to response IDIC - SANS GIAC LevelTwo ©2000, 2001 21 Most Intrusion Detection Systems avoid the issue of knowing the firewall policy and simply... not the content Correlation and profiling are two of the most powerful TA tools IDIC - SANS GIAC LevelTwo ©2000, 2001 23 This slide, and the one that follows contrast Traffic Analysis (TA), also referred to as header analysis, against the primary technique in play, content analysis and string matching Either technique can be done in “real time” or at least near real time and “post mortem” or retrospective... information and resources and so that intrusion detection components can be reused in other systems.” CIDF represents not only a common data model, but also a language to communicate between components using the common model For instance, if two components need to reference something in which the hostname is involved in some activity, we need to have a standard language to reference the hostname To understand... in perimeter security In addition, packets with SYN and any other tcp flags set except for RST are flagged as well This is due to end systems handling them in different ways - to wit: Microsoft NT treats a SYN|FIN as a raw SYN and happily returns a SYN|ACK This should alert you of more sophisticated attempts to circumvent filters 25 Test cgi-bin and /etc/passwd % grep 2 GET 2 GET 2 GET 2 GET 2 GET... S-expressions 11 Intro to S-Expression (Hostname ’www.sans.org') This S-expression groups two terms, Hostname and ’www.sans.org' It should be noted there isn’t a binding relationship between Hostname and a host name (www.sans.org) IDIC - SANS GIAC LevelTwo ©2000, 2001 12 Hostname is an S-Expression atom and so is ‘www.sans.org’ There is no requirement for the hostname argument to be bound to www.sans.org . GIAC LevelTwo ©2000, 2001 1 First Principles Continued Interoperability and Architecture Hello, and welcome to the second half of the First Principles. development of this standard format will enable interoperability among commercial, open source, and research systems, allowing users to mix -and- match the deployment