Information asymmetry is the root cause of every breach

Information asymmetry is the root cause of every breach. Your adversary knows something that you do not.

For instance, your adversary might discover:

• A remote management system exposed to the Internet that you haven’t adequately protected
• An account that uses weak, legacy authentication (e.g., an account lacking multi-factor authentication
• A software vulnerability that you don’t know about, or know about but haven’t mitigated through patching or otherwise

Of course, this aspect of asymmetry doesn’t just apply to weaknesses on the target side. Your adversary likely has some level of specialization that works to their advantage, and that you can’t effectively predict. This might include deep understanding of:

• One or more particular pieces of software
• The inner workings of underlying compute and/or infrastructure platforms
• The limitations of security controls or mitigations

Apex adversaries often have a deep bench, able to tap individuals or teams with specialization in myriad technical, operational, and other disciplines. You should assume that these adversaries either check every box on the lists above, or have the resources to do so.

Information asymmetry applies to intrusion operations, too.

Your adversary has the benefit of initiative. In addition to knowing technical, operational, and other aspects of intrusion operations, they are able to:

• Plan and coordinate amongst themselves and their partners
• Be as patient as needed
• Balance things like the urgency of their operations against their risk tolerance (where risks are things like outright failure, attribution, and more)

So what’s the good news? If you can identify points of asymmetry, you can counter them.

We love to tell people to “think like an adversary”. Thinking like an adversary isn’t really a thing. It’s a few things, coupled with intent. But most of what adversaries are doing is looking for points of asymmetry and exploiting them.

Look at the lists above, and then consider how you might approach the same points of asymmetry, but to a different end. Selected examples:

• Double down on understanding your attack surface, particular the subset that is most exposed
• Provide strong identity protection, at virtually any acceptable cost
• Patch your software, focusing first on vulnerabilities that have been actively exploited (don’t forget that your security controls are attack surface, too!)

Identify areas where asymmetry exists, and do a little work to try to learn the things that an adversary would seek to learn.

Get there first.

The top initial access vectors in 2022, mapped to ATT&CK

This data is from 2022. For data from 2023 (the most recent), please go HERE.

In reviewing security firms’ 2022 threat data, a subset of these include insight into the initial access vectors leveraged most frequently in successful intrusions. This is a summarization of findings based on their reporting.

Methodology

To determine the most prevalent initial access techniques leveraged by adversaries in 2022, I relied on data from the following reports:

• eSentire 2023 Ransomware Report: Disrupting Initial Access
• HP Wolf Security Threat Insights Report Q4 2022
• IBM Security X-Force Threat Intelligence Index 2023
• Kaspersky Nature of Cyberincidents 2022
• Kroll Q4 2022 Threat Landscape
• Mandiant M-Trends 2023
• NCC Group Annual Threat Monitor 2022
• Secureworks Learning from Incident Response: 2022 Year in Review Report

Because not all of these reports use a standard taxonomy, reported vectors were mapped to the corresponding MITRE ATT&CK Initial Access parent technique.

As with all threat reports, the findings and prevalence are subject to each firms’ visibility and methodology.

How to use this information

From my earlier thoughts on this matter:

A good use case for these types of lists–and a way to make them actionable–is to look at tactics starting with initial access and progressing through the intrusion lifecycle. For each tactic, look for common vectors and MITRE ATT&CK techniques (some of this is readily available in the source reports below). The goal is to see whether we can glean good enough insights and do it quickly, assess risks, and take preventative measures.

A company with a formal org chart is a company big enough to have an informal org chart that accurately describes how things actually get done. Permalink

From Byrne Hobart at The Diff, a list of scaling bottlenecks often encountered by startups: Recruiting, decision-making, management, and more.

[O]ne of the biggest scaling bottlenecks ends up being the related problems of asymmetric information and decision fatigue. In a small company with a flat corporate hierarchy, information travels fast. If people are working long hours in close proximity, it’s almost impossible for anything to stay secret. And if everyone’s either a founder or a direct report of one, there isn’t much room for politics. A company with a formal org chart is a company big enough to have an informal org chart that accurately describes how things actually get done. Whether this is described as “politics” or as “effective” partly depends on people’s relative positions in both. And that adds an inescapable tax to growth: more people means more conflicting interests, and more cases where the right choice for the company as a whole conflicts with the right choice for individuals.

On delegation in particular, very much a limiting factor for learning and growth:

Effective delegation can be best defined in negative terms: a manager is not delegating unless their subordinates at least occasionally make exactly the opposite decision from the one their manager would have made.

If you wait until you feel like doing stuff, you’re fucked. Permalink

If there’s an article-length version of Atomic Habits, published years prior to the best-selling book, this might be it.

Motivation is like manually winding up a crank to deliver a burst of force. At best, it stores and converts energy to a particular purpose. There are situations where it is the correct attitude, one-offs where getting psyched and spring-loading a metric fuckton of mental energy upfront is the best course of action. Olympic races and prison breaks come to mind. But it is a horrible basis for regular day-to-day functioning, and anything like consistent long-term results.

By contrast, discipline is like an engine that, once kickstarted, actually supplies energy to the system.

Productivity has no requisite mental states. For consistent, long-term results, discipline trumps motivation, runs circles around it, bangs its mom and eats its lunch.

In summary, motivation is trying to feel like doing stuff. Discipline is doing it even if you don’t feel like it.

Observability as a function of your threat model

This model attempts to explain the relationship between visibility, observability, detection, and mitigation, which are closely related and important to understand when implementing any information security or cybersecurity program.

Of course, having a model is not the same as having an implementation or an operational capability. And in implementing any program based on a model, it’s very easy to fall into the trap of using the model as a bingo card, treating each component equally and in doing so expending resources in a way that is inefficient or ineffective.

In considering how to approach these four components, it might help to bucket them based on:

• Their primary inputs or drivers
• Any limiting factors that they have in common

Visibility is a function of your attack surface. Some key inputs here include facilities, networks, infrastructure, and service providers. For each of these, you’re wise to invest in as much visibility as you can. Keep in mind that visibility is knowing that an asset exists, but not necessarily knowing everything about it, how it’s used, or actively monitoring it. You can get a lot of mileage out of good accounting related to identities, devices, applications, etc.

Observability, detection, and mitigation are functions of your use cases. Use cases will include things like the needs of your operational teams, including technical and security operations. They may need more or less of these things in order to maintain systems, detect threats, investigate incidents, and generally mitigate threats or other types of problems.

Observability is the most interesting of the three, because there is so much debate (and marketing) surrounding the types and levels of observability that you need. Of course, a vendor that makes money when you feed it log, security, or other event data–or one who sells you products that produce those signals–is going to make a case that you need as much observability as you can afford. From a security standpoint, I would argue that observability should be driven largely by your threat model, and your understanding of where you need to be in order to observe, detect, and respond effectively to threats.

An implementation of this approach might look something like this:

You can go wild with this implementation, but you can also keep it relatively simple and get great results. The guiding principles are that you want to ensure the broadest possible visibility, so that you understand your attack surface and the assets that are at risk, and you want to implement the right level of observability to meet adversaries where they operate, which is where you need to be in order to detect, respond, and mitigate related threats.