Security Incident and Event Management platforms are one of the most important tools in a security team’s arsenal. They are also one of the most expensive and time consuming tools in that same toolbox. For a fledging security team, a SIEM may seem like one of the first project to undertake (if you have your asset management already in line! CIS Top 20 anyone?). A project like this though requires careful planning!
Before the team dives into purchasing and just ingesting every available log source, they should really be asking themselves, “Why do we want a SIEM?” and “What are we going to do with a SIEM?”. It is surprising how often those question leave blank faces around a room.
I don’t claim to be an expert in anything, but I have had some success in SIEM installations, management, and use by following a fairly strict guideline: No logs without a use. Now, some uses are extremely easy to justify – AWS Cloudtrail for example. Without aggregating Cloudtrail it is extremely difficult to answer basic questions like: “What did Joe Bob do on Tuesday that brought down Production?” or “When did Sally Threat Actor open up all those ports?”.
Even for Cloudtrail, though, we should have a basic use case written out that will help us justify the cost for ingesting those logs. Remember, security generates value for the business by reducing risk – not by spending money needlessly on every shiny tool!
Another important point to consider when documenting your use case is any regulatory requirement you may come across. As of this writing, GDPR is the pre-eminent privacy law, and it extends to internal monitoring practices. You can’t just collect data on people without a reason, even employees! So use your use cases to provide some CYA against these regulatory requirements, and curry favor with auditors and legal folks.
Below is an example I have used in the past.
SIEM Use Case: Cloudtrail
Log Category: Cloud Audit
Log Description:
AWS Cloudtrail is AWS’s standard logging utility. Cloudtrail can log both administrative activity and data access requests to S3, DynamoDB, and Lambda. Cloudtrail must be deployed upon account creation, and should be sent to an S3 bucket, and that bucket replicated to a central archive. Preferred management of this log source is through a central AWS Organizations account.
Log References:
Collection Purpose:
- Identify malicious changes in AWS accounts
- Investigate cloud compromises
- Investigate data access requests
- Investigate system outages
- Monitoring change activity
Sensitive Data Fields:
| Field Name | Data Type |
|---|---|
| Username | PII |
| IP Address | PII |
| User Device Info | Internal Information |
| Request | Varies, up to ePHI |
Retention Period: 6 years
In the book Blue Team Handbook, Don Murdoch lays out a much more complete use case that dives into much more detail than mine above. One key element that his makes use of that mine lacks is an assurance metrics section. Example:
…
Blue Team Handbook, Don Murdoch
Assurance Metrics:
* Achieve 100% rate of group change notificaition to the group “owner”
* Ensure that additions/removal from monitored groups occurs within a reasonable time window (usually within 2 minutes of a change
…
By providing clear success metrics for use cases Don highlights how a SIEM operator understand that their SIEM is actually working.
Guided Security 