I am so happy that Citrix allowed me to release under Creative Commons license the threat modeling framework I developed in the last four months.
What was the challenge?
Doing threat modeling is one of the main requirements for almost any Agile organization. Most of the teams are doing it wrong, and as an award, they receive a false sense of security, which leads to products and services that attacker personas can easily exploit.
What’s the solution?
I created an agile visual threat modeling framework (code name: Protecto)
Steganography is the art and science of embedding secret messages in a cover message so that no one, apart from the sender and intended recipient, suspects the existence of the message.
The most common example is to hide a message in an image file without compromising how the image looks. The majority of the people are using the photos to share a fantastic moment or two and don’t know that they can contain a secret message.
What could be the use-case?
Someone can hack your phone and embed your text messages in the pictures you take and share in, say, Instagram.
A not so happy employee can post a picture on your blog with a secret message embedded in it to share some trade secrets with your competitors.
Steganography also is a well know method for exchanging information between spies.
Even if it sounds like science fiction, this is a very viable threat against your systems and you.
Steganography Protector API
I have created a small API (as a Proof of concept) that could discover a secret message hidden in any image file.
Most of the companies I worked for or know about have a bizarre threat modeling process. They count on the architect or the most knowledgeable person to do the threat modeling. It’s defined as a one-person job!
If your goal is to do it, because it’s one of the required artifacts for your service to go in production or any other stage, it may be the right approach. But this is no threat modeling; it’s a false sense of security. You call for harmful attempts against your system because you put all the eggs in one basket.
It’s the exact opposite of the goal of a threat modeling session.
Involve your team members when you do your threat modeling.
Every person in your team has a unique perspective and a way of thinking about possible threats against any system.
Every person has a different experience compared to the others.
Every person has different emotions and morale.
All of those qualities play a critical role in the threat modeling process.
Let me give you an example:
I started a fun and useful exercise, explaining the threat modeling goal by bringing people together in front of a virtual whiteboard and doing a threat modeling against a beer tap infrastructure.
We have a yard with a few doors to enter it. We also have the beer tap, a pressure system, key storage, and some power controls. We have two boundaries to protect.
The team members were encouraged to “go wild” and think just for 7 min about all possible threats they see against the infrastructure individually.
Then I asked them to put virtual “sticky” notes near the components that could be threatened and discuss the findings as a team.
I did that with six groups from different geo-locations, and every time, I received different results. 90% of the threats were common, but 10% of them differed from group to group. This is how you make your modeling better.
To compare, I asked a few people to do this exercise alone for the same time, and the difference I saw was that the wisdom of the crowd identified with 40% more threats than a single individual. If this is not hard proof, which is it?
Involve your team members when you do your threat modeling. It’s the first step into your journey towards creating a bit more secure products.