Deciphering Threat Modeling: Balancing Tools And Manual Approaches For Effective Security

I am here to talk about threat modeling and uh it's two broad categories how to threat model uh like manual approach and uh tools based approach uh let's dive in so first we'll uh walk through the agenda I have categorized my talk into six main sections uh we'll quickly cover the first two sections which are threat modeling I mean what is threat modeling and why do we thre model then we'll talk about the two broad categories which are manual approach and the tools based approach and then we'll just compare between the two categories like uh what are the pros and cons of the two methods and then like what is the balanced approach and how we can uh make the most

value using the pros of both the approaches so and before I move ahead I'll just give a give a brief introduction about myself I am niharika gani uh senior security systems engineer working with epam systems Canada I am a mother a wife and a homemaker a passionate threat modeler cyber security consultant speaker and I do give some time to my hobbies like baking cooking singing and I love traveling so let's go to what is threat modeling well it is a structured activity it part of SSD LC or we call it as secure SSD secure sdlc and it is used to identify evaluate and manage potential threats Identify some architectural design flaws recommend security mitigations and it is

a design phase activity so where does it sit in uh secure ssdc you see uh it sits in the design phase so when we talk about threat modeling it is done even before implementing any system even before the coding is done so in simple terms it helps us identify what could go wrong in a system before it is even built and the primary goal is to analyze the system from a security perspective early in the development process so potential risks and vulnerabilities are uncovered before significant time money and resources are in invested how do we threat model well uh it can be uh it can be done by answering Adam Shack's for famous questions what

are we working on what can go wrong what are we going to do about it and did we do a good job so what are we working on we we can analyze and decompose the system and create some dfds what can go wrong we can identify threats in that phase what are we going to do about it we'll Define our mitigation strategies and then the most important step validation did we do a good job enough did we find out the most crucial uh threats and risks and did we uh mitigate them but the question is why do we threat model why is it so important where we have so many security uh scans and uh security uh process implement in

sdlc like s dast iast penetration testing all things are there then why do we threat model well let's talk about the benefits of threat modeling so it's an early assessment so we uh we apply like this early assessment very early in the sdlc phase and we do not need a code for doing this kind of analysis like by its basic nature threat modeling is is the anal is which is done on the uh visualization or design visualization wherein you conceptualize any system or any application so you do uh security analysis on those diagrams you create dfds and then you uh figure out the threats and work on its on their mitigations so you don't need the code

you don't need existing systems for doing this analysis so that way it's cost effective it saves time money and efforts it unveils insecure design flaws because when we run sast dust or do penetration testing it cannot always uh point out the insecure design flaws which we'll talk about later in the presentation so threat modeling is very crucial for unveiling those kind of design flaws and prioritization so that way we prioritize what is important which which threats are really important we we essentially do a risk and analysis after uh identifying the threats and that way we can do a prioritization of fixing the high or critical threats and risks now the two broad categories for doing threat modeling we have a manual

approach we have tools based approach so uh in today's world uh everyone must have seen that every organization is just running behind the tools they want to grab the most famous tools for each security analysis and by uh grabbing them and setting the maximum number of tools for security posture management they uh brag about their security posture that they are very secure I personally do not agree to it because by uh you cannot just automate your way out of every solution every problem there has to be some human brainstorming required for some kinds of problems so there are some manual approach and there are tools based approach let's talk about manual threat modeling so the essential uh components

of manual threat modeling is drawing the diagrams we draw diagrams we we analyze the con concept of applications and systems we uh we brainstorm the uh designs and the architecture of the system and applications which which is going to be built we create the diagrams we create attack trees and attack surface although this is not a very mandatory steps this is an optional step uh which is done in some kinds of threat modeling methodology but uh yeah it's not important we apply uh various uh threat modeling Frameworks and uh identify threats uh when we talk about Frameworks we can uh enumerate like stride pasta dread there are many lyen for privacy we list out mitigations and

security controls for uh mitigating those uh threats which have been identified and yes last but not the least preparing a report trust me preparing a report is very important in threat modeling uh practice if we have done everything correct and we have not uh prepared a good report for the business for the development team it's uh not going to give you enough uh uh value of your practice then we have tools based threat modeling we have so many uh tools in the market uh the famous ones being Microsoft threat modeling tool OS risk threat model SD elements but they uh in on those tools we can create uh our own diagrams or we can take take some existing diagrams as

input so every tool has their own uh format of taking existing diagrams and they have certain limitations uh on the tools we can also uh select what Frameworks or libraries we can apply or we want to apply we have that option uh we can automate the threat identific identification but then again it's like framework and Library based we can automate the mitigations recommendation for the threats identified and yes it does save time and effort manual uh practice does take a lot of time and tools based uh does save time so what is better we spoke about manual methodology and the auto tools based automated one which one is better let's compare so in while in manual approach

it's we see that it's uh time consuming and human errors will be there like a famous saying to be human is to where so definitely there can be some human errors and scalability like uh when uh the huge there is huge number of applications and uh systems which require threat modeling to be done it's like it scalability is an issue at that point of time but in tools based approach the main problem is too much of information and limited customization and overlooking of Contex context specific threats let's talk about too much of information while manual method does require expertise and lot of time the overwhelming number of findings from most of the tools also consume lot of

time for triaging so while the tools are saving time by creating um uh threat modeling threat models and the threat modeling reports the huge number of overwhelming number of findings they also consume time for uh triaging those findings in one of my last jobs uh the uh threat modeling report itself took few hours to be created for application whereas triaging took a week uh to uh like bring down the numbers to uh actual uh or relevant findings uh a research by grammar Tech found that triaging a single finding irrespective of category requires 10 minutes and of on an average in other words triaging only 240 issues requires 40 hours which equates to a work week of

effort let's take take a example of context specific analysis few years back there was a straa heat map uh published on internet which used uh data from some famous uh fitness trackers and it you uh published an interactive heat map of uh people running uh or doing activity all over the world so if you see this map you will see uh blazes of flash on some parts of the world it's like very much illuminated but there were some War zones and desert areas which were like almost dark except for some scattered pinpoints of activity so if you if we zoomed in zoomed in to those areas it brought into Focus the locations and outlines of known US military zone bases

and other sensitive sites so it is just an example that it brought out some serious information disclosure threat because of this and this is like very context specific uh threat found out which may not be uh brought brought up by any tool so human brainstorming is required sometimes for uh critical applications or uh systems what do we do then if there are uh like some cons associated with manual methodology and some Cons with automated approach so uh like it does it have to be 100% of one or the other like uh either we should be uh relying on manual approach or tools based approach the answer is no we should automate everything that we can automate the

scale and speed of uh today's development environment demand that but the question is what can we automate and where do we need human expertise we can use the right combination so like tools work and give output based on patterns it cannot give the right contextual threats it can answer questions about what it knows so whatever libraries or whatever uh uh data we have fed into the tools based on that only it can give us the threats and mitigations so we need some human B brainstorming to find out the contextual threats and their mitigations also uh it can it cannot talk think about the nuances of the world that may come from some Corner cases so

and if we have a expert team of manual threat modelers then the question is why should we use tools because we can be way more effective by freeing up useful resources time and effort by using uh tools where it is good at such as uh uh like uh by using tools for creating reports so as I had enumerated earlier that creating report is very crucial for threat modeling creating the right report which can give you the right insight into the threats uh critical threats identified and what should be actually worked upon so if if it's like overwhelming time uh information in your report no one is going to uh see that and the huge number of false positives

they just slow down the development and they can also increase friction between security and Engineering so the right combination is very crucial for threat modeling it's not essential that if we have uh uh a very famous Tool uh the license for a very famous Tool uh for doing threat modeling that we are very secure we need some experts for doing threat modeling and brainstorming and uh yeah that's all I have thank you great thank you thank you so much so um we have time for a few questions so if there's any questions please raise your hand oh sorry I had my glasses on so I didn't see you yes please I'm not very familiar with automated threat modeling

tools and the type of findings that you would find out from those how would you differentiate if you were to use one of those tools the types of findings that you would find as opposed to something like a vulnerability scan so uh like personally if you ask me I've uh there is a very fine line between the vulnerability scanner and the threat modeling tools these days because uh like threat modeling tools also I mean they uh where they uh create huge number of uh findings which are very close to the existing vulnerabilities in a system that is why I I really don't like uh using tools because the number of findings or the uh quality of findings that you are getting

out of a threat modeling tool they are like very similar what you get out of a vulnerability scanner or sast or D they are like kind of mixed up but when we do uh manual threat modeling we actually like talk about the framework and we create our own diagram we visualize it we create our own diagram and we brainstorm there and it's it doesn't have to be a security expert to for doing threat modeling it's like uh a business team and the security expert or a developer everyone can sit sit for a huddle and do the threat modeling and it can be any Corner cases with uh that can come up which can have a critical

severity for its uh threat and risk So based on like let's uh talk about stride which is like spoofing tampering repudiation Integrity denial of service and elevation of privilege so there can be just one or two finding uh where where we do a manual analysis but they will be like meaningful and uh really important or crucial but when we use tools based uh threat modeling sometimes I have seen they uh create some 500s of number of findings which are very similar to vulnerability scanner so and sometimes for using threat uh threat modeling tools uh threat modeling tools based uh modeling you need existing systems to feed in as input so they take existing systems or whatever has been

already implemented they automatically create diagrams and they find out the threats which are not exactly threats they are vulnerabilities in the existing system correct because when you when you point something when you point any type of scanner at something you you're not looking at threats per se because threats come from out there doesn't come from that particular Target thing exactly and the very basic nature of threat modeling when it was uh introduced it's like we brainstorm on the uh visualization like we are visualizing some concept of an application or a system and then we find out the flaws that what could go wrong or what can go wrong so if we have already built the system and uh then we

are doing we are using tools for doing threat modeling we are not not getting the enough value of this practice then we can go for SAS dust and penetration tests because it is not actually giving you the benefit of saving time and money before U before implementation so I mean using threat modeling it should be done before implementation or before starting the coding wherein is uh whereas in these days uh many organizations are just taking it as formality like the application has already built or the system is already built and just for putting a tick mark on their list they are going for threat modeling which is not the correct way so from from the

manual process per perspective how would you differentiate threat modeling from conducting a threat risk assessment uh so I'll just repeat the question it's uh how do you how do you what's the difference between threat modeling and doing a threat risk assessment exercise I I am not uh very much aware of threat risk assessment which is done uh after implementation but yeah threat modeling should be done before implementation because it identifies the threats and we do a risk analysis on those threats and we try to uh prevent for uh which uh prevent something that can go wrong and we are trying to like save money which can uh which can be like uh big if we

are trying to fix it in U later stages of development so yeah it sounds like the the the threat model the way it's being conceived is that it's definitely way talking about push left it's way far left right that exercise exists in the design phase and you need a design phase in order to um execute a threat model exactly yes oh sorry you no no no I I think yeah so if you have somebody who is doing threat modeling if you're going to pick like fre skills or areas of knowledge that they should have to be successful at that what what do you think they would be uh I mean uh are you talking like

what kind of expertise is required for doing threat modeling yeah figure out uh yeah I mean for doing threat modeling for a like a really crucial or critical applications wherein like uh some very sensitive data or uh uh feature is involved I think Security Experts are really required but that's not mandatory like anyone can threat model it's not like only a security expert expert team can do threat modeling it's a security Champion can also do threat modeling and there comes the use of tools if it's just security Champion they can really utilize the tools for doing uh threat modeling on their end wherein uh if Security Experts are doing that they can you really use their brainstorming power

for identifying some crucial threats so think there's a couple more questions there's one here and then one up here so I'll start with you and then we'll go on I'm curious um in your experience um how often is threat modeling actually sort of effectively done because I'll tell you what my experience has been that is a very good question Ops perspective there's a real benefit to threat modeling because those data FL flow diagrams also tell you what you should be monitoring exactly both from an infrastructure perspective and from a security perspective and my experience is that it doesn't happen very often because the monitoring is usually yeah so I actually uh once uh I have been into uh I have worked with a

client which uh where they had the very uh effective process for doing threat modeling so yes I have witnessed that effective way of doing threat modeling wherein I learned also a lot but uh in today's world many organizations are doing threat modeling just for the tick mark just to pass the security gate so uh I think there is a huge gap which we need to like cross to uh bring a very good value from threat modeling so I don't have a question but I want to answer my fox asking between vulnerability and threat modeling so thre threat modeling actually finds you the flaws and weakness into your system that can uh exploit the vulner vulnerability in the future so there is

a there difference yes the threat modeling comes first it's like on not a critical version but you find those like you know flaws into your system before it happens as aity in the future so it's a prerequisite for vulnerability if you want to have your system pretty much accurate andure so in other words you identify those flaws even before the product even exists exactly okay yep okay thanks thank you for answering that question okay anyone else great okay all right thank you so much oh one more question I'm so sorry you were sorry AEL continu Ong basis over a number of years there going to be a lot of changes softare over those how envir

Con well um threat modeling is applied in a child methodology as well so I mean whenever there is a change U subjected to any application or there is a change cycle every time uh threat modeling should be uh uh done uh repeated it should be reassessed and again that is also one uh scenario where we can use tools so for any minor version changes or any uh like reassessment we can use the tools wherein we have already created some basic DFD and we are just subjecting some change so we can use the potential of tools for doing uh the rework on threat model thank you so much great thank you