TTP Intelligence & Risk Reduction

The TTP intelligence blog launched with a review of key sources that add value to TTP (“tactics, techniques, & procedures”) intelligence analysis. Next, we discussed how a framework like ATT&CK enables security teams to align controls with real-world adversary threats, unlocking the potential for control validation at scale. Recently we covered in more detail how TTP intelligence informs prioritization in the security validation process, improving time and resource allocation.

The series introduction closes today with an exploration of the intersection among TTP intelligence, control validation, and risk reduction. The next entry launches the blog’s regular format - analysis and defensive guidance on a trending TTP - with an exciting change!

Compliance- and Threat-Focused Security Programs

How do organizations conceptualize, build, and improve their security functions?

Some organizations - especially in heavily regulated industries - model security functions around compliance frameworks, such as NIST 800-53 or the Cybersecurity Framework, HIPAA (healthcare), or PCI DSS (payment processors). Even if they aren’t tightly regulated, organizations may choose to model their programs around compliance frameworks due to the structure these frameworks provide. For example, the CIS Controls list three “Implementation Groups”, which guide progressive security policy and control deployment. This format provides an excellent starting point for organizations building a security function for the first time, which may have limited security expertise.

However, the structure built into most compliance frameworks makes it easy to fall for one of their main limitations (when using them for risk management purposes). Many organizations seek to “check off” more and more framework line items, in order to graduate to a new maturity threshold defined by the framework. They even reach a point where checking these boxes becomes a security end-goal in itself.

Organizations with a check-the-box mentality expose themselves to very real gaps between perceived and real security. For example, an organization may deploy a specific security technology, such as a firewall to defend against external unauthorized access, in order to comply with a framework; however, a misconfiguration may be enough to render the tool ineffective. The organization still meets the compliance requirement, but a security gap exists, exposing it to real threats.

Alternatively, some security functions focus overwhelmingly on tracking myriad threats. (Note: it’s great to see growing awareness of adversary threats within the security space, and a threat-tracking capability may seem like a luxury for less-resourced teams.) However, security programs overly-focused on threats suffer from mis-allocation of resources. Only a portion of all threats apply to a given organization at a given time (certain techniques only affect certain technologies; meanwhile some actor groups are only motivated to attack certain targets). Time and resources allocated to analyzing, reporting on, and mitigating irrelevant threats are, put simply, wasted.

Adversary Tool & TTP Development

Tracking all threats all the time - especially for a mid- or less-resourced organization - is an unwinnable game (just one data point is the recent news that Google tracks 270 state-sponsored threat actor groups - let’s not even get started here on the potential volume of discrete cyber crime adversaries...). Besides the sheer volume of adversaries that exist, we’re also challenged by the speed and pace of contemporary adversary tool and TTP development.

In large part due to the hardening of our defenses, adversaries consistently revise their methods for attacking companies, government agencies, organizations, and individuals. In direct response to the constant evolution of adversary techniques, Recorded Future has a dedicated team within its research group dedicated to identifying, tracking, analyzing, and reporting on new and emerging tools and TTPs. Importantly, when new threats emerge, our team uses a structured methodology (visualized below) that involves routinely crafting hunting packages and signatures aligned with those threats, then scanning the entire routable Internet space for indications of those threats. Many of the new tools and technique implementations that we observe, including offensive security tools, are shared (or offered for sale) on the surface or underground web, and we consistently see adversaries adopt these methods to carry out real attacks, often in extremely quick fashion.

This is another key area where compliance frameworks are limited, including something as valuable as ATT&CK which we’ve discussed here significantly before. Frameworks are only updated periodically (ATT&CK undergoes two main revisions per year and sees adhoc updates in the interim). Given the extreme pace of contemporary adversary tool and TTP development and adoption, if we base our security posture only around the boxes listed currently in a given framework, gaps in protection against the latest adversary attack methods will certainly exist.

Risk-Driven Programs

Risk-driven security functions blend the control-strengthening aspects of compliance frameworks with the real-world focus of threat-driven programs. Security programs that focus on risk (defined simply by event likelihood multiplied by the potential loss resulting from that event) are best positioned to measurably improve their organization’s security posture.

My colleague Levi Gundert’s book on risk outlines the importance of security teams focusing on risk far more eloquently than I can, and it provides pragmatic steps for shifting to a risk-based security approach. A key takeaway is the notion that security intelligence functions should focus on the categorization of relevant threats, and then continually work to identify relevant threat deltas (“RTDs”) - changes in the external threat landscape, as well as internal changes in technology, controls, or processes that create potential gaps in the coverage of security controls previously in place.

How are RTDs identified? One element relies on inventory and understanding of the internal technology, control, and process environment, while the other is the identification of threats. The key here is alignment of the two - analysis of whether the identified threat has a material impact on the existing technology and control environment. For example, if a newly observed technique only affects operating systems or versions that are not in place within the organization, the analyst can and should move on (as we know, there is never a shortage of other threats to analyze!).?

Another key factor in determining threat relevance is the control environment. Our last post outlined the key steps and emphasized the importance of iterative security control validation for measurably improving security within an organization. Security teams should have an understanding of what controls they have in place, but critically, knowledge of whether those controls are functioning as expected. If a newly identified threat involves techniques for which the organization has strong (and validated!) controls, it too can and should be discarded in favor of more valuable work. (Hint #1: many of the tools and techniques on which our team reports specifically involve net-new techniques or implementations of techniques, so controls for these TTPs should be validated, or newly put in place. A look at TTPs generally trending in the threat space may also be helpful and is one of the purposes of this blog!)

Ultimately, RTD analysis informs the inputs to the underlying quantitative risk model (hint #2: see Levi’s book for details on how to implement a pragmatic risk framework based on threat categories). In reality, the increasing pace of some iterative control validation programs (especially those enabled by technology solutions) can allow these programs to largely stand-in until a fuller risk management program is developed.

While the term may be unfamiliar, identification and analysis of RTDs represents the foundation of an intelligence function for a truly risk-driven security program, and in comparison, other tasks such as daily summaries of previously-reported threats begin to seem much lower priority. Daily (or similar high-cadence) threat reporting is a common characteristic of threat-driven programs, but as highlighted above, summaries of myriad threats already reported in sources like news articles - purely for awareness sake - will not be an effective allocation of valuable resources (such as a smart and trained analyst).

Analysis of new threats - in the context of the internal technology and control environment - is neither quick nor necessarily easy, typically lending itself toward reporting-out on a weekly or even monthly or quarterly cadence. But it is required to actually drive a security program on the basis of risk. Access-permitting, it is often possible for security analysts to begin at least quick or preliminary investigations into their organization’s control environment, in order to line up and analyze whether a given threat actually poses a risk to their organization. In closing the introduction to the TTP intelligence series, I encourage teams - even if they don’t roll up to a formal risk program - to consider adopting this “first-person” approach to their routine intelligence analysis and reporting (is a given threat actually relevant to my organization, and can we validate that we are protected) - it’s very much possible to begin driving a risk-focused security approach from the bottom-up!

#TTP #intelligence #RecordedFuture #risk #MITRE #attack #security #ttps #infosec #cyber #cybersecurity #framework #compliance #NIST