CAKED: Threat Modeling for Managed Attribution Part 3

In part 2, I demonstrated how to threat model a simple OSINT scenario. For the final part of this series, I’d like to examine a fictional scenario of active engagement with an overseas illegal marketplace that is operated by the target.  

Let’s start off with a quick recap. The threats against managed attribution (MA) are memorable through the acronym CAKED. 

• Correlation of entities 
• Attribution of actors 
• Knowledge of operation 
• Exposure of aliases 
• Discovery of resources 

And we are considering four kinds of threat actors:  

• Unprivileged observers 
• On the wire 
• On the device 
• In the conversation 

In this example, the operator’s mission is to actively engage with a criminal marketplace. This scenario highlights international complexities; the target webserver is running in Mexico, and there are likely to be threat actors in some of the foreign ISPs.  

The operator in this scenario is significantly more vulnerable than in the OSINT scenario from part 2. The target has much greater access to information about the operator. As the hosting webserver, they can see all technical details of the connection and run various tests against the operator’s browser and system to detect unusual signatures.  

A viable managed attribution solution needs to prevent the target, or other sympathetic entities, from discovering the existence of the operations, exposing the alias, or attributing anything back to the operator. In this example, there is only a single alias, but if there were more, we would also need to consider preventing correlation of those aliases or any associated infrastructure. 

How to Visualize CAKED for Managed Attribution

Pictured below is a possible solution architecture for this example. There are multiple layers of standoff between the operator, the MA service provider, and the target. In cross-border contexts, the regional IPSs and governments are often a bigger concern as threat actors.  

This operation also involves direct financial transactions that also need to be protected. The image below illustrates that path. The solution is built using conventional transfers between banks. If the operator were to use bitcoin, it would introduce a new threat exploitable by unprivileged observers.  

Let’s examine four threat actors with different views of the solutions.  

You can see in the image below that the target website is clearly in the conversation with access to clear text of all communications and meta-data. To avoid exposing the alias and mission, the MA service must ensure that all technical cover support looks realistic and appropriate in the face of sophisticated analysis. I have discussed most of those issues in another cast.  

With this design, the alias will appear to be in Brazil using an Argentinian bank for payments. They will have the ability to scan the Brazil exit point, enabling the discovery of other MA resources.  

A threat actor with access to the Argentinian banking information would see a Brazilian customer taking funds from a Swiss Bank and using them for transactions with the criminal website. If this pattern is appropriate for the typical visitors to that website, it would not expose the existence of an operation or provide any attribution.  

A threat actor on the Brazilian exit server, perhaps a hacker or the hosting company, might be able to infer the existence of the operation by seeing the traffic relaying between Paris and the target. They are also being paid by a Swiss bank, and the exit node is communicating with an Argentinian bank. Careful hardening and monitoring of the exit server can minimize the chances of a successful hack, while thoughtful selection of a trustworthy hosting provider can reduce the chances of hostile intent and monitoring. The threat actor also has very detailed information about the design of the exit node, which might allow discovery of other MA resources on the internet. To mitigate this, you should vary the identifying characteristics between all nodes (perhaps by following the CAKED model).  

A threat actor inside the trusted American bank would be able to see that the operator’s organization is engaged in an operation using an MA service. They do not have visibility into what kind of operation it could be, the target, or any of the aliases used. If this knowledge would be problematic, then additional mitigation through a trusted financial intermediary could provide protection. 

Again, the process is to iterate this procedure. You need to examine each element and vantage point to look for what threats are possible and decide to take precaution or accept the threat; any new mitigations need to be examined for new vulnerabilities. 

For a more detailed look at this model and the acronym CAKED, watch the full video.