Every failed SIEM project that I have witnessed was due to a lack of ownership from the client. Too many organisations depend on the vendor and say that "once the product is installed I will figure out how to make use of it" and don't bother defining their requirements upfront and take control of the project outcome.
Unfortunately, I have seen a number of Australian organisations spend in excess of five million dollars on their SIEM deployment without any return on their investment. But you don't need to spend too much money if you know what you want to get out of the project.
Getting key stakeholders and business groups involved in helping define the requirements also plays a big part in ensuring the success of the project. At a minimum you need executive sponsorship and internal audit, compliance, IT security and IT operations involved.
Clearly define your operational requirements
Too often the vendor is depended upon to guess what the client's requirements are and the end result is a vanilla install of the product that doesn't meet any of the specific business requirements. The value of any SIEM product is directly related to the data that is put into the system, the understanding of what the system can derive from the data, and the actions the system can be programmed to take.
You need to clearly define why you're deploying a SIEM solution and look past the vendor's marketing messages. Is it to support your 24/7 security operations centre? Is it to provide real-time and historic views into external attacks? Is it to meet your audit and compliance mandates? Is it to manage insider threats? Is it to manage fraud? Once you meet your key requirement you then have all the time to extend your SIEM deployment into other areas. Develop a two to three year road-map for all functions that will influence buying decisions for the initial implementation.
Think outside the square
Where is your important data? On the routers, switches and firewalls, or is it on the back-end databases and mainframes?
Too often, organisations collect terabytes of meaningless data while their core assets and data are ignored. Too often a SIEM is used for simple log management, while its real power is never utilised and the value that can be gained from the internal assets ignored. No auditor cares about which servers are secure unless they relate to a business application. When considering log analysis for security governance, make sure you understand which physical and logical assets support the business application and don't get caught up in technology silos. List these supporting components and ignore log output which is not relevant to the business application. Some of the better deployments I have seen include:
- Mobile device security - a mobile operator used a SIEM to detect malware-like behavior among subscribers based on connectivity patterns, as well as preventing DDoS attacks by monitoring increases in Call Detail Records (CDR) averages.
- Fraud management - a financial institution detected known, unknown, and potential instances of fraud by comparing disparate data sources, finding irregularities amongst a baseline of legitimate transactions, and identifying repeated events that represent actions taken by fraudsters.
- Management and monitoring of the convergence of physical and logical security - a government agency collected events from their door-access system and used their SIEM to send a command to their camera system to start recording anytime someone entered their data centre cage and stop recording when they exited. The same agency also combined physical door-access events to Windows Active Directory network access events to look for staff that were logged into the network but that had not swiped into the front door's card access system.
- ITIL Compliance - a service provider used a SIEM to reconcile their ITIL processes such as change, configuration and incident management.
- Insider threat management - a software company that held substantial amounts of intellectual property used their SIEM as an early warning system, detecting suspicious activity such as printing large numbers of files outside of business hours, emailing large attachments to personal email accounts, employee communication with competitors, and the clearing of system audit logs. In addition to the early warning system, the insider threat management includes information leak and IT sabotage-specific detection capabilities such as real-time rules designed to identify inappropriate access or transmission of sensitive data, or internal use and presence of hacking tools.
Don't underestimate the resourcing requirements
Things to watch out for include: the time it takes to define your requirements from all the key business stakeholders, disk space requirements, server hardware requirements, training requirements, and ongoing support requirements.
Security log volumes can be enormous and grow with explosive speed. Ensure that each log message that is being stored and retained supports some outcome. Don't store meaningless data. I have witnessed organisations invest significantly in SIEM licensing only to realise that they didn't budget enough for server hardware and storage.
