There is a lot to know, and that will require a breadth and depth of knowledge and experiences. This requires training (such as reading this or other primers on threat modeling) and a healthy dose of pessimism and critical thinking when it comes to what is and what could be (and how things could go wrong). It takes rare and highly specialized talent-to do threat modeling well, you need to tease out the weaknesses in a system. Let’s face it-threat modeling the traditional way is hard, for many reasons: You may be wondering-how will threat modeling automation make your life easier, and not one more tool/process/responsibility to care about in the long run? We wondered the same, too.
#SDL THREAT MODELING TOOL FOR MAC CODE#
When it comes to creating the state of the art in threat modeling techniques, performing threat analysis and defect elicitation, you can use automation techniques dubbed threat modeling with code and threat modeling from code. In this chapter, we explore an evolution in the making. For example, if you’re not sure whether data flow A between endpoints X and Y leaves your critical data exposed to the mythical Eve, 1 you can use a program to figure that out. While the human element is arguably an important part of a threat modeling activity, construction and analysis of system models is something a computer can accomplish with ease you, of course, must supply the input.Īutomation not only helps you to design the model, but also can assist with answering questions. One way you can facilitate good security engineering is to limit the need to build system and threat models by hand and turn to automation to help reduce the burden on you, to meet the needs of the business and the security team. Do you try to influence your organization to bite the bullet and be more rigorous in applying security engineering practices, or do you try to get as much done as possible with your shrinking resources, knowing that the quality of your results (and, by extension, the security of the end product) may suffer? How do you maintain high security standards and the attention to detail that is necessary to create a well-engineered system? That leaves people who focus on security in a difficult position.
Therefore, security practices that were accepted as necessary evils because they consumed more than a few minutes of developer time are being abandoned as too costly (perceived or otherwise). However, in this age of continuous everything, and everything as code, a lot of pressure is placed on development teams to deliver more in less time. These techniques and methodologies are an effective approach to both system and threat modeling, if you have the time and energy, and can convince your organization that this approach is important. You also saw methodologies that look deeper in the threat “stack” to analyze the underlying causes that lead to threats (and adversarial targets)-weaknesses and vulnerabilities, which alone or in combination result in disaster for your system’s functionality and data (as well as your reputation and brand). You learned of methods that find high-level threats, with a consideration for the adversaries who have the capability and intent to carry out an attack.
In Chapter 3, you got an overview of threat modeling approaches that consume the system models you create, allowing you to identify areas of security concern within your system under evaluation. You also saw the information you need to gather when constructing those models. In Chapter 1 you got an in-depth look into the mechanics of building different types of system models “by hand,” by drawing on a whiteboard or using an application like Microsoft’s Visio or draw.io. There didn’t seem to be any computer-driven process that couldn’t be improved upon by humans crawling around on the actual structure and writing on it with grease pencils.
0 kommentar(er)
