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 />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.”
11
IDIC - SANS GIAC LevelTwo
©2000, 2001
11

CIDF as a Language
- Raw event information, (e.g., audit trail
records and network traffic)
- Analysis results, (e.g., descriptions of
system anomalies and detected attacks)
- Response prescriptions, (e.g., halt
particular activities or modify component
security parameters)
The language is written in S-expressions
This slide is the heart of why you should be familiar with CIDF. The researchers sat down and
asked: what is the heart of interoperability; what do we have to be able to do? Their answer is shown
on this slide. The simple AusCERT format we looked at earlier is not sufficient for interoperability;
it does not meet any of the criteria on the slide.
According to the CIDF Web site at />“The Common Intrusion Detection Framework (CIDF) is an effort to develop protocols and
application programming interfaces so that intrusion detection research projects can share
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 the basis of this language, we must talk briefly about S-expressions.
12
IDIC - SANS GIAC LevelTwo
©2000, 2001
12
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).
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. That is, you could just as well say (Hostname
‘888-555-1212’). This isn’t a problem as long as people write intelligent programs, but we all know
the dangers of untyped programming languages.
It’s as if Hostname is the variable to reference hostname for all components in CIDF, and the value
bound to that changes to reference the exact hostname we need to specify.
The next slide offers an example of a slightly more complicated S-expression.
13
IDIC - SANS GIAC LevelTwo
©2000, 2001
13
Example S-Expression
(Delete
(Context
(HostName 'first.example.com')
(Time '16:40:32 Jun 14 1998') )
(Initiator
(UserName ’lp') )
(Source
(FileName '/etc/passwd') )
)
/>The URL above points to a paper on CIDF. Here is a slightly modified quote from that paper that
explains this S-expression:
This S-expression is a complete sentence asserting that the user with username ’lp’ deleted the file
'/etc/passwd' from the host 'first.example.com' at 16:40:32 on Jun 14 1998. This example highlights
special kinds of Semantic Identifiers, or SIDs, such as verb SIDs, (in this case delete), that show
what happened. It also shows role SIDs (e.g., Context, Initiator, and Source), that portray

"whodunit", what it was done to, where it was done, and so forth. Other SIDs give details (such as
the time) about these various components of the event.
14
IDIC - SANS GIAC LevelTwo
©2000, 2001
14
Example Atomic SID
Name: Severity
Code: 00000007
Type: octet
Description: The severity of an event, as measured by
the observer. A value of 0 means that the event is
believed to represent no risk to the system, (again, this
shouldn't be used very often). A value of 255 expresses
maximum severity. What represents maximum severity
will clearly vary from system to system. In other words,
caveat receptor.
Obviously, this is a simplistic view of severity as the slide warns. If we wanted to have an S-
expression similar to the one on the previous slide that incorporated the SID Severity, we would take
what we had before:
(Delete
(Context
(HostName 'first.example.com')
(Time '16:40:32 Jun 14 1998') )
(Initiator
(UserName ’lp') )
(Source
(FileName '/etc/passwd') )
)
… and basically just add some parentheses and the SID to keep track of the severity of this event…

( Severity 127)
)
15
IDIC - SANS GIAC LevelTwo
©2000, 2001
15
CIDF Summary
• Potentially provides the building
blocks for full court ID
• Provides a common vocabulary to
discuss ID issues
• Overtaken by IDWG?
Primary CIDF site: />To summarize, CIDF attempts to provide a common language and vocabulary for components of
intrusion detection systems to “discuss” ID issues. While CVE limits itself to names of
vulnerabilities, CIDF attempts to describe a much wider range of ID aspects, such as event
information, analysis results, and response procedures.
The current status of CIDF is unclear, though some of its efforts may have been overtaken by the
Intrusion Detection Working Group (IDWG), which we will discuss next.
16
IDIC - SANS GIAC LevelTwo
©2000, 2001
16
IDWG
• Intrusion Detection Working Group
• Draft RFCs approaching
implementation quality
• IAP Intrusion Alert Protocol
• Data Model based on XML
According to the IDWG charter, located at />“The purpose of the Intrusion Detection Working 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 attempts. The best thing to do is check on the progress of the IDWG via the Web once a month
or so. One of the IDWG sites is: The Internet Engineering
Task Force is also a good place to start, (), or even more dynamic, the following
URL,( />17
IDIC - SANS GIAC LevelTwo
©2000, 2001
17
Intrusion Alert Protocol
•Based on TCP/IP
• Sensor/Analyzer reports to a Manager
• There may be addition intermediaries
such as proxies and gateways
S/A
P
G
M
The Intrusion Alert Protocol (IAP) is an application-level protocol for exchanging intrusion alert data
between intrusion detection elements, notably sensor/analyzers and managers in IP networks. The
protocol is designed to be independent of the type of data representation.
The idea is that the Sensor/Analyzer (S/A) producer sends alert data over IAP to the Manager (M).
There may be additional intermediaries in this communication, such as proxies (P) and gateways (G).
A Proxy does not have an IAP identity. It acts as a relay of messages without understanding their
content. It MAY do some rewriting of the content, but in a manner that does not impact the security
properties of alerts.
18
IDIC - SANS GIAC LevelTwo
©2000, 2001

18
IDMEF
Intrusion Detection Message Exchange Format
The IDWG has selected an
eXtensible Markup Language (XML)
based solution for message
exchange. XML is an html_like
language for describing languages.
The IDWG defined a format for message exchange between ID components, called the Intrusion
Detection Message Exchange Format (IDMEF). According to IDWG, the 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-and-
match the deployment of these systems according to their strong and weak points to obtain an
optimal implementation.”
The IDWG decided that an XML-based solution was best at fulfilling the IDMEF requirements, and
defined the IDMEF data model by creating an XML Document Type Definition (DTD). XML, for
those who are not familiar with the term, is an HTML-like language for describing other languages.
Those interested in the details of the IDMEF data model should take a look at the draft of its
specifications at />19
IDIC - SANS GIAC LevelTwo
©2000, 2001
19
Interoperability Summary
• Interoperability standards slowly
maturing
• CVE defines names for vulnerabilities
• CIDF defines language for ID
components communication
• IDWG formalizes data exchange

procedures
Let’s summarize what we discussed so far in relation to interoperability between intrusion detection
components. The standards for ID interoperability are maturing slowly but steadily. CIDF was a
pioneer effort that helped frame the 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.
20
IDIC - SANS GIAC LevelTwo
©2000, 2001
20
Signatures,time
and detect
flow
In the final part of the “First Principles” discussion, we will introduce the notion of attack signatures.
We will discuss the flow and process of detecting and reacting to intrusions.