Security Information and Event Management (SIEM)1 systems are all the rage at the moment – and with good cause.
As you are all aware, one item of data2 does not a case make, it is the combination & correlation between _all_ of the data that creates “evidence” – and here in the SIEM we are seeing the very thinnest separation between forensics and security – if we look at it today it is security, if we look at it tomorrow, it’s forensics.
An SIEM (oft pronounced “seem” – although mostly I like to spell out my TLAs ESS-AYE-EEE-EMM [ with a few notable exceptions … raid, scuzzy, wizzywig … but I suspect that shows my age more than anything else ! ] ) is a centralised system that collects information from other systems in the network. This information is typically – but not exclusively – collected from some, or all, of the normal logging of the system.
It should be noted that although a SIEM could, theoretically, collect _all_ of the logs across a network – it usually doesn’t. Therefore it isn’t a replacement for centralised logging systems that _do_. More typically it seeks out a subset of the log entries that are perceived to be relevant to “Security” and collects these.
The determination of what a “Security” relevant entry consists of is clearly open to debate. Most of the SIEM vendors will provide you with a helpful template for a given system, and these are perhaps a good start. The British Government also publishes some recommendations (requirements if you are on an HMG system) in a document called, rather catchilly, “Good Practice Guide 13 – Protective Monitoring for HMG ICT Systems” – it is UNCLASSIFIED, so theoretically anyone can read it – good luck on getting a copy though, it’s a nightmare to find !
I’ve been involved in two major SIEM implementations of late, one which was being sold as a service ( client data coming into the SIEM for Security-as-a-Service [ another acronym there – SaaS – not to be confused with SaaS which is Software-as-a-Service 😉 ] ) the other which is monitoring a large network infrastructure on which clients depend … ( Subtly different … )
SIEM setups will vary in their forensic value depending upon how well set up they are, how much “meta-data” ( for want of a better word ) they include with each alert, how synchronised and consistent the logs are and, possibly most importantly – how trustworthy the SIEM itself is. If we are looking to gain data from an SIEM to use forensically, then we need to be sure that the data is sound in line with the standard forensic principles – so if the SIEM is open to all to change as they wish, or the SIEM isn’t consistent about recording time, or the SIEM does substantial rewriting of data, modifying the source then whoever is presenting it faces an uphill struggle to get it accepted as evidence.
So, as a parting shot and summary here are some forensic specific tips:
- Make sure that you are recording sufficient information that your SIEM contains enough detail to reconstruct as required – that doesn’t mean everything, but the right things.
- Ensure that your time is consistent.
- Hash, hash and hash again to show consistency – high volume SIEMs won’t be able to hash each entry – hash batches, then hash batches of batches and then batches of batches of batches … ( Repeat as necessary ) This way, although you may not be able to identify _which_ has been modified, hopefully you can show that something has been if it is corrupted in some way.
- Spend as much time, if not more, securing the SIEM than the systems that it is looking after. Don’t forget – “Quis custodiet ipsos custodes?“ 3
If you’d like to chat about SIEMs, their implementation or forensic use, please drop in a comment below !
1. Or … Security Incident and Event Management – I’ve seen both.
2. Datum ?
3. Who watches the watchmen ? ( Terry Pratchett fans know the answer to this to be “Me. I watch him.” 4 )
4. Thud!: Terry Pratchett
