1. 程式人生 > >DevSecOps, Threat Modelling and You: Get started using the STRIDE method

DevSecOps, Threat Modelling and You: Get started using the STRIDE method

DevSecOps, Threat Modelling and You: Get started using the STRIDE method

Nowadays more and more DevOps teams are starting to shift towards DevSecOps. The security aspect in Software Engineering is now crucial and fundamental taken into account the world we live in. No longer we can simply rely on Infosec departments to get involved in a later phase and help to improve the system security. It needs to be considered from the get-go by the same people creating and developing the system as a basic element (similar to the infrastructure, CI/CD, etc).

In this context, Threat Modelling sessions are becoming more and more popular among Engineering teams. In DevSecOps, it is one of the cornerstones and must-have regular practices that any team needs to establish.

While there are many different ways to do Threat Modelling, STRIDE is by far my favourite method to use in these sessions. I find it very complete and yet really easy to iterate with groups of different sizes. In fact, you can even use it by yourself when designing a new system to guide and validate your own thinking.

In short, STRIDE is an acronym for the following terms:

STRIDE acronym

What does this mean?

Spoofing — pretend to be something or someone you are not
Tampering — manipulate/change information you are not suppose to (i.e., data integrity)
Repudiation — ability to claim you didn’t do certain actions (no matter if you did or not )
Information Disclosure — leak/expose information
Denial of Service — prevent the system to provide a service
Elevation of Privilege — gain rights to do things that you are not suppose to

How does it work in practice?

Start with an architecture diagram or sequence/flow diagrams of the system that you want to threat model. It is crucial that you keep your focus and define the scope. Quite easily you might get tempted or just carried away and start drifting from the original scope and boundaries you initially defined — Don’t! Be strict!

Once you (and the rest of the participants) have a shared understanding of the system (via the diagrams), start iterating over each STRIDE term.

For each of these terms, put yourself in an attacker shoes and think from different angles what and how an attack — in the context of the term — would happen

Below you can find a small description and example questions you can pose for each of them. Try to exaust each term before moving on to the next one. Typical outcomes in each term are: Architecture changes, Security measures, Increased validation, Investigate in-depth certain technical aspects, etc.

Spoofing

pretend to be something or someone you are not

How do you authenticate the user or service? How do you authorize and validate it? How could I impersonate other user?

Tampering

manipulate/change information you are not suppose to

Can I change other person information? How could I go around the business logic controls? Can I change data directly in the database?

Repudiation

ability to claim you didn’t do certain actions (no matter if you did or not )

How can you prove user X perform a certain action? If needed (for auditing or troubleshooting purposes ) can you retrace the steps of an user?

Information Disclosure

leak/expose information

Is the system information sensitive? Why? What are the risks of unauthorized information exposure to public (or other users within the system)?

Denial of Service

prevent the system to provide a service

What is the service(s) the system is providing? What are the consequences if it gets interrupted? How likely is that to happen?

Elevation of Privilege

gain rights to do things you are not suppose to

How could an user escalate to gain admin rights? Can a user with an expired subscription continue to use the service?

That’s it! Keep asking and challenging your system with each of the terms. By the end of your threat modelling session remember to:

  • Create (or update) your backlog with all the findings and new work uncovered.
  • Keep your Architecture and Flow diagrams up-to-date

I hope you found this article useful ! Please share your feedback and thoughts.