Pencils & Crayons

The Art of Selecting A SIEM

Chuck Johnson
8 min readJul 9, 2020

If this article is enticing, then you probably already know that SIEM is an acronym for Security Incident and Event Management. A SIEM platform provides Security teams with the ability to manage security incidents and events. The goal of this article is to provide a framework for defining and rating a SIEM to help ensure a successful selection, all using a pencil, crayon, and coloring analogy.

SIEM platforms contain different components depending on the vendor, with newer vendors offering cutting-edge capabilities and seasoned vendors providing a stable, known product, and support. Expanding this beyond the product into a replacement or selection effort requires a project which may have high visibility due to its scope. Like vendors, the project participants, whether sponsors or implementation personnel, also have unique individual ideas of what a SIEM platform and replacement effort should involve. Due to these factors, I feel it is critical to define the “SIEM platform”, and I recommend that definition utilize business capabilities.

Defining the “SIEM platform” via business capabilities is akin to outlining a picture with a pencil. Remember when you used to color in drawings in a book? It’s like that! Business capabilities describe what you are seeing. To complement this drawing, you use color or success principals. These principals will be the color applied to the picture you outlined. Completing these two steps will provide a framework, the drawing, and its soon to be applied color. The actual coloring and resultant comparison occur at the end.

Business Capabilities — The Pencil

To help with the idea of business capabilities, think services, or micro-services. If the SIEM platform was a monolithic legacy application, what services or micro-services would it contain? Capability means “qualities, abilities, features”; what you are doing is defining the monolithic SIEM platform into a micro-services architecture.

Back to the drawing analogy, what capabilities (qualities, abilities, features) must be drawn, must be part of the picture, to correctly define the “SIEM platform” from your perspective? What must the definition contain? Performing this step will define the business capabilities and the resultant requirements of the “SIEM” for your project, assisting you in aligning vendors, leadership, and project team members towards a common understanding of the generic acronym “SIEM”.

Ok, so let’s start. Here are some examples of core capabilities (qualities, abilities, features) that could exist within a SIEM platform:

  • Log/Event Collection
  • Log/Event Parsing / Normalization
  • Log/Event Search / Hunting
  • Log/Event Correlation / Pivot
  • Use-Cases & Alerting
  • Log/Event Storage
  • Dashboards / Reporting / Visualization

You may feel this list is not complete. You or your vendors may want to include other core capabilities into your definition, like; UEBA (User / Entity Behavior Analysis) or SOAR (Security Orchestration / Automation). Great! Define them. Realize this practice is less about agreeing with me on SIEM capabilities and more about defining for yourself, your company, and your vendors, what you are scoping into the definition of a SIEM platform.

Figure 1: Outlining business capabilities

Once your tier 1 (highest level) business capabilities are defined, you can continue brainstorming, identifying possible tier 2 and tier 3 capabilities that would role up to these first few tier 1’s. Think of tier 1 as the outline for the body, tier 2 as the outline for the vest, and tier 3, the stripe.

The goal is to articulate what you see when you say “SIEM platform” so you can compare your drawing to everyone else’s and thereby land on a single combined picture of what qualities, abilities, and features (capabilities) your “SIEM platform” contains.

Figure 2: Actual business capability diagram. Note Log/Event Collection as tier 1 with Agent or Agentless collection as tier 2. Expand to include what is essential to deliver a successful SIEM platform. Review and agree as a team and share it with your vendors, so all are on the same page. Update the model as needed.

Core Success Principals — The Crayon

The next step is to define the core principals that will help color success. In other words, what colors are required for the drawing to be good? How else will the final product be measured? That is what you are trying to figure out in this step. I suggest utilizing the following colors.

Note: Determining the quality of the coloring comes later.

Usability / Responsiveness

Is the tool easy to use? Are the things you want it to do, easy to do within it, and is it responsive? Do I have to engineer responsiveness into the tool, or are their SLAs provided by a platform? How long does a time-series query take against 30 days of data @100Gb / day?

Supportability / Scalability

How difficult is the tool to troubleshoot, manage, and scale? A critical aspect of a business-critical application fraught with large data volumes. For example, if you were evaluating an IaaS based SIEM vs. SaaS, supportability/scalability would be a factor. IaaS will require more personnel to manage it but may cost less. All of these items need to be defined, weighted, and scored to make a sound, long-lasting decision.

Durability / Resiliency

Think architecture. For each business capability that requires durability/resiliency, how well is it architected to provide that? Does it provide HA by default, or does that need to be engineered in by the customer? How quickly does ingest occur? Will I have to wait for 15m to see my logs appear?

Interoperability (API)

Is the SIEM platform easy to integrate? Do they have a robust, well documents API layer?

Open Source Community Support

Community support is listed after interoperability because it can provide your team with the ability to stand on the shoulders of giants. If other organizations have made significant progress with this platform, that benefits you and your team. If it is new without a large community of support, you will be the giants for someone else to stand on. Which do you want to be? Both are fine. Just be aware. What level of resources and support does the vendor provide the open-source community? Are they helping, managing, committing to the repos? You want to either create or become part of an ecosystem.

Data Gravity

Last but not least, I add the category of data gravity. It comes into play when you are selecting a SIEM. It is no accident that the big three cloud providers have each launched their own SIEM platforms. They know they have the data first. Data gravity is on their side, along with simplicity. Integrating their systems is streamlined; it’s usually just pointing and clicking. Add in more connections to move data, and you add in more potential problem areas, management points, and cost. When it comes to competing with gravity, less is more. The further away data moves from its source (the more connections), the more cost. To help visualize this variable, I suggest creating a force map. The circles depict the physical location of log sources, with each circle sized to represent the overall log/event volume expected from that location. Everything from each geographic point (real or logical) is expressed in a single circle, sized according to log volume.

Think data center(s), corporate buildings, remote or retail offices, and remote employees. The goal here is to visualize data volume. Lots of remote offices or remote employees, make them each a single category.

As an example, suppose you are a Citrix or centralized VDI shop (or plan to be) with all your applications and desktops in Google, AWS, or Azure. Maybe you have very few remote workers or sites. I would heavily weight Google’s, AWS, or Azure’s SIEM platforms, especially if you are thinking about this strategically and want this choice to stick for four or more years. If the big three cloud providers’ offerings are not mature enough yet, I would ask, can you postpone your replacement a year and establish a relationship with the cloud provider to become an influencer of where their product is going? It would be easier to move once than twice, and in 24 months, these big three will be very competitive in the SIEM space.

Let’s say you are not data center centric. Your data center is small; maybe most of your data is generated by distributed sources like remote users, offices, IoT devices, etc., then any cloud-based SIEM platform may work well for you.

The point here is to know your business. What’s its strategy? What’s its direction? How does it offer services now, and how does it plan to provide services later? How does that play into data gravity? How does this impact your decision?

Data gravity is a real force now, and will only grow to be more of an impact later. You are trying to avoid being surprised by how data, one of the primary ingredients to a successful SIEM platform, impacts scalability, complexity, and cost of your solution not just now, but years from now.

And One More Thing

The big three cloud providers entered the SIEM market for multiple reasons. Data gravity is just one reason. The simplicity of integrating with cloud-native technology is another. I wrote an article titled “The Art of Securing The Business”, where I described a third more abstract reason; InfoSec learning what they will be required to learn anyway. The primary three cloud providers SIEMs will be easier to integrate, assuming you are primarily cloud-based. Their products will align to data gravity, and possibly provide synergy for your InfoSec team to utilize the same query platform and resources as your IT delivery partners. The big three saw all of this coming, which is why they entered the SIEM market!

Conclusion

You have just covered the concepts required to establish a picture of your potential SIEM platform, and you have identified the colors you want to use to fill it in how the possible platforms compare. Now it’s time to work with your vendors to color. The quality of the coloring is dependent on the quality of the platform the vendor offers. Pencils and crayons. The art of selecting a SIEM. If the platform is usable and resilient, then these colors are applied well, staying within the lines and saturated. If these items are lacking, the color is faint and hard to see. You can also look at the outline (capabilities). Are all the items you require in a SIEM, available from the vendor? How does that compare to other vendors? Are some drawings missing capability details? Score those poorly.

Combine business capability scores with success criteria scores, and you begin to see how the drawings compare. In the end, you want the brightest, most colorful picture.

I hope you found this article and this framework helpful. Good luck on your journey.

--

--

Chuck Johnson

A witness to life; its patterns & flow. A discoverer of the essence of things. A creator of designs through observation. A security architect. Author.