[00:00.000 --> 00:04.600]  Welcome back. And thank you, Tim. Thank you for supporting DEF CON. Thank you for supporting the
[00:04.600 --> 00:10.840]  Red Team Village. The floor is yours. Take it away. Hi, folks. Good morning, good afternoon,
[00:10.840 --> 00:15.640]  good evening, wherever you are in the world. Welcome to my session, All of the Threats,
[00:15.640 --> 00:19.320]  Intelligence, Modeling, Simulation, and Hunting through an Attacker's Lens.
[00:20.860 --> 00:25.300]  So just to put a little bit of background behind this at a very high level,
[00:25.300 --> 00:29.980]  ATT&CK rocks. But what happens when ATT&CK doesn't give you the information you need?
[00:32.140 --> 00:39.760]  So introduction. TLDR, who I am, what the plan for this presentation actually looks like.
[00:40.240 --> 00:48.200]  So I'm not a data scientist. I'm not aligned to either blue or red. I do various activities on
[00:48.200 --> 00:54.060]  both sides of the fence. And I fully acknowledge that this isn't a solved problem. This is my stab
[00:54.060 --> 01:01.140]  in the dark trying to get somewhere with it. So who I am. So I work at Cisco. I've done various
[01:01.140 --> 01:07.440]  roles. I've done assessment work. I've done threat intelligence. I occasionally help out
[01:07.440 --> 01:11.840]  with incident response when we get weird situations. And indeed, I've also done my
[01:11.840 --> 01:21.000]  fair share of spreadsheet filling as an auditor. I am a technical person. I like bugs. I like Unix
[01:21.000 --> 01:25.320]  in particular. And I like exploiting stuff. Probably the most recent stuff you can go and
[01:25.320 --> 01:32.880]  find is Mimikatz and Unix. What happens in an active directory on a Unix estate. So the plan
[01:32.880 --> 01:36.300]  for this presentation, I'm going to give you a little bit of background. I'm not presuming that
[01:36.300 --> 01:40.280]  everybody knows the difference between threat intelligence, threat hunting, threat simulation,
[01:40.280 --> 01:47.260]  etc. I'm going to talk a little bit about building bespoke threat models. I'm going to talk about
[01:47.260 --> 01:53.660]  how we can use data we already have. I'm going to talk about how that translates into the real
[01:53.660 --> 01:56.840]  world. I'm going to look at some of the stuff that we do from an offensive standpoint and how that
[01:56.840 --> 02:03.200]  maps into things like attack. I'm going to talk about how we can be using this kind of information
[02:03.200 --> 02:06.260]  to improve our threat models. And hopefully I'm going to finish up some recommendations and
[02:06.260 --> 02:11.980]  conclusions and it'll all make sense and you'll go in and everything will be great. So background.
[02:13.200 --> 02:17.620]  The concept was we need to bring all of these different disciplines together. We have people
[02:17.620 --> 02:20.760]  that do threat intelligence, we have people that do threat modeling, we have people that do simulation,
[02:20.760 --> 02:25.700]  we have people that do hunting. And attack gives us a common language for all of those things.
[02:25.780 --> 02:31.480]  But does it go far enough and does it help us with, I guess, the business system? So that's
[02:31.480 --> 02:37.480]  kind of where we are. So as I said, bring the five disciplines together. Most of the people
[02:37.480 --> 02:44.960]  guessing on this will be involved in at least one of these. Maybe you're doing recovery work
[02:44.960 --> 02:48.760]  when breaches happen. Maybe you're doing detective work, you're sitting in a sock.
[02:48.960 --> 02:52.820]  Maybe you're the person that's meant to be responsible for keeping everything safe.
[02:53.420 --> 03:00.440]  You know, we're all in this together, right? So an ideal approach. Ideally, we'd all have a good
[03:00.440 --> 03:06.140]  understanding of targeting hypotheses and how we validate. You know, we'd understand actors,
[03:06.140 --> 03:13.400]  TTPs, assets. We'd be able to draw out hypotheses about how actors get into networks, what they do
[03:13.400 --> 03:18.640]  once they're in networks, and what they're looking for in terms of actions on targets,
[03:18.640 --> 03:23.900]  what they're looking to get away with. And hopefully, we'd have a common way to talk
[03:23.900 --> 03:29.000]  about that from a validation standpoint, either in terms of posture or telemetry,
[03:29.000 --> 03:32.580]  or indeed any of the other mechanisms that may or may not exist.
[03:33.320 --> 03:39.120]  So threat intelligence. That's all about identification, understanding emerging TTPs,
[03:39.120 --> 03:44.840]  understanding what malicious behavior looks like, collecting and enriching that, and providing
[03:45.660 --> 03:51.680]  situational awareness to your organization, to those people that you work with.
[03:52.160 --> 03:57.960]  Threat modeling. The mission there, I guess, is to describe the assets. So take that information
[03:57.960 --> 04:04.840]  that threat intelligence gives you, augment it, build kill chains, map attack surfaces,
[04:05.120 --> 04:11.580]  talk about vulnerabilities and weaknesses and how they inform that threat model,
[04:11.580 --> 04:16.380]  understand the motivation, understand the impacts of attacks.
[04:17.180 --> 04:21.860]  Simulators. Yeah, there's various different classes within that. You've got simulation,
[04:21.860 --> 04:25.500]  you've got emulation, you've got traditional penetration testing. But essentially,
[04:25.500 --> 04:29.020]  that's looking to take that information about what the threat model looks like,
[04:29.020 --> 04:35.100]  that information about what threat actors are out there, and recreate it so that your blue team,
[04:35.100 --> 04:42.080]  your defenders can understand, can test their telemetry, can test that they can pick it up,
[04:42.080 --> 04:48.120]  and hopefully so they can improve either the identification or the automation,
[04:48.120 --> 04:54.940]  the response to those threats. Hunting. That's, I guess, the final part of the jigsaw from my
[04:54.940 --> 05:02.740]  perspective. That's about understanding how threat intelligence, how threat models,
[05:02.740 --> 05:08.220]  what they look like on the ground. When an attacker has got in, what are they doing?
[05:08.220 --> 05:12.400]  What does it look like? And how can you go and find them and hopefully kick them out?
[05:12.400 --> 05:16.220]  So it's about understanding posture, it's about understanding telemetry,
[05:16.220 --> 05:21.300]  it's about reading that information, identifying where attackers are actually active,
[05:21.300 --> 05:28.320]  taking steps to remediate that problem. So that's kind of a high-level view of the people
[05:28.320 --> 05:36.020]  I'm talking to. What of it? What should we be doing? I talked about the fact attack is great.
[05:36.300 --> 05:40.700]  It's really good if you're talking about heterogeneous Windows networks, active directory,
[05:42.260 --> 05:49.700]  phishing through to crypto mining, phishing through to crypto lock-in. The traditional
[05:49.700 --> 05:54.160]  stuff that everybody worries about on their Windows desktops. But where it doesn't, in my
[05:54.160 --> 05:59.240]  opinion, particularly help is when you step beyond that. Most businesses, well, they actually have
[05:59.240 --> 06:05.040]  data, they have applications that essentially drive their business. And that's the purpose of
[06:05.040 --> 06:10.240]  this talk, is to look at how we take attack and leverage in those kinds of situations.
[06:11.520 --> 06:17.940]  So building bespoke threat models. I'm going to go through what I think requirements look like,
[06:17.940 --> 06:23.460]  what I think the workflow looks like. Some ideas about how to use a workflow effectively.
[06:24.760 --> 06:32.020]  How you can apply hypotheses. Some of the use cases that maybe we don't really tackle today,
[06:32.020 --> 06:39.640]  but perhaps we ought to. Some of the capability gaps that certainly exist. And why in my head,
[06:39.640 --> 06:45.420]  and this is just my head, I think threat intelligence collection is really just a backstop.
[06:45.420 --> 06:51.080]  There are far more useful sets of information about our platforms, about our assets, about
[06:51.080 --> 06:56.180]  our data, about our users, that should give us a far better understanding of where threats are
[06:56.180 --> 07:03.340]  likely to raise their heads. So in terms of requirements, broadly speaking, we need to
[07:03.340 --> 07:10.420]  define a mission. And I will say the value of any system, well, that's the data. Secondly,
[07:10.420 --> 07:16.080]  we need to have an understanding of what threat looks like from one perspective or another.
[07:16.920 --> 07:21.460]  In terms of building hypotheses, well, we need to understand what the organization actually cares
[07:21.460 --> 07:26.900]  about. And we probably need access to the design. It's very difficult to build threat models
[07:27.460 --> 07:31.520]  purely based on attack once you step into business systems, because you're
[07:32.100 --> 07:39.040]  really not matching like for like. A Windows desktop, the users, the use cases,
[07:39.040 --> 07:43.620]  are significantly different from, you know, an enterprise resource planning system,
[07:44.820 --> 07:49.320]  a data warehouse. So we need to understand what the designs look like, you know,
[07:49.320 --> 07:53.260]  three-tier architectures, are they using containers, are they using microservices,
[07:53.260 --> 07:58.640]  that kind of thing. And then from a validation standpoint, one way or another, we need some
[07:58.640 --> 08:04.180]  visibility of those targets. From an intelligence standpoint, I guess, third-party sourced evidence
[08:04.180 --> 08:07.960]  is kind of useful. If you're talking about simulation, well, you need to be in a position
[08:07.960 --> 08:13.100]  to go and actually test the systems that you're talking about. From a hunting standpoint,
[08:13.100 --> 08:19.760]  you need configuration, you need access to the logs. Ideally, you'd need dynamic telemetry,
[08:19.760 --> 08:25.080]  that is to say, telemetry that's feeding back in real time. But at the very least,
[08:25.080 --> 08:31.320]  the ability to see the events, the log events that are occurring in SAP, in a database environment,
[08:31.780 --> 08:39.780]  is pretty key to getting this right. So in terms of workflow, from my perspective,
[08:39.780 --> 08:46.260]  I've sat in all those different nodes at one stage or another. I sat there and looked at TTPs.
[08:46.320 --> 08:53.120]  I've gone and tried to simulate vulnerabilities and weaknesses to exercise attack surfaces.
[08:53.980 --> 09:00.800]  I've considered the impact from a governance standpoint. And in all and amongst that,
[09:00.800 --> 09:05.940]  you've got to understand the motivation. But hopefully, no matter what part of the security
[09:05.940 --> 09:10.580]  lifecycle you live in, you'll map into one of those areas fairly cleanly.
[09:11.680 --> 09:17.560]  And then, of course, the challenge is to hand off to the next node. And indeed, in practice,
[09:17.960 --> 09:23.780]  there's nothing to stop you handing across in other ways. Understanding impact, well,
[09:23.780 --> 09:28.260]  that feeds vulnerabilities and weaknesses. Understanding motivation, well, that might
[09:28.260 --> 09:35.000]  actually tell you something about TTPs. So iterating effectively through it.
[09:36.440 --> 09:40.660]  Understanding a platform. I talked about the fact attack is great. But if you understand
[09:41.220 --> 09:46.460]  the platform, maybe you can take attack on its own and filter out those TTPs that you're most
[09:46.460 --> 09:52.680]  interested in. Some of the work I've been doing recently has been around, for example,
[09:52.680 --> 10:00.960]  taking attack and extracting verticals, extracting regional differences,
[10:01.900 --> 10:08.560]  extracting particular vulnerability classes. In terms of threat modeling in a practical sense,
[10:08.560 --> 10:11.820]  you've got to be able to go and speak to the people, you've got to understand the roles,
[10:11.820 --> 10:17.680]  you've got to understand the processes. Tooling wise, there is nothing better than pen and paper
[10:17.680 --> 10:23.400]  or a whiteboard. But if you want to record your information, Microsoft Threat Modeling Tool,
[10:23.400 --> 10:28.820]  others of its, ILK, Visio and Excel, well, they can all help. And then fundamentally,
[10:30.060 --> 10:34.760]  producing a worksheet. And it doesn't really matter if that worksheet is built from the
[10:34.760 --> 10:41.120]  perspective of an adversary, a red team, whether it's built from the perspective of a threat
[10:41.120 --> 10:45.240]  intelligence person, whether it's built from the perspective of a threat hunter.
[10:45.240 --> 10:50.680]  Once you have that worksheet, actually, you can pivot those questions to answer whichever
[10:50.680 --> 10:59.850]  question you're actually asked. So applying hypothesis to real world platforms and applications.
[11:01.030 --> 11:07.530]  First of all, at a very high level, familiarizing yourself with ATT&CK. It is still useful,
[11:07.530 --> 11:10.650]  and you'll see this a little bit later in some of the data I draw out.
[11:11.650 --> 11:17.050]  Mapping out those ATT&CK surfaces, you might recognize the four I've iterated through.
[11:17.050 --> 11:23.870]  They're actually straight out of CVSS. It's a starting point. Vulnerabilities and weaknesses.
[11:24.730 --> 11:32.350]  ATT&CK TTPs are great, but actually CAPH, CWE, perhaps give you value that you're not necessarily
[11:32.350 --> 11:37.810]  recognizing today. If you're fortunate enough to have good threat intelligence, understanding
[11:37.810 --> 11:43.630]  motivation, understanding threat groups. If you're fortunate enough to have access to business data,
[11:43.630 --> 11:49.990]  understanding system value. And then, of course, impact. It's a pretty lazy way to do it,
[11:49.990 --> 11:54.530]  but stride still helps in that regard. Fundamentally, attackers are still spoofing,
[11:54.530 --> 12:03.180]  tampering, causing information to be disclosed, etc. So use cases.
[12:04.500 --> 12:11.120]  In an enterprise, fundamentally, ATT&CK gets used for manual design verification.
[12:11.500 --> 12:16.780]  It gets used for sourcing IOCs. It gets used for telemetry configuration.
[12:17.660 --> 12:22.180]  And it gets used for response prioritization. There will be other use cases and there will
[12:22.180 --> 12:27.600]  be sub-use cases to each of these. But fundamentally, the threat model
[12:28.160 --> 12:33.840]  concept is about understanding a design. It's about understanding what's likely to be attacking
[12:33.840 --> 12:39.400]  it. It's about making sure you've got the right security controls. And these days with consider
[12:39.400 --> 12:47.700]  breach, telemetry is a key aspect. And it's about being able to respond when breaches occur, because
[12:47.700 --> 12:59.270]  again, consider breach. So capability gaps. I've been into a fair few SOCs, either working in them
[12:59.270 --> 13:04.970]  or talking to them, evaluating their current capabilities. And that's what one's a pretty
[13:04.970 --> 13:12.630]  key one in my mind. SOCs are great at dealing with enterprise. Most people these days are
[13:12.630 --> 13:19.350]  familiar with ATT&CK. They do understand enterprise risks. But actually, once you start to grow them
[13:19.350 --> 13:24.830]  beyond that, and start to ask them about their SAP infrastructure, their banking enterprise
[13:24.830 --> 13:33.590]  applications, their data warehouses, we're kind of blind to a degree. And I think that's probably one
[13:33.590 --> 13:38.470]  of those things that we need to tackle. And I hope that some of what I'm talking today about
[13:39.080 --> 13:44.170]  is about informing how we can tackle some of this. We're clearly not going to teach every
[13:44.170 --> 13:50.150]  SOC analyst every application that a business cares about. So making better use of the knowledge
[13:50.150 --> 13:58.550]  they have, giving them the tools to translate generic enterprise risks into key business risks,
[13:58.550 --> 14:07.710]  that's pretty critical. Collection and routing, logs, audit events, telemetry. I guess depending
[14:07.710 --> 14:13.710]  on where you work, who you work for, you might say, we're pretty good at this. You might say,
[14:13.710 --> 14:18.110]  I'm not quite so sure. You might even just put your hand up and say, no, we're terrible.
[14:18.770 --> 14:23.850]  I think every incident response engagement I've turned up to over the last five years
[14:25.690 --> 14:31.550]  hasn't had as much information as we would require to evaluate the system. And if you talk about
[14:31.550 --> 14:37.810]  enterprise, that's a really good example. We did a response engagement recently, where it turned
[14:37.810 --> 14:42.410]  out that actually it was a message queue that was being tampered with. And guess what? Their message
[14:42.410 --> 14:48.570]  queue had no useful logs at all. Nothing that told you that much about who was accessing the
[14:48.570 --> 14:54.410]  message queue, where they were accessing it from. And indeed, when we eventually managed to find the
[14:54.410 --> 14:59.770]  application logs, the development data essentially about how the message queue was functioning,
[14:59.770 --> 15:05.430]  and we found that it was logging the messages, we were so excited. But even with that information,
[15:05.430 --> 15:10.550]  trying to take that back to a SOC and say, actually, which of these are the legitimate events?
[15:10.550 --> 15:15.010]  Which of these are? It was a challenge, because the security organization just didn't understand
[15:15.010 --> 15:25.490]  that. Orchestration and enrichment. Key to those two previous points is getting SOCs to a point
[15:25.490 --> 15:33.070]  where they know what data is useful, and they know how to use it. It's easier to do with Windows,
[15:33.070 --> 15:38.850]  it's easier to do with endpoint devices. But actually, if you want to kick someone out of
[15:38.850 --> 15:45.630]  to go back to that point, a message bus, where do you start? What data is useful? We had to tell them
[15:45.630 --> 15:52.510]  every step of the way, because they simply didn't know. And then, of course, you look at things like
[15:53.470 --> 15:59.630]  the... what is bad? What does bad look like in an enterprise resource planning application
[15:59.630 --> 16:06.650]  in a Unix estate for microservices? So those capability gaps, we need to start to fill them.
[16:09.010 --> 16:14.290]  But all of that data exists, which is kind of why I argue that threat intelligence really
[16:14.290 --> 16:19.590]  should be a backstop. If we're not consuming the data that the organization is already generating
[16:19.590 --> 16:23.910]  in one form or another and using it effectively, we're going to be forced to use threat intelligence
[16:23.910 --> 16:34.170]  as our only means to identify threat actors, identify attacks. But in terms of threat intelligence,
[16:34.170 --> 16:40.510]  even there, we could be using it more effectively, right? We know the vulnerabilities exist, for
[16:40.510 --> 16:46.390]  example, yet we don't necessarily use that in an effective way from a threat intelligence standpoint.
[16:47.190 --> 16:51.930]  We don't use it in a predictive fashion as much as we might like.
[16:52.650 --> 16:56.690]  We certainly don't construct the same degree of hypotheses around
[16:57.790 --> 17:06.410]  application vulnerabilities as we do around password cracking, phishing, etc. We need to
[17:06.410 --> 17:12.770]  get better at putting together hypotheses, straw men, that we can start to buy off in pieces.
[17:13.050 --> 17:19.310]  And ultimately, from a threat intelligence standpoint, we need to get better at tracking
[17:19.310 --> 17:25.310]  that kind of threat intelligence in just the same way that we track TTPs for enterprise threats.
[17:26.290 --> 17:32.530]  A SAP system will still have that kind of information. We should still be able to work
[17:32.530 --> 17:38.650]  out the validity of the information. We should still be able to understand where it might affect
[17:38.650 --> 17:42.870]  us as an organization. We should still be able to understand why an attacker might wish to do it.
[17:43.030 --> 17:48.330]  And we need to start to ask threat intelligence teams to give us that information so that we can
[17:48.330 --> 17:54.930]  make the right decisions. So that's some of the problems. Let's have perhaps a little bit of a
[17:54.930 --> 18:01.230]  solutions. And here, what I was really looking to do was to map some of the more traditional
[18:01.230 --> 18:08.410]  concepts of threat modeling, Stride, Microsoft's tooling, and equivalent into attack language,
[18:08.410 --> 18:16.110]  into kill chains, into the attack matrix. So working in Cisco, I have a pretty good
[18:16.890 --> 18:20.950]  source of information about all of the assessment work that we do.
[18:21.510 --> 18:26.450]  The vulnerabilities, the weaknesses. I have the ability to extend that tooling.
[18:26.570 --> 18:30.970]  So I kind of wanted to say, well, actually, if we've got vulnerability data from an assessment,
[18:30.970 --> 18:35.770]  how do we translate that into a threat model that a SOC can use?
[18:35.770 --> 18:40.470]  So I want to label our findings. I want to start to analyze our data a bit more depth.
[18:41.690 --> 18:46.790]  So that's our vulnerability model, fundamentally. We take all of the things you would find in a
[18:46.790 --> 18:54.230]  pen test, the idea of scoring criticality, defining the weakness in generic terms,
[18:54.230 --> 18:58.350]  describing the vulnerability, describing the impact, talking about recommendations,
[18:58.930 --> 19:07.350]  industry references, etc. But on top of that, we have our not inconsequential VDB. It's internal,
[19:07.350 --> 19:11.310]  but it imports from Nessus, from MITRE, and from other sources. And our reporting engine
[19:11.310 --> 19:16.770]  is really driven off that. So when we report a finding, if it's a finding we've seen before,
[19:16.790 --> 19:23.010]  it will come from our VDB. If it's a new finding, it will end up in our VDB. So we have quite a
[19:23.010 --> 19:30.010]  rich historical view. I won't say it goes back 20 years. We have to clear down a lot of customer
[19:30.010 --> 19:36.590]  data, as you can imagine. But certainly in terms of the VDB portion, we have an understanding about
[19:36.590 --> 19:41.230]  how vulnerability trends have changed over time. And we should be able to leverage that to build
[19:41.230 --> 19:49.590]  more interesting analysis. So what have we been doing? So we've been automating some of our
[19:49.590 --> 19:57.110]  scenario generation. We've been taking ATT&CK using PyTAC, which is a Python framework,
[19:57.110 --> 20:03.990]  to start to filter the STIX output from the ATT&CK matrix. We've been starting to look at
[20:03.990 --> 20:10.010]  how we label vulnerabilities in our VDB, vulnerabilities in our customer reports,
[20:10.010 --> 20:15.390]  with ATT&CK TTP, so that we can say, we found this vulnerability on a traditional pen test,
[20:15.390 --> 20:20.250]  but actually it maps here into your kill chain. And these are the kinds of controls you're likely
[20:20.250 --> 20:26.990]  to need. Not just the tactical fixes of yet you should go and patch, or yet you should go and
[20:26.990 --> 20:33.670]  harden this particular service. But actually, have you got monitoring here? Is this system
[20:33.670 --> 20:41.230]  being protected by behavioral analysis engines, etc? And then of course, we can take that
[20:41.230 --> 20:46.690]  information, we can export it out, and we're using STIX for that. And then we can do cross data
[20:46.690 --> 20:51.850]  sharing. So for example, I can take out vulnerability data from our reporting engine,
[20:51.850 --> 20:57.190]  and I can share it with TALOS, or with PISA, or with any of the other security teams that would
[20:57.190 --> 21:02.890]  sit within Cisco. The idea being that we can get a better understanding of what our customers'
[21:02.890 --> 21:08.950]  environments look like, and we can drive some of the features that we think are critical into,
[21:08.950 --> 21:16.450]  obviously, Cisco's products. And ultimately, we're taking some of that knowledge and using it to make
[21:16.450 --> 21:22.010]  more effective business risk analysis. And we're starting to go to customers and actually use these
[21:22.010 --> 21:28.090]  techniques on their data, not in our VDB, but on their risk management systems.
[21:30.010 --> 21:36.230]  So I talked about labeling findings. This is probably a pretty trivial example,
[21:36.730 --> 21:42.730]  certainly with the data that we have. But broadly speaking, we're scoring our findings, we're
[21:42.730 --> 21:49.110]  comparing those scores against ATT&CK TTP definitions, and we're labeling findings.
[21:49.410 --> 21:54.150]  And then we're identifying similar findings elsewhere, so that we can validate that the
[21:54.150 --> 22:01.510]  scorings we're applying are appropriate. And then applying labels where relevant, so that we start to
[22:01.510 --> 22:08.610]  build up a contextual map of how individual vulnerabilities, individual weaknesses found in
[22:08.610 --> 22:15.470]  an incident response engagement, incident instances of technical vulnerabilities in a red team,
[22:15.470 --> 22:23.870]  how they all map together. To do this, it's not necessarily trivial, certainly if you don't have
[22:23.870 --> 22:29.330]  the data to begin with. But in our instance, we've been developing plugins that give us customer views,
[22:29.330 --> 22:35.750]  platform views, ATT&CK surface views of our data. Like I said, we've been extending our findings to
[22:35.750 --> 22:42.470]  capture this information. But then we've been able to develop plugins that do that automation for us
[22:42.470 --> 22:48.550]  using the mechanism shown on the previous page. And then we can start to render that information
[22:48.550 --> 22:52.750]  in kind of useful fashion. So I think a couple of slides time, I'll show you an example where I've
[22:52.750 --> 22:59.610]  taken a bunch of vulnerabilities from our VDB and using a tool called Gephi, I've actually mapped
[22:59.610 --> 23:05.610]  them into a full keychain. And you can start to see where the critical nodes are.
[23:05.610 --> 23:12.350]  And this is generic vulnerability data, not red team ATT&CK TTPs we're talking about here.
[23:14.910 --> 23:20.570]  Let's stop and pause for a second. CVSS is not a shoe size contest.
[23:21.270 --> 23:27.830]  How many organizations out there look at CVSS as a number? They look at a 10 and they go,
[23:27.830 --> 23:32.810]  we need to patch that immediately. They look at it as a six and they go, we can patch that in a
[23:32.810 --> 23:38.170]  little bit of time. They look at it as a three and they go, actually, we don't need to patch it at all.
[23:38.170 --> 23:45.630]  So frustrating. So what we've been doing there, we've been attempting to map CVSS
[23:45.630 --> 23:51.590]  into the cyber keychain. One of the reasons that CVSS is kind of quite interesting
[23:51.590 --> 23:57.910]  is because nobody feels fearful about sharing that data in isolation. If I go to a customer,
[23:57.910 --> 24:02.730]  I say, I don't want anything else about your estate. I'd like to know your CVSS scores.
[24:03.610 --> 24:08.270]  Most organizations feel comfortable with that. And what that means is that they can then give
[24:08.270 --> 24:13.090]  me some information, which actually, when you start to break it down, becomes slightly more useful.
[24:15.770 --> 24:23.110]  So this is a rough mapping of our model. And what I've essentially got on there on the left-hand
[24:23.110 --> 24:29.790]  side is all of the key kill chain phases. And then as you progress through, I've got the aspects of
[24:29.790 --> 24:37.670]  CVSS that are likely to impact or likely to be interesting in each of those stages. And then
[24:37.670 --> 24:44.350]  I've rated them in terms of how useful they are. So I'm able to say that, you know, from a
[24:44.350 --> 24:52.030]  confidentiality standpoint, if the confidentiality impact is high, that's probably going to be useful
[24:52.030 --> 24:56.370]  from a reconnaissance standpoint. It's also probably going to be useful from an actions
[24:56.370 --> 25:02.310]  and objective standpoint. And similarly, with some of those other nodes in that graph.
[25:03.110 --> 25:09.950]  And where you get to is this. If you take all of our BDB data, and indeed, if you take Cisco's
[25:09.950 --> 25:15.350]  publicly disclosed vulnerabilities, and you break down and you score in the way that I've described,
[25:15.350 --> 25:20.630]  you can see where individual vulnerabilities that we report to customers, individual vulnerabilities
[25:20.630 --> 25:27.790]  that get reported to us, well, how they potentially, and it's my model, so only potentially,
[25:27.790 --> 25:33.230]  how these potentially map into the kill chain phases. And given that the kill chain phase is
[25:33.230 --> 25:38.870]  inspired attack, we're then in a position where maybe we can start to look at actually which parts
[25:38.870 --> 25:46.490]  of the kill chain are we exercising effectively, which parts we're exercising badly. Yeah, we never
[25:46.490 --> 25:55.490]  report almost anything that helps us with weaponization. We rarely report anything that
[25:55.490 --> 26:03.850]  talks to installation. And command and control, well, actually, if you think about it from a
[26:03.850 --> 26:08.490]  pentest standpoint, that kind of makes sense. We're unlikely to really look at command and
[26:08.490 --> 26:12.310]  control. We're unlikely to look at installation. We're unlikely to look at weaponization.
[26:12.690 --> 26:18.450]  So it's almost reflective of what you expect to see. But what it means is actually,
[26:19.330 --> 26:23.450]  if we were doing a pentest tomorrow, if we were doing a threat hunt tomorrow,
[26:23.450 --> 26:27.810]  where perhaps should we focus our efforts? Installation and command and control might
[26:27.810 --> 26:32.090]  be kind of interesting if you're an organization that has regular pentests,
[26:32.090 --> 26:36.270]  simply for the fact that pentests are unlikely to produce useful findings in that space.
[26:38.750 --> 26:43.570]  And then I said we talked to some of our customers and started to use this kind of information on
[26:43.570 --> 26:50.710]  their risk databases, on their vulnerability databases. For that, we've been going into
[26:50.710 --> 26:55.430]  organizations, perhaps a couple of steps up the tree. We've been talking to CISOs, executives,
[26:55.430 --> 27:02.730]  etc. And we've been using this concept of FAIR, which is essentially a risk framework
[27:03.290 --> 27:09.830]  that allows you to talk about risk in quite an interesting way. It allows you to talk about
[27:09.830 --> 27:16.890]  things like resistive strength, threat capability, probability of action, primary loss, secondary loss,
[27:16.890 --> 27:23.030]  etc. And it allows you to put proper numeric scores. Indeed, FAIR encourages you to score
[27:23.030 --> 27:31.590]  in ultimately a dollar, a pound size value. But what it means is that we can go and talk
[27:31.590 --> 27:37.290]  to organizations at levels that the executive cares about. The executive doesn't necessarily
[27:37.290 --> 27:44.590]  care about CVSS version 10. What they care about is that they're able to trade, that their IP
[27:44.590 --> 27:50.390]  isn't being stolen, that if they're a bank, someone hasn't got access to the treasury and
[27:50.390 --> 27:58.570]  stolen all the money. So starting to take vulnerability data and turn it into business
[27:58.570 --> 28:05.890]  impact, business risk, etc. Yeah, that's kind of quite compelling to a lot of C-suite.
[28:08.960 --> 28:16.500]  So why do the labeling? This statement, it's a great statement and it's very true.
[28:16.940 --> 28:22.260]  Defenders thinking lists, attackers thinking graphs. If you think about it logically that
[28:22.260 --> 28:26.480]  makes perfect sense. An attacker doesn't care how they get into an organization.
[28:27.200 --> 28:33.060]  Yeah, if they can't get in one way, they'll get in another. That's a graph. If you think about how
[28:33.060 --> 28:37.540]  risk management businesses work, how risk management organizations work,
[28:37.540 --> 28:44.580]  guess what? For most part, they're operating on spreadsheets or the equivalent. So getting to a
[28:44.580 --> 28:50.020]  place where we can help those risk management functions think more effectively in graphs,
[28:50.020 --> 28:55.940]  that's kind of going to be useful. So when we do the labeling, it allows us to produce
[28:57.200 --> 29:04.660]  documents such as this. So this I think was from recollection was AWS, but essentially was taking
[29:04.660 --> 29:12.960]  all of the TTPs, all of the threat groups, all of the parts of the attack matrix and map them,
[29:13.680 --> 29:22.100]  filtered as I say through the view of AWS rather than the whole STIX object collection.
[29:22.740 --> 29:29.500]  But we're now starting to do the same thing with penetration tests. We're starting to do the same
[29:29.500 --> 29:33.900]  thing with red teaming. And hopefully we'll get to a point where we can deliver it right across
[29:33.900 --> 29:40.380]  the board. Every report in my view, this visualization is pretty key to helping people
[29:40.380 --> 29:49.160]  understand what matters to them. So that's all of the theory. That's all of the data science
[29:49.160 --> 29:54.920]  from a person that isn't a data scientist. What I really wanted to do is have a look at how our
[29:54.920 --> 30:00.580]  data maps to the real world. And I talked about the fact that my background is Unix and big systems
[30:00.580 --> 30:06.600]  and that attack doesn't really help. So I kind of constructed three hypotheses, which I thought
[30:06.600 --> 30:14.580]  were probably pretty short to evaluate. I was probably going to be challenged to find useful
[30:14.580 --> 30:23.600]  data to support me. But it was a starting point. So I chose my targets. As I said, Unix. I built
[30:23.600 --> 30:29.520]  hypotheses. I validated those hypotheses. And I'm hoping to start to feed some of that learning back
[30:29.520 --> 30:35.560]  into our reporting. And I'm certainly more comfortable to talk to some of the missed
[30:35.560 --> 30:42.480]  opportunities that I've seen along the way. So in terms of targeting, if you're familiar with
[30:42.480 --> 30:47.120]  Portcullis, obviously we're Cisco these days. But if you're familiar with Portcullis, you'll know we
[30:47.120 --> 30:52.060]  spent years doing lots of interesting stuff in Unix. It seemed a good place to start. We've
[30:52.060 --> 30:58.080]  written quite a lot of things that you could consider to be TTPs, if you were that way inclined.
[30:58.480 --> 31:05.420]  And as I said, we had quite a lot of access to our customer data. So we were able to do things like,
[31:05.420 --> 31:12.060]  actually, what have we reported over the last 10 years? And the way we have our data segmented
[31:12.060 --> 31:19.000]  means that our VDB keeps track of how many times a particular issue gets reported.
[31:19.000 --> 31:22.600]  Even if we clear down the customer data, we still have an understanding of trends
[31:23.280 --> 31:30.280]  going back not many decades, but certainly the last 5-10 years kind of thing.
[31:31.420 --> 31:38.420]  So the hypotheses I constructed. Attackers are using our tools to target environments.
[31:39.060 --> 31:45.240]  Attackers are using techniques from attack to target Unix environments.
[31:45.660 --> 31:52.480]  And attack is not representative of the TTPs that we, that is the traditional pen testing arm of
[31:52.480 --> 31:59.080]  Cisco, find success with when we go and do professional service engagements for our customers.
[32:03.620 --> 32:11.460]  So, hypothesis validation. I used a small selection of our TTPs, in particular, two tools.
[32:12.200 --> 32:20.700]  Pentest, Monkeys, Unix check, and my Linux implementation for attacking AD on Unix.
[32:25.320 --> 32:33.240]  And, as I said, there's a lack of information out there. So I was kind of hoping we'd go and have a
[32:33.240 --> 32:38.300]  look at a bunch of incident response reports. And we'd kind of say, okay, there's loads of
[32:38.300 --> 32:44.260]  useful information in there. Guess what? When you look at enterprise systems,
[32:44.260 --> 32:50.680]  that might be the case. When you go and look at big box servers, far less often does it occur.
[32:51.240 --> 32:58.280]  So we went back to the drawing board. Detonations, bits of attack that might be useful,
[32:58.500 --> 33:06.300]  a lot of Googling furiously, and to the point about VDBs, many of our other data sources.
[33:09.650 --> 33:16.310]  So, hypothesis one. Attackers are using our tools to target Unix environments.
[33:16.310 --> 33:25.750]  So, guess what? It's almost impossible to determine whether, if an attacker was to
[33:25.750 --> 33:33.110]  compromise a Unix box, and they would use off-the-shelf, publicly available tools,
[33:33.790 --> 33:37.630]  it's almost impossible to tell whether they'd actually be picked up.
[33:37.770 --> 33:44.010]  Unix privilege check was undetected in pretty much all of the cases. And even
[33:45.130 --> 33:49.170]  where it was detected, it wasn't classified as malicious.
[33:50.570 --> 33:54.710]  Kind of cool. I kind of like the fact that I could rock up, I could use this tool
[33:54.710 --> 34:00.450]  when I do an assessment. But actually, you probably want to know whether it's on your
[34:00.450 --> 34:06.570]  network, even if ultimately you go, it's the pen testers, and they're meant to be using it.
[34:10.290 --> 34:14.370]  Again, looking for detonations. I went out and had a look to see if anyone had spotted
[34:14.370 --> 34:22.450]  in the wild. And guess what? They haven't. Is that because it's not malicious? Is that
[34:22.450 --> 34:26.830]  because people have looked at it and kind of gone, we don't mind, it's only being used by
[34:26.830 --> 34:33.630]  pen testers. Actually, it's probably because if an attacker gets you onto a system,
[34:33.630 --> 34:37.890]  they're probably not going to pass it through a Windows box unless they absolutely have to,
[34:37.890 --> 34:42.150]  or at least not in a way that a Windows AV is like to pick it up.
[34:42.810 --> 34:48.490]  Which means that unless you have good telemetry on your Unix estate, both those tools, you're
[34:48.490 --> 34:54.590]  unlikely to see them up until the point that the breach occurs and you start going back through
[34:54.590 --> 35:01.250]  your historical data. And even then, you're probably not going to see it unless you've got
[35:01.250 --> 35:08.690]  an attacker that's left it in the history, or an attacker who has left it on the file system,
[35:08.690 --> 35:16.970]  or an attacker who is ultimately pretty incompetent. If I wanted to get those tools
[35:16.970 --> 35:23.210]  onto a Unix box right now, I could do so. The fact that we don't even have the telemetry to allow us
[35:23.210 --> 35:31.090]  to spot the sloppy amongst us is probably a challenge that we ought to address.
[35:33.730 --> 35:40.110]  So, science of life and attack. Well, neither of those tools are mentioned. Kind of understand why
[35:40.110 --> 35:47.810]  it's not generic enterprise attacks tools. But guess what? It's used by almost every
[35:47.810 --> 35:53.350]  penetration tester out there. It's in lots and lots of tutorials. And it's even being
[35:53.350 --> 35:58.890]  used by people that we would probably consider to be threat actors. Phineas Fisher literally
[35:58.890 --> 36:08.530]  mentions it in his paper around how to breach organizations. Now, you might argue that
[36:08.530 --> 36:14.370]  Phineas Fisher isn't an adversary you care about. It didn't really matter. The fact that
[36:15.050 --> 36:20.770]  we haven't even identified these tools exist when our own community knows they exist and is using
[36:20.770 --> 36:26.990]  them. You know, we talk about offensive security tools. These are offensive security tools that
[36:26.990 --> 36:30.410]  will be being used by people and we'll just never see it.
[36:32.310 --> 36:38.610]  So, the second hypothesis. Attackers are using techniques from attack to target Unix environments.
[36:39.310 --> 36:45.310]  Like I said, that's pretty hard in a practical sense. If you look at the stuff that comes up
[36:45.310 --> 36:53.850]  in attack from a Linux standpoint, it's mostly IOT or front end centric. It's a bit of a chicken
[36:53.850 --> 36:58.830]  and egg situation. If you can't monitor your estate effectively, you're probably not going
[36:58.830 --> 37:04.670]  to spot it. And from an incident response standpoint, well, organizations, perhaps they're
[37:04.670 --> 37:09.910]  not going to be particularly honest, certainly publicly, about just how deep breaches went.
[37:10.370 --> 37:14.030]  But anecdotally, and I'll call back to the Phineas Fisher point,
[37:14.510 --> 37:19.570]  they certainly are doing things that would fall into the attack categories.
[37:20.270 --> 37:26.470]  Unix backend breaches do occur. There is almost always some level of application
[37:26.470 --> 37:32.350]  level interaction. Remember I said the value of any asset is the data that it holds.
[37:34.450 --> 37:39.270]  Some access are truly incompetent if it's not a Linux host. We did an incident response
[37:39.270 --> 37:44.970]  engagement for a mainframe platform that had a Unix-like shell. And the attacker had gone
[37:44.970 --> 37:50.650]  to that Unix shell without really realizing what they'd done and poked around a bit,
[37:50.650 --> 37:56.010]  not had a huge amount of success, and then attempted to wipe their evidence.
[37:58.590 --> 38:04.290]  If I'm looking at this critically, the TTPs from attacker are actually probably still
[38:04.450 --> 38:13.790]  a reasonable place to start with Unix, with enterprise business systems, with servers, etc.
[38:14.470 --> 38:18.310]  But perhaps we don't have the telemetry to support it at this point in time.
[38:21.420 --> 38:27.500]  If anybody wants to know what a good breach report looks like, this is probably the best
[38:27.500 --> 38:35.620]  one I've found. It's looking at fast cache on AIX. And it's not perfect, but it does support
[38:35.620 --> 38:42.640]  the fact that a lot of this stuff is stuff that attack knows about. Okay, it's AIX, not Linux,
[38:42.640 --> 38:48.780]  but question marks against that. But it certainly calls out to the same techniques that the fast
[38:48.780 --> 38:59.080]  cache malware was using in terms of persistence, privilege escalation, evasion, persistence,
[38:59.640 --> 39:06.380]  impact, etc. There's a little bit of speculation on application and entry point,
[39:06.380 --> 39:13.820]  probably not enough. But this is the kind of thing, in my mind, should be going into the
[39:13.820 --> 39:19.240]  attack matrix. Or if it's not going to the attack matrix, should be going into the equivalent matrix
[39:19.240 --> 39:23.900]  for business systems. If we don't capture this kind of information, we're never going to get
[39:23.900 --> 39:32.340]  our socks to start looking for them. So hypothesis three. So this was taken from our VDB.
[39:33.060 --> 39:39.480]  I took the top 10 or so issues that we regularly report to customers when we go and look at Unix
[39:39.480 --> 39:47.140]  systems. I went and I had a look at whether they were captured inside ATT&CK as it stands today.
[39:48.520 --> 39:53.960]  Security patches, password reuse, etc. They're all covered.
[39:55.440 --> 40:01.600]  Role accounts for interactive logins. Semi covered, but perhaps not the way I would have
[40:01.600 --> 40:09.660]  viewed it from my standpoint. That third, fourth one down, that's not captured at all in any useful
[40:09.660 --> 40:20.240]  sense. It gets us into almost every enterprise Unix box we go and look at. You get your
[40:20.240 --> 40:25.640]  role account, you get your low privilege user. Almost every single one of them will get to
[40:25.640 --> 40:32.960]  read through that. So we ought to make sure that ATT&CK factors that in, describes it,
[40:32.960 --> 40:38.300]  and gives the information that allows a sock to start to detect, to start to respond
[40:38.840 --> 40:46.100]  when those kinds of attacks are used. So broadly speaking, I guess where we're at,
[40:46.100 --> 40:51.700]  I think we don't have the right level of platform and application awareness today,
[40:51.700 --> 40:57.700]  which inevitably means there's an intelligence gap. Which means that no matter whether you're
[40:58.580 --> 41:03.140]  doing intelligence, whether you're modeling, whether you're simulating, or whether you're
[41:03.140 --> 41:08.940]  hunting, you're going to be working, I think, from an incomplete set of hypotheses.
[41:09.140 --> 41:14.480]  Which means that the models that you're working to probably don't relate to the systems that you're
[41:14.480 --> 41:19.780]  actually caring about. And you're probably not going to be as accurate as you might want to be
[41:20.620 --> 41:30.120]  when you start to validate them. How do we improve all of this? It's the million dollar question.
[41:33.260 --> 41:38.800]  Threat modeling certainly plays a part. If you were simply to take the approach I did with
[41:38.800 --> 41:45.860]  the vulnerabilities, and use that to drive the threat models for systems you don't know about,
[41:46.620 --> 41:50.600]  you would certainly get to a place where your blue team would probably have a better understanding of
[41:50.600 --> 41:57.780]  what bad is likely to look like. Once your blue team have an understanding,
[41:59.300 --> 42:05.640]  then they can drive the visibility. And then you can start to refocus your offensive services to
[42:05.640 --> 42:14.280]  validate that visibility is appropriate. Ultimately, I would posit that at least some
[42:14.280 --> 42:20.580]  of the problem is there aren't enough bums on blue team seats. I guess what I mean by that,
[42:20.580 --> 42:24.380]  we need to find a way of making it attractive to have those people that understand those
[42:24.380 --> 42:29.420]  applications, the security models behind them, sitting directly in the blue teams,
[42:29.420 --> 42:34.240]  or certainly sitting adjacent to those blue teams, so that the blue teams can start to
[42:34.760 --> 42:40.480]  understand what some of the applications the businesses care about actually look like.
[42:43.440 --> 42:48.040]  Yeah, we can't fix architectural alignment or mission tomorrow.
[42:48.840 --> 42:55.280]  We probably can work on threat visibility and on target visibility, if we know what we're
[42:55.280 --> 43:04.140]  aiming for. If we understand the threats, we can better protect our customers and our data.
[43:04.860 --> 43:11.020]  More importantly, if you can start to talk about individual vulnerabilities,
[43:11.020 --> 43:17.260]  in terms of their impact or threat model on the kill chain, not only can you make sure that your
[43:17.260 --> 43:24.180]  SDLC is looking for the right things, but you can also make sure that the people that are
[43:24.180 --> 43:28.740]  doing the code, you know, the people that are sitting there writing the web applications,
[43:28.740 --> 43:34.780]  writing the code that interfaces with your message bus, your database, etc. So they understand
[43:34.780 --> 43:40.680]  why and how an attacker might attack them. And hopefully we'll get into a situation where less
[43:41.020 --> 43:47.680]  vulnerabilities of note will make it into business applications in G-course. Ultimately,
[43:48.300 --> 43:54.500]  organizations will have profit motivated. And if we can talk in language that
[43:55.540 --> 44:03.820]  makes it apparent to the C-suite why it matters, what the cost of not doing X is,
[44:03.820 --> 44:06.740]  I think perhaps we'll be slightly more successful in that regard.
[44:09.240 --> 44:12.100]  So, offensive services.
[44:13.920 --> 44:20.980]  I think there's life beyond Nessus and MITRE. But that data is still useful,
[44:20.980 --> 44:26.660]  even from a red team standpoint. I guess we need to figure out how to
[44:27.540 --> 44:33.260]  use it more effectively. You know, we need to be in a position where we can
[44:33.980 --> 44:39.780]  far more quickly, far more comfortably talk to the kinds of bespoke briefings that organizations
[44:39.780 --> 44:49.180]  want. Craft war games that are actually appropriate to the things that matter to a business.
[44:49.740 --> 44:56.560]  We need to be able to articulate all of that. And obviously, better metadata,
[44:56.560 --> 45:00.560]  visual representation certainly helps with that communication piece.
[45:00.560 --> 45:07.440]  And we need to refine our assessment methodologies. I think too much of pen testing
[45:07.440 --> 45:17.420]  today is focused on the break in. And I think the data I showed around CVSS shows that actually,
[45:17.420 --> 45:23.980]  given that pen tests are still the lowest bar most organizations will jump through,
[45:23.980 --> 45:28.460]  they're actually getting testers to a place where they feel comfortable to talk about
[45:29.260 --> 45:34.880]  the other side of the line. The system has been compromised. How do we get back out
[45:35.480 --> 45:39.500]  is something we probably ought to focus more time on.
[45:40.980 --> 45:47.560]  So some conclusions. What have we learned? How do we do this better? Next steps.
[45:49.380 --> 45:57.240]  We can automate extraction of hypotheses. We can build threat models in an automated fashion.
[45:59.460 --> 46:06.780]  Vulnerability data, no matter how poor you may think it is, could still be useful
[46:07.820 --> 46:17.740]  with the right labeling applied. Actually, from a tester standpoint, it'd be kind of great if we
[46:17.740 --> 46:22.940]  rocked up organizations and they had a threat model based on their existing understanding of
[46:22.940 --> 46:29.580]  their vulnerability state. Extract your quality information, build that threat model, give it to
[46:30.140 --> 46:35.320]  the tester at the start and say, this is kind of where we think the threats live. Help us validate
[46:35.320 --> 46:43.780]  that. Again, if you can get to a place where you can take your vulnerability data and start to
[46:43.780 --> 46:49.280]  think about it in attack terms, then you can start to think about the control sets that you need.
[46:49.280 --> 46:55.120]  And potentially, you can start to think about automatic generation and validation.
[46:57.160 --> 47:04.180]  Ultimately, it's a communication problem, right? Attack has given us a wonderful tool to help us
[47:04.180 --> 47:12.000]  bridge the gap between red and blue, between operational and management. We just need to
[47:12.000 --> 47:21.060]  make sure we take the best advantage of it. So doing this better. Better consideration.
[47:21.380 --> 47:28.120]  I know that from a red team standpoint, we would argue that perhaps we're there. But actually,
[47:28.120 --> 47:37.920]  I don't think a VA, a generic pen test necessarily needs to consider the scope they're given to be
[47:37.920 --> 47:45.360]  an impedance to giving better outcomes to customers. We do a really good job of collecting
[47:45.360 --> 47:50.340]  awesome information about threats and vulnerabilities, whether it's Reddit, whether
[47:50.340 --> 47:58.180]  it's peer list, unfortunately closed down, or anywhere else. But even that data, we don't
[47:58.180 --> 48:05.400]  particularly do a good job of enriching it. Having a platform that allows proper automated enrichment
[48:05.400 --> 48:11.400]  of that kind of information. Maybe you're lucky and you're sitting in an organization that has
[48:11.400 --> 48:18.820]  it. It's a bit of a forlorn dream for me. Personally, getting our database to a point
[48:18.820 --> 48:23.960]  it's fully labeled and being able to run queries against those labels will be pretty kick ass.
[48:25.260 --> 48:31.720]  Taking that the next step and making it actionable. I mentioned that we use sticks.
[48:31.720 --> 48:39.500]  Sticks is good at talking about the types of threats. It doesn't really capture the level
[48:39.500 --> 48:45.680]  of information that's required for machine action ability. There are some solutions to that,
[48:45.680 --> 48:51.600]  the Sigma and others. But we're really not at a point where we define vulnerabilities in a way
[48:51.600 --> 48:58.520]  that's particularly helpful for scale. And ultimately, if we don't generate for scale,
[48:58.520 --> 49:05.100]  improving EDR and workload protection products is going to be pretty forlorn. If every vulnerability
[49:05.100 --> 49:12.580]  report that every pen test or security researcher turned out had essentially a cool chain graph
[49:13.200 --> 49:19.880]  that an EDR solution or workload protection product could import and then look for,
[49:19.880 --> 49:27.320]  rather than being reliant upon hashes, IP addresses, host names, that would take us a huge
[49:27.320 --> 49:37.840]  way forwards. So next steps, call to action, I guess. Just because we don't have the capabilities
[49:37.840 --> 49:44.780]  to look for bad guys doesn't mean they're not there. Attackers, we use the easiest TTPs that
[49:44.780 --> 49:49.560]  get them to the root prompt. Those things I was talking about are pretty damn easy.
[49:50.940 --> 49:58.580]  Behavior, don't rely upon agents that are merely relying upon hashes and IP addresses.
[49:59.980 --> 50:06.820]  If you're doing Unix stuff, make sure you're exercising those things, because the bad guys
[50:06.820 --> 50:15.720]  certainly are. And Linux apps, Unix check, I kind of look forward to the day when they appear
[50:15.720 --> 50:23.000]  in a virus title, and they're being detonated and being marked as malicious. It'll make my job a
[50:23.000 --> 50:31.680]  little bit harder, but actually it'll make Blue Team's jobs a hell of a lot easier.
[50:31.680 --> 50:38.640]  Finally, a few thanks, my old colleagues, Cisco's wider team, MITRE,
[50:38.640 --> 50:46.660]  ATT&CK wouldn't exist without them. Swimlane, PyTAC is still the most comfortable interface I've found
[50:46.660 --> 50:52.640]  rather than writing in Perl. And Blue Team's everywhere, because you do a thankless job,
[50:52.640 --> 50:59.600]  and for the most part, you do it as well as you can do. And with that, questions?