Security information and event management (SIEM) is about collecting, detecting, and responding. That is, collecting data into a single pane of glass to provide a complete picture of what’s happening in your network, identify threats, and track responses. Ideally, when well-tuned, this single pane of glass “finds the needles in the haystack.”
Any SIEM should start with these two key goals:
The next critical element is understanding what you’re protecting, how to get visibility, and what controls can mitigate or block an attack. About 20 years ago, I started with a CAVE model, just to make it easier to remember.
It’s all about the data. Which asset (application, system, database…) has the data that matters most to the business? That’s the first log you’ll want. If that asset is not logging access and usage, then turn logging on and collect that data!
So, what do you log?
You need to answer the question:
You need to enable logging and parse key fields in any given log into indexed labels. Searching by regular expression matches against text in database terms is a full table scan that can take hours, and the volume and velocity of events does not support doing this.
Each device type has critical fields, and it’s a best practice to parse as many fields as possible. That's why we like Google Chronicle's Unified Data Model (UDM) and use it for Resolution Intelligence Cloud.
|
Network
|
Source IP address
|
Destination IP address
|
|
|
|
Authentication
|
Source user
|
Destination user
|
|
|
|
All
|
Event name
|
Event ID
|
|
|
|
EDR and Fileshares
|
Object/File
|
File extension
|
File name
|
File path
|
|
System
|
Process ID
|
Parent Process ID
|
Process name
|
|
|
Proxy
|
URL
|
Top-level domain
|
URL category
|
|
|
Email
|
Email sender
|
Email recipient
|
Email subject
|
Email attachments
|
Checking the parsing and normalization of logs into indexes that have high-speed search is a critical part of SIEM onboarding and validation.
“For every log, there is a complementary log.”
Any single log is full of both useless and critical events. Noise reduction to .001% output requires both good correlation rules and threat data sets.
Consider the key field in each source, and a complementary log that includes whitelists of safe sources and blacklists of known bad actors. These data sets include IP addresses for firewall logs, URLs for proxy logs, vulnerability data for IDS events, identity access management (IAM) data for application events. Context and known safe and evil are critical to noise reduction and threat detection.
Every decent SIEM tool has a correlation rules engine capable of first-level noise reduction. Three simple patterns apply:
For more details, read “Want to Optimize Threat Detection & Response? 5 Patterns versus 500 Rules” or the SANS papers linked below for the core 20 rules you should be running on every SIEM.
Any SIEM can provide data to support compliance and audit requirements, but don’t get bogged down in a million reports. Pick a common compliance framework and map one report to the required compliance outputs. Unified Compliance Framework is an early leader that maps standard reports to PCI, NIST, FISMA, GDPR, and more.
On page 2 of the 2016 CIS poster, you can find mapping controls to the compliance framework.
In all too many implementations, organizations only use SIEM for threat detection and compliance reporting. However, when used well, a SIEM can provide oversight for the security tools feeding the data. A bit of log analysis around “volume and variety” each month becomes a continuous feedback loop. For example, “Top 10” reports on what was detected, what was blocked, and what was allowed can help teams decide what to do to prevent future incursions and continually improve the system.
Resolution Intelligence Cloud™ from Netenrich is a data analytics platform that offers a new way to manage security and digital ops. So, while not a traditional SIEM, it covers substantial SIEM functionality, and Google Chronicle is built in.
In fact, not only does the platform play well with other security and ops tools thanks to its open architecture, but it also offers service-provider scale and speed. With Resolution Intelligence Cloud, you can achieve all the goals I outlined above and more. Unlike most SIEMs, the platform easily handles data at speed and scale while significantly reducing and prioritizing alerts so teams know where to focus their time and efforts.
If you want to read more or dig into details, here are a few papers in the SANS reading room to help.
A Process for Continuous Security Improvement Using Log Analysis
This paper details a repeatable process for continuously improving security and provides an outline of log analysis with case studies and sample output based on actual data. The process is broadly applicable and does not require a SIEM or centralized log management (LM) system, though both do make the process easier.
Successful SIEM and Log Management Strategies for Audit and Compliance
Organizations often spend a great deal of money on LM and SIEM, with disappointing results. Many organizations struggle with “use cases,” and most SIEM vendors fail to provide effective out-of-the-box correlations. What’s more, many also fail in their vision and process, considering SIEM just another tool to be dropped onto the network.
A Compliance Primer for IT Professionals
Regulations abound, and the acronyms are endless. After suffering seemingly endless confusion, I set about in this paper to document the basics of each of the major compliance regulations, to whom they apply, a list of audit frameworks, key IT requirements, and links to best practices and relevant sites. I provided summary tables up front to condense the bulk of the information.
A Practical Application for SIM/SEM/SIEM Automating Threat Identification
This paper documents key events and correlations for identifying threats in security logs and a process for application in SIEM.