Filter Out Threat Agents Who Have No Attack Surfaces Exposed to Their Typical Methods
Through the process of filling out Table 5.4, we have already filtered out a series of attacks that do not have an appropriate attack surface exposed to them. In fact, by attempting to apply attack methods to attack surfaces, we have even eliminated, or significantly reduced, a threat agent: security researchers. Security researchers’ stunt level hacks are unlikely since the attack surfaces required to execute these attacks are not exposed. To simplify the process in order to understand it, we didn’t list security researchers in any of the subsequent attack methods in Table 5.4. Nonetheless, security researchers can and will attempt all the other attack methods we have listed. Unless we do something very insecure on this website, stunt hacks on the website are not very likely to occur.
We will continue the filtering process in the next step.
List All Existing Security Controls for Each Attack Surface
The reason that the ATASM process encourages delaying the assessment of existing controls is to ferret out all of the attack surfaces. Discussions start to get bogged down in rating the sufficiency of existing controls. Because of this tendency, this particular approach to the threat modeling process urges us to wait until we have all the attack surfaces and all the attack methods catalogued before applying existing controls in order to prioritize. The essential problem is that we can never be 100% sure that we are sufficiently defended. Furthermore, we have to assume that some of our defenses may fail under sophisticated attack. It comes down to risk: There are no sureties. Risk decisions have to be made in order to account for limited resources to apply to the defense. Those discussions are best had at a later stage of analysis, once discovery has been completed.
In Table 5.4, the existing security controls are not shown. We have made a couple of assumptions for the sake of understanding the process. Namely, we’ve assumed that Web-Sock-A-Rama has a mature website management and administrative function. In previous chapters, we’ve listed what those functions typically are. This assumption provides the usual set of controls to the backend of our website. In the real world, I would never make that assumption without investigating first. An ARA has a due diligence responsibility to tie every loose end down, to dot every “i” and cross every “t.” The upside is that one usually only has to investigate an infrastructure once to understand its strengths and weaknesses. After that investigation, the infrastructure knowledge can be applied to each system that will be deployed to the infrastructure, instance after instance. The foregoing, of course, echoes and underlines the importance of preassessment knowledge, such as understanding the intended deployment infrastructure.
We do not know if some AppMaker applications or some Web-Sock-A-Rama pages require authentication. We don’t know if some transactions require authorization. We don’t know where the firewalls are, if any. We don’t know what actions are monitored, or even if there’s a security team who can monitor them (although a mature administrative function would imply security monitoring for attacks).
Because we don’t know what security controls exist, we could assume that there are none. If that were so, then we’d be ready to start writing security requirements. We would skip the next step in our process.
However, this chapter is devoted to learning the process. So, just for the sake of completing the process fully in every one of its steps, let’s assume that there is a single firewall between the public Internet and HTTP termination. Let’s also assume that there’s an authentication mechanism for certain operations, like changing a customer’s profile. Assume that each individual customer is authorized to change only her or his record and none others. Let us assume, as well, that there are no other controls existing.