Threat Modeling Software Features vs Architecture
Threat Modeling Software Features vs Architecture
Architectural driven Threat Modeling
Microservices and agile methodologies push in the direction of delivering business functions fast and often. Agile projects are split into sprints, with each sprint focused on a limited number of “user stories”, which represent specific customer requirements. The first time an application is threat modeled, preferably in the design stage, a good approach is to start from the software architecture. This way we can focus primarily on technical threats. To support this process in a scalable way, IriusRisk offers a broad range of architectural components. They represent the building blocks of the subject system’s architecture. These could be a web service, a database or a file system etc. Threats to these components are grouped based on the technology stack underneath and the relevant configurations that could affect the key component's security properties.
Feature-driven Threat Modeling
As systems evolve with time, new user stories that require new software features will be included in the application’s backlog. A software feature could be defined as a functional capability provided by the application. In fact, there is an architectural model (Functional Architecture) that is focused entirely on trying to achieve a high-level representation of the application’s features from the use-case perspective.
As stated by NIST in their report: "The Common Misuse Scoring System (CMSS): Metrics for Software Feature Misuse Vulnerabilities", implicit and explicit trust assumptions are at the root of software feature misuse vulnerabilities:
"A software feature misuse vulnerability is a vulnerability in which the feature also provides an avenue to compromise the security of a system. Such vulnerabilities are present when the trust assumptions made when designing software features can be abused in ways that violate security. Misuse vulnerabilities allow attackers to use for malicious purposes the functionality that was intended to be beneficial."
Source: https://nvlpubs.nist.gov/nistpubs/ir/2012/NIST.IR.7864.pdf
Software misuse vulnerabilities are not entirely new. The origins of phone phreaking could be traced back to AT&T's implementation of fully automatic switches during the fifties. Joe Engressia, a blind seven-year-old boy, was one of the pioneers that exploited the trust assumption of the long-distance dialing systems in the in-band signaling tones. Engressia (who had perfect pitch) discovered that whistling the fourth E above middle C (a frequency of 2637.02 Hz) would stop a long-distance telephone call.
In many cases, software misuse vulnerabilities could arise from user stories that don’t even need to modify the architectural blueprint underneath. That’s why it’s interesting to articulate an easy way to derive relevant threats from the user stories, even if the architecture remains unchanged.
The security implications corresponding to the functional aspects of the applications are on the rise, particularly as technology adoption continues to evolve, and serverless applications have virtually no architecture to deal with from the application developer's perspective. With serverless functions, in theory you don't have to worry about the stack underneath the function. You can focus purely on the functionality. The same happens with low code and no code frameworks where you can abstract the architecture layer to focus your efforts on the business functions. The architecture becomes commoditized. However, the threats don't disappear, you are just transferring the risk for some group of the architectural threats to your cloud provider. That’s why sometimes it’s useful to find an alternative way to represent those changes in a threat model diagram.
New IriusRisk library of functional components
IriusRisk functional components could be defined as containers that group threats related to a specific function of a system or application. With the goal of improving the developer experience during the iterative threat modeling process, we've created a new developer-centric library with a catalog of native functional components in IriusRisk. One of the main goals with this approach is to give developers the ability to focus the threat discovery process on the functions related to the user story they have to implement.
Some characteristics for this new library of functional components are:
- 11 component definitions (Login, Change password, Reset password, User registration, Web form, User profile, File chooser, File handler, Formatter, Exception handler and Audit log).
- 20 risk patterns.
- 43 threats.
- 75 countermeasures.
Below is an example of what this looks like from the IriusRisk user’s perspective.
This is only the first iteration for this new library, setting a baseline for this new approach to functional components. We intend to extend this catalog of components and risk patterns to cover the most common functions in today's applications.
We would love your feedback on which application features you’d like to see in this catalog. Please, drop us a line at horizon@iriusrisk.com.
