Tips & Tricks
2005 issa journal-simsevaluation
Like this document? Why not share!
Kalibrera USA Cyber ansträngningar ...
by Franchesca Blit
Borges poema a los amigos
by Benjamín González
Natgraph Airforce High Temperature ...
Energy solutions final
by Archita Goyal
Lotus greens floors
Gestio electronica (Ajuntament Alzira)
by Ajuntament d'Alzira
Email sent successfully!
Show related SlideShares at end
2005 issa journal-simsevaluation
May 28, 2010
Comment goes here.
12 hours ago
Are you sure you want to
Your message goes here
Be the first to comment
Be the first to like this
Number of Embeds
No notes for slide
Transcript of "2005 issa journal-simsevaluation"
1. Evaluating and Implementing Security Information Management1 Systems By Aurobindo Sundaram firstname.lastname@example.org 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.
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
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.