Fail to prepare, as the saying goes, and you prepare to fail. This maxim certainly applies to most large-scale IT projects, and doubly so for Security Information and Event Management (SIEM) projects.
Recent figures from industry observers including Gartner have shown that SIEM projects have a surprisingly higher failure rate compared to other projects. Does that mean the SIEM concept is flawed? Not at all – otherwise companies wouldn’t even be attempting SIEM deployments. The benefits of SIEM are clear: rapid ROI, ongoing savings in manpower and equipment, more effective security management, and compliance with key legislation.
No, the failures simply highlight the fact SIEM is one of the most ambitious and far-reaching projects that can be undertaken by a company. Because SIEM ties together so many disparate technologies, and working groups – from specialised IT teams to C-level board executives, including risk control groups, compliance executives and HR on the way, project success is inevitably based on careful preparation and planning.
Points of failure
So what are the reasons behind the project failures? Gartner, McKinsey and other sources state that the leading reasons were, not altogether surprisingly:
- No cross-function steering committee was appointed at the outset
- Project owners did not have clearly defined roles
- Projects had no defined timescale, or where too ambitious for the timescale
- Requirements were poorly defined
- Poor planning for continuity or remediation.
Inevitably, poor involvement of non-IT teams was close behind. These reasons clearly highlight planning as an essential before starting a SIEM project.
But where should the planning and preparatory effort be directed, to minimise both risks and costs in a SIEM deployment? I believe there are four key steps which should underpin preparation work.
Before we get to those four steps, let’s first recap what a SIEM system is. It’s software that takes input logs and alerts from a range of systems (firewalls, routers, anti-malware, servers, etc) and informs IT teams of unusual occurrences which warrant further investigation.
As well as collecting and storing this raw log data, the system safeguards the data for subsequent audit needs and for compliance-aligned reporting. This same source data satisfies multiple needs and functions, in that the security team will use it to see if any breaches have occurred; the IT team will check to see if network devices are working correctly; the compliance team will check to see that security breaches have not occurred, and so on.
Crucially, SIEM cuts information overload by reducing false positives and negatives, excluding “normal” activities from view (so reporting by exception), consolidating logs from different systems into single “alerts”.
In effect, SIEM improves the signal to noise ratio for IT teams, enabling them to more easily identify “real” threats from false alarms. This means a team of a given size can do the work of a larger (and possibly more skilled) team. It’s all about getting the most out of the people on the IT security team. So, before you begin, make sure everyone you’ll be working with is onside.
SIEM deployments cut across organisations’ boundaries. In IT you can expect to involve stakeholders in architecture, operations, help-desk, and security functions. Within business management, you may need support from finance, HR, compliance, risk management, and the sponsoring C-level executive. It’s essential that any SIEM project secure buy-in from all stakeholders before work begins in earnest. Once the team is assembled, you’re then ready for the 4-step process to perfect SIEM preparation.
Step 1: assess
This step is all about gather as much relevant information on key stakeholder requirements and thoroughly auditing your existing IT and security arrangements.
The ultimate aim is to establish an acceptable known base line for security, from which you can build the rest of the project. So you should perform vulnerability assessments on existing systems and networks, identify current or potential weaknesses and fix them first. Then you can start to understand priorities, such as which critical systems to plug into the SIEM first, what levels of detail are needed, and which parts of the infrastructure are taking most heat.
This ensures your people and processes are ready to move to Step 2.
Step 2: simplify
Attempting to integrate SIEM with complex or contrived infrastructure will add time-consuming work and extra cost at each stage of the project.
So look for any opportunities to simplify your networks. Topologies may have changed significantly since your original deployment of firewalls, IDS, and other security products. Users may have relocated physically or migrated to new methods of accessing their applications and data. It may be possible to retire some of your security systems and consolidate networks and security policies associated because their functionality has now been added to other products.
To help with this, review the placement of security infrastructure in the light of the threats and vulnerabilities you catalogued in Step 1. Remove, redeploy, or reconfigure security products that serve little or no purpose in their current position. Take the opportunity to retire legacy access methods, and reduce the number of routes into your network. Again based on your work in stage 1, consider grouping high-value assets together in a high-security “green zone”.
One of the most powerful tools for adding simplicity to Default Deny – allowing users and applications to perform only specified tasks across networks and servers, and denying anything else. This means more elegant configuration, fewer events, and greater overall security. Server consolidation brings further management and cost benefits. Remember: keeping it simple maximises SIEM benefits.
Step 3: tune
In SIEM terms, tuning applies mainly to just one system: Network Intrusion Detection/Prevention, which generates more alerts than any other product. In essence, it means weeding out false positives. The strongest reason for tuning an IDS is this: if they have to report every event, the IDS may not keep up with the traffic and information will be lost.
The cost of your SIEM system is broadly proportional to the number of events per second it must handle and potentially store. And as we’ve gone a long way in Steps 1 and 2 toward streamlining infrastructure, tuning the IDS sensors in order to reduce the most obvious noise going into the SIEM can dramatically reduce the flow of spurious alerts.
One of the easiest IDS tuning activities takes advantage of the fact that you can logically group servers by OS, and so can tell the sensors to selectively ignore Windows attacks directed at UNIX machines and vice versa. This logical grouping does not necessarily mean moving systems and cables. Using a combination of intelligent port mirroring and tuned IDS you can opt to show a given sensor “just the UNIX traffic” and so obviate the need for running Windows signatures and their false alerts on that sensor or interface.
Another option is to screen alerts on Web servers, by qualifying signatures such as Python, PHP, Perl, .net and so on, in or out of the alert signature list.
Step 4: deploy
To ensure success, ensure the SIEM project is aligned with your business strategy, and consider what value the SIEM is supposed to deliver.
Also remember to deploy the solution in stages, with definable goals concluding each stage. One of the common reasons for failure is that the project tries to achieve too much, too fast – so proceed with care.
SIEM should help you to free up the small, specialist security team from doing day-to-day investigations and device support work. It should enable you to meet compliance requirements for reporting, without large amounts of custom coding and scripting. And critically, it should cut the chances of a breach passing unnoticed, and shorten the clean-up period, reducing overall exposure to risk.
Remember, the ultimate SIEM goal is to help your existing teams to do more, be more reactive with their current resources and to enhance security. Now that’s well worth a little extra preparation.
Perfect SIEM Preparation: the crib sheet
- Establish a cross-department steering committee first, to ensure all parties are onside
- Build a security baseline: assess activities & risks, prioritise them, and how you’ll remediate
- Simplify the network before installing large management systems to shorten implementation time, reduce event numbers and raise input quality for SIEM
- Boost signal to noise ratios for reduced hardware load and fewer events
- Phase the roll-out
- People and procedures are vital for successful deployment.