By Augusto Barros, Cybersecurity Evangelist, Securonix
IDP, antimalware, and other security tools detect security threats and breaches using threat signatures, indicators of compromise, correlation rules, machine learning models, and other detection content that tells them exactly what to look for. The volume of detection content they work with is massive and changes daily. Much of it is not relevant to every organization.
If you want to avoid overwhelming your security team with irrelevant alerts, you need to choose and adapt detection content to fit your organization’s specific security needs. Does it cover the right systems and threats? Is it effective and aligned with your IT environment or does it take up your time with a lot of false positives and irrelevant alerts?
The best way to manage security content is with a carefully crafted detection development life cycle (DDLC) process. The common model for a DDLC is very similar to that of software development with similar steps: detection use case identification, detection implementation, detection review and tuning, and detection retirement.
Agility is Central to a Development Life Cycle
All of these steps are vital for effective and efficient detection content management. And, as with software, an agile methodology is the best way to keep your detection content timely and relevant without bogging down your team with a lot of unnecessary work. Let’s take a look at each DDLC step.
Detection Use Case Identification
Detection content comes from a variety of sources, including security tool vendors, threat intelligence, and internal development. The main goal in this step is to identify and prioritize the content that monitors your organizational infrastructure best and is most feasible to deploy now. That usually means balancing the following factors.
Importance You’ll want content to focus on the threats, techniques, and tactics that pose the highest risk today and tomorrow.
Relevance You’ll want to avoid wasting time with irrelevant content, for example that which relates to operating systems you don’t have running in your organization.
Feasibility You’ll need to decide whether to include content with high implementation and operations costs. For example, some content may degrade the performance of your security tools, require data your tools don’t currently provide, produce output that requires too many resources to address, or generate an overwhelming number of alerts and false positives.
You may choose to work with content you can get started with fast today and leave other content for development at a later time.
Identifying necessary content takes time and resources. You need to monitor existing and new threats so you know what type of activity you should be looking for in your environment. Security technology vendors have an important role in this activity and can greatly reduce the effort of your team. The vendor operates on your behalf, so give preference to solutions backed by strong threat research teams.
You also need to decide how you want content defined, whether on the granular level of MITRE ATT&CK techniques or the more general level of MITRE ATT&CK tactics. Many organizations start at the tactic level and gradually incorporate more techniques over time.
This step is where you translate the content use cases you defined into actual content, such as connectors and parsers for specific data sources, IDP signatures, and SIEM rules. The agile paradigm of small, quick iterations with feedback loops provides the quickest time to value.
You also need to define how content will be triggered and handled in terms of response and you should test the new content with attack simulations to ensure it works. Then deploy it with appropriate change control and management. If you are relying on content provided by vendors, ensure they have an efficient way to deliver the content to your environment and give you the right capabilities to test it before promoting it to production.
Detection Review and Tuning
This happens at regular intervals and in response to a breach or an adverse situation such as excessive false positives or too many events to handle. You may make small changes in content thresholds, data, queries, and alert conditions to make the content more effective. However, if perfecting the content is impossible, you move on to the next stage.
As threats and systems change over time some content will become irrelevant, either because the threat is no longer widespread, the related vulnerability has been addressed, or the threat model is no longer relevant—such as when a website or application has been outsourced to a third party. The process can be tricky, as you must identify all the artifacts that need to be removed and ensure they’re not necessary for other detection content.
This is a basic DDLC template you can customize. The exact process you design and implement depends on your environment and resources and whether you’re just starting out or have evolved your DDLC over time. For your content to be effective at detecting threats and not overwhelm your resources, you’ll need a DDLC process that works best for you.
For more detail and perspective on DDLC, good DDLC metrics, and the steps involved, check out “Improving threat detection with a detection development life cycle” and a recent webinar “How to Build a Modern SOC in 2022?” that explores this topic further.