Security Experts:

Practical SIEM Deployment

- Getting The Most From Your SIEM Solution -

A typical SIEM deployment conversation may look something like this:

Vendor: Ms Customer, now that you’ve purchased our shiny new SIEM, complete with new SIEM smell, what use cases would you like to implement?

Customer: Um, well, I don’t know. What should we do with it?

Vendor: Well, what would you like to do with it?

Ad infinitum.

The reality is most SIEM and Log Management deployments are purchased to satisfy a compliance need: PCI, HIPAA, NERC, FISMA, GPG 13 – the list goes on. And while log management and reporting, which comprise the lion’s share of technical controls prescribed by most regulations and compliance documents, are important, a properly deployed SIEM can add tremendous value to an organization’s security program. Customers know that applying SIEM to the single task of compliance is like stamping a check box with a sledgehammer, but many don’t have a good sense of SIEM’s full potential, so they look for the vendor or VAR to provide guidance.

And vendors truly want to help. The problem is, in order to apply SIEM to an organization’s problems, the vendor or VAR has to understand those problems. It’s relatively easy to deploy an anti-virus solution: the problem is universal: stop malware. The same malware that may infect a paralegal’s workstation in Atlanta is the same malware that will compromise Windows-based SCADA PC in a rum manufacturing facility in Sao Paulo. The malware may only activate on a particular Siemens control system, but the goal remains to keep the junk off the computer in the first place. There is typically no context to consider.

Checklist

SIEM, on the other hand, is highly context dependent. Okay, that’s a bit of a lie. There are a number of general use cases that can be applied to just about all customers: botnet detection, excessive authentication failures, traffic from darknets, IDS alerts that a particular attack is targeting an asset that the VA scanner confirms is vulnerable to that exploit. Vendors typically provide these as out-of-the-box content in the form of rules (with alerts), dashboard widgets, reports, and saved searches. Sales reps point to this as proof of how easy it is to deploy their SIEM. Taken literally, that’s true: deployment is not the hard part, at least for modern SIEMs; the trick is deriving continuous value from SIEM and customizing it to your evolving needs.

The practical reality is there are two general phases to SIEM deployment. The first phase is to get the solution fully deployed, collecting telemetry from key log sources, and general use cases implemented and tuned. Launching the kitchen sink at your SIEM out of the gate, every scrap of logs and every event that crosses the wire, is like going out one Saturday, buying every item at all the yard sales within a 20 mile radius of your house, and having it all dumped on your front lawn.

The second phase is a perpetual, iterative one: define use cases and implement them one at a time. How do you derive use cases? Take business problems, find out if they have an information security or operations component, and investigate whether SIEM can solve the problem. Let’s say you’re responsible for IT risk management at a large investment brokerage and the business is concerned about trader fraud. Instead of buying an expensive, highly verticalized package backed by three guys in a garage, perhaps you can feed the transactions into your SIEM, parse out the trade value, shares traded, and other fields. Now write a correlation rule that alerts on anomalous trades, ones that exceed the average trade value over a period of time by more than 50%. Or create a watch list on certain stocks based on market news, which is parsed from Twitter feeds. Yep, you can do that with some SIEMs.

I skipped an interim phase, though. After the initial deployment there’s a percolation period, for the customer as well as the SIEM. While the SIEM is busy building up historical data, correlating events at your bidding, and constructing baseline activity models, the customer is also observing the pattern of activity in their information infrastructure and learning what SIEM is capable of. Then strikes the mind-expanding epiphany that this tool can do so much more than tell you when Ursulla mistyped her password five times before her first morning coffee. Put on your mortarboard and gown, you just graduated to phase 2.

Since I skipped ahead, let’s tackle the details of phase 1. The key log sources you should start with are:

• Authentication events, usually from Microsoft Windows Active Directory and often other enterprise identity management services

• Windows, Linux/UNIX, and other OS administration logs

• Perimeter firewalls and VPN concentrators

• Anti-malware logs

• File and directory auditing on high-value servers (i.e., those that contain PII, ePHI, financial information, sensitive company information and IP)

These cover many of the controls in compliance mandates and provide a good foundation for your log management program, not to mention they’re the main log sources used by default rules in most SIEMs. Some of you will note the absence of IDS/IPS events and network activity/flows. IDS/IPS events are core telemetry; however, many IDS/IPS implementations never get properly tuned and can overwhelm unseasoned SIEM administrators. Once you get the SIEM tuned to around under 25 offenses or incidents a day, IDS/IPS is an excellent next bite of this particular elephant. In fact, SIEM often provides a better platform to monitor and tune your IDS/IPS than the vendor tools themselves.

Network activity and flows are only as effective as what SIEM does with them. If flows are treated as events and only useful for correlation, you’re better off integrating them when you’ve defined use cases that call for the information they bring to the party. If, however, the SIEM has natively integrated network activity so it adds context and situational awareness, you’ll want to bring it into the SIEM up front. Network activity can automatically discover and profile assets in your environment, and dramatically simplify the tuning process. Vulnerability Assessment (VA) scanners can also build an asset model; however, VA scanners are noisy, performing active probes rather than passively watching the network, and only give you a point -in-time view of the network. To be sure, VA scanners are core telemetry, and every SIEM deployment should integrate them, but not as a replacement for native network activity monitoring, which provides a near-real-time view and can alert to new assets popping up, network scans—even low and slow ones—and DDoS attacks. And if you’re monitoring network activity and collecting flows, don’t forget to collect the events from the routers and switches as well.

And what about application logs, database logs, logs from door entry systems? Sure, collect them, one at a time, do what you will with them, and tune the system to accommodate the new stream of data. It may be that you just need to collect and store logs from your IIS web server and not perform any correlation. Or maybe you want to correlate your door entry events against logins from assets and make sure the user was physically in the room where her credentials were used.

These are use cases and you’re starting to see your security program through their lens, which means you’re now a Sherpa on your own SIEM Everest, creating value out of your investment.

Subscribe to the SecurityWeek Email Briefing
view counter
Chris Poulin brings a balance of management experience and technical skills encompassing his 25 years in IT, information security, and software development to his role as Chief Security Officer at Q1 Labs. Prior to joining Q1 Labs in July 2009, Poulin spent eight years in the U.S. Air Force managing global intelligence networks and developing software. He left the Department of Defense to leverage his leadership and technical skills to found and build FireTower, Inc., an information security consulting practice.