Contenu connexe
Similaire à 2005 issa journal-simsevaluation
Similaire à 2005 issa journal-simsevaluation (20)
2005 issa journal-simsevaluation
- 1. Evaluating and Implementing Security
Information Management1 Systems
By Aurobindo Sundaram
aurobindo_sundaram@hotmail.com
Introduction
In today’s security world, with hundreds of security devices of different
types, millions of log entries per day, and the requirements of IT audit and
regulatory bodies to monitor logs regularly, it is impossible to use a man-
ual solution. Security Information Management Systems (SIMS) automate
the collection of event log data from heterogeneous security devices and
present a normalized, aggregated and correlated view of network security.
This article introduces the technology, presents different requirements that
should be fulfilled by any SIM product, discusses licensing and cost con-
siderations, and presents a template for implementing a SIM solution.
Most security sensor devices in use today (e.g., anti-virus, firewalls, vul-
nerability assessment systems, intrusion detection systems) generate large
amounts of security events during their operation. Most of these sensors
generate these logs in their own proprietary format (often binary). In addi-
tion, they usually require dedicated consoles to view, report and analyze
this data. In a typical enterprise, this makes security information manage-
ment extremely time-consuming, inconsistent and unmanageable.
Security Information Management Systems (SIMS) technologies are a
potential solution for this problem. SIMS products promise to gather logs
from disparate security point devices and merge them into a common,
ordered, risk-assessed interface. However, SIMS is still an emerging tech- Figure 1: The three layers of a Security Information
nology, and the marketplace is in flux. In the following sections, we will dis- Management system
cuss what we believe are key requirements for an enterprise-class SIMS.
Following this, we’ll discuss licensing and cost considerations that the Native logging formats are typically better compressed, have a richness of
enterprise should be cognizant of, and finally, present a blueprint for information that is harder and inefficient to translate into a pure text output
implementing a SIM system. such as syslog, and have built-in hooks that allow external programs to access
events in real-time. Where the native logging solution is syslog (e.g. Unix
Requirements authentication logs), the point above is moot. Users are strongly encouraged
to verify and test the support and type of support of event collection.
Event Collection It is desirable for some (but not all) filtering of the event data to occur
This layer of the SIMS deals with the collection, normalization, initial fil- at the agent that collects it. The trade-off is that the more filtering is done
tering and forwarding of security-related events to a processing entity. at the source, the better the network performance, and the worse the cor-
Normalization is the process of translating various vendor event logs relation results. This is because local filtering reduces the traffic that must
into a common format that the SIMS can understand and manipulate. It is be sent across the network to the central engine. However, correlation
important to ensure that the format of the normalized data to be extensi- works best when access to data in its entirety is available. The communi-
ble by the end user—this ensures that company-specific fields (such as cation between the agent and the console must be secured using an open
classification level, or handling instructions) can be added to the normal- strong encryption standard. In addition, the agent should have local stor-
ized logs. Although there are currently no standard normalization formats, age facilities, so it can buffer data in a store-and-forward mechanism if the
it is important to obtain a commitment to openness from the vendor. console is unavailable.
The event collection layer should support the collection of data from as The SIMS must supply an application programming interface (API) so
many different point devices as it can. In particular, collection of the data that agents may be built to collect data from third party and esoteric
should be as close to the source as possible, and in the native format of devices. This is important when you try to integrate home-grown applica-
the point device where allowable (e.g. Firewall-1 OPSEC rather than syslog). tions, newer security solutions, and physical security events.
THE ISSA JOURNAL ◆ April 2005 ©2005 Technical Enterprises, Inc. Reproduction of this document without permission is prohibited.
- 2. Event Processing User Interface
This is the most important portion of the SIMS. The main rationale for The primary user interface should be Web-based and near real-time,
SIMS is that they can process huge streams of data, aggregate similar although an alternate stand-alone client may be provided. As with all good
events, and perform correlation on volumes of events that would be security products, the ability to configure and audit the access to the inter-
impossible for a human to do. It can be split into the following functional face, per user/role, is essential.
components. Administrators should be able to manage incidents entirely from the
Aggregation is the process of combining events of a similar type into interface, for example, by running investigative tools, changing incident
one consolidated event. The biggest problem with security systems today status, or adding journal notes to an incident.
is data overload. The SIMS must support aggregation with the ability to drill The interface must allow agents to be controlled from it (e.g., to
down to individual events on demand. dynamically change rule sets, start/stop, etc.).
Correlation is the process by which events are analyzed and entered Users must have the option to run predefined reports, or to define their
into a common “event thread.” Correlation goes beyond aggregation in that own criteria for analysis. From an operational standpoint, there is value to
it can incorporate logic engines and rule sets to make sense of distributed showing the ROI of the system by using built-in reports. However, users
and stealth attacks that a human may not catch. The SIMS must support ele- will no doubt require their own reports, and it is important that users be
mentary correlation rules (correlate by attack type, source address, destina- able to easily create their own.
tion address, etc.) as well as allow an administrator to define business rules,
such as multi-way correlation based on events and time. Costs and Licensing
Correlation is particularly important because it can allow an enterprise
to correlate vulnerability assessment data against actual attacks observed In most cases, small companies should not attempt to use SIM tech-
by IDS and firewall devices. This allows the system to make intelligent nology. This is primarily because SIM has a very high initial price point
decisions (e.g. “Attacker X tried attack Y; your vulnerability assessment sys- ($100K+ for software alone, could run to $200K if you include scalable
tem states you are not vulnerable to attack Y; ignore attack”). It is hardware and services). Smaller organizations are urged to consider man-
extremely important that it is possible to create arbitrary correlation rules aged service providers, who will charge a flat fee per device monitored. In
based on attributes in the normalized database. addition, there are rarely issues with hardware and software maintenance,
rule tuning, workflow creation, etc.
Threat Assessment Medium to large enterprises should consider SIM if the number of
The SIMS typically performs a threat assessment on an event before dis- managed devices is sufficiently large as to make managed service
playing it in the user interface. The SIMS must allow the assessment to be providers too expensive (any company that spends more than $1M on
performed using business rules defined by the enterprise, in addition to pro- managed service providers is likely a good candidate for SIM). It is impor-
viding a pre-defined list of rules, based on best practices (e.g., Mitre CVE, or tant to note that headcount will be required to manage the system, in par-
SANS best practices). It should also supply a modifiable knowledge base of ticular if it is expected to run under strict SLAs (e.g. 24-hour operation,
event types. For instance, users should be able to designate a certain type of 30-minute response time, etc.).
event as critical (e.g. ANY attack against finance servers; high-severity attacks It is important to carefully read the licensing model of the SIM ven-
against systems in the DMZ, etc.) dor. Some vendors will count aggregated devices (e.g. when multiple
Unix systems log to a single syslog server) as one device, which is
Response, Escalation and Integration cheaper, and others will count them as individual devices, which are
While there are many valid designs, the following capabilities are cer- more expensive.
tainly “must-haves” for a SIMS: It is also important to factor in the cost of additional software, in par-
ticular database licenses. SIMS have high hardware requirements, and
▲ SIMS must implement automated response workflows based on most database vendors will license by processors. Therefore, if the cus-
rules defined by the enterprise. They should be able to control tomer picks a four-processor system, it is possible that their database cost
common point devices natively. For instance, the SIM should be able will quadruple from their expectations.
to page or e-mail a user when a certain event or sequence of events Finally, it is very important to adequately scale the hardware require-
occurs. ments. We recommend that you speak to the vendor technical contacts
▲ SIMS must implement escalation workflows where an incident about the appropriate scaling factor. While the initial price may give you
changes in severity based on other events, time or business rules. For sticker shock, it is far better to scale up and buy the hardware than have
instance, a low-severity event should be escalated to medium severity to replace it within 6 months because it was not scaled correctly.
if it has not been addressed for 24 hours.
▲ SIMS must be able to integrate with or interface otherwise with Step by Step: Implementing a SIM
existing asset and risk management systems. For instance, the
system should be able to import comma-separated asset This is not a comprehensive step by step, but it gives the reader some
information files so that the user does not have to manually enter important steps to follow while considering a SIM solution:
asset criticality information into the system individually.
▲ SIMS must provide APIs to interface bi-directionally with third-party 1. Write down your requirements (both business and technical).
ticketing and incident management systems. The third-party ticketing Decide carefully what you really need.
system integration is extremely important because it allows the SIMS 2. Create your evaluation requirements and test cases (how you
to integrate seamlessly with the processes already in place in the decide if a product satisfies your criteria).
enterprise. 3. Create and issue an RFP (pick the 4-5 most suited vendors).
©2005 Technical Enterprises, Inc. Reproduction of this document without permission is prohibited. THE ISSA JOURNAL ◆ April 2005
- 3. Ensure that you invite not only security, but also operations to the
decision meetings.
4. After the evaluation, pick two vendors to bring in-house and run
against your test cases. In particular, make sure you test stress
conditions (data overload) against the test system.
5. At this point, ensure that you carefully study and understand
licensing options in your scenario.
6. As part of the pilot, also make sure you talk to external sources as
well as reference customers from both vendors to judge actual level
of effort in implementation.
7. Do not try to go too fast. Start slowly with a phase 1 approach
targeting only security event logs from detection point products
(firewalls, routers, Unix, Windows). Initial ticketing system and asset
management integration should be built as well. Phase 2 can target
more correlation, performance tuning, and integration with physical
access and vulnerability assessment systems.
Some things vendors will say to you (and what they really mean
in italics):
1. We can work with any product. We can, but it’s often so painful
to do that you’ll spend a fortune on consulting fees. Always
make sure you understand exactly how easy integration with a
product is.
2. Our product is plug-and-play. If you require the simplest
solution possible with no additional features. Always make sure
you understand how long the simplest implementation and
how long the first functional implementation will take. They’re
not the same.
3. We can be up and running in a week. If all you want is standard
logging with no aggregation, correlation or integration with
anything else. Be very careful about believing vendors on this point.
There is no panacea to this problem. You will require several weeks
to months to tune your system appropriately. Indeed, even after
initial tuning, there is continuous configuration to perform on the
system to ensure that it runs effectively.
The Marketplace
The marketplace in the SIM space is crowded with small private com-
panies jockeying for space with the larger, more established vendors. In
general, the smaller niche vendors have been able to hold their own so far.
Some private vendors are: eSecurity, ArcSight, netForensics, and
GuardedNet. Some of the larger vendors moving into the space include
Computer Associates (with eTrust Security Command Center) and
Symantec (with their Incident Manager and other products). We expressly
do not make recommendations on which vendor to use. It is strongly sug-
gested that you go through an RFP process with these vendors and create
your own requirements and judgments. ¡
Aurobindo “Robin” Sundaram, CISSP/CISM, is the Director of Network Security at
ChoicePoint Inc. Robin has worked in the information security business for over
7 years in various capacities. He also holds the CISA and CCSA technical certifi-
cations and is currently working on his MBA from the Goizueta School of
Business at Emory University.
1
Also referred to as Security Event Management (SEM)
THE ISSA JOURNAL ◆ April 2005 ©2005 Technical Enterprises, Inc. Reproduction of this document without permission is prohibited.