Aligning Security Operations with the MITRE ATT&CK Framework E-Book

Rebecca Blair

• Herausgeber: Packt Publishing
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Englisch

Seitenzahl: 278

Veröffentlichungsjahr: 2023

Beschreibung

The Mitre ATT&CK framework is an extraordinary resource for all SOC environments, however, determining the appropriate implementation techniques for different use cases can be a daunting task. This book will help you gain an understanding of the current state of your SOC, identify areas for improvement, and then fill the security gaps with appropriate parts of the ATT&CK framework. You’ll learn new techniques to tackle modern security threats and gain tools and knowledge to advance in your career.
In this book, you’ll first learn to identify the strengths and weaknesses of your SOC environment, and how ATT&CK can help you improve it. Next, you’ll explore how to implement the framework and use it to fill any security gaps you’ve identified, expediting the process without the need for any external or extra resources. Finally, you’ll get a glimpse into the world of active SOC managers and practitioners using the ATT&CK framework, unlocking their expertise, cautionary tales, best practices, and ways to continuously improve.
By the end of this book, you’ll be ready to assess your SOC environment, implement the ATT&CK framework, and advance in your security career.

Leseprobe

Aligning Security Operations with the MITRE ATT&CK Framework

Level up your security operations center for better security

Rebecca Blair

BIRMINGHAM—MUMBAI

Aligning Security Operations with the MITRE ATT&CK Framework

Copyright © 2023 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Group Product Manager: Pavan Ramchandani

Publishing Product Manager: Prachi Sawant

Senior Editor: Runcil Rebello

Technical Editor: Arjun Varma

Copy Editor: Safis Editing

Project Coordinator: Ashwin Kharwa

Proofreader: Safis Editing

Indexer: Tejal Daruwale Soni

Production Designer: Prashant Ghare

Marketing Coordinator: Agnes D’souza

First published: May 2023

Production reference: 01280423

Published by Packt Publishing Ltd.

Livery Place

35 Livery Street

Birmingham

B3 2PB, UK.

ISBN 978-1-80461-426-6

www.packtpub.com

To my colleagues both past and present, thank you for your mentorship and cooperation. To my friends, thank you for the support and for pushing me to be who I am, especially Tyler and hype-woman Jennifer. To my family, Emily, Alex, and Gadget, thank you for your patience and support; without it, this book would not have been completed. To countless others not mentioned, thank you.

– Rebecca Blair

Contributors

About the author

Rebecca Blair has, for over a decade, focused on working in and building up security operations center (SOC) teams. She has had the unique experience of building multiple teams from scratch and scaling them for growth and 24/7 operations. She currently serves as the manager of the SOC, corporate security, and network operations center (NOC) at a Boston-based tech company, and as a cyber educational content creator for N2K Networks. She previously worked as the director of SOC operations at IronNet, a lead technical validator, a watch officer, and an SOC analyst for various government contractors. She has a bachelor of science degree in computer security and information assurance from Norwich University, a master of science degree in cybersecurity from the University of Maryland Global Campus, and a master of business degree in administration from Villanova University.

About the reviewer

Allen Ramsay has worked in the cyber trenches in 24/7 SOCs for most of his career. He has specialized in network defense and alert triage. He has previously contributed to multiple articles for SC magazine and has been a contributing author to The Rook’s Guide to C++. He has a bachelor of science in computer security and information assurance from Norwich University and a master of science degree in cyber forensics and counterterrorism from the University of Maryland Global Campus.

Table of Contents

Preface

Part 1 – The Basics: SOC and ATT&CK, Two Worlds in a Delicate Balance

1

SOC Basics – Structure, Personnel, Coverage, and Tools

Technical requirements

SOC environments and roles

SOC environment responsibilities

SOC coverage

SOC cross-team collaboration

Summary

2

Analyzing Your Environment for Potential Pitfalls

Technical requirements

Danger! Risks ahead – how to establish a risk registry

Red and blue make purple – how to run purple team exercises

Discussing common coverage gaps and security shortfalls

Summary

3

Reviewing Different Threat Models

Technical requirements

Reviewing the PASTA threat model and use cases

Reviewing the STRIDE threat model and use cases

Reviewing the VAST threat model and use cases

Reviewing the Trike threat model and use cases

Reviewing attack trees

Summary

4

What Is the ATT&CK Framework?

A brief history and evolution of ATT&CK

Overview of the various ATT&CK models

Summary

Part 2 – Detection Improvements and Alignment with ATT&CK

5

A Deep Dive into the ATT&CK Framework

Technical requirements

A deep dive into the techniques in the cloud framework

A deep dive into the techniques in the Windows framework

A deep dive into the techniques in the macOS framework

A deep dive into the techniques in the network framework

A deep dive into the techniques in the mobile framework

Summary

6

Strategies to Map to ATT&CK

Technical requirements

Finding the gaps in your coverage

Prioritization of efforts to increase efficiency

Examples of mappings in real environments

Summary

7

Common Mistakes with Implementation

Technical requirements

Examples of incorrect technique mappings from ATT&CK

Examples of poor executions with detection creation

Summary

8

Return on Investment Detections

Technical requirements

Reviewing examples of poorly created detections and their consequences

Finding the winners or the best alerts

Measuring the success of a detection

Requirement-setting

Use cases as coverage

What metrics should be used

Summary

Part 3 – Continuous Improvement and Innovation

9

What Happens After an Alert is Triggered?

Technical requirements

What’s next? Example playbooks and how to create them

Flowcharts

Runbooks via security orchestration, automation, and response (SOAR) tools

Templates for playbooks and best practices

Summary

10

Validating Any Mappings and Detections

Technical requirements

Discussing the importance of reviews

Saving time and automating reviews with examples

Turning alert triage feedback into something actionable

Summary

11

Implementing ATT&CK in All Parts of Your SOC

Technical requirements

Examining a risk register at the corporate level

Applying ATT&CK to NOC environments

Mapping ATT&CK to compliance frameworks

Using ATT&CK to create organizational policies and standards

Summary

12

What’s Next? Areas for Innovation in Your SOC

Technical requirements

Automation is the way

Scaling to the future

Helping hands – thoughts from industry professionals

Summary

Index

Other Books You May Enjoy

Preface

Hi, infosec professionals! This book is for cyber security professionals that are interested in SOC operations and/or are currently working in SOC operations. It is also for those interested in learning about the MITRE ATT&CK framework and bridges the gap between theoretical and practical knowledge through the use of examples, implementations, and detections.

There are three main portions to this book. They are as follows:

The Basics – SOC and ATT&CK – Two Worlds in a Delicate BalanceDetection Improvements and Alignment with ATT&CKContinuous Improvement and Innovation

There are various resources out there about different tools that map to MITRE, as well as the MITRE ATT&CK framework, which is fully publicly available online at https://attack.mitre.org/. What sets this book apart is that it takes practical knowledge of how to set up your environment and an in-depth review of the MITRE ATT&CK framework and explains how you can apply that framework to your environment.

Who this book is for

This book is for security professionals of all levels. It is focused on SOC environments but also covers some compliance, purple team exercises, threat hunting, and so on. It can be used to help build new security programs, as well as level up and assess the maturity of your current program.

What this book covers

Chapter 1, SOC Basics – Structure, Personnel, Coverage, and Tools, introduces the landscape of the SOC, which is a critical team in security and can have many different roles and sub-teams. We’ll discuss SOC basics such as alert triaging, creating detections, incident response, and “trust but verify,” as well as how it can interact with other teams or have sub-teams. This information is important because depending on the environment, you’ll be able to apply different aspects of ATT&CK.

Chapter 2, Analyzing your Environment for Potential Pitfalls, discusses techniques for critically reviewing your processes, coverage, and systems, and provides advice on potential problem areas. By following this, the reader will be able to directly apply it to their environments to look for areas of improvement and avoid any pitfalls; it will also be helpful when looking to implement ATT&CK.

Chapter 3, Reviewing Different Threat Models, reviews multiple different threat models, their use cases, and their advantages and disadvantages. Doing so will allow the reader to apply the one that makes the most sense for their environment; the chapter also provides a comparison point to compare those threat models to ATT&CK.

Chapter 4, What is the ATT&CK Framework?, outlines the evolution of the ATT&CK framework and the various different high-level configurations for types of systems (i.e. cloud, mobile, Windows, etc.). It will also be the first introduction to related use cases.

Chapter 5, A Deep Dive into the ATT&CK Framework, provides a deeper look at the different techniques that are covered by the framework, and potential gaps within the framework. The reader will understand how to rank different techniques and their applicability to their own environments. This will focus specifically on the cloud, Windows, Mac, and network frameworks.

Chapter 6, Strategies to Map to ATT&CK, discusses how to analyze your environment, identify coverage gaps, and identify areas for improvement. Then, we’ll cover how to map those gaps to the ATT&CK framework, to increase coverage and build out maturity in your security posture.

Chapter 7, Common Mistakes with Implementation, presents an overview of common mistakes that I have personally made in mappings and detections, as well as areas where I’ve seen others make mistakes. That way, you can learn from our shortcomings and implement mappings the right way.

Chapter 8, Return on Investment Detections, explains how creating detections and alerts is the bread and butter of any SOC environment. It should not be a surprise to anyone that less-than-stellar detections are created/triggered on a daily basis. This chapter will discuss alerts that we have had the highest efficiency ratings on, as well as the lowest, and how to measure their success.

Chapter 9, What Happens After an Alert is Triggered?, covers how once an alert is triggered, in theory, a set of actions begins. This chapter will discuss the different sets of actions, how to create playbooks, and how to ultimately triage alerts.

Chapter 10, Validating Any Mappings and Detections, argues that the most important step you can take to help yourself is setting up a review process. This can be completed manually, or you can create an automated feedback loop to track the efficiency ratings of your mappings and make improvements when necessary.

Chapter 11, Implementing ATT&CK in All Parts of Your SOC, goes through how to narrow down your environment and prioritize where you need to fix a coverage area. The chapter will then outline how you can implement detections and the ATT&CK framework as part of your overall security posture, and how it can be applied to teams outside of the SOC as well.

Chapter 12, What’s Next? Areas for Innovation in Your SOC, points out some key areas that can take a SOC from basic to mature, covering topics such as scalability and automation. This chapter will include ideas that I had for innovating my own SOC but also interviews with other industry professionals and what they think needs to be done to achieve innovation.

To get the most out of this book

This book can apply to all types of SOC environments, and while no specific software is required, there are multiple examples that use Log Correlation or Security Information Event Management (SIEM) tools, as well as Search Orchestration Automation and Response (SOAR) tools. This book will also cover matrices for multiple operating systems such as Windows, Linux, macOS, network, mobile, and so on, so a base understanding of those types of operating systems and environments would be helpful but not necessary.

Software/hardware covered in the book

Operating system requirements

MITRE ATT&CK framework

Windows, macOS, or Linux

SOAR tools (Insight Connect)

SIEM (Splunk)

Amazon Web Services (AWS)

Download the color images

We also provide a PDF file that has color images of the screenshots and diagrams used in this book. You can download it here: https://packt.link/Cy0Jj

Conventions used

There are a number of text conventions used throughout this book.

Code in text: Indicates code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles. Here is an example: “Screen Capture is carried out by an attacker utilizing the screencap, screenrecord, or MediaProjectionManager commands.”

A block of code is set as follows:

index=network_data size= (bytes_out/1024) size>= 100 | table _time, user, size

Bold: Indicates a new term, an important word, or words that you see onscreen. For instance, words in menus or dialog boxes appear in bold. Here is an example: “A tactic in the ATT&CK framework for the enumeration of shares can be found at Network Share Discovery.”

Tips or important notes

Appear like this.

Get in touch

Feedback from our readers is always welcome.

General feedback: If you have questions about any aspect of this book, email us at [email protected] and mention the book title in the subject of your message.

Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/support/errata and fill in the form.

Piracy: If you come across any illegal copies of our works in any form on the internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.

If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.

Share Your Thoughts

Once you’ve read Aligning Security Operations with MITRE ATT Framework, we’d love to hear your thoughts! Please click here to go straight to the Amazon review page for this book and share your feedback.

Your review is important to us and the tech community and will help us make sure we’re delivering excellent quality content.

Download a free PDF copy of this book

Thanks for purchasing this book!

Do you like to read on the go but are unable to carry your print books everywhere?
Is your eBook purchase not compatible with the device of your choice?

Don’t worry, now with every Packt book you get a DRM-free PDF version of that book at no cost.

Read anywhere, any place, on any device. Search, copy, and paste code from your favorite technical books directly into your application.

The perks don’t stop there, you can get exclusive access to discounts, newsletters, and great free content in your inbox daily

Follow these simple steps to get the benefits:

Scan the QR code or visit the link below

https://packt.link/free-ebook/978-1-80461-426-6

Submit your proof of purchaseThat’s it! We’ll send your free PDF and other benefits to your email directly

Part 1 – The Basics: SOC and ATT&CK, Two Worlds in a Delicate Balance

The first part of this book will provide you with the basics. This means that it will cover what goes into a SOC, or Security Operations Center, including the teams and key roles that play a key part in security operations, and some of the teams that a SOC works closely with. Then, you will learn how to analyze your environments for security gaps and gain an understanding of a few different threat models that could be applied to your environment. As a send-off for the first part, we will cover an introduction to the ATT&CK framework, and we will cover it in more depth in the following parts.

This part has the following chapters:

Chapter 1, SOC Basics – Structure, Personnel, Coverage, and ToolsChapter 2, Analyzing Your Environment for Potential PitfallsChapter 3, Reviewing Different Threat ModelsChapter 4, What Is the ATT&CK Framework?

1

SOC Basics – Structure, Personnel, Coverage, and Tools

In this chapter, we will cover the landscape of what your average security operation center (SOC) looks like. We’ll discuss the structure of the specific roles within the SOC and possible sub-teams that can feed into or be part of the SOC environment. We’ll discuss strategies for alert triage, creating detections, incident response, and other important functions such as “trust but verify,” and how these functions can promote cross-team collaboration and apply to all aspects of the business. Having a strong understanding of the SOC can be critical to applying the various aspects of the ATT&CK framework. This will also allow you to evaluate the SOC environments that you might work in or interact with, and suggest possible changes, improvements, or areas for expansion. This chapter is comprised of the following sections:

SOC environments and rolesSOC environment responsibilitiesSOC coverageSOC cross-team collaboration

Technical requirements

For this chapter, there are no installations or specific technologies that are required.

SOC environments and roles

The SOC environment is one of the most critical teams that comprises your organization’s security posture. At the same time, there is no true one-size-fits-all for any SOC environment, which is part of the fun when evaluating yours for improvements. So how do you evaluate how your SOC should be set up? Well, that depends on the purpose of your organization. To test that theory, we will discuss a few hypothetical companies and the make-up of a few different SOC teams that I have seen first-hand. We’ll also talk through important traits for any SOC employee and drill down to specific roles.

SOC environments, as mentioned, all look different, but at the core, they are responsible for alert triage and incident response. In some cases, they can also be responsible for red team activities, security engineering, and network monitoring. That means that your basic roles are SOC analysts, incident responders, and SOC managers, but again that changes depending on scope. Expanded SOC environments might have network operations center (NOC) managers, NOC analysts, security engineers, threat intelligence analysts, or red team operators.

The first hypothetical SOC that we will evaluate is for a company called Blair Consulting. Blair Consulting has a SOC that is responsible for the management of security tools for building detections and for tabletop exercises, and they also have a hybrid environment, which means that there is a combination of on-premises systems and cloud systems. A SOC at that company would be comprised of a SOC manager, incident responder, security engineers, a red team specialist or engineer, and a cloud security engineer. The specific number of people would depend on the size of the organization, but as a rule of thumb, I try to have 1 incident responder for every 200–300 employees. That number primarily takes effect after you have a base set of employees for your team, which is done in the scaling-up period. This also changes if you are a public or private company because if you are public, or depending on the types of data your organization has, you might have reporting requirements for incidents, such as reporting to credit card bureaus in the case of a breach that concerns payment card industry data.

As you can see, any environment will require different teams and personnel, and no one environment looks the same. You should base it on the resources your organization has, the risks that have been identified as high and critical for your organization, and the projected growth/scalability of both the team and the organization.

SOC environment responsibilities

A SOC environment can have varying responsibilities. At the core, you have an incident response and alert triage. To accomplish comprehensive incident response, you want to have a strategy for 24/7 coverage, which can be accomplished by having a larger team and having shift patterns, partnering with a managed service security provider (MSSP), implementing a follow-the-sun model, or using an on-call roster. The option that you choose depends on the resources and infrastructure your team has. For example, if the organization has multiple offices located around the world, you would want to implement a follow-the-sun model, where you have multiple SOC analysts located at each office so that they can work their respective 9–5 type shift, and due to the various time zones and the addition of a few weekend shifts, that will give you the 24x7 coverage envisaged by the follow-the-sun model. The advantages of using an MSSP would give you the advantage of having a smaller in-house team while having support for alert triage and 24x7 coverage, but of course, that comes with a typically high price tag.

If you do everything out of one office and in multiple shifts, you would typically see 4 different shifts of 12 hours, A Day, A Night, B Day, B Night, where in 1 week, members assigned to A Day and A Night work for 4 days with 12-hour shifts, and the ones assigned to B Day and B Night work 3 days with 12-hour shifts, Each week, it would flip for the team that worked weekends.

The following chart will help you envision this:

Figure 1.1 – 2-week 4-shift rotation schedule

The benefit of that is that in a 14-day time period, you only work 7 days, but again they are 12-hour shifts. You’ll see this type of setup in a lot of government SOC environments. The final option is to just use an on-call roster. In theory, if a high-severity alert is triggered or someone needs to trigger the incident response process, they would use a call roster or a tool such as Ops Genie, which would page whoever is on call. While this is the cheapest option for coverage, it does come with a higher level of risk that alerts will go untriaged, or incidents might take longer to contain or mitigate. In my experience, I’ll typically start a new SOC environment following the on-call method while processes are established, and then as the organization and SOC mature, I’ll either contract with an MSSP or hire enough staff to use the follow-the-sun method.

In addition to incident response, another core responsibility is alert triage. To have alerts, you need to also establish detections that can be completed by SOC analysts or dedicated detection engineers. Alert triaging can sound boring and monotonous, but it is a situation where you are constantly solving a different puzzle. It’s the responsibility of the SOC to create alerts to be able to effectively analyze the logs to find potentially suspicious actions or traffic. The purpose of that is that it is not effective or scalable to be analyzing raw logs all day; the rate at which suspicious actions would be missed is astronomical. Therefore, in theory, it is a key responsibility to have the ability to create complex alerts, which ideally pull in information from various data sources to essentially complete the first few steps of triage for your analysts. You also need to test alerts and review them regularly for efficiency because you do not want your analysts to spend all day triaging false positive alerts. Another aspect that can help with this responsibility is setting up some type of case management system to ensure that analysts do not duplicate efforts by triaging the same alert, and that would allow you to track metrics such as time to ticket, time to triage, and time to mitigation, which can help you drive initiatives for your team.

Threat intelligence analysts can be like security engineers or other types of roles in the SOC, the same way that a SOC analyst might perform some threat intelligence activities such as conducting operational intelligence research, which would provide contextual information for potentially suspicious IPs, domains, URLs, among other types of activities. A threat intelligence analyst conducts research on a larger scale. Some of their responsibilities might include integrating threat feeds such as ones from Abuse.ch, FireEye, and GoPhish (there are literally hundreds of both public and private threat feeds) or creating a deny list of hashes or domains based on triage findings, which can be applied to your organization’s firewall or endpoint detection and response tools. Another responsibility of a threat intelligence analyst is to stay current on all cyber threats, advanced persistent threat groups, and vulnerabilities, which may include writing threat reports on vulnerabilities that apply to the organization or industry.

The NOC is a part of the SOC or can be its own team. The NOC contains team members called NOC analysts, who have similar responsibilities to SOC analysts. They are responsible for monitoring networks; however, they can be less security-focused. A great example of a NOC is where it monitors smaller managed networks and remediates or investigates changes that might not align with a golden image, or reviews whether a change management process was followed properly for any network changes. If a network change might be suspicious, the NOC would work closely with the SOC to triage and assist where needed in the incident response process.

Security engineers can have a multitude of responsibilities. First, they can assist with creating detections and alerts for analysts. Next, they work heavily on the concept of “trust but verify.” This means that you trust employees with the best of intentions, but review configurations to ensure that they are secure. One common example is that when testing in a development environment, it’s very easy to stand up a new Amazon Elastic Cloud Computer (EC2) instance or create a new security group and in the interest of time, leave its firewall rules wide open to the internet. A security engineer would ideally have alerts set up to trigger when a new overly permissive group is stood up and work with that initial person to restrict the group as needed for the project.

Red team operators similarly can be their own team and work closely with security engineers and the SOC or fully be part of the SOC. Red team engineers or operators typically work on offensive operations tasks such as penetration testing, purple team testing, and assisting with trust-but-verify. The penetration testing responsibility and purple teaming go hand in hand. A purple team exercise is where a penetration test is being conducted via a set of pre-specified use cases, and the SOC analysts are notified when the testing is going to begin, its status, and so on. That way, it is a collaborative effort to test out any detections and coverage and provide an opportunity to improve.

Managers of sub-teams or of the SOC, or really any leadership role as part of the overall SOC, needs to be unique. They of course must handle administrative tasks, such as capturing metrics, creating reports, and personnel management, but they also must have a strong technical background to be effective. They must plan out a roadmap that addresses the risk of the organization, allows the team to grow and follow a scalable model, while also supporting the team members. To provide for proper growth and planning, the managers should be able to project the next 6 months of roadmaps. I recommend planning out no more than 60% of your time for projects depending on the role, to account for interrupts such as incidents or unforeseen complications and be flexible in the amount of work or types of projects projected to allow for necessary pivots.

SOC environments clearly have many varying roles and responsibilities, which really depend on the specifics of your organization and environment. You should identify the expected responsibilities of your SOC and ensure that you have enough personnel with the correct skill set or potentially provide training to develop the needed skill sets to fill any role. For scaling purposes, I typically try to add one SOC analyst and one security engineer per 500 employees, 1 NOC analyst per 5,000 network assets, 1–3 total red team engineers, 1 threat intelligence analyst for every 1,000 employees, 1 manager for every 5–10 SOC employees, and a senior manager or director as needed. Of course, this is just a general rule of thumb and can be tweaked to meet your needs.

SOC coverage

Expanding coverage and using your data effectively is critically important to any SOC’s ability to carry out its responsibilities. With a lack of coverage or visibility, the SOC will have nothing to monitor or detect, and your organization will have a significantly higher risk level because of it. That’s why it is an important factor within a SOC to determine the current level of coverage, where the gaps are, how to prioritize the gaps, and how to fill those gaps by increasing coverage.

The first stage is to determine what level of coverage you currently have. Regardless of whether your organization is a newer SOC or a more established one, I make it a point to baseline coverage before making any other roadmap decisions. To do so, I take note of all data sources that are being ingested into whatever security information event management (SIEM) is in use, such as Splunk or ELK, and I write down and organize all alerts by function. In addition to this, I review or create a risk registry that categorizes the highest risks that face the organization and, if time permits, conduct a purple team exercise. As explained in the SOC environment responsibilities section for a red team engineer role, and will be further explained in future chapters, a purple team exercise is a joint project where offensive operations are carried out to test the visibility and efficiency of alerts in place. This can also be useful in proving the negative, which means proving that attacks can be conducted without any visibility, which helps push the importance of increasing coverage.

After you have determined where the gaps are, you need to prioritize them and create a plan on how to fix them. One of the strategies for prioritizing is to list out the types of logs and visibility each missing source would give. For example, if you are not capturing logs from your organization’s Virtual Private Network (VPN), and it’s a remote work environment, then you have limited visibility into User browsing logs. You would then write out the risks or potential attacks that could be discovered with those logs and write down any mitigations. For example, while you might not capture user browsing logs but capture endpoint detection and response logs, you’ll still have some visibility into the applications used, and downloads, so that might lower the risk of not capturing those initial logs. Another strategy is after writing down the missing sources and suspected size of the logs, to prioritize them based on an effort to ingest them. For example, if you can download an app on your SIEM, utilize an API key and creds, and everything is managed in-house, then as long as the size of the logs isn’t the problem, you should be able to easily configure the new ingest. I typically recommend picking a mix of harder-to-implement logs to start the process for ingest while also implementing a few that are considered a quick win. Another way to prioritize coverage gaps is based on what you are prepared to write detections for or base it on team expertise. That way, you know whatever source of data that gets added will immediately be used to increase coverage because, in theory, you don’t want to waste licensing space, time, or money if you can’t take advantage of the additional coverage.

Filling any coverage gaps after prioritization can be done by expanding your ingest license for your current SIEM tool or using a data lake to capture additional logs without ingest in your SIEM tool. Therefore, you’ll still be able to run analytics and only ingest absolutely necessary data within your SIEM tool. Expanding your resources and current license seems like the simplest path, but a common issue with that path is that it can be cost-prohibitive. That’s where other solutions such as log tiering or using a data lake come into play. By implementing a different technical solution, such as a data lake through providers such as Snowflake, you are able to have logs transferred and collected in a centralized location, and then run analytics over those logs, and only ingest detections on a subset of the logs. That way, you have the coverage, but your ingest costs are lower. One of the downsides to this approach is that you need to implement a new technical implementation, connectors, and so on, and that, of course, has its own costs associated with it. Of course, any approach that is taken to fill a coverage gap is reliant on proper cross-team collaboration.

Coverage is always an ongoing battle as your company grows and gains capabilities. It’s important to regularly evaluate your coverage for improvements and to document any gaps, as this will help your SOC team mature. As mentioned, there are multiple ways to evaluate coverage and identify gaps, which will allow you to make an action plan for how to remediate those gaps.

SOC cross-team collaboration

“Alone we can do so little; together we can do so much” – Helen Keller.

This quote