WHAT IS A SIEM, AND WHY SHOULD YOU HAVE ONE?

SIEM (pronounced like “sim” from “simulation”), which stands for Security Information and Event Management, was conceived of as primarily a log aggregation device. However, a SIEM’s primary capabilities are to provide threat detection, better enable incident investigation, and speed up your incident response time, while also giving you a unified, holistic view of your infrastructure. A SIEM is just one piece of the puzzle of securing and monitoring your network and systems – a puzzle that, according to Michael Oberlaender, is a 10-piece stack that, at first, can appear quite daunting.

On a slightly more in-depth level, a SIEM generally provides the following:

• Event & Log Collection: aggregation of event and log data from sources across your network for easier monitoring.
• Dashboards: frequently take the form of information charts put together from collected data to make it easier to identify patterns or anomalous activity.
• Correlation: linking events together on the basis of common attributes to turn the data into meaningful groups that can then be contextualized.
• Alerting: automated analysis of correlated events that can also provide verification of continuous monitoring, trends, and auditing.
• Forensic Analysis: the ability to use specific criteria to search across logs on different nodes and/or time periods.
• Compliance: automating the gathering of compliance data via applications to produce reports adapted to existing security, governance, and/or auditing processes.
• Retention: storing historical data long-term to ease the correlation of data over time, and enables application of compliance requirements.
• Normalization: translating computerized jargon into readable data for easier display and mapping to user- or vendor-defined classifications and/or characterizations. Sometimes referred to as field mapping.

A SIEM isn’t just a plug and forget product, though. If all your company does is purchase a SIEM, hook it into the network, and then assume that the SIEM has the security bases covered, you’re going to run into a lot of issues. A SIEM is a means of standardizing a security workflow for your incident response or digital forensics teams – in concert with the SIEM these employees can help keep your network secure.

That’s just one reason of many though – some other reasons to deploy SIEM systems are:

• Compliance with regulations like HIPAA, SOX, PII, NERC, COBIT 5, PCI, FISMA, etc.
• Certification acquisition and maintenance like ISO 27000, ISO 27001, ISO 27002, and ISO 27003
• Log management and retention
• Incident response and continuous monitoring
• Case management or ticketing systems
• Policy enforcement validation and monitoring for 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 allow not only for the protection of sensitive data, but provide a means of proving that this is being accomplished while meeting those compliance requirements. Through a SIEM, the company 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 those regulations.

However, as previously said, a company cannot simply deploy a SIEM and assign employees to monitor it, 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 must be fine-tuned. Too many alerts, and the teams assigned to work with the SIEM will start missing 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 know the network well, keep an eye on the SIEM and the systems it monitors, and update according to the needs of the business and network. The Gartner Adaptive Security Architecture model below demonstrates 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 into it – without reviewing, observing, and adjusting the SIEM as necessary, it will become stagnant and eventually turn into a liability. The SIEM solution(s) implemented should be business-driven and process-centric – something like the ITIL framework can assist with determining what processes or procedures need to be combined, modified, or even thrown out altogether.

Where to begin? Try a service catalogue, 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 using a SIEM should be done in a continuously adaptive manner, the same applies here – the field is constantly changing, and the following change with it:

• Compliance requirements
• Processes
• Procedures
• Threats
• Vulnerabilities and CVEs
• People or Personnel
• Client/User Expectations
• SLAs

How your business implements SIEM solutions may not be identical nor 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 the purpose that you want for the SIEM, which makes it easier to define assets and prioritize.

With assets and priorities sketched out, the next step is to define the scope. This is key to ensuring that your SIEM solutions fits properly, as opposed to being over- or under-built for your purposes. This scope should encompass empowering in addition to supporting and protecting the business.

Efficient technology, network operations, or security operations teams work under some sort of procedures and processes in place to identify:

• Data classification
• Key assets
• Ingress/Egress points (both network and physical)
• Applicable compliance mandates
• Internal IP schema

Once you have these, there must also be processes in place that include responsibility and accountability. It’s also important to have a resource that has the answers or that can get the answers – be it a person, team, or even an internal webpage to act as a reference document.

To ensure consistency with your implementation, you can align your SOC (or SIEM implementation) with the ITIL general & service management practices (https://en.wikipedia.org/wiki/ITIL) and use it as a guide or roadmap, since it is focused on service management.

Strategy Management

Define either your vision for a SIEM, or the service that the SIEM solution will provide as a whole. It can be simple or complex, but it’s better to start simple and define a ‘common sense’ set of objectives. The 10 common use cases linked earlier can serve as a good starter set.

Service Design

Once you have analyzed the business requirements, you can start to line up your expectations for a SIEM/SOC with the business, along with deployment initiatives. The goal here is to create a “SIEM service catalogue”, a set of metrics that act as the core functions of the SIEM for your business.

Service & Technical Management Practices

Your SOC or SIEM operators need to be kept aware of changes in the environment. This may seem like an obvious thing to point out, but this boils down to a need for controls. A SOC or SIEM operator who doesn’t know that a new PC was added to the network, or that a data center is offline temporarily (for instance), can lead to a situation where there are false alarms, failed audits, invalidated reports, and much more.

This is also the step where you’ll want to show the core functions described in “Service Design” by defining responsibility, communications, and SLAs and OLAs, if possible. You especially want to note trends, remediation, daily activities, as well as configuration and inventory changes.

Continual Improvement

This is often the hardest step for a business, but it is also the most necessary. This is the stage at which data is reviewed and used along with the metrics established earlier to redefine or refine services, processes, and procedures. This is a great opportunity to also verify and validate data gathered using manual or GRC methods and mechanisms. Use of a continual improvement register (recommended by ITIL) can assist here too.

By now, you should understand why you need a SIEM, and understand some of the many points of value 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 gain a better understanding of what a SIEM can do for you specifically. Use proven frameworks and resources that have been proven invaluable for cybersecurity management – like a SIEM. A tool like the NIST cybersecurity (https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.04162018.pdf) reference tool can be an excellent assistant in determining some of your initial requirements.

To learn more about Tripwire’s SIEM and log management solutions, click here.

The post ” WHAT IS A SIEM, AND WHY SHOULD YOU HAVE ONE?” appeared first on TripWire

Source:TripWire – Ary Widdes