Software-Centric Threat Modeling

Engineering-led, developer-focused, or software-centric threat modeling: they all have software in common. Composing software into functions through the user story's lens is important. Farshad Abasi shares his journey from being a software engineer to forming a global AppSec team at HSBC Bank. Farshad expresses the importance of asset-based threat modeling and the need to keep things simple. He emphasizes the importance of focusing on the user story and considering the "comma, but" scenario to understand potential threats. He also suggests using pull request templates in source control to ask standard threat modeling requirements-specific questions.

Farshad recommends doing architectural threat modeling at the beginning of the development process and revisiting it periodically, perhaps quarterly or annually. He also highlights the importance of being part of the DevSecOps process to review user stories regularly. 

The key points are asset-based threat modeling, following the data, focusing on the user story, balancing high-level architecture threat modeling at the right time, and adopting pull request templates as reminders for threat modeling. 

Provide a solid process that makes sense to developers, as they don't mind threat modeling when presented in this way.

Welcome to Smart Threat Modeling. Devici makes threat modeling simple, actionable, and scalable. Identify and deal with threats faster than ever. Build three free models and collaborate with up to ten people in our Free Forever plan. Get started at devici.com and threat model for free! Smart threat modeling for development teams.

Episode Transcript

Chris Romeo (00:09):
Engineering-led, developer-focused, or
software-centric threatmodeling.
Each of these is threat modelingwith a focus on those that write
the software.
No matter what we call it, thegoal is to dig into the software
and decompose it into functionsby looking through the lens of
the user story.
Let's explore threat modeling.

(00:29):
In the world of developers,

Farshad Abasi (00:32):
Hey, Farshad Abasi hailing from Vancouver,
British Columbia up here inCanada.
I started as a softwareengineer.
Went, did the com slide thing,went built software, started
building, web applications backin the.com era.
A friend of worked at HSBC Bankand they recognized the value of
doing application security andsoftware security from inside

(00:52):
the development organizationrather than outside team.
we ended up forming a globalAppSec team.

Chris Romeo (00:58):
Large organizations must choose a specific process
and methodology to succeed inthreat modeling.
Farshad landed on asset-basedthreat modeling at the core.

Farshad Abasi (01:09):
About a year we discussed this, and now a
conclusion was that we weredoing, a simplified version of
OWASP, asset-based threatmodeling.
Keep things simple.
Don't make it too complicated.
So the asset is information.
It's either that or theresources that cost you much.
take an internet bankingapplication, that internet
banking application is assets.
So the balances and the people'snames and all that's one way
they could lose money is that,that data is either deleted or.

(01:31):
Compromised, you or exposed ormodified in some way.
The other way that bank couldlose money is that the, compute
that's running the, webapplication is misused so that
the attackers run some cryptomining on there, and then
they're just like costing a tonof money that's also gonna get
charged.
To that department who owns thatparticular application.
So your application can cost youin two ways, Your, the cia, the

(01:51):
confidentiality, integrity,availability, impact on the
data, as well as some resourceimpact on the infrastructure
that you're running in.
That's where we draw the line.
So we do asset based threatmodeling.
We say how can those assets behurt in the way, like how can
the data be hurt in terms of thecia and how can the compute and
infrastructure be misused thatit would cost us money?

Chris Romeo (02:10):
Threat modeling is only as repeatable as its
process is robust.
Here's Farshad's, take on theprocess.

Farshad Abasi (02:19):
It seems like the general way that everyone
teaches this is says, you havesomething of interest, It's an
asset.
use the house example, right?
You got an asset is sittingsomewhere, someone's gotta get
to it.
What are the different entrypoints to this?
So the different entry point isyour window, your door, your
chimney.
Each of them may, some may beeasier, some may be more
difficult, depending on what'sat stake.
The attacker will go and, andleverage more resources to get

(02:41):
to the asset.
So if it's like a.
A hundred million dollars in thehouse, he might try to go
through the chimney if that'show, what he has to do, because
it's a lot for him to gain.
as the impact goes higher, thenthere's more to gain for the
attacker and they're, morelikely to take extreme measures.
So you have to really focus yourthreat model.
how theoretical do you get isbased on what's there for them
to gain.
you of start with thatconceptual model, but then
that's the traditional threatmodeling, Then you take an

(03:02):
application system, let'sdecompose it into, its
architectural components and thelinks, and then follow the data,
So that's easy to understand

Chris Romeo (03:10):
Sometimes as a threat modeling teacher, you
find illustrations that work tohelp people simplify the steps
they must follow, like Farshaddoes using data from Star Trek:
Next Generation.

Farshad Abasi (03:21):
I remember the presentations where we used to
teach the teams at HSBC.
We used put a picture of datafrom Star Trek and it'd be data.
And everyone would rememberthat.
if you're lost, just followdata.
Where does it come in?
Where does it go?
Where does it get touched?
Wherever it gets touched, it'san opportunity for an attacker.
To do something bad to it.
So that's easy for developers,for everyone to understand.
Is it processed security?
Is a stored security in those,points?

(03:42):
where that stops short is that,within that component that
you're making, so maybe that'sprocessing the data in a secure
way, but maybe there's afunction in there that could be
abused.

Chris Romeo (03:52):
Now we hone in on one of the most important parts
of Farshad's process, focusingon the user story.
As my friend, Izar Tarandach, isfond of saying,"Threat model,
every user story." The plotthickens as Farshad adds the
"comma, but."

Farshad Abasi (04:11):
Take a user story.
I'm making a function or afeature here, that as a user I
should be able to view the listof my transactions.
As a user, I should, I should beable to view.
The list of my transactions formy checking account.
If you want to figure out thethreat scenario, you put a
comma, you put a, but you saycomma, but I should not be able
to view other people'stransactions there.
You just came up with a threatscenario that as a user you

(04:32):
shouldn't be able to view otherpeople's transactions.
when you're building this userstory, have you thought of a
control that prevents thatperson from being able to view
other people's transactions withthe feature that you've built?
We of practice these thingswhere it gets them to not just
think of the good user becausethe good user just wants to see
their banking transactions,their account balance, but the
bad user wants to use thatfunction to see other people's
data.
in any of the user stories, ifthey put that"comma, but...,"

(04:56):
and then think of what the baduser would wanna do, and that's
a really easy way for them tounderstand.
And then that's how we get themstarted.
And we, mentor that.
we do a but of that stufftogether.
And then hopefully once they geta hang of it, we get them to
start, coming up with.
those evil stories,

Chris Romeo (05:10):
Here's another tip I want to highlight so you don't
miss it.
Farshad recommends using pullrequest templates in source
control to ask some standardthreat modeling
requirements-specific questions.

Farshad Abasi (05:22):
If the development team is using, Git
for example, if they have a pullrequest set up so that there's a
manual review required, we getthe person that's doing the
manual review in the templatefor the poll request, to add a
few of those common things thatthey need to remember.
Like, in this user story?
Have you remembered to consideraccess control and input
validation, et cetera, etcetera, all those application
security controls that I wouldcall cross-cutting concerns or

(05:43):
common controls that apply tomost stories.
We would put them in a pollrequest template as a reminder.
So when they're considering thethreat model, have those
controls been considered or aspart of the solution

Chris Romeo (05:54):
As we think about the user story-based threat
modeling, it does open achallenge that at the user story
level, we miss out on threatsthat exist at the 50,000 foot
view or the architecture.
Farshad has an answer.

Farshad Abasi (06:09):
If someone was to say, Hey, fresh, I'd wear DevOps
team.
When should I do threatmodeling?
I say, you should do thatarchitectural threat modeling at
the beginning when yourarchitecture is forming, and you
get into sprints and you buildand you build, and maybe once a
year when you do your tabletop,you also do a full threat model
at the architecture level ormaybe every quarter.
So you see, have you added anyarchitectural like interfaces or

(06:29):
are you talking to any new thirdparties or data stores?
If you are a security AppSec guyand you come to me and say, test
my application and do thatfunctional threat modeling,
You've spent hundreds of sprintsdoing all those user stories.
For me to retroactively gothrough all of those and do it,
it doesn't work.
So that really works well whenyou're actually a part of the,
the DevOps process if you'repart of the DevSecOps, if you
will, and you're able toregularly review those user

(06:50):
stories.
Otherwise, when we do itretroactively, I just go, give
me the high level functions.
Like I know I'm not gonna beable to dig into every user
story you've developed.
Just tell me at a high level,what are the key functions of
your application, and then I'lljust try to figure out if
there's possibilities to abusethose business functions and
functional threat modeling inregard.
The architecture diagram is thestuff that should only be done

(07:11):
once or twice.
Remember I was saying thatthat's not the stuff that
developers should do every day.
That's like, Hey, in thebeginning, let's take a ideal
world scenario.
You're building an application,you're gonna follow DevOps,
right?
Or Agile.
There's always gonna be thatinitial inception product
inception stage, where youcreate that initial architecture
and your first backlog of userstories at that stage before you
go into Sprint one.

(07:31):
You define the high levelarchitecture.
You're like, yeah, we're gonnabuild a microservices
application.
AWS is gonna look like this,right?
You haven't started buildinganything yet.
That's where you do that initialthreat modeling.
At that point, often it'sprobably a good idea to get a
security SME involved of somesort.
If not, you know, you get yoursolution architect, you know
that.
Then they do that traditionalarchitecture level threat
modeling,

Chris Romeo (07:50):
Asset-based threat modeling, follow the data, focus
on the user story, balance thehigh-level architecture threat
model at the right time, andadopt poll request templates as
reminders for threat modeling.
Developers don't mind threatmodeling when you provide a
solid process that makes sense.
Learn from what Farshad hasachieved with threat modeling

(08:11):
and focus on modeling every userstory.