SIEM (pronounced as “sim” from “simulation”), which stands for Security Information and Event Management, was designed primarily as a device for aggregating logs. However, the core capabilities of a SIEM are to provide threat detection, better enable incident investigation, and speed up your incident response time, all while giving you a unified and holistic view of your infrastructure. A SIEM is only one piece of the puzzle of securing and monitoring your network and systems – a puzzle that Michael oberlaender, is a stack of 10 coins which at first can seem quite intimidating.
On a somewhat deeper level, a SIEM typically provides the following:
- Collection of events and logs: aggregate event and log data from sources on your network for easier monitoring.
- Dashboards : Often take the form of tables of information assembled from the data collected to help identify patterns or abnormal activities.
- Correlation: relate events to each other on the basis of common attributes to transform data into meaningful groups which can then be contextualized.
- Alert: Automated analysis of correlated events which can also provide continuous monitoring, trend and audit verification.
- Forensic analysis: the ability to use specific criteria to search logs on different nodes and / or time periods.
- Compliance: automate the collection of compliance data through applications to produce reports tailored to existing security, governance and / or audit processes.
- Retention: store long-term historical data to facilitate correlation of data over time and enable compliance requirements to be enforced.
- Standardization: translate computerized jargon into readable data for easier display and mapping to user or vendor defined classifications and / or characterizations. Sometimes referred to as a field mapping.
A SIEM is not just a plug and forget product, however. If all your business does is buy a SIEM, connect it to the network, and then assume SIEM has the security basics covered, you’re going to run into a lot of issues. A SIEM is a way to standardize a security workflow for your incident response or digital forensics teams. Together with SIEM, these employees can help secure your network.
This is just one reason among many. Here are some other reasons to deploy SIEM systems:
- Compliance with regulations such as HIPAA, SOX, PII, NERC, COBIT 5, PCI, FISMA, etc.
- Certificate acquisition and maintenance such as ISO 27000, ISO 27001, ISO 27002 and ISO 27003
- Management and retention of logs
- Incident response and continuous monitoring
- Case management or ticketing systems
- Validation of the application of policies and monitoring policy violations
A major factor for companies that have deployed SIEM systems in the past was compliance with government regulatory requirements. The functions of a SIEM not only protect sensitive data, but provide a means to prove that it is accomplished while meeting these compliance requirements. With a SIEM, the business can avoid a failed audit – the retention and reporting features of a SIEM can validate and verify that compliance requirements are being met in a manner consistent with these regulations.
However, as stated earlier, an organization cannot simply deploy a SIEM and assign employees to monitor it and then “walk away” from the system. For a SIEM to be useful, especially as an incident response and threat detection system, its alerting and event / log collection processes need to be fine-tuned. Too many alerts, and the teams assigned to work with SIEM will start to miss critical data that gets lost in the noise. Too few alerts and critical incidents may never be detected at all. This tuning happens on the human side – people who are familiar with the network, keep an eye on SIEM and the systems it monitors, and update as needed for the business and the network. The following Gartner Adaptive Security Architecture model illustrates this cycle.
In short, a SIEM adheres to the GIGO principle – garbage in, garbage out. A SIEM reflects what you and your security team put in it – without reviewing, observing, and adjusting the SIEM as necessary, it will become stagnant and eventually become a handicap. The SIEM solution (s) implemented should be business and process oriented – something like the ITIL framework can help determine which processes or procedures need to be combined, changed, or even removed.
Where to start Try a service catalog, and if you don’t have one, use a few basic use cases (https://www.sans.org/reading-room/whitepapers/logging/effective-case-modeling-security-information-event-management-33319) and go from there. You don’t have to start from scratch.
Just as the use of a SIEM must be continuously adaptive, so too – the field is constantly evolving, and the following change with it:
- Compliance requirements
- Process
- Procedures
- Threats
- Vulnerabilities and CVE
- People or staff
- Customer / user expectations
- SLA
The way your business implements SIEM solutions may not be the same or even similar to how a neighboring business or competitor implements theirs – you’ll need to see what works for your environment and business. Creating a roadmap to use as a guide will help – start with the “why” or goal you want for SIEM, which makes it easier to define assets and prioritize.
Once the strengths and priorities have been outlined, the next step is to define the scope. This is essential to ensure that your SIEM solutions scale correctly, instead of being over or underbuilt for your needs. This scope should encompass empowerment in addition to supporting and protecting the business.
Effective technology, network operations, or security operations teams work through some sort of procedures and processes in place to identify:
- Data classification
- Key assets
- Entry / exit points (network and physical)
- Applicable compliance mandates
- Internal IP scheme
Once you have them, there should also be processes in place that include responsibility and accountability. It’s also important to have a resource that has the answers or can get the answers – whether it’s a person, a team, or even an internal web page serving as a reference document.
To ensure consistency with your implementation, you can align your SOC (or SIEM implementation) with ITIL general management and service practices (https://en.wikipedia.org/wiki/ITIL) and use it as a guide or roadmap, as it focuses on service management.
Strategy management
Define either your vision of a SIEM or the service that the SIEM solution will provide as a whole. It can be simple or complex, but it’s best to start simple and define a set of “common sense” goals. The 10 common use cases linked previously can make a good starter set.
Service design
Once you have analyzed the business needs, you can begin to align your expectations for a SIEM / SOC with the business, as well as deployment initiatives. The goal here is to create a “SIEM Service Catalog”, a set of metrics that constitute the main functions of SIEM for your business.
Service and technical management practices
Your SOC or SIEM operators need to be kept abreast of changes in the environment. It may seem obvious to point out, but it boils down to a need for controls. A SOC or SIEM operator who is unaware that a new PC has been added to the network, or that a data center is temporarily offline (for example), can lead to a situation where there are false alarms, failed audits, invalidated reports, and much more.
This is also the stage where you will want to demonstrate the basic functions described in “Service Design” by defining accountability, communications, and SLAs and OLAs, if possible. In particular, you want to note trends, corrective actions, daily activities, as well as configuration and inventory changes.
Continuous improvement
It is often the most difficult step for a business, but it is also the most necessary. This is the stage at which data is reviewed and used along with previously established metrics to redefine or refine services, processes, and procedures. This is an excellent opportunity to also verify and validate the data collected using manual or GRC methods and mechanisms. Using a continuous improvement log (recommended by ITIL) can also help here.
Now you should understand why you need SIEM and understand some of the many value points it can add to your business environment. But it’s important to note that priorities, methods, and initiatives vary by environment – start simple and add complexity as you better understand what a SIEM can do for you in particular. Use proven frameworks and resources that have proven invaluable for managing cybersecurity, such as a SIEM. A tool like NIST cybersecurity (https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.04162018.pdf) can be a great assistant in determining some of your initial requirements.
To learn more about Tripwire’s SIEM and log management solutions, click here.
