Why Do I Need A SIEM?

In my previous post in this series, we discussed that a "SIEM" is defined as a group of complex technologies that together, provide a centralized bird's-eye-view into an infrastructure. Furthermore, it provides analysis and workflow, correlation, normalization, aggregation and reporting, as well as log management. In this next post, I hope to answer the question: "Why do I need SIEM?" and touch on some of the basic capabilities of implementing a SIEM in your environment. I will also expand on an idea called ITIL – a framework that when paired with SIEM (Security Information and Event Management), could potentially become a self-propelling, self-maturing system. Let's start by noting some of the driving factors behind why some major corporations have implemented a SIEM. This can also shed light on why many SIEM implementations fail or succeed. As I mentioned in my last post, the SIEM is used and perceived differently depending on initiatives or what you expect out of it. Some of the major drivers behind why companies deploy SIEM technologies, and why you need a SIEM are:

• Compliance obligations (HIPAA, SOX, PII, NERC,COBIT 5 ,FISMA, PCI, etc.)
• Gaining and maintaining certifications (such as ISO 27000, ISO 27001, ISO27002 and ISO 27003)
• Log management and retention
• Continuous monitoring and incident response
• Case management or ticketing systems
• Policy enforcement validation and policy violations

Primarily, SIEM has been implemented in response to governmental compliance requirements. Similarly, many companies decide to implement SIEM in an effort to not only protect sensitive data but also demonstrate proof that they're doing so, while meeting their compliance requirements. A failed audit could have catastrophic results of loss of business and employees, in addition to hefty fines. For these reason, many companies regularly complete their own internal audit to validate and verify that they are meeting these requirements. With SIEM, this is totally avoidable. Figure 1 Deploying a SIEM is relatively straightforward. Reference the figure above (Figure 1) – you collect the logs, normalize, correlate and present it. Implementing, however, is a whole different animal, and this is where most companies fail. The SIEM isn't a plug-and-play notion. I like to compare the SIEM to a child... Just as every child born healthy has the potential to do almost anything or become anything, there are conditions, which lead us into nurture vs nature. If the child has no parenting, no leadership, no education, no anything, his or her future would look pretty bleak, and rightfully so. A SIEM is similar. You don't install, turn on, assign personnel and walk away – it needs constant tuning and attention based on business needs and expectation. Believe it or not, this is exactly what companies do, while complaining about how disappointed they are in the product they deployed. Figure 2 Take a look at the Gartner adaptive security architecture here (Figure 2). The SIEM is a direct reflection of what you put into it. If you do not continually invest in it by reviewing, observing and adjusting, it will initially become stagnant, then eventually – a liability. The most important thing I've observed is people should realize that – just like kids, there are no two SIEM implementations alike, and no two environments alike. They may be similar, but they are not the same. This is where a SIEM implementation can potentially become engineer centric, and it shouldn't. It should be business driven, and process centric. With the ITIL framework in mind, you'd not only begin with a head start, you'd mature your SIEM into providing a value to your business and team. You'd be able to see what processes or procedures need tweaking, combined and thrown out altogether. Start with a service catalogue. Don't have one? Use a few basic use cases, and go from there. There's no need to reinvent the wheel. However, it is imperative that continuous adaptive framework are incorporated. This is necessary primarily because the playing field, the components and the rules continue to change. Also, as defined in the ITIL framework, you need to employ ITIL key performance indicators or KPIs, clearly defined to validate effectiveness or need for tweaking and tuning. It's essential that this cycle is continuous because of these constant changes:

• Compliance Requirements
• Processes
• Procedures
• Threats
• Vulnerabilities
• People or Personnel
• Vulnerabilities and CVEs
• Client\User Expectations
• SLAs

As stated before, there are no two implementations alike, and you need to see what works for your environment and business. Create a roadmap that can be used as a guide – you start first by defining the "why" or the purpose. This will help when defining assets and prioritizing. Next, define the scope... I cannot say that loud enough. This is important, so you don’t over-build, or under-build and end up with a SIEM solution that doesn’t ‘fit’. Remember, business is the driver, so this should also encompass empowering, as well as supporting the business. To be very efficient, a business’ technology teams, network operations or security operations need to have some sort of procedures and processes in place that would identify:

• Data classification
• Key Assets
• Egress\Ingress points
• What compliance mandates are applicable
• Internal IP Schema

Once you have these, you must have processes, which include responsibility and accountability. As with any process, there needs to be a resource that has the answers or can get the answers. Otherwise, I guarantee a lousy ROI and negative SIEM deployment experience. Align your SOC, or SIEM implementation with ITL service management life cycle because it is so focused on service management and if used as a guide or roadmap, then you can ensure consistency.

What you need to know about implementating a SIEM

Service Strategy

Define your vision, or what services will the SIEM provide as a whole. This could be simple or complex. It’s best to start simple by defining a common sense set of objectives. The 10 common use cases could be a good starter.

Service Design

After analyzing all of the business requirements, now you begin to align your SIEM\SOC expectations and deployment initiatives with the business. Define your metrics to be used as your KPIs. These will be the core functions of the SIEM, or the "SIEM service catalogue.”

Service Transition

This is pretty self-explanatory but I will touch on it anyway because many implementations fail in this stage. Basically, SOC or SIEM operators should be made aware of changes in the environment. (Duhhhh, right?) Well, turns out this is a rarity, which brings me to my next point of controls. You need controls in place for this issue alone. This causes false alarms, failed audits, invalidates reports, and that’s just the tip of the iceberg.

Service Operations

The core functions described in 'Service Design,' are now shown as how they will be provided – define responsibility, communication and SLAs and OLAs if possible. You want to note:

• Trends
• Remediation
• Daily activities
• Configuration and inventory changes

Continual Service Improvement

Here, a review of all data gathered and based on KPI and other related metrics redefine or refine services. Processes and procedures. This is the best opportunity for verification and validation of data gathered using manual or GRC methods and mechanisms. Now, we see some of the many components or moving parts of this business of cybersecurity, and how overwhelming it can be. Now, we see why you need a SIEM, and just a few of the value points it can add to your environment. Just keep in mind that priorities, methods and initiatives vary by environment. This can introduce another set of complexities; however, just start simple. You may use some proven frameworks and resources that have been invaluable for cybersecurity management, which SIEM is a component of. A great reference tool is the NIST cybersecurity reference tool to assist in determining some of your initial requirements. To learn more about Tripwire's SIEM and log management solutions, click here.

About the Author: Joe Piggeé Sr. is a Security Systems Engineer that has been in the technology industry for over 25 years. He works in the eDiscovery and Forensic industries, and is a SIEM specialist and ITLv3 evangelist. He also provides volunteer security awareness, network monitoring, security operations and ITIL training to small businesses and non-profit organizations. I am currently working to achieve my CISSP and CISA. Editor’s Note: The opinions expressed in this and other guest author articles are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc. _{Title image courtesy of ShutterStock}