Product and service reviews are conducted independently by our editorial team, but we sometimes make money when you click on links. Learn more.
 

A Guide to Security Information and Event Management

A Guide to Security Information and Event Management
By

Security Information and Event Management systems require a lot of planning before implementation begins. The path to SIEM success is not an easy one, but done right it can play a critical role in identifying and preventing security breaches.

One word seems to come up often when describing the implementation of a Security Information and Event Management (SIEM) system: daunting. SIEM often ends up costing more than anticipated, requires expertise that often must be outsourced, can be difficult to tune and can take considerable time before it yields results.

Various compelling events could drive a company to implement SIEM -- compliance with a government or industry standard, being the victim of a cyber attack, or perhaps a third party that requires a certain level of measurable security before signing a contract. Regardless of what the compelling event is, one thing is certain: The company is in for a lot of work before it starts seeing results from its new software environment, even if it already has logging and monitoring capabilities.

SIEM Implementation Considerations

Implementing SIEM requires a lot of preparation, even before the SIEM software is purchased, says Vikas Bhatia, CEO of the New York-based cyber security consultancy Kalki Consulting. SIEM requires an intimate understanding of the network topology and protocols by the security team, not just the IT and network engineers. It also requires a clear understanding of what it is the SIEM system is expected to accomplish.

"SIEM is really logging and monitoring," Bhatia says. "Almost all vendors want to sell you a big bang approach. but the best way to deploy is a phased approach." Management of the logging and monitoring capabilities, either by in-house engineers or a service provider, and responding to alerts (again by in-house staff or a service provider) are two of the most important components to a successful implementation, he notes.

A successful SIEM implementation is more than just logging and monitoring the network, according to Mike Spencer, a SIEM expert and consultant at the Denver-based information security services provider Accuvant. One of the biggest gotchas Spenser says he has seen is management not knowing what it wants out of a SIEM and not being prepared to implement and sustain the SIEM solution. "Many organizations do not know what their critical assets are and therefore do not know how to protect them," he says.

Spencer says it is important to have staff that is trained in using and understanding the SIEM application. "Too often organizations rely on a single SIEM operator/analyst," he notes. However, having only one trained operator creates a single point of failure that can be a serious vulnerability if that employee leaves or is unavailable when an incident occurs.

"Having a solid understanding of the requirements and purpose for the SIEM helps in sizing a SIEM," Spencer notes. "If the goal is just compliance then the size is often much smaller, but the amount of customization required to meet all the compliance requirements is much greater. If full enterprise visibility is the goal then a much larger deployment will be required but the customization to meet the requirements may be less."

It is essential to identify in advance what system log files will be required for monitoring, Bhatia says. Some companies will require a variety of logs that collect and process data differently. Before the SIEM system is able to provide useful reports, he says, the various logs need to be normalized so that the data is consistent.

Often companies begin logging when they are small and simply duplicate the log rules as they increase the number of servers, he says. Over time, the log files might be duplicating logs or, in the case of companies that merge or get acquired, they could be collecting different data in similar log files at various physical facilities. Additionally, companies that have servers in different time zones might be collecting logs without standardizing on a single time zone so that logs created at the same time in different regions will have unsynchronized time stamps. This can be a challenge, he says, if the CISO is trying to track an event that happened at 3 a.m. Eastern Standard Time that impacts an office on the West Coast. Unsynchronized time stamps will be three hours apart.

Configuring the SIEM system to address time zones, what data is collected on each type of server, how and where data is stored, and how potential incidents are triaged by the SIEM system are essential before a company can take full advantage of its SIEM purchase, he notes.

The SIEM system needs to match the company's needs. For example, Bhatia says, assume that a midsize company is implementing its first SIEM and the company only has IT staff monitoring the system during regular business hours. If the company buys a SIEM that generates real-time results and alerts 24/7 but the alerts are only monitored during business hours, the company will have overpaid for features and functions it cannot use. As a result, management's expectations, including those who approved the purchase, likely will not match the results or expected value, he says.

"Each SIEM has its own set of requirements for gathering logs," Spencer says. "Generally Syslog logs can be sent to an agent of some type to be connected. Microsoft logs are generally gathered from an agent either installed locally on the device, where logs are being collected from, or centrally with a Windows Management Instrumentation (WMI) or Remote Procedure Call (RPC) to the devices where logs will be collected from. There are many other types of log sources but syslog and Windows generally cover 75 percent or more of a company's environment."

Security is a process and not a one-and-done tactical operation, Bhatia adds. In order to obtain measurable results for the investment in SIEM and other security products and services, the key executives responsible for information security first need to be able to identify all of their IT assets and know what level of security each asset requires.

Once a company selects a SIEM product, Bhatia suggests that it start implementation with logging only of the most critical assets. Once the logging environment is fully configured, the other features in the product can be rolled out.

Often SIEM implementations end up costing a lot more than originally anticipated, Bhatia acknowledges. This can happen when a company underestimates the time and effort it takes to prepare for implementing SIEM, both from a technological standpoint and from a personnel standpoint. Additionally, if the original expectations for SIEM are not mapped out, it can be easy for a company to end up buying more capabilities than it needs. Tuning the application to process all of the logs also can take longer than expected, resulting in higher anticipated costs. Also the IT and security staff might require training to manage the SIEM application.

In some cases, a company might opt for outsourced SIEM management from a company that specializes in information security. The benefit of a SIEM specialist is that less training is required and the SIEM environment can be more of an operating expense rather than a capital expenditure. On the downside, Bhatia says, the company's data never leaves its premises and there is less reliance on the Internet in order to manage the network.

Spencer notes that for an on-premises product, the company has control over the hardware and the logs. They have the ability to configure the correlations (rules), reporting, retention periods, and other settings to meet their needs. Internally managed SIEMs, he says, can suffer from low staffing rates and current staff being pulled off SIEM work to work on projects or other duties. He concurs with Bhatia that SIEM requires specialized training and standard operating procedures that must be created and maintained for each environment.

The off-site approach requires that logs are sent to the vendor managing the software with little or no visibility provided to the company. The managing vendor typically sets an initial set of correlations that the company may be able to alter and a standard set of reports. Retention periods are generally dictated and are very short.

The disadvantages the client can faced when dealing with a vendor-owned SIEM product are a lack of visibility and the inability to move between vendors and maintain the older logs. The ability to open a console to the SIEM tool and see logs is not generally available, he says. "This lack of visibility causes issues with hunting for new threats as well as determining what should be reported on," he says. "The inability to move logs between tools and vendors is also a downfall of the off-site SIEM."

In addition, staff turnover is less of a concern with managed services if a single person leaves, the whole effort doesn't stop. Additionally, since managed service providers specialize in SIEM, they are much more efficient and typically have a deeper pool of expertise to draw on than non-managed SIEM operations.