Threat modeling is a core activity and a fundamental practice in the process of building trusted technology; it has been identified as one of the best "return on investment" activities with respect to identifying and addressing design flaws before their implementation into code. It aims to identify the attacks a system must resist and the defenses that will bring the system to a desired defensive state.These attacks expose and exploit potential weaknesses that will affect the system being modeled in negative ways."System" in this context is defined very broadly to include any type of computer system, including small pieces of software functionality, discrete software applications, complex integrations involving multiple hosts, multiple applications and runtime execution environments, infrastructures and even distinct legal entities.
The express aim of threat modeling is to identify and eliminate design issues: to identify security weaknesses or arrive at a set of security needs that must be built. These are sometimes referred to as"requirements." We are using the term "requirements" in this document to mean "security issues that need to be addressed." In other words, "requirements" refers to any required item that must be implemented and does not necessarily refer to formally generated requirements.Once identified, the security requirements when implemented will bring a system or set of systems to the intended security posture. Identifying likely threats and the probable consequences of a successful attack are the method of investigation to identify an appropriate set of defenses. It is an industry best practice to validate the defenses that were derived from the threat model.While some threat-modeling methods focus on identifying threats and security issues, other methods also perform an assessment of the resulting risks by rating the consequences (impacts) and the likelihood of threats. Such methods are also called Threat and Risk Analysis or Assessment (see, for example, ISO27005 , nist SP 800-30 ). Such a rating can be used to prioritize defenses.
When to do Threat Modeling
Ideally, threat modeling is applied as soon as an architecture has been established. There is a timing element to threat modeling that we highly recommend understanding. No matter how late in the development process threat modeling is performed, it is always critical to understand weaknesses in a design's defenses. The cost of addressing issues will generally increase when we uncover design misses and missed security requirements later, or worse, at the end of the development process. It is much more useful to begin the process of identifying potential attacks and their treatments while identifying other system requirements.
A threat model should begin when the major structures, the major components or functions of architecture, are known. Before this point, much time might be wasted redoing work as structural changes. Beginning too long afterward might mean that significant structural changes or additional structures required for security will be uncovered only after the time-frames and resources allocated for development have been exhausted. Broad requirements and constraints help to define an architecture, and these Tactical Threat Modeling necessarily become more specific as things become better defined. Security must be among these and present from the start, becoming "built in" rather than "bolted on."Thus, threat modeling can be used as part of requirements engineering to derive security requirements, based on a first architecture overview, or threat modeling can be used as a design analysis technique, is applied to the software design before coding starts. Threat-modeling techniques might focus on one of these use cases.Though teams are encouraged to perform threat modeling early in their structural definition process, if that cannot be achieved, threat modeling is still a useful exercise regardless of how close the system is to deployment or how long the system has been in use. The next development cycles may be used to mitigate risks that a system currently carries. Even when changes to a system are not expected, organizational decision-makers may wish to understand any significant risks a system may add to the organization. Note that there is a distinction between the end of development and end of support, and even when active support has ceased, a proper threat model will bring clarity about the possible flaws in the system, which will inform a decision on further investment in the product.
For the complete paper CLICK HERE or https://www.safecode.org/wp-content/uploads/2017/05/SAFECode_TM_Whitepaper.pdf
As the guy that put this paper together I wanted to start a thread about what was missed in this paper - feedback appreciated in advance.