Threat Modeling for Managed Attribution: Part 1
Threat modeling is a core discipline for ensuring the security of anything. Whether it’s a website or a military base, you need to be aware of your threat landscape in order to effectively prevent and respond to attacks. Unfortunately, a managed attribution (MA) system is vulnerable to a number of threats that are not part of standard threat modeling methodologies.
Listen to the Ntrepid Cast podcast on this topic.
For example, being identified is normally a positive thing from a security perspective. To secure your perimeters, you need to be able to identify users, visitors, and outsiders. In a misattributed operation, however, being identified is a worst-case mission failure and should be avoided at all costs.
To successfully combat such a vastly different set of threats, a new framework needs to be applied. Our team of experts and I have developed a new methodology for understanding and addressing the threats specific to managed attribution solutions.
For information security threat modeling, STRIDE is common framework to categorize threats:
- Spoofing
- Tampering
- Repudiation
- Information Disclosure
- Denial of Service
- Elevation of Privilege
Like any other information technology, managed attribution systems need to mitigate against these threats.
Following the example of the STRIDE categories, I’ve come up with a framework that addresses threats that are specific to managed attribution: CAKED.
- Correlation of entities: Can the attacker connect two accounts, servers, identities, etc. that are not meant to be seen as connected?
- Attribution of actors: Can an outsider identify who is behind the activity? This could reveal the operator, their organization, or the MA provider.
- Knowledge of operation: Can the adversary recognize that the activity is part of an operation and possibly understand the nature or purpose of the operation?
- Exposure of aliases: Can someone discover that an alias account is not a real person?
- Discovery of resources: Are there any loose threads that could help identify other previously unknown attribution management infrastructure?
Now that we have identified the different kinds of threats that exist for an MA solution, it is important to also assess and determine the various threat actors that could be involved:
- The unprivileged observer: individuals that only have access to publicly available information (PAI) including information obtainable through network scans
- On the wire: actors that are able to intercept traffic like internet service providers (ISP) and government entities
- On the device: entities that are actually in control of one of the communicating servers. These include social media platforms and companies that are operating and hosting the server
- In the conversation: the known or unknown parties in an exchange that have access to cleartext and meta-data
In many cases, people focus too much on the technical internet aspects of MA and ignore all the non-technical identifiers that can expose them. To help ensure that the important parts of the system are not overlooked in the threat model, I think of solutions being built across five different, but often interwoven, domains: internet communications, phone / SMS communications, financial transactions, physical infrastructure, and virtual infrastructure.
When threat modeling a managed attribution solution, you should start with a diagram that shows how the system operates in all applicable domains to ensure that all vulnerable paths and elements are included.
For each element of the diagram, consider which of the threat actors apply. Then, examine each element and consider how it could be vulnerable to any of the CAKED threats from those threat actors. This will produce a matrix of possible vulnerabilities that need to be individually addressed in the threat model by either an existing mitigation, a plan for mitigating against it, or an explicit acceptance of the risk.
Threat modeling brings structure and discipline to the analysis of managed attribution solutions. It can clarify which potential threat actors are significant threats, and can help focus the budget and effort on mitigations that will provide the maximum benefit. It can point out weaknesses in the architecture and create a clear communication and documentation about what is protected and what threats have been accepted.
Curious about how this framework can be implemented? Watch for the next installments of this series where I demonstrate the methodology by working through two example scenarios.