devopsy.kinsta.cloud

Tag: threat modeling

  • Threat Modeling: The Why, How, When and Which Tools

    Threat Modeling: The Why, How, When and Which Tools

    You may have heard of threat modeling as a structured activity for identifying and managing threats. Threat modeling can be applied to a wide range of things, including software, applications, systems, networks, IOTs and business processes.

    Threat modeling’s motto should be, “The earlier the better, but not too late and never ignore.” Without threat modeling, your security is a gamble—and in today’s business environment,  you’re sure to lose.

    When you design an application, you will face several security issues during different phases of the software development life cycle (SDLC), and so having threat modeling in the SDLC from the beginning can help to safeguard that applications are being developed, with security built in.

    Simply put, threat modeling is a procedure to identify threats and vulnerabilities in the earliest stage of the development life cycle to identify gaps and mitigate risk, which guarantees that a secure application is being built, saving both revenue and time.

    Why Threat Modeling?

    • It is better to find security flaws when there is time to fix them.
    • It can save time, revenue and the reputation of your company.
    • To build a secure application.
    • To bridge the gap between developers and security.
    • It provides a document of all the identified threats and rated threats.
    • It offers knowledge and awareness of the latest risks and vulnerabilities.

    How To Do Threat Modeling

    Many people think only security engineers can do threat modeling. That’s not true. Anyone, from developer to software project manager, can threat-model. In fact, I would suggest they should also know a little bit of threat modeling as part of their work.

    Let’s look at the elements of threat modeling:

    Assets: What valuable data and equipment should be secured?

    Threats: What the attacker can do to the system?

    Vulnerabilities: What are the flaws in the system that can allow an attacker to realize a threat?

    Steps to Threat Modeling

    Step 1: Identify the assets (database server, file servers, data lake stores, Active Directory, REST calls, configuration screens, Azure portal, authenticated and anonymous web user, Azure AAD client apps, database users, DB administrators)

    Step 2: Outline details of architecture on which the valuable asset is being processed. It may include the software framework, version and other architectural details (ASP.net web application connection to cloud data stores and third-party services using JWT tokens).

    Step 3: Break down the application regarding its process, including all the sub-processes that are running the application. We create a data flow diagram (DFD).

    Step 4: List identify threats in a descriptive way to review to process further.

    Step 5: Classify the threats with parallel instances so that threats can be identified in the application in a structured and repeatable manner.

    Step 6: Rate the severity of the threat.

    Threat Modelling Methodologies

    STRIDE (Uses application-centric approach)

    PASTA (risk-centric approach): Process for Attack Simulation and Threat Analysis

    TRIKE (risk-based approach with unique implementation and risk-modeling process)

    VAST (Visual, Agile and Simple Threat modelling)

    OCTAVE (focused on assessing organizational (non-technical) risks that may result from breached information assets.)

    When to use Threat Modeling

    In simple words, at the early stages of the SDLC, perform threat modeling:

    • Every time there is a change in the system’s architecture.
    • After a security incident has occurred or new vulnerabilities are introduced.
    • As soon as the architecture is ready.

    It is not a mandate to perform threat modeling at the early stages of the SDLC; you can still pick up threat modeling at any stages even if it is close to deployment.

    Threat models are continuously changing, and the models you prepared today may not be efficient tomorrow. And it is difficult to say that you are covered from all the threats. But if you have performed threat modeling and done whatever it takes to minimize your exposure to security risks, at least the impact of something very bad happening will be manageable (again, hopefully, but not a guarantee).

    Tools to Perform Threat Modeling

    I have used two tools for threat modeling, both of which are free to use.

    1. OWASP Threat Dragon
    2. Microsoft Threat Modelling Tool 2016.

    Let’s take a look at both the tools:

     

    Microsoft Threat Modelling Tool 2016         OWASP Threat Dragon

     
    Full version available for free (as of now) Alpha version available, flaws are still there. It is an OWASP incubator project, so it is at its early stage.
    Installable desktop application available. The tool comes in two variants: an online web application for GitHub and second an installable desktop application.
    Documentation easily available on Microsoft website. Default threat template is available. You have to search, default threat template is present
    I found the UX better, unique methodology available, the user can understand threats better. Guidance and feedback in drawing a model. Good UX. Fun and engaging user experience.
    Presently using this tool for threat modelling. Maybe I will use. I think will continue to improve.
    End-user documentation is available. End-user documentation is also available. Automated threats.
    Threat Grid, Template editor, Mitigating existing DFDs. Mitigating existing DFDs. Powerful threat mitigation. Rules have not yet been coded as it is the Alpha stage.
    Comes with a base set of threat definitions using STRIDE categories. Even in its current stage (alpha), you can create threats from those STRIDE categories.

     

    — Debarghya Pandit

  • Q&A: Speaking DevOps and Threat Modeling with the author of Threat Modeling: Designing for Security

    Q&A: Speaking DevOps and Threat Modeling with the author of Threat Modeling: Designing for Security

    If you want to understand how to threat model systems and applications in most any environment you turn to someone who has done so. That’s why we took 30 minutes to speak with Adam Shostack. Adam is responsible for security development lifecycle threat modeling at Microsoft and he is one of the very few threat modeling experts in the world. We thought, with more and more organizations moving toward DevOps and Continuous Deployment, would be a great time to discuss how this impacts the design of secure software. Earlier this year Adam published his book, Threat Modeling: Designing for Security, available here. The book provides pragmatic and actionable advice on how to make security an integral part of systems, software, or services from the outset.

    This advice applies to systems and development teams both big and small and is especially crucial as application deployment times accelerate.

    devopsy.kinsta.cloud:Why threat modeling? What benefits does it provide the business as well as the application development and operations teams?

    Adam Shostack: For the business, executives, they don’t want to deal with individual problems as they arise, they want to address problems as a category. They want to manage a class of things that can be completed in a consistent, repeatable, or predictable way. When it comes to managing application risks, threat modeling gives you an opportunity to answer questions as to whether you are dealing with certain vulnerabilities across all of the applications – rather than coming at them as one-offs. It’s a way to model and abstract away many of the details and look at things in a more strategic fashion.

    The other value threat modeling provides is the degree of predictability as you’re developing things – instead of forging ahead and building things and then running a pen test at the end only to learn then that you have serious security problems. What ends up happening in that scenario is that once you fix those problems, you then run another pen test and learn of even more or new security problems and you end up in that very unproductive cycle for a very long time.

    So threat modeling helps you think about your security before you start building. This way you can bake security into what you’re doing. My book helps to make both of those value propositions concrete and approachable. You can take these lessons in the book, give them to people and say go do these things and you really get an increased degree of control and predictability through what you’re designing through what you’re delivering.

    Also, when you threat model, you get a picture of where things are likely to go wrong. A lot of the threat modeling practice can be very process heavy. That’s why there’s a lot of very process heavy documentation out there. But actually threat modeling integrates well inside a test driven design approach to software development. Why? Because threat modeling tells you where you need to concentrate your security testing. If you’re looking for bug classes, don’t look at random sets of things or relatively random sets of things and you won’t get nearly as much test coverage.

    devopsy.kinsta.cloud: So, they can operationalize secure development into the processes, which is what security advocates have often spoke of as the optimal state of security’s relationship with application development and operations – rather than be a barrier at the end of the development process.

    Adam Shostack: The whole barrier meme comes from the idea that you do security activity late. A lot of people come into security through hacking. You hear the hacking metaphors all of the time. They are memes like “you can’t secure something if you don’t know how to break it.” Now, knowing how to break things is great. It’s a fun skill. It’s an important skill set. But you notice when you ask about making it operational is that one of the things that security people love to say is you’re never done threat modeling. Now, if you go to a VP of development or a VP of Ops or a VP of DevOps and say, “I want you to do this thing and it’s never done, but it’ll fit into our four week sprints….” You will get a big “huh?” The conversation won’t go anywhere from there.

    In order to work it has to be complete-able. It has to be focused and it has to be prescriptive with checklists. It has to have exit criteria, and it has to have metrics that answer: “Are we doing this well?”

    devopsy.kinsta.cloud: That type of thinking strikes me as fitting well with the continuous improvement objectives of DevOps.

    Adam Shostack: Absolutely. I’ve been threat modeling in various ways for a good 20 years. When I joined Microsoft I encountered people in development and in operations who were passionate about security, who knew that they had to do security and they wanted to do it right. But they also wanted to focus in on reliability, on accessibility, on internationalization, on performance. They wanted to focus on all of these other things each of which is an important property of the system you’re developing. I had to learn to make threat modeling easy. I had to learn to focus in on the highest value deliverables and make sure that those deliverables were accessible and capable. This has to be so even when you didn’t have a security expert groomed because people don’t understand that their decision has a security implication. They’ll make a decision without a security person handy. If you make the security goals accessible and understandable, they’re more likely to understand that what they’re doing has a security implication and they’re more likely to do it well.

    Let me give you an example of this. One of the areas that most often goes wrong in the design of a system is people don’t draw their trust boundaries. They don’t know where different principles are going to interact with one another. And application accounts with different authorization levels interacting are a natural place for security problems to arise.

    So what you can do is draw these trust boundaries on a white board. It doesn’t have to be a fancy diagram. Scribble on a white board and say, this is where things happen in admin. This is where things happen in the database. This is where things happen as the web user, and this is where web sessions are authenticated and you put boundaries between each of them. Developers understand that these things that they’re writing are run at different privilege levels.

    They then say, okay, this code runs on the web user context, this code runs on the database context. That’s great because once you’re doing that you can see the places that your threats are going to arise and look for places to exploit. There are lot of elements in threat modeling that you can work toward incorporating, but the fundamentals are actually easy to teach, easy to learn, and they’re easy to apply.

    devopsy.kinsta.cloud:We started out by talking, from a high level, what threat modeling means to different constituencies in an organization. More concretely, what is the payback of threat modeling for developers? Is it more resilient applications, fewer problems that have to be dealt with after the fact, and generally improved outcomes?

    Adam Shostack: Those are great values. The biggest “what’s in it for me” for a developer is that threat modeling takes all of these details about security that they want to deal with and provides a model, an abstracted way to frame them. So, instead of constantly worrying “Gosh, I might have another security issue” you can get a sense for how much you’ve done to solve the risk, and how much of it might remain. You get a sense of where you want to prioritize that work.

    I think a big misconception is that people believe that only an expert can do threat modeling. One of my aspirations for this book is to show that threat modeling should be like version control. Every developer, every ops person should know a little bit of threat modeling. And it doesn’t have to be a security expert. Perhaps it’s the person who manages your source tree. Or, if you work in a small organization threat modeling will be a side job for someone and that’s okay too. The important thing is to make it a part of your work.