← All talks

What if we really assumed breach?

BSides Amsterdam · 201730:44182 viewsPublished 2017-09Watch on YouTube ↗
Speakers
Tags
Mentioned in this talk
About this talk
Every large organization that takes security seriously is supposedly doing it: “assume breach”. By working under the assumption that an attacker will at some point bypass your perimeter defenses, you approach IT security in a different way. You perform regular hunts, continuously improve detection, perform war games, etc. But are we really treating our security as we say we are? In this talk, I will show where most organizations fail to actually uphold the assumption of an impending compromise. By accepting limitations in scope, effort and data sources involved, security teams are often severely hampered in their efforts. How can we improve this by looking at real world incidents and learning from the challenges we face in incident response situations? By gaining visibility on your strong and weak areas, I will show that a lot more can be done than is often thought. Kevin is a senior manager within the Cyber Risk Services team of Deloite Risk Advisory, with over 8 years of experience in IT security. Before joining Deloitte in 2017, Kevin was responsible for Fox-IT’s forensics and incident response team. Prior to that he worked as a Forensics Expert and Incident Handler for Fox-IT and the Dutch Police. In this capacity he gained extensive experience in helping clients deal with serious cyberattacks and forensic investigations. Kevin holds a master's degree in forensic science from the University of Amsterdam and is a registered expert witness in the Netherlands
Show transcript [en]

good morning everybody again thanks for for having me here first one of the day and to ease you into today I'll start with a not very technical talk or not technical at all I guess titled what have we really assumed breach and of course I'll explain in a minute why I chose that title first maybe short introduction I'm Kevin I work for a Deloitte as a February of this year certainly a few months basically focusing on what we call security restoration so mainly helping clients who are dealing with you know the fallout of a large incident or series red team or pen test findings and trying to you know improve their security very quickly and in the first

couple of months and then also get them into a larger or usually larger transformation project prior to joining Deloitte I work for Fox IT for over seven years doing Incident Response of forensics so I basically saw a lot of clients in the worst state you could encounter them but it gives you a little a lot of very interesting insights into what could go wrong and and why it goes wrong as well which is what I've also worked into this talk a bit I guess so I'm going to talk about assume breach here today you're probably all familiar with with the the mantra of assume breach you know you basically assume that your prevention measures in terms

of IT security are not going to keep out attackers forever at some point they will fail attackers will bypass it and and enter your network your infrastructure and possibly caused all kinds of havoc so it's it's something that you've been hearing for or for years now in the security industry and something that you hear a lot of organizations claim that they're also doing so they say yeah we're following this this attitude of assume breach and and we worked it into our IT security and what they usually tell you is you know out of the Holy Trinity of prevent detect respond they're not only doing prevention anymore but they're moving a lot of effort into detection mainly and

also effective response to to any stuff day they detect or any breaches that could potentially occur so following this logic why am I here during this talk if everybody already knows what assume breaches and how you shoot you should handle if you want to follow that the train of thought it's because there's still a lot of stuff that goes wrong I think when organizations try to work under the assumption of a breach that could happen at any moment so I mainly focus this talk around the topic of detection and want to take you through some of the things first that I see usually go wrong in organizations and then of course also hopefully provide some sort of a solution a way of

thinking that could hopefully overcome a lot of these issues so first thing that you often see that goes wrong is the scope of a lot of the detection mechanisms in organizations so I mean any larger organization these days we'll probably have a seem insult and I'd have run it themselves or have some third party do it for them maybe they also have IDs or other clever stuff running in their infrastructure but what you often see is that these systems get set up and collect data just based on on best effort or what's easy to collect or what's easy to grab or whatever people are familiar with so you know any engineer will probably know about

Windows Event log so might be a logical thing to start collecting data from windows event locks and and build rules around that and see if you can detect any any anomalies or weird behavior in that data set but it's not necessarily what's the most useful part to to look at in your infrastructure so there's usually or there's often I should say no link between the actual business process and the type of data that gets collected and analyzed in these detection measures and then obviously you know just like these binoculars she can only move them around within certain limits but around there there's all kinds of other stuff that you might not be seeing and it's

it's basically an analogy for for what a lot of detection measures do within organizations another thing that you see is that and and this is awfully obviously a very hot topic right now in InfoSec is it's you know having as much as possible being performed by machines so obviously we know the basic detection stuff where you build rules and use cases and and use it to detect anomalies in in traffic or in logs and whatever there's also big rise in in all kinds of AI technology climbing to basically do more than humans ever could I'm not I'm not expert on the subject I should say that but until it's it's really proven technology I think the the human factor

in detection is really important so what you see happen a lot is that detection measures are put in place and every once in a while maybe somebody adds some new rules to D the rule base and and you know ensures that some new things are being picked up but it's not an active feedback loop where there's also analysts on a regular basis you know going out doing manual threat hunts and and trying to find that stuff based on just their human expertise and a human knowledge and also their knowledge mainly of what drives the business and how the business works and what kind of applications and system support that those processes so I think the feedback

loop between threat hunting which usually results in in what you could call good hunts useful stuff that you find while doing the hunting that should be converted into new use cases for your detection mechanism right but that doesn't happen a lot especially with organizations having third parties doing the the security monitoring for them you see that this is is often lacking and it means that you're you're not improving as fast as you could I think third thing that you you often see is what I would call monitoring in in a hostile environment and it's not like the blue team you know I guess arrest each day physically or whatever but it's more like the infrastructure is maybe not ready or

suitable for a very advanced detection and this could be caused by a number of reasons for example a very flat and and unsegmented network so that there's a lot of stuff going on in the same central place so it's hard to to figure out what's what or what belongs to what or what correlates to other traffic unstructured networks where all kinds of different protocols and traffic are crossing each other over over the same physical lines maybe so it's really hard to do decent detection if you don't have a good overview of what flows where we also see especially where you just deploy for example IDs technology within clients that there's still a lot of what

we call low-hanging fruit in the network so very easy basic stuff that you know botnet malware or something like that that should already have been picked up long ago and removed but it's still there and obviously if there's a lot of noise like that you're it's really hard to look beyond that into traces of really more advanced attacks that you're probably looking for and the final example that I'd like to to mention here is that in a lot of cases everybody except the detection should happen but there's no real response readiness so whenever a real alert or possible you know traces of an attacker found doing the actual response might be really hard so just last week I was at a client

where a guy in their blue team spent one and a half days trying to figure out what physical device was using a specific IP address that did some weird stuff that they saw under seem well you can imagine that I didn't that was one and a half days the attacker might have moved over to all of all kinds of other places and so it was really hard to figure out where it was and then the next issue he had was that once he informed the systems administrator that was basically the owner of the device as well that guy just wiped the device and reinstalled it removing any traces of you know data that could possibly be investigated further so

thinking about detection you also need to be ready to respond actually and and not just think when I find it out I'll just see what happens next another thing that that that might be not as obvious when you you think about assume breach is the impact factor so I you know we usually approach risk with you know the formula of the chance that something happens times the impact if it happens and you see that that that impact factor is not always considered I still think it's it's a really important part of the zoom breach because if you assume that attackers might bypass your prevention measures it's only logical to also assume that at some point they

might even pass by your detection measures and and go by undetected and so in that case it's also important to think about what can I do to limit impact or at least you know to slow down an attacker make sure that he has to jump through a lot of Hoops before he gets where he wants to be and again this should usually be really business driven and I think we all know the idea of focusing on crown jewels your most important assets and and and data and systems in the infrastructure and trying to think about how you can protect those a bit more but I think it goes a few layers beyond that and you should really

see the entire chain maybe from you know phishing an employee and getting access to his laptop all the way to these crown jewels and see where you can you can improve and if you think about and actually work on on trying to prevent a serious impact from a breach that will also usually help you improve your detection again because it will take an attacker more time and to actually get where he wants to so again that leaves you more room for for detection usually I think one final thing and then I want to move more to a positive side like how can we wiki who could we approach this and remediate this is what can we learn

from real actual real life incidents and as I said I've been doing it for over seven years and and you see a lot of weird stuff happening obviously especially a couple of years ago you still saw a lot of organizations who didn't have the assume breach mindset at all they were just surprised that an attacker got in even though they had this expensive firewall and antivirus etc but if you if you look more closely at the incidence there's there are some things that I think are also applicable to just day-to-day Blue Team operations and I think one of the the important things I learned is that for example if you have a especially of you more

advanced attackers think the really good criminals or even nation-states that might be in your network you might need to observe before you really act so and what I mean by that is is you might not want to kick out the attackers at the first opportunity you have at the first anomaly you you spot but you might want to wade out a bit and and see what they're heading for see what they're doing see what kind of or what areas of the infrastructure they've already infiltrated or or entered so did you get a better understanding of what they're working on and and and where they're at because I've actually seen some organizations who just you know kick

them out at the first opportunity and and usually that's what the business side wants right so that's that's always an interesting discussion but you should be ready for that as a blue team I think and if you kick them out they might you know still be in other parts of the network that you you haven't really covered because they're using different software more were there to now keep a presence stuff like that so waiting it out and and finding the right time to start remediating and cleaning up that's an important aspect that you also need to take into account with just you know regular regular detection and another thing I see is that a lot of

organizations jump into doing more detection and they want to start out with the most advanced complex stuff that they can can buy or can get which is really not usually the best thing to do I mean attackers are probably lazy as well just economics right if you can get somewhere easy why try and use do it the complex way so most incidents are not a chain of seven zero days that nobody knows about and are used in insanely advanced ways now it's usually just three very simple stuff that everybody could have come up with but just happen to be you know unlucky chain of events you could say that led to a full compromise and that's something to take

into account when doing detection because that means that you also should make sure that you first have you know that the basic stuff under control before you start looking for way more advanced topics and I'll get back to that in a second as well I think another one but it's it's to be honest I'm I'm on the fence myself whether this is really something we should do as a blue team in day-to-day operations but again the more advanced attackers will probably be interested in what the blue team has to say amongst themselves like what are they focusing their detection on there their actions right now what are you looking for what are they developing so I mean it's no surprise

that attackers will probably be interested in communications in a company but they might also be interested in what the defenders are doing and trying to do so in in larger incidence it's not uncommon to set up separate communication channels for the blue team and maybe external parties to talking to etc but I think depending on your or your threat profile and and and what kind of actress you might be up against it might be sensible to think about what do you need to use safeguards like that separate channels as a default maybe and I mean it's not a lot of work to do it's something you need to think about so as you can see there's a lot of stuff

that can go wrong but how do you how do you fix that actually I think it's it's not very hard per se but it requires kind of a different mindset and you need to be able to step out from only looking at the technical side of things and make sure that you also look at the business and the process side of things and how your organization actually works and maybe to give an example what you would you often see we all know this one right the kill chain there's there's numerous variants of it but I tend to see the Lockheed Martin one a lot when I talk to clients where they've defined all these steps and you know that the path of an

attack basically but what bothers me about this one if you use it to model your defenses against it is that you know first of all if you put it more like in a kind of a time relative skill these three steps delivery exploitation installation Dibley usually pretty close together and might only take minutes right and then after that comes a very long time where a lot could happen and if you look at it honestly I think these steps there's some stuff you might detect but in all honesty there's way more room for detection in in the steps after that but with a lot of models that's that's not really divided into very clear clear steps and so if you're

going to model your detection on this it's going to be quite messy because you're gonna say well to detect command and control I can do those 50 things for example but it's it's it's messy so I'm a big fan of using a model like this The MITRE wanna attack but it basically only started exploitation so everything before that is is not covered or a relative irrelevant for this model but it's a very useful model for for detection and response in my view because they take these ten categories off of stuff that attackers can do and mind you these are not necessarily in the order that an attacker will do this could be switched around but what this provides you with is a lot

more it gives you the capability from a technical side at least to provide more detail on the areas where your detection is good or where it's bad or you know where you're already top-notch because what mitre also does and and obviously you can you can modify this or use it in your own way but mitre has an entire wiki behind this where they say okay for lateral movement we've seen these I don't know 50 techniques that were used in and per technique they list the campaign so it could be you know a PT 28 or whatever and they say that's where it was used it involves this technique they even say what known detection techniques

are possible and for some it's also known well it's it's really harder and almost impossible to detect and based on that you can this is another tool that mitre provides open-source tool the carrots and and so at the top here you see does ten categories and then below that I'm not sure if you can read it but it's all the techniques so for let's say persistence they list the number of stuff things that they know happen in the wild like setting up scheduled tasks to achieve persistence you see some colors here as well so this is just an example where red means we're not covering that with our current detection or even prevention measures and yellow

means yeah we're probably covering some of that and it could even be green squares where you're pretty sure that you're covering almost any attempt of using such a technique now looking at this you're probably wondering this is still very technical how does it help me involve the business side of things well what you should should add to this layer basically is you know what I'd call a scenario analysis or more in-depth analysis of what the business processes are that are critical for an organization and below that you can usually put like the systems and applications that support those processes and when you do that you can also start think about what are the attack paths that an

attacker could use to you know get into those business processes and achieve some kind of goal which means you also need to know which actors you're up against you know which actors are interested in those attack bats and and you know what level of sophistication they might have and how they would work in in achieving those attack paths but if you have the attack bats that's where this basically comes in because that's where you can think of okay so I've got this Windows machine here that's critical to this process so if it's interesting to an attacker you probably want to achieve persistence so what kind of Windows persistence techniques do I know am i covering them in my detection

on this specific system or not and if I'm missing some stuff that I think is pretty vital let's see if we can work to where it's remediating that I'm adding maybe data collection and and detection on that specific specific system on the relevant log files so I think that's a really key part of of improving and and what really what's really nice about such an overview of course such a major matrix is that you can basically see what your current status what kind of stuff are you detecting and you can also show improvement over time of course so you know hopefully more red squares will turn yellow and then perhaps even turn turn green so I think this is this is

vital to focusing your your detection and response operations and and for some things you could even add a little bit more prevention but let's focus on the detection side and based on that you can ensure that you're you know coming back to the scope slide that I had at the beginning you can ensure that you're looking at the right scope and it might be a much smaller scope then you're maybe looking at right now but it could be a much more useful scope than the larger one you're dealing with and this obviously also helps in you know staffing issues and and bring down a number of alerts that you get and have to analyze because you're much more

focused on what's really important for for the organization now there's one final issue that that you often see even if you do all of this right is that you actually need real attacks to determine whether it all works right so if you're one of the lucky ones who maybe doesn't get a text for over a year how does the blue team know that they're doing the right things and actually detecting stuff well the answer is easy right you simulate the attack so I think we all know and and and all are aware that red teaming is an important part of building your appear defenses but what you see a lot of practice is that the red team only does

what what the red team mainly wants to do is is usually break stuff and you know get in and and show that they've achieved all the the objectives and then you know provide a list of how do you attack when what path they chose what what tools and methods they used and and say blue team here you go good luck fixing it and it's usually not a very constructive way of dealing with it of course and so I'm a big proponent of what a lot of people call purple teaming so bringing the red and blue team together maybe even during the red team already so have specific points in time where you do a debrief of the blue

team and already tell them maybe how far you got so that they can you know readjust some of their detection measures focus again on on whether a team might be so that you prevent that the red team spent six weeks on an attack with the blue team being completely in the dark I mean that's not useful to anyone except for the confidence level of the red team probably so you want to make sure that the blue team also has got work on their hands and and also becomes very aware of the stuff they're still missing and and you know basically you want to verify that this matrix is actually in the state that it that you think it is so it

could also help it purple teaming to select specific techniques or detection areas that you want to test and make sure that the red team specifically targets those and does a good debrief of the blue team in to help them again improve the detection and you know if he you're really going to the more mature levels of doing this this could be like a feedback loop that you go through several times where after debriefing the blue team you might want to try the attack again because they've improved their detection and see if you can still pass by some points of the defense and then again do the debrief so you know it becomes kind of an arm race arms race of

a second defense we try to constantly improve each other and it's usually a way more healthy situation for red and blue team to be in because they can more actively learn from each other right so I've come to the end of my my talk here some some key takeaways as I said to really assume breach so to really live under this this assumption is to know what kind of patch your attackers are likely to take and and you you take that from looking at the business side of things I think you should focus on on defending those paths first adding prevention and detection on those specific paths that are critical to the business and and you better do

these right and and just ignore the others for now then you know do an entire infrastructure how heartedly or without a lot of success then it's also important to you know test measure adjust whatever you're doing preferably through purple teaming I'd say because no one gets it right straight away obviously you will always you know cover some stuff using default rules and basic stuff you can come up with yourself but the human creativity is is you know it knows no limits I guess so there's always ways finding ways around the defenses and you really need to to prove that and test that to really get your defenses to the next level and I think a

key point in that until you know AI basically rules the world is that you need humans to do so and with that I'd like to end my talk any questions does it work yeah okay perfect so you mentioned about the advance attackers that maybe it's a good idea to let them go into your network a bit and then do things about it but how do you convince like the c-level executives to allow something like this because it's it's a risk also because you don't know it's an advanced attacker until you've actually looked into it so how do you deal with that yeah it's it's a bit of a catch-22 I agree so usually you have F some some concrete leads or

yeah well if you only have an inkling that it could be an advanced attacker I agree this discussion will be very hard and and even I might suggest well let's just get rid of it but if you have some leads that it is advanced maybe because it's new malware you found that you know isn't on virustotal yet could be could be interestingly you know stuff like that and then so I've been in discussions like that a few times I've not always won them but the times I did I think it was very important to explain what could be the consequences of remediating right now which is that the attacker might still be in a network but you have no

visibility at all on them anymore and it also depends of course on the type of impact that you're experiencing or likely to experience in the near future so especially with nation-states if it's you know espionage or something like that also depending on the organization of course it might be not that terrible began and you know because sometimes they might be in there for months or years already so you know the worst damage has already been done and it's just just stealing information not bringing down your infrastructure or whatever so in those cases I think you you do have a good opportunity to convince them that you might want to watch them a bit more before you kick them out to ensure that

she can do an effective as effective remediation as possible hi I was just wondering if you work got a bit busier after the latest Shadow Broker the releases and all these advanced malware and stuff a bit busier in what way in cleaning up stuff and helping clients with not a good did not do a good patching job and stuff so yeah I think in general we get busier like every every quarter almost which is not necessarily get to do with developments like that but just also general awareness of the security you will have to be approached more seriously what you usually see when when stuff like that breaks and and gets in the news is that

there's a number of clients who get you know do some phone calls to us and want to get a bit of more info like how relevant is this to us and and you know how serious is this should I take this strap but I think overall you know the biggest bumps in in busyness are when stuff like wanna cry or non pity I you know stuff like that happens of course because that's when there's actual impact and I think when there's just the threat of potential future impact it's suddenly for the mature clients more mature clients who worry about that and others just think I don't know what it means it's probably not relevant to

me okay so I think we need to move on to the next question Thanks thanks guy thank you [Applause]