The Life Cycle of a Threat Pattern

Applying a structured approach to developing and maintaining significant threat patterns is absolutely key to successfully hunting for the advanced TTPs used by many motivated threat actors. In the post, Context in Risk-Based Threat Patterns, author Demetrio Milea suggested a simple and effective method borrowed from the Software Development Life Cycle (SDLC) to design and maintain threat patterns in security platforms. What would this look like in a real scenario? Let’s go through it step by step.

Analysis – Get deeper into the context.

Understanding the scenario that the organization lives in can help the process of defining patterns, which would help ensure the generation of  a low number of false positives and ideally no false negatives. The scope of this phase includes analyzing the high and low level design of the assetwhich the threat pattern is intended to monitor, as well as assess the residual risks. A few questions to consider:

• What are the data flows, components and access points that define the asset?
• What is the use and misuse case you want to cover?
• What kind of security controls are already deployed?
• What techniques and tools are you trying to detect?

Design. – Employ an analytical mindset before jumping to the keyboard.

Conceptually describe the threat patterns that would meet the requirement specifications, as well as the use and abuse cases depicted during the initial analysis. Then, evaluate which security platforms the pattern can be deployed to be more relevant and effective against specific attack vectors. Once you verify all the necessary data, design the relationships to ensure the previously defined objectives are met. Some useful questions to consider:

• Which data feed is required by the indicator?
• What is supposed to be logical flow of the pattern and its indicators?
• What are the building blocks and how are those linked together?
• What should be the thresholds to set?

Implementation – The dirty jobs that somebody has to do… 

A good implementation can make the difference between a happy SOC, or,  angry analysts dealing with tons of false positives. The golden rule here is to not assume that what you have in mind will necessarily behave in the same way, once the concept has been translated into the proper machine language. And like with any good software development project, divide the work in modules and units before starting the actual coding.

• Are all the sources feeding the expected data?
• What are the most appropriate security platforms to implement the pattern?
• Can the detection of the pattern be fully automated?
• Is the pattern deploying correctly in the tools?

Testing – Prevent problems before they happen.

Make sure the threat pattern has certain inherent qualities by verifying both its adequacy against the functional requirements and its contribution in addressing the original problem.

During this phase, it is common to realize that the feed of data collected or received by the SOC is not as clean as it should be – this could result in a negative impact if not accounted for correctly. Threat patterns have to be tested extensively like any new piece of software: there must be ideally a 100 percent code coverage before moving it into production, to avoid unexpected results.

Some questions to consider on this phase are:

• Is there an adequate number of test use cases to extensively prove the implementation?
• Is the pattern matching (triggering) when it should?
• Is the output the one we were expecting?
• What is the false positive/negative rate?

Evolution. Citing a fascinating scientific article “No, humans have not stopped evolving”.

A threat pattern working today may become obsolete in a short while. The TTPs change and the surrounding scenario will change, as well. This is why it is key to periodically review each pattern, define clear triggers for starting this process (targeted to a broad spectrum), still ensuring the original logic is preserved. It is now time to ask yourself the following questions:

• Is a new threat pattern required or can we enhance an existing one?
• Is the need to alter a pattern documented correctly?
• Is the change correctly covering the evolved scenario?
• How would we measure the updated residual risk?

This might seem like a lot of work, but it’s worth it!  The competition and threat actors have a lot of advantages already and they need to find just one exposed weakness to conquer the kingdom. And, we are constantly combating inadequate budgets, skill shortages, and limited personnel. This is why only by adopting a structured and focused approach, we can effectively protect the business of our organization, by leveraging the best resources we have available.

The post The Life Cycle of a Threat Pattern appeared first on Speaking of Security - The RSA Blog.