Threat Modelling for Detection and Response

hey thanks for having me um i hope you can see the slides uh that i'm trying to share and not my presenter view with all my notes um and yeah this is the last talk of the day so i will try to make it as entertaining and as energized as possible so you guys can uh hopefully catch the last closing notes as well after um so yeah i'm going to be talking about threat modeling for detection and response um let me just make sure okay okay cool so apparently all is good all right so uh i'm a security engineer on the detection and response team at cloudflare and uh i am based out of san francisco so right

now my local time is 6 30 so if i have any word mishaps just attribute it to the early time but yeah some of my teammates also just gave a talk at defcon and b-sides lv on some of the engineering work that we're doing so i would recommend you guys check that out all right so first i'm going to get into an intro to cloud um we're building a global cloud network to help the faster more secure and more reliable so cloudflare is an internet company that offers network performance and security solutions for websites and teams we have over 25 million internet properties that are using our services um 200 um sorry 200 we operate in 200 cities and in 100

plus countries uh you know every single day we have 87 billion cyber threats that are blocked and we have over 2 000 employees all over the world and 99 of the internet connected population in the developed world is located within 100 milliseconds of our network so hopefully as more of the world gets connected to the internet we can be closer to uh serve them so to run this vast network we need many different tools and services so here is a list of some of the engineering tools that we use to run cloudflare in the back end there's a lot of data that's exchanged between these services that enable our network to run efficiently so how does a security team protect it

all uh we do this by having a wide range of responsibilities that span across all of these functions um but in order for us to be proactive about protecting these services effectively with engineering teams to understand the risks that exist in our services or architecture you know authentication changes we need to really have a good relationship with them and one of the ways we do that is through threat modeling so in so i'm going to give a quick overview in case people in the audience haven't heard of threat modeling or they haven't actually done it in a production environment and have read about it but they haven't um actually gotten an opportunity to do it in at work

um so most threat model frameworks out there uh regardless of the methodology generally have these goals in mind and it really i'm not going to go over all the points on my slides but it really boils down to risk management identifying vulnerabilities and prevention of exploitation through bug fixes so the general approach includes answering some of these questions right you could be assessing apis your cloud environment um gcp aws or you could be manage you could be assessing certificate management and how the service authenticates to other services so you're also looking into where things can go wrong you could be dealing with over permissive users mismanagement of keys or even hardware related vulnerabilities and how we generally try to address them is

through documentation which sounds unintuitive but it's really true when security teams identify all these vulnerabilities the engineering teams aren't able to prioritize it yet so the best thing we can do is add it to a backlog and make sure it's documented somewhere um add in detections and obviously clean up code so here are some of the general steps and these are some of the common frameworks that some of you may be familiar with so the first step is the planning phase um and this is where you scope out the threat model and try to figure out which part of the system you're going to be focused on focusing on and sometimes if you haven't touched

the system at all it can just be a combination of everything and then a high level overview the next phase usually involves identifying which is identifying and classifying the types of threats that you may be exposed to after you've done the planning and assessment third is prevention and mitigation and this is where you typically identify threat and risk mitigations and tools and processes and bug fixes as well to prevent exploitation of the risks that have been found and finally it's validation and remediation so you've done all the mitigation and now you want to make sure that um it's it's actually covering the risk that you've identified and this the i feel like these last honestly all these steps are um

iterative and you revisit them every once in a while hopefully ideally and i'm going to be focusing on the prevention and mitigation step so i'm going to be talking about methodology that can help security teams but in particular detection and response teams effectively involve themselves and detection and response principles into threat modeling to be more proactive and to make make the most of the process so if your team is too small to have a dedicated function just for detection and response then you can think about all the things that i'm going over in terms of someone advocating for dnr principles um and some of the things i'm going to be describing uh may be like it's going to be describing a

lot of like how it's done at cloudflare but the approach may be varied based on the company and the security team so it's supposed to be flexible around that um so the role of detect fonts um is usually not something that people think about in my experience in threat modeling and different factors impact a security team's priorities and ability to prioritize dnr goals usually it's product security and application security right like if you identify a bug during threat modeling are you really going to be worrying about like logging and auditing or do you just want to fix that bug and then deal with like the 20 other things that are going on so teams may run very lean and

prioritize fixing bugs as opposed to proactively detecting bad behavior which is understandable but it isn't to say that noting down risks or building a backlog to help detect malicious behavior wouldn't help in the long run um so like i said different teams have different priorities and perspectives and in my experience product security and application security uh usually have the principles of fixing vulnerabilities and they're usually the first ones to come in to evaluate a system to understand what risks and software vulnerabilities exist they generally seem to be focused on the foundational principles of confidentiality integrity and availability and when you think about authentication architecture these kind of map back to cia so product security teams typically get

embedded into the sdlc process and are included for security reviews when features are added and even minor changes could actually introduce really troublesome security bugs that developers may not think about so when a team security teams typically lean one actually may want to reduce the amount of logs that come in for an application so this is where detection and response teams i think come in because we want to prioritize adding in the future of auditing for our system so that you know even once the security bugs or vulnerabilities are addressed through code reviews um we can make sure that we have detections in place that can identify the un like underlying actions that may point to a new bug or a new fix

um and security handling or um product security teams because they may de-prioritize logging they can actually you know it's a give and take right like different teams are going to be prioritizing different things so this is why it's important to have different perspectives involved in the threat modeling process so let's say um you're at a company now and the security team has diff has different functions and they're ready to think about involving dnr um so these are the scenarios that i found to be very useful uh to involve detection response teams um essentially without i would i would describe the scopes as being focused on you know security feature changes infrastructure changes uh logging auditing and major

modifications to user permissions and access dnr engineers want to know if they can detect these changes and if they're enabled through auditing and logging to be able to detect them so now i'm going to go into a framework and how dnr engineers can get the most out of the threat modeling session so let's say now you're included in the sessions and you want to know how to make the most of it so how do we prioritize what we need to focus on there's a lot of different tools and different services that are operating in a production environment and so there's different types of risks per area so i would say something that's really helped me is

using a data centric risk evaluation so you know where is the most sensitive data located uh where how can that data be exploited think about attack vectors and traversal paths through your environment and attacker trees is something that's mentioned in a lot of um threat modeling methodology so i'm not claiming that as mine but not a lot of them have modernized it in the sense of like there's a lot of frameworks out there like the attack matrix that help detection and response engineers think through the types of exploitations in in a more structured format and a lot of this can also vary based on the culture of your company it could be that your company really

wants to focus on where customer data is located or maybe they're in a phase where they really want to de-prioritize customer information for this quarter and they want to focus on insider threats and employee data so these are overview of areas to review when you're trying to prioritize which service or system to look into so the first one is authentication some of the questions that i've thought through in the past is how does authentication to the service work who or what services has access to this system and who or what controls access to it so it could be very much a process related vulnerability or gap where one person has the ability to grant access to

engineering teams to to a data store and then who is able to make changes to this data next is storage so you want to think through what platforms store this data where is it forwarding data to and where is it getting data from think about how long that data is stored and who has access to this data in the data stores a lot of this can be i guess what i want to say is when companies scale really fast a lot of this can be rushed through because they're trying to get things to work and they're trying to meet very very quick and tight deadlines so a lot of this may not be as secure as

you originally think so two more areas logging um so what logging and auditing is available to monitor for anomalous activity and what logging should be implemented um and is our logging pipeline set up in such a way that we can ingest the available logs so my intention with this point is um like i said in the last slide a lot of engineering teams if they had to scale really quickly or if they had to get things pushed into production really quickly they don't really prioritize adding in uh logging during in into like crucial interactions of a system so the thing you want to think through here is are we are we logging the um interactions that

we consider to be the riskiest in how a system is run and if your detection and response team is it you know aggregating all those logs into a sim or some other tool then can we ingest those logs in a way that enables us to build detections on it and one other point to say about logging before we go into the next one is sometimes logging doesn't even exist right so it's not as simple as okay that's something that we need to have engineering teams need to be able to prioritize this and you know maybe even add it into their backlog so that they can commit to generating logs so the fourth point is service to

service interaction um so how do other services interact with this one what type of customer information does it interact with and then um yeah does the service interact with customer data so service to service interaction means um what kind of uh downstream and upstream services is it exchanging data with and what kind of information is it sending to um to these other services maybe we want to detect when it sends a wrong kind of data point or if uh it allows for user intervention and users to manually push different kinds of data in can we detect that right so another important aspect of threat modeling is to take on different perspectives so imagine your red team like what would an

attacker look like in this environment what are some of the ways you can exploit it next is blue team what could we use to validate detection of specific adversarial techniques and the third point is insider threat so intentional or not uh what is possible given the amount of access that a user or service is given in this application so internal threat actors and different access points we want to make sure that a internal user that has the perm has permissions to interact with the system is also something that we're all logging and making sure that we can identify those malicious that malicious behavior uh so there's an attack navigator tool that the attack matrix framework has released and that is

to that is used to think through like different attacks in a system they have it for mac linux and windows but then they also recently released an attack defense matrix and it's used to identify detection techniques that could apply to your environment so they have different techniques that list out the different kinds of attack vectors or techniques that they map back to so it's kind of like a two different sides of one coin sort of thing that i think i found to be very useful when i've threat modeled in the past

so long-term benefits of threat modeling again you can track items flagged as risks so even if as a detection and response engineer you know it sometimes it takes a long time for something good to happen and a lot of the times you're relying on the system owners to enable our um our work right we may not be the subject matter experts on a system but as long as we are able to effectively track these items as risks we can work with the engineering teams in the long term to enable our objectives it's collaborative and iterative the goal isn't to uh threat model a system that one time and then forget about it ideally you're going back you know

as new features are added or crucial features are modified or when a new system is developed engineering teams know who to reach out to and they're familiar with working with your team and so this really is a process and culture driven thing as well so distributed approach to scaling threat modeling um it sounds like a fancy little phrase but it's really just um trying to describe the different teams that are involved in threat in a threat modeling session um so if you have different security teams that you want to include if you want to have different engineering teams included in it so it's not just a detection and response engineer's responsibility like you need to have you need to you know

help people feel uh like they have uh skin in the game when they're working on this start small and then expand um i if this is uh this is not the first time you're looking at a system or at least people have a general understanding of it um then you can pick on a specific part of the system and then just threat model that like maybe you just want to focus on authentication because i feel like authentication is one of those things that it sounds pretty simple when you when you think about it but there's a lot of different things that go into it like certificate handling the process of getting authentication the granular access like

permissions and who controls all of that so uh ideally start small and then expand the scope of the system that you're starting with in a collection of audit logs um no one really loves to work on i think uh certain things just for compliance so um you know i think this is a point um that would help the long-term objectives of detection and response and so once you have a system that you've identified that doesn't generate logs and you're able to work with engineering teams to actually implement it then that's a huge win in my opinion that you can build on in the years to come to make sure that you're enabling the dnr team

work with engineers to adopt better auditing i think i've spoken this point to death at this point but um yeah making sure that uh engineering teams um know that you know auditing is not just for uh debugging that there's benefits um to certain kinds of audit logging for detecting malicious behavior and then documentation uh this goes into you know engineers and you know when people leave the company things may not be documented as thoroughly as you'd like and then you have a new member coming in who may need to start from scratch uh and you know which isn't ideal because you've just lost all of the benefits of the months-long process of or work that

this previous person has done so um it's it's pretty important uh to make sure that you've documented your findings pretty um clearly all right stakeholder engagement so system owners that know the ins and outs and historical context like i said a lot of times teens have to scale up really quickly and then just get things out of the door um and so that knowledge could be concentrated in one or two you know one or two people that are at the company and not really document or share it anywhere so it's really important to build good relationships with them and make sure that they're involved in this threat modeling process as well because ultimately they're gonna they're going

to be able to influence the roadmap in case you need to have you need to have asks for the engineering teams application security um so this is from the perspective of detection and response you want application security and and the other security teams to be honest um involved in the threat modeling process because it's like i said a very like holistic approach um i just like ideally wouldn't just be product security or application security that's doing threat modeling it wouldn't just be dnr engineers as well and then partnering with engineering teams so obviously start small and then expand you don't want to just you know be heavy-handed with implementing a partnership program with engineering teams you want to make sure that

you've tested the process out with one or two teams and you you know identify what works and what doesn't work how people like to be engaged understand how the security org in your company um prioritizes tasks and think about the larger things that are happening at the company right like you need to be able to um it's a give and take you can't just expect them to prioritize our asks because we're a security team and obviously security is the most important thing i'm biased but yeah agreed upon timelines for any auditing implementation uh you know at cloudflare uh at least for us what's worked is if there's um business needs and external needs outside of the security team that

are also helping us ask for an implementation and auditing engineering teams are quicker to get to it but that's not always the case they have their own priorities their own quarterly goals and everything going on so make sure that you're able to negotiate a timeline for when they can implement it otherwise you know you can go quarters and quarters without really being able to really know what's going on in a system and it's just going to be like a black hole all right so uh we're in a remote world now pretty much so how do we prepare for a remote threat modeling create and send out diagrams and pre-meeting material what this could mean is

um but you can use the existing documentation existing information out there about a system to go and then read read the code that you know your company is implemented to run the system and try to create diagrams and a general understanding of your understanding of how the system works and make sure that it's available for everyone who's involved in this session the benefit of that is um one it leads to a general understanding of the system uh and then you also have done some proactive work and are not asking the engineering teams and the system owners to explain everything to you which is a the quickest way to you know get them to not really want to

do it again because who has that kind of time right and i think something else that helps when you have multiple teams involved is a general understanding of who should focus on what and this is more of a cultural thing and this is something that can vary between teams but if you want a certain team to focus on one aspect of the system and then you want another team to focus on another one it can really allow those engineers to die dive deeply into those topics as opposed to everyone working on everything and then slowly making progress in each of those pillars you can have specialized engineers working on uh very specific things but obviously this could vary depending on

the size of the team and the amount of like resources and time that you have to dedicate to this so define scope beforehand um ideally you would know if you're trying to do like a high level overview or if you're looking into a specific aspect of it there's no yeah this is speaks for itself and then again explain or share foundational knowledge um tribal knowledge and uh unintentional knowledge like hoarding basically can really lead to inefficiencies um in an organization so uh you know i would encourage you if you're the one that's leading the session to really make sure you you document and capture um what you've found in an effective way so that someone that's

reading your threat model document can almost pretty much be at the same place that you are uh after having spent x amount of time on it and that i think is a win well that's the end of my talk so thank you for joining um this is uh my email at cloudflare my linkedin is also attached there once the slides and recordings are out and there's a link to cloudflare jobs if anyone is interested in joining our team and i also want to say special thanks to four of my teammates that have helped me with this presentation