Understanding the basics of threat abstraction and modeling

Understanding the basics of threat abstraction and modeling


Threat Abstraction and Modeling is an important piece of planning in the enterprise as it can be used as an approach to better secure software. Spending some time during your planning stages thinking about threats and potential threats to your latest project can pay for itself in spades when the rubber meets the road and you’re ready to build out or deploy your latest software project or infrastructure installation.
While on its surface, the topic of threat modeling seems like an advanced skill and above your pay grade, in reality, as humans, we have a predisposition to employ threat modeling in our lives already. For example, you may already ask yourself: 
“Do I walk alone down that poorly-lit alley at night?”
“Should I shield the PIN pad from view when I enter my PIN at the ATM?”
“Why is this person walking so close to me?”
“Is it okay to leave my backpack in the back seat of my car?”
“I’m late… do I take the chance in speeding to my meeting or running that red light?”
These are some of the myriad of threats or potential threats we face on a daily basis, and this type of thinking has a direct relation to thinking about threats in the world of information technology. Threat modeling and abstraction really boils down to this simple point: when building things, whether it be software or systems, you need to spend some time considering and predicting the various threats that those things may face during their lifetime. By looking into some of the ways that attackers could exploit the software, it can provide insight into an attacker’s perspective and help sure up some security vulnerabilities along the way.

Why should I use threat modeling?

Really, the question you should ask is why shouldn’t you spend some time building threat models for the things you create? Maybe you think you don’t have the time. Maybe you think you’re not a target. Maybe you think that it’s a waste of resources thinking about the “What If’s” instead of just getting things done. All of those things are certainly reasonable points, but the threat landscape reality doesn’t really agree with these points anymore. There’s a quote I like to reference about this, from Purdue University professor Gene Spafford:
“The only truly secure system is one that is powered off, cast in a block of concrete and sealed in a lead-lined room with armed guards - and even then I have my doubts.”
This of course makes me think about the US/Israeli joint attack on Iran’s nuclear centrifuges, which gave the world Stuxnet and ushered in a new era of cyberwarfare. Iran built an air gapped system with no Internet access. They apparently didn’t take into consideration the old-school intelligence method of recruiting a mole inside the facility who was able to hand deliver a USB drive with the malware payload on it and launch the attack. What if the Iranians had superglued shut every USB port inside the refinery? What if every person entering and exiting the facility were forced to enter an X-ray and strip search? 
That anecdote aside, the reasons for threat modeling in your own environment gives you some significant advantages. It may allow you to find or avoid exploitable bugs before deployment, it can give you a good idea as to your actual security needs, and ultimately lets you create more secure systems.
In my next post, I’ll dive deeper into the basic steps you may want to take to begin your threat modeling journey – what to think about and some common pitfalls people make in building threat models.

Comments