hey everyone so today we i'll i'll be presenting about set modeling and yeah like i i start with
my dad like my dad is a great set modeler so we will learn set modeling with the reference
of my dad so first thing first something about me i i work as a security engineer at finoa
i suffer from voluntary stress because like i like you can find me volunteering with almost
every conference working behind the scenes i'm more of a security rank than an engineer
i live on the principle of working around and finding out the landmines
in the organization infrastructure and architecture
you can always find me on twitter and discord
so let's start okay so as once dan kaminsky said it during defcon 23
who are we who are the hackers like we are the people who manipulate how systems really work
not just merely how they are supposed to work and that does not always mean we know how they work
it helps
you
, but we don't always know and not knowing how things work tends to cause them to fail
and we hackers just define the failure condition as a success condition when every engineering team
fails security team wins and like we in security think that other people can make mistakes and
fall into pets but we security folks are immune to everything but we believe we screw things all the
time
but we we just have an attitude about it
so threat modeling what is threat modeling like by definition threat modeling is a structured approach
of identifying and measuring risks or prioritizing them determining the value that potential
mitigations can reduce or neutralize those threats in general when we when we proceed
to threat modeling there are four questions which comes in our mind
first is what are we building or what we are looking at what could go wrong either it's
an infrastructure application or maybe a physical building you like you can threat model anything any infrastructure anything
uh it reminds me of last week i was attending dana initiative virtual conference and there was a talk about threat modeling for mental health and like it was a superb talk then we can talk about the choice between
can identify threats by thinking what could go wrong and then when we recognize threats
then we need to understand what we are going to defend to defend us against those threats
and the final step will be like if we know that there are threats we know from whom we
have to defend ourselves now are we acting on those steps or not if we have acted then
what's the residual risk now i'll start with some boring frameworks to get the basic understanding
i won't go deep into them i promise and like as as usual no one likes doing things in theory
so let's start with octave octave is more like practice focused threat modeling framework
and full form of octave is operationally critical threat asset and vulnerability
evaluation framework
which basically defines the risk like which basically defines strategy based on risk
assessments and planning techniques like octave is a self-directed approach when you are
starting with octave it it just gives you variation of tailored limited means that
you you have unique constraints limited to your organization size there's one more variation of
of of octave which is like octave s which is used for the teams less than 100 people
and having a threat modeling function of only just three to five people
second is strike strike is mostly works with uh in reference with erm and what erm
is enter erm is enterprise risk management so it mainly works as a risk management tool within this
framework threat models are used to satisfy the security auditing process set models are based
on requirement model and the requirement model establish the stakeholder defined acceptable level
of risk now what this acceptable level is we'll talk about it later when we will be talking about
risk acceptance and installments then analysis of these requirement model yields a threat model
from which threats are enumerated and assigned a particular risk values which ties to the businesses
then third stride stride is quite popular and it's mostly a developer focused state modeling
technique stride stands for spoofing tampering repudiation information disclosure or denial
of service and escalation of privileges so it is just a model of threats used to help
you
reason and find tricks to a system it is used in conjunction with a model of target system
that can be constructed in parallel like like other threat modeling models try do not works as a
works only in ideation phase or just at the end cycle but striders are like striders
applicable during the whole product life cycle like at every step you can think what we are
building what processes we have what data stores we have what data flows we have and
how we are creating the trust boundaries between these all these data sources today it
is often used by security experts to help answer a simple question what can go wrong in the system
we are working on then we have pasta pasta is basically a process for attack simulation
threat analysis it's a seven-step risk-centric method methodology just like strike it also works
on to risk management thingy but like it measures business impacts more from the attacker's point of
view the intent of this method is to provide a dynamic theta identification enumeration and
scoring process once the set model is completed security engineers can develop a detailed analysis
of the identified sets finally the security controls can be numerated again the meta
methodology is intended to provide an attacker-centric view of the application
so that's that's all about frameworks now why why we are thinking so much about threads why
no no one likes threads no no one does but we we cannot protect against anything we cannot
we do not know about so we need to know threats if we want to defend assets from those threads
so basically
set modeling helps us to have a mitigation strategy and techniques based on the identified
and documented sets you basically identify and address the greatest risk you prioritize that's
which which states you can assert which can which states you can circumvent with another technology
you increase the discoveriness in your organization
and then you basically once you have things and once you know how how your risk exposure
looks like you benefit from cost justification and support for needed controls you can use
artifacts to document due diligence for each software project each infrastructure project
any kind of project you have in your organization then some examples like how things look like
basically so this is the platform where we can use this platform to document new data and to create our projects
and like we will be talking about examples only in the context of stride because otherwise it
will be a lot of examples if we start picking every framework so stride as as i said stride
stands for spoofing tampering reputation information disclosure dos and elevation of privileges
like every every uh keyword in stride impacts a particular parameter of a paradigm of information
security so spoofing impacts authenticity tampering impacts integrity reputation causes
non-reputability information disclosure is breach of confidentiality dos is breach of like there is
no availability and elevation of privileges breach breach of confidentiality and so on
authorisation so half what is spoofing spoofing is basically illegal access and using that access
to have have information which one are not supposed to have the basic example can be
cookie hijacking like for example if you have an application in your organization where you can
if you reuse cookie of another user then you can basically log in into the
account and you can use it to access the app so spoofing is basically illegal access and
if there's no 2FA network so so that's a spoofing fit from that particular application then we come
to tampering tampering is more about integrity and like example can include unauthorized changes made
to a persistent data such as that held in some database and alteration of data or maybe alteration
of data when data is in flow from an open network to a computer like man in a middle attack you
intercept thing and you manipulate it through a proxy then we have reputation reputation gets a
bit complicated like reputation is associated when you cannot uh uh uh reputation can be
can cause non-reputation which is like when you cannot backtrack the actions of a user
backtrack malicious actions to a particular user for example
if you
have a application in your organization which can only have single admin and you have three system
administrator and what they're basically doing are they are using single set of credentials
between three of them if one of them poses like is the insider threat to the organization and
they do some malicious action you cannot use the audit logs of the that application to backtrack the
actions of the malicious user because all three users are using the same set of credentials
so when there's a non-reputation locks becomes useless so it's it is considered as a risk
and then there is information flow or disclosure information disclosure is just
breach of information which should not be exposed and it can be accidental share of files externally
like if if some
some files are uh files are confidential to your organization and they get shared
by human error or by insider outside organization then basically it's an information disclosure
in some cases you can reduce human uh error factor for example if you have shared drives
in your company and human error can happen that one user accidentally
shares your confidential data with someone external to just a single click but you can
enforce controls that like you can have dlp policies on your shared drives that you can
restrict the external use external share at all so even if they make that error it won't happen
then there's denial of service denial of service is basically denying the service to valid users
For example, making a web server temporarily unavailable or unusable.
Then we have elevation of privilege and unprivileged user gains that privilege access and then compromise the security or destroy the entire infrastructure.
Yesterday I was having an interesting discussion with a friend about elevation of privilege that if we have a project in any ticket management tool
and if we want to restrict that project from admin of that particular tool, then it's nearly possible because admin can always give themselves privilege to have access to that project.
So it's an issue.
Now we know what is Threat Modeling, how to do Threat Modeling, now when to do Threat Modeling.
Mainly Threat Modeling is done as a top to bottom exercise when certain benchmarks are made.
For example, if you have plans of launching new set of features,
if you have been developing new features,
or you have like you are acquiring some companies,
so maybe you want to Threat Model the coming entity or you might be having a compliance requirement or you might be needing a regulatory approval.
So Threat Modeling matters because it gives you the risk score of your company which ties back to finances of your company.
And like this,
even the one use case which I always think is like if an engineering team is,
if an engineering team face some incident and they are doing root cause analysis,
then they can do Threat Modeling during RCS as well.
Because even when the root cause is of more pedestrian nature,
performing a root cause analysis can get the right people thinking about potential Threats.
They may have ignored previously or they never considered them.
Or maybe by patching that particular vulnerability,
they might propose new dependency,
which may introduce unexpected security issues.
Then otherwise,
in my opinion,
Threat Modeling perspective should be the way of life for every security engineer or like engineering team as it promotes security by design from every aspect.
A day comes when you don't have to do Threat Modeling exercise anymore because you are designing everything from the Threat Modeling perspective.
You are thinking security before doing things.
And it is applicable from application to infrastructure,
infrastructure to your even physical security.
So now when not to do Threat Modeling,
we just said that we should do Threat Modeling by default,
but then not to do it.
Basically,
I can think of only one thing when not to do it,
when you have plenty of Threats in your environment.
And those Threats are critical.
You cannot just ignore them and find more fire hazards in your organization.
As one of our wise men said that you don't go and look for more fire hazards when your house is already on fire.
Don't overwhelm your engineering team so they stop caring about the Threats.
As one chief in NAPO said,
Threat is a mirror of security gaps,
but cyber threat is mainly a reflection of our weaknesses.
Then my dad,
my dad is a great Threat Modeler and that's a good thing.
But what he is doing wrong.
He is doing this.
He is making the same mistake,
but almost every security engineering team makes,
which is Threat Modeling.
Being good at Threat Modeling is one thing and
dealing with the outcomes.
Of it is another.
So if you are doing Threat Modeling,
you are getting reports.
How are you dealing with the results?
Are you becoming overwhelmed?
Are they becoming overwhelming to you or like what's happening?
So basically two wrong things happen usually when you deal with the Threat Modeling reports.
First is either security teams becomes too paranoid
or engineering teams stop caring at all about them.
And those are like usual cases.
And they,
they happen in lots of organization.
Why they happen?
Mainly security engineers when get too paranoid,
they,
this,
they become a bottleneck for every process or every thing,
everything coming.
So we can start with risk acceptance.
What is risk acceptance?
Risk acceptance is like,
amount of risk your organization is willing to accept.
And this appetite is like capacity of risk.
They can like diverse kind of risks your organization can accept
to achieve its business objectives.
Organizations basically recognize that they cannot remove all risk
from their business.
Unlike we exist in world full of risk and for achieving our business goals,
we need to require,
accept some risk and mitigate them or either transfer them.
We can have,
we can have compensating controls around the Threats to reduce the Threat and have
then residual Threats,
which is like of lesser risk factor.
Then what is risk tolerance?
Risk tolerance is the amount of acceptable deviation from an organization's risk appetite.
Why risk appetite is a broad and like strategic term.
Risk tolerance is much more of a tactical concept that identifies the risk associated
with a specific initiative or a specific project.
While risk appetite is organization's appetite and risk tolerance,
various project to project.
One way to understand the solution is I was reading an article by TechTarget
and they presented it like where,
for example,
when driving,
driving,
driving at very high speed on government roads is like,
is a high risk for the driver and to all the other drivers on the road as well.
And government creates speed limits designed to control this.
The faster a car drives,
the more risk is created.
So the lower the speed limit,
the lower the degree of overall risk to the every driver on the road.
However,
lower speed limits or lower limits also inhibits the flow of traffic,
preventing vehicles from quickly reaching their destinations.
Government must balance these concerns and determine the appropriate rate of speed,
which is like government's risk appetite,
like how much risk they are willing to take to strike the balance between risk and fit.
Then fun part.
How,
how I built a tech modeling function with just three people,
including me in a team.
And like,
it's totally doable.
Just,
just give them a perspective,
just make them think and just make them think how things can go wrong and tell them to spread that mindset.
Like when I started in my organization,
we were just three people.
Loads of features in product were coming.
We were reinventing infrastructure.
We were migrating to different technologies.
Hence,
tech modeling was needed everywhere.
We were waiting on regulatory approval.
We were waiting on compliance requirements.
We had to do tech modeling at every,
every step.
And there were so many landmines in between.
So in my experience,
frameworks are good for,
to give you a mountain side of perspective when you are new to tech modeling.
But with time you develop it,
like frameworks becomes a bit hard to scale up or,
become a bit complicated for a big organization.
And it's,
it's sometimes hard to go by the book all the time.
So you can have your own framework and you can decide how you want to measure the threat and link it to the risk factor.
Then once you are proficient at threat modeling,
then you pass on that mindset to every team.
Then every team,
every engineering team learns to threat model of what's coming.
And even gets better as they understand the product more than you.
They understand the infrastructure better than you as they're working on infrastructure all the time.
And they see the gaps just better than you.
Like I've been on calls where I used to do threat modeling and now those developers or those infrastructure engineers are doing threat modeling way better than me because they understand how it is working.
I have to first understand the technology to find,
to highlight the threat.
But they already know how it's,
how it's working in detail.
They,
they just need that mindset to look into things.
What,
what can go wrong and imagine every worst case scenario.
And as I always say that threat modeling is more than just an exercise.
It's,
it's a mind,
mindset or a philosophy.
I'll conclude my slides with like,
thanking to Max and who helped me brainstorming ideas and curating a raw idea about the third modeling and like supporting me into building the whole function and just with just three people.
So any questions you can always find me at Twitter and discord.
I'm,
I'm quite active there and always open for chat.
Thank you.