nobeastsofierce - Fotolia
Cloud applications are inherently distributed, offering multiple vulnerable surfaces for attackers and hackers trying to steal data or disrupt services. Attackers can use application interfaces to gain access to data or other system resources. Optimizing security is a multi-faceted challenge. No single tool, technique or practice will mitigate all risks, but a combination of approaches, including security threat modeling, will help lower those risks.
Threat modeling is a methodical way to assess potentially vulnerable points -- spoofing, data leaks and tampering -- in your application. The threat-modeling process evaluates an application from the perspective of an attacker trying to gain access to the system. This is different from code reviews and other techniques that take a defensive approach to assessing vulnerabilities.
As part of your security threat-modeling assessment you may want to run vulnerability scanners against your application. If attackers use those tools to search for vulnerabilities, it is reasonable to run them yourself before releasing code into production. And while Amazon Web Services (AWS) allows customers to perform vulnerability scans, they must follow specific company guidelines when doing so.
Threat modeling depends on application developers and owners, as the cloud's shared security model segregates some security responsibilities. While it is clear that AWS and other infrastructure as a service providers are responsible for physically protecting their data centers, developers need to be vigilant in assessing the security risks of their applications. Threat modeling complements other software development lifecycle processes; it should not replace code reviews and static analysis.
Three-pronged approach to security threat modeling
There are three necessary assessments in the threat-modeling process: the functional modules of your application, the data stored within your application or its database and the interface points an attacker may use to gain access. Experienced application developers are often familiar with use-case modeling, in which analysts develop scenarios describing how a user interacts with a system. Threat modeling examines use cases, but with an interest in exploiting the application interface. The output of the first phase is a set of data flow diagrams that show how processes progress through a system and how privilege levels change in different stages.
Threat categorization is the main goal of the second stage. Using lists of common threats, such as those in the Secure Application Web Framework, analysts can rank the relative risk posed by each threat. For example, a database front-end application may be especially vulnerable to SQL injection attacks, while Web sessions may be compromised if sufficiently random session IDs are not used. Potential threats can be compared and ranked based on likelihood and severity of adverse impact.
A business that highly values customer data might place high priority on mitigating the risk of SQL injection attacks against Web interfaces to its database. It is not unreasonable for businesses to assume attackers will use automated tools to scan for Web applications and then scan those targets with other vulnerability scanners. These tools increase the likelihood of being targeted, as attackers are not limited to manual searches for targets. The combination of a high-value target and high likelihood of attack would make for a top-priority risk.
The last phase of threat modeling focuses on devising countermeasures to mitigate the risks identified in the second stage. Countermeasures include techniques such as verifying code accounts for injection attacks by using parameterized queries. Companies can further protect themselves by using programming libraries that account for arithmetic overflows and provide suitable error trapping.
The Open Web Application Security Project has published some useful information on the basics of threat modeling. The document includes a well-structured description of different types of threats, including injection attacks, input validation threats, session management weaknesses and configuration vulnerabilities. For more in-depth guidance, Threat Modeling: Designing for Security covers strategies for threat modeling, understanding attack trees, defensive tactics and validating that threats have been addressed.
Implementing AWS security best practices
Test your AWS cloud application security
Implementing security operations management in AWS