WEBVTT 00:00.000 --> 00:01.220 Welcome back. 00:01.320 --> 00:02.200 And thank you, Tim. 00:02.200 --> 00:03.740 Thank you for supporting DEF CON. 00:03.740 --> 00:05.700 Thank you for supporting the Red Team Village. 00:05.860 --> 00:06.780 The floor is yours. 00:06.780 --> 00:07.740 Take it away. 00:08.380 --> 00:09.360 Hi, folks. 00:09.360 --> 00:12.760 Good morning, good afternoon, good evening, wherever you are in the world. 00:12.800 --> 00:19.320 Welcome to my session, All of the Threats, Intelligence, Modeling, Simulation, and Hunting through an Attacker's Lens. 00:20.860 --> 00:26.460 So just to put a little bit of background behind this at a very high level, ATT&CK rocks. 00:26.640 --> 00:29.980 But what happens when ATT&CK doesn't give you the information you need? 00:32.140 --> 00:33.820 So introduction. 00:35.100 --> 00:39.760 TLDR, who I am, what the plan for this presentation actually looks like. 00:40.240 --> 00:42.800 So I'm not a data scientist. 00:42.980 --> 00:45.420 I'm not aligned to either blue or red. 00:45.420 --> 00:49.640 I do various activities on both sides of the fence. 00:49.820 --> 00:53.260 And I fully acknowledge that this isn't a solved problem. 00:53.260 --> 00:57.120 This is my stab in the dark trying to get somewhere with it. 00:57.700 --> 00:58.780 So who I am. 00:58.780 --> 01:00.140 So I work at Cisco. 01:00.180 --> 01:01.780 I've done various roles. 01:01.780 --> 01:03.680 I've done assessment work. 01:03.720 --> 01:05.600 I've done threat intelligence. 01:05.900 --> 01:10.220 I occasionally help out with incident response when we get weird situations. 01:10.580 --> 01:16.340 And indeed, I've also done my fair share of spreadsheet filling as an auditor. 01:16.540 --> 01:18.420 I am a technical person. 01:18.940 --> 01:20.420 I like bugs. 01:20.420 --> 01:22.020 I like Unix in particular. 01:22.140 --> 01:23.680 And I like exploiting stuff. 01:23.740 --> 01:28.880 Probably the most recent stuff you can go and find is Mimikatz and Unix. 01:28.880 --> 01:32.020 What happens in an active directory on a Unix estate. 01:32.320 --> 01:35.280 So the plan for this presentation, I'm going to give you a little bit of background. 01:35.280 --> 01:40.920 I'm not presuming that everybody knows the difference between threat intelligence, threat hunting, threat simulation, etc. 01:41.380 --> 01:45.020 I'm going to talk a little bit about building bespoke threat models. 01:46.120 --> 01:49.700 I'm going to talk about how we can use data we already have. 01:50.560 --> 01:53.900 I'm going to talk about how that translates into the real world. 01:53.900 --> 01:59.360 I'm going to look at some of the stuff that we do from an offensive standpoint and how that maps into things like attack. 02:00.160 --> 02:04.340 I'm going to talk about how we can be using this kind of information to improve our threat models. 02:04.340 --> 02:10.400 And hopefully I'm going to finish up some recommendations and conclusions and it'll all make sense and you'll go in and everything will be great. 02:10.820 --> 02:11.980 So background. 02:13.200 --> 02:16.960 The concept was we need to bring all of these different disciplines together. 02:16.960 --> 02:22.020 We have people that do threat intelligence, we have people that do threat modeling, we have people that do simulation, we have people that do hunting. 02:22.840 --> 02:25.700 And attack gives us a common language for all of those things. 02:25.780 --> 02:30.720 But does it go far enough and does it help us with, I guess, the business system? 02:30.720 --> 02:32.940 So that's kind of where we are. 02:33.240 --> 02:35.900 So as I said, bring the five disciplines together. 02:36.680 --> 02:42.440 Most of the people guessing on this will be involved in at least one of these. 02:42.580 --> 02:46.220 Maybe you're doing recovery work when breaches happen. 02:46.220 --> 02:48.760 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 --> 02:55.900 You know, we're all in this together, right? 02:56.640 --> 02:58.640 So an ideal approach. 02:58.860 --> 03:04.400 Ideally, we'd all have a good understanding of targeting hypotheses and how we validate. 03:04.680 --> 03:07.620 You know, we'd understand actors, TTPs, assets. 03:07.620 --> 03:20.380 We'd be able to draw out hypotheses about how actors get into networks, what they do once they're in networks, and what they're looking for in terms of actions on targets, what they're looking to get away with. 03:20.520 --> 03:32.580 And hopefully, we'd have a common way to talk about that from a validation standpoint, either in terms of posture or telemetry, or indeed any of the other mechanisms that may or may not exist. 03:33.320 --> 03:35.140 So threat intelligence. 03:35.140 --> 03:51.680 That's all about identification, understanding emerging TTPs, understanding what malicious behavior looks like, collecting and enriching that, and providing situational awareness to your organization, to those people that you work with. 03:52.160 --> 03:53.440 Threat modeling. 03:53.560 --> 03:56.940 The mission there, I guess, is to describe the assets. 03:56.940 --> 04:16.380 So take that information that threat intelligence gives you, augment it, build kill chains, map attack surfaces, talk about vulnerabilities and weaknesses and how they inform that threat model, understand the motivation, understand the impacts of attacks. 04:17.180 --> 04:18.620 Simulators. 04:18.800 --> 04:21.000 Yeah, there's various different classes within that. 04:21.000 --> 04:24.700 You've got simulation, you've got emulation, you've got traditional penetration testing. 04:24.700 --> 04:42.080 But essentially, that's looking to take that information about what the threat model looks like, that information about what threat actors are out there, and recreate it so that your blue team, your defenders can understand, can test their telemetry, can test that they can pick it up, 04:42.080 --> 04:50.540 and hopefully so they can improve either the identification or the automation, the response to those threats. 04:51.540 --> 04:52.580 Hunting. 04:52.640 --> 04:55.640 That's, I guess, the final part of the jigsaw from my perspective. 04:55.660 --> 05:04.860 That's about understanding how threat intelligence, how threat models, what they look like on the ground. 05:04.880 --> 05:08.220 When an attacker has got in, what are they doing? 05:08.220 --> 05:09.420 What does it look like? 05:09.420 --> 05:12.400 And how can you go and find them and hopefully kick them out? 05:12.400 --> 05:24.380 So it's about understanding posture, it's about understanding telemetry, it's about reading that information, identifying where attackers are actually active, taking steps to remediate that problem. 05:25.260 --> 05:29.820 So that's kind of a high-level view of the people I'm talking to. 05:29.820 --> 05:30.920 What of it? 05:30.920 --> 05:32.600 What should we be doing? 05:33.180 --> 05:36.020 I talked about the fact attack is great. 05:36.300 --> 05:48.580 It's really good if you're talking about heterogeneous Windows networks, active directory, phishing through to crypto mining, phishing through to crypto lock-in. 05:48.680 --> 05:52.580 The traditional stuff that everybody worries about on their Windows desktops. 05:52.580 --> 05:57.040 But where it doesn't, in my opinion, particularly help is when you step beyond that. 05:57.340 --> 06:03.000 Most businesses, well, they actually have data, they have applications that essentially drive their business. 06:03.220 --> 06:10.240 And that's the purpose of this talk, is to look at how we take attack and leverage in those kinds of situations. 06:11.520 --> 06:13.960 So building bespoke threat models. 06:14.900 --> 06:20.240 I'm going to go through what I think requirements look like, what I think the workflow looks like. 06:20.240 --> 06:23.460 Some ideas about how to use a workflow effectively. 06:24.760 --> 06:27.380 How you can apply hypotheses. 06:28.100 --> 06:33.440 Some of the use cases that maybe we don't really tackle today, but perhaps we ought to. 06:33.740 --> 06:37.280 Some of the capability gaps that certainly exist. 06:37.600 --> 06:45.420 And why in my head, and this is just my head, I think threat intelligence collection is really just a backstop. 06:45.420 --> 06:58.140 There are far more useful sets of information about our platforms, about our assets, about our data, about our users, that should give us a far better understanding of where threats are likely to raise their heads. 06:58.960 --> 07:04.480 So in terms of requirements, broadly speaking, we need to define a mission. 07:04.760 --> 07:09.120 And I will say the value of any system, well, that's the data. 07:09.840 --> 07:16.080 Secondly, we need to have an understanding of what threat looks like from one perspective or another. 07:16.920 --> 07:22.360 In terms of building hypotheses, well, we need to understand what the organization actually cares about. 07:22.640 --> 07:25.220 And we probably need access to the design. 07:25.220 --> 07:34.800 It's very difficult to build threat models purely based on attack once you step into business systems, because you're really not matching like for like. 07:35.000 --> 07:46.060 A Windows desktop, the users, the use cases, are significantly different from, you know, an enterprise resource planning system, a data warehouse. 07:46.660 --> 07:54.440 So we need to understand what the designs look like, you know, three-tier architectures, are they using containers, are they using microservices, that kind of thing. 07:54.580 --> 08:00.420 And then from a validation standpoint, one way or another, we need some visibility of those targets. 08:00.560 --> 08:05.540 From an intelligence standpoint, I guess, third-party sourced evidence is kind of useful. 08:05.580 --> 08:11.380 If you're talking about simulation, well, you need to be in a position to go and actually test the systems that you're talking about. 08:11.540 --> 08:16.040 From a hunting standpoint, you need configuration, you need access to the logs. 08:16.560 --> 08:23.700 Ideally, you'd need dynamic telemetry, that is to say, telemetry that's feeding back in real time. 08:23.700 --> 08:35.340 But at the very least, the ability to see the events, the log events that are occurring in SAP, in a database environment, is pretty key to getting this right. 08:36.080 --> 08:43.780 So in terms of workflow, from my perspective, I've sat in all those different nodes at one stage or another. 08:43.780 --> 08:46.260 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 --> 08:57.860 I've considered the impact from a governance standpoint. 08:58.180 --> 09:02.520 And in all and amongst that, you've got to understand the motivation. 09:02.520 --> 09:10.580 But hopefully, no matter what part of the security lifecycle you live in, you'll map into one of those areas fairly cleanly. 09:11.680 --> 09:16.180 And then, of course, the challenge is to hand off to the next node. 09:16.280 --> 09:21.700 And indeed, in practice, there's nothing to stop you handing across in other ways. 09:22.480 --> 09:26.020 Understanding impact, well, that feeds vulnerabilities and weaknesses. 09:26.560 --> 09:30.460 Understanding motivation, well, that might actually tell you something about TTPs. 09:32.080 --> 09:35.000 So iterating effectively through it. 09:36.440 --> 09:37.960 Understanding a platform. 09:37.960 --> 09:39.900 I talked about the fact attack is great. 09:39.900 --> 09:47.840 But if you understand the platform, maybe you can take attack on its own and filter out those TTPs that you're most interested in. 09:48.320 --> 10:04.460 Some of the work I've been doing recently has been around, for example, taking attack and extracting verticals, extracting regional differences, extracting particular vulnerability classes. 10:05.100 --> 10:13.580 In terms of threat modeling in a practical sense, you've got to be able to go and speak to the people, you've got to understand the roles, you've got to understand the processes. 10:13.960 --> 10:19.060 Tooling wise, there is nothing better than pen and paper or a whiteboard. 10:19.520 --> 10:27.280 But if you want to record your information, Microsoft Threat Modeling Tool, others of its, ILK, Visio and Excel, well, they can all help. 10:27.600 --> 10:31.740 And then fundamentally, producing a worksheet. 10:31.820 --> 10:45.240 And it doesn't really matter if that worksheet is built from the perspective of an adversary, a red team, whether it's built from the perspective of a threat intelligence person, whether it's built from the perspective of a threat hunter. 10:45.240 --> 10:52.900 Once you have that worksheet, actually, you can pivot those questions to answer whichever question you're actually asked. 10:55.470 --> 10:59.850 So applying hypothesis to real world platforms and applications. 11:01.030 --> 11:06.030 First of all, at a very high level, familiarizing yourself with ATT&CK. 11:06.130 --> 11:10.650 It is still useful, 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:19.210 They're actually straight out of CVSS. 11:20.090 --> 11:21.750 It's a starting point. 11:22.050 --> 11:23.870 Vulnerabilities and weaknesses. 11:24.730 --> 11:33.970 ATT&CK TTPs are great, but actually CAPH, CWE, perhaps give you value that you're not necessarily recognizing today. 11:34.390 --> 11:40.830 If you're fortunate enough to have good threat intelligence, understanding motivation, understanding threat groups. 11:40.830 --> 11:45.550 If you're fortunate enough to have access to business data, understanding system value. 11:45.850 --> 11:47.790 And then, of course, impact. 11:47.790 --> 11:52.270 It's a pretty lazy way to do it, but stride still helps in that regard. 11:52.310 --> 11:59.110 Fundamentally, attackers are still spoofing, tampering, causing information to be disclosed, etc. 12:01.460 --> 12:03.180 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:13.980 It gets used for sourcing IOCs. 12:13.980 --> 12:16.780 It gets used for telemetry configuration. 12:17.660 --> 12:20.440 And it gets used for response prioritization. 12:20.560 --> 12:25.260 There will be other use cases and there will be sub-use cases to each of these. 12:25.260 --> 12:31.600 But fundamentally, the threat model concept is about understanding a design. 12:31.680 --> 12:34.260 It's about understanding what's likely to be attacking it. 12:34.260 --> 12:38.020 It's about making sure you've got the right security controls. 12:38.240 --> 12:42.880 And these days with consider breach, telemetry is a key aspect. 12:43.340 --> 12:49.900 And it's about being able to respond when breaches occur, because again, consider breach. 12:52.750 --> 12:55.990 So capability gaps. 12:56.390 --> 13:03.230 I've been into a fair few SOCs, either working in them or talking to them, evaluating their current capabilities. 13:03.790 --> 13:06.890 And that's what one's a pretty key one in my mind. 13:07.730 --> 13:10.210 SOCs are great at dealing with enterprise. 13:10.550 --> 13:13.770 Most people these days are familiar with ATT&CK. 13:13.770 --> 13:16.630 They do understand enterprise risks. 13:16.990 --> 13:31.970 But actually, once you start to grow them beyond that, and start to ask them about their SAP infrastructure, their banking enterprise applications, their data warehouses, we're kind of blind to a degree. 13:31.970 --> 13:35.450 And I think that's probably one of those things that we need to tackle. 13:35.450 --> 13:42.190 And I hope that some of what I'm talking today about is about informing how we can tackle some of this. 13:42.190 --> 13:48.030 We're clearly not going to teach every SOC analyst every application that a business cares about. 13:48.230 --> 14:00.190 So making better use of the knowledge they have, giving them the tools to translate generic enterprise risks into key business risks, that's pretty critical. 14:00.950 --> 14:06.730 Collection and routing, logs, audit events, telemetry. 14:06.990 --> 14:12.510 I guess depending on where you work, who you work for, you might say, we're pretty good at this. 14:12.510 --> 14:15.190 You might say, I'm not quite so sure. 14:15.190 --> 14:18.110 You might even just put your hand up and say, no, we're terrible. 14:18.770 --> 14:30.390 I think every incident response engagement I've turned up to over the last five years hasn't had as much information as we would require to evaluate the system. 14:30.710 --> 14:34.170 And if you talk about enterprise, that's a really good example. 14:34.530 --> 14:40.970 We did a response engagement recently, where it turned out that actually it was a message queue that was being tampered with. 14:41.070 --> 14:41.950 And guess what? 14:41.950 --> 14:44.830 Their message queue had no useful logs at all. 14:44.850 --> 14:50.990 Nothing that told you that much about who was accessing the message queue, where they were accessing it from. 14:51.270 --> 15:03.690 And indeed, when we eventually managed to find the application logs, the development data essentially about how the message queue was functioning, and we found that it was logging the messages, we were so excited. 15:03.730 --> 15:10.550 But even with that information, trying to take that back to a SOC and say, actually, which of these are the legitimate events? 15:10.550 --> 15:11.610 Which of these are? 15:11.610 --> 15:15.870 It was a challenge, because the security organization just didn't understand that. 15:17.710 --> 15:19.830 Orchestration and enrichment. 15:21.810 --> 15:29.810 Key to those two previous points is getting SOCs to a point where they know what data is useful, and they know how to use it. 15:31.230 --> 15:36.190 It's easier to do with Windows, it's easier to do with endpoint devices. 15:36.410 --> 15:43.390 But actually, if you want to kick someone out of to go back to that point, a message bus, where do you start? 15:43.390 --> 15:44.750 What data is useful? 15:44.750 --> 15:49.810 We had to tell them every step of the way, because they simply didn't know. 15:50.590 --> 15:55.250 And then, of course, you look at things like the... what is bad? 15:56.250 --> 16:02.890 What does bad look like in an enterprise resource planning application in a Unix estate for microservices? 16:03.230 --> 16:06.650 So those capability gaps, we need to start to fill them. 16:09.010 --> 16:15.730 But all of that data exists, which is kind of why I argue that threat intelligence really should be a backstop. 16:16.110 --> 16:30.670 If we're not consuming the data that the organization is already generating in one form or another and using it effectively, we're going to be forced to use threat intelligence as our only means to identify threat actors, identify attacks. 16:31.730 --> 16:37.710 But in terms of threat intelligence, even there, we could be using it more effectively, right? 16:37.890 --> 16:46.390 We know the vulnerabilities exist, for 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 --> 17:04.790 We certainly don't construct the same degree of hypotheses around application vulnerabilities as we do around password cracking, phishing, etc. 17:05.530 --> 17:12.770 We need to get better at putting together hypotheses, straw men, that we can start to buy off in pieces. 17:13.050 --> 17:25.310 And ultimately, from a threat intelligence standpoint, we need to get better at tracking that kind of threat intelligence in just the same way that we track TTPs for enterprise threats. 17:26.290 --> 17:30.370 A SAP system will still have that kind of information. 17:31.090 --> 17:35.310 We should still be able to work out the validity of the information. 17:35.690 --> 17:39.730 We should still be able to understand where it might affect us as an organization. 17:39.730 --> 17:42.870 We should still be able to understand why an attacker might wish to do it. 17:43.030 --> 17:49.630 And we need to start to ask threat intelligence teams to give us that information so that we can make the right decisions. 17:51.390 --> 17:53.230 So that's some of the problems. 17:53.350 --> 17:56.030 Let's have perhaps a little bit of a solutions. 17:56.710 --> 18:11.670 And here, what I was really looking to do was to map some of the more traditional concepts of threat modeling, Stride, Microsoft's tooling, and equivalent into attack language, into kill chains, into the attack matrix. 18:13.270 --> 18:20.950 So working in Cisco, I have a pretty good source of information about all of the assessment work that we do. 18:21.510 --> 18:23.410 The vulnerabilities, the weaknesses. 18:24.010 --> 18:26.450 I have the ability to extend that tooling. 18:26.570 --> 18:35.770 So I kind of wanted to say, well, actually, if we've got vulnerability data from an assessment, how do we translate that into a threat model that a SOC can use? 18:35.770 --> 18:37.710 So I want to label our findings. 18:37.710 --> 18:40.470 I want to start to analyze our data a bit more depth. 18:41.690 --> 18:44.350 So that's our vulnerability model, fundamentally. 18:44.830 --> 19:00.570 We take all of the things you would find in a pen test, the idea of scoring criticality, defining the weakness in generic terms, describing the vulnerability, describing the impact, talking about recommendations, industry references, etc. 19:00.690 --> 19:06.070 But on top of that, we have our not inconsequential VDB. 19:06.310 --> 19:10.210 It's internal, but it imports from Nessus, from MITRE, and from other sources. 19:10.250 --> 19:12.830 And our reporting engine is really driven off that. 19:12.830 --> 19:18.610 So when we report a finding, if it's a finding we've seen before, it will come from our VDB. 19:18.750 --> 19:21.790 If it's a new finding, it will end up in our VDB. 19:21.890 --> 19:24.450 So we have quite a rich historical view. 19:25.530 --> 19:27.810 I won't say it goes back 20 years. 19:27.810 --> 19:31.190 We have to clear down a lot of customer data , as you can imagine. 19:31.350 --> 19:39.410 But certainly in terms of the VDB portion, we have an understanding about how vulnerability trends have changed over time. 19:39.510 --> 19:43.830 And we should be able to leverage that to build more interesting analysis. 19:44.810 --> 19:46.950 So what have we been doing? 19:47.210 --> 19:50.930 So we've been automating some of our scenario generation. 19:50.930 --> 20:01.570 We've been taking ATT&CK using PyTAC, which is a Python framework, to start to filter the STIX output from the ATT&CK matrix. 20:02.050 --> 20:17.810 We've been starting to look at how we label vulnerabilities in our VDB, vulnerabilities in our customer reports, with ATT&CK TTP, so that we can say, we found this vulnerability on a traditional pen test, but actually it maps here into your kill chain. 20:18.090 --> 20:21.050 And these are the kinds of controls you're likely to need. 20:21.050 --> 20:29.210 Not just the tactical fixes of yet you should go and patch, or yet you should go and harden this particular service. 20:29.210 --> 20:32.370 But actually, have you got monitoring here? 20:32.490 --> 20:38.450 Is this system being protected by behavioral analysis engines, etc? 20:38.770 --> 20:45.350 And then of course, we can take that information, we can export it out, and we're using STIX for that. 20:45.450 --> 20:47.810 And then we can do cross data sharing. 20:48.270 --> 20:58.650 So for example, I can take out vulnerability data from our reporting engine, and I can share it with TALOS, or with PISA, or with any of the other security teams that would sit within Cisco. 20:58.650 --> 21:11.230 The idea being that we can get a better understanding of what our customers' environments look like, and we can drive some of the features that we think are critical into, obviously, Cisco's products. 21:11.550 --> 21:18.990 And ultimately, we're taking some of that knowledge and using it to make more effective business risk analysis. 21:19.090 --> 21:28.090 And we're starting to go to customers and actually use these techniques on their data, not in our VDB, but on their risk management systems. 21:30.010 --> 21:33.430 So I talked about labeling findings. 21:33.470 --> 21:38.810 This is probably a pretty trivial example, certainly with the data that we have. 21:38.810 --> 21:49.110 But broadly speaking, we're scoring our findings, we're comparing those scores against ATT&CK TTP definitions, and we're labeling findings. 21:49.410 --> 21:56.290 And then we're identifying similar findings elsewhere, so that we can validate that the scorings we're applying are appropriate. 21:56.310 --> 22:17.210 And then applying labels where relevant, so that we start to build up a contextual map of how individual vulnerabilities, individual weaknesses found in an incident response engagement, incident instances of technical vulnerabilities in a red team, how they all map together. 22:19.570 --> 22:24.990 To do this, it's not necessarily trivial, certainly if you don't have the data to begin with. 22:24.990 --> 22:32.930 But in our instance, we've been developing plugins that give us customer views, platform views, ATT&CK surface views of our data. 22:33.630 --> 22:37.670 Like I said, we've been extending our findings to capture this information. 22:37.930 --> 22:45.950 But then we've been able to develop plugins that do that automation for us using the mechanism shown on the previous page. 22:46.490 --> 22:49.850 And then we can start to render that information in kind of useful fashion. 22:49.850 --> 23:01.990 So I think a couple of slides time, I'll show you an example where I've taken a bunch of vulnerabilities from our VDB and using a tool called Gephi, I've actually mapped them into a full keychain. 23:01.990 --> 23:05.610 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:17.270 Let's stop and pause for a second. 23:17.750 --> 23:20.570 CVSS is not a shoe size contest. 23:21.270 --> 23:25.570 How many organizations out there look at CVSS as a number? 23:26.190 --> 23:29.390 They look at a 10 and they go, we need to patch that immediately. 23:29.490 --> 23:33.690 They look at it as a six and they go, we can patch that in a little bit of time. 23:33.730 --> 23:36.910 They look at it as a three and they go, actually, we don't need to patch it at all. 23:37.810 --> 23:39.230 So frustrating. 23:41.390 --> 23:47.990 So what we've been doing there, we've been attempting to map CVSS into the cyber keychain. 23:48.750 --> 23:56.370 One of the reasons that CVSS is kind of quite interesting is because nobody feels fearful about sharing that data in isolation. 23:56.690 --> 24:00.570 If I go to a customer, I say, I don't want anything else about your estate. 24:00.570 --> 24:02.730 I'd like to know your CVSS scores. 24:03.610 --> 24:06.110 Most organizations feel comfortable with that. 24:06.390 --> 24:13.090 And what that means is that they can then give me some information, which actually, when you start to break it down, becomes slightly more useful. 24:15.770 --> 24:20.630 So this is a rough mapping of our model. 24:21.110 --> 24:25.430 And what I've essentially got on there on the left-hand side is all of the key kill chain phases. 24:26.010 --> 24:36.630 And then as you progress through, I've got the aspects of CVSS that are likely to impact or likely to be interesting in each of those stages. 24:37.090 --> 24:40.190 And then I've rated them in terms of how useful they are. 24:40.390 --> 24:54.090 So I'm able to say that, you know, from a confidentiality standpoint, if the confidentiality impact is high, that's probably going to be useful from a reconnaissance standpoint. 24:54.190 --> 24:57.930 It's also probably going to be useful from an actions and objective standpoint. 24:58.270 --> 25:02.310 And similarly, with some of those other nodes in that graph. 25:03.110 --> 25:05.290 And where you get to is this. 25:05.590 --> 25:22.710 If you take all of our BDB data, and indeed, if you take Cisco's publicly disclosed vulnerabilities, and you break down and you score in the way that I've described, you can see where individual vulnerabilities that we report to customers, individual vulnerabilities that get reported to us, 25:22.710 --> 25:30.970 well, how they potentially, and it's my model, so only potentially, how these potentially map into the kill chain phases. 25:31.290 --> 25:45.230 And given that the kill chain phase is inspired attack, we're then in a position where maybe we can start to look at actually which parts of the kill chain are we exercising effectively, which parts we're exercising badly. 25:45.330 --> 25:52.050 Yeah, we never report almost anything that helps us with weaponization. 25:52.070 --> 25:57.550 We rarely report anything that talks to installation. 26:00.190 --> 26:05.550 And command and control, well, actually, if you think about it from a pentest standpoint, that kind of makes sense. 26:05.550 --> 26:08.890 We're unlikely to really look at command and control. 26:08.890 --> 26:10.370 We're unlikely to look at installation. 26:10.370 --> 26:12.310 We're unlikely to look at weaponization. 26:12.690 --> 26:16.890 So it's almost reflective of what you expect to see. 26:16.890 --> 26:25.790 But what it means is actually, if we were doing a pentest tomorrow, if we were doing a threat hunt tomorrow, where perhaps should we focus our efforts? 26:26.170 --> 26:36.270 Installation and command and control might be kind of interesting if you're an organization that has regular pentests, simply for the fact that pentests are unlikely to produce useful findings in that space. 26:38.750 --> 26:47.670 And then I said we talked to some of our customers and started to use this kind of information on their risk databases, on their vulnerability databases. 26:48.330 --> 26:53.210 For that, we've been going into organizations, perhaps a couple of steps up the tree. 26:53.210 --> 26:56.190 We've been talking to CISOs, executives, etc. 26:56.370 --> 27:08.970 And we've been using this concept of FAIR, which is essentially a risk framework that allows you to talk about risk in quite an interesting way. 27:08.970 --> 27:17.430 It allows you to talk about things like resistive strength, threat capability, probability of action, primary loss, secondary loss, etc. 27:17.430 --> 27:21.010 And it allows you to put proper numeric scores. 27:21.010 --> 27:29.010 Indeed, FAIR encourages you to score in ultimately a dollar, a pound size value. 27:29.530 --> 27:35.330 But what it means is that we can go and talk to organizations at levels that the executive cares about. 27:35.330 --> 27:39.550 The executive doesn't necessarily care about CVSS version 10. 27:39.550 --> 27:52.230 What they care about is that they're able to trade, that their IP isn't being stolen, that if they're a bank, someone hasn't got access to the treasury and stolen all the money. 27:52.850 --> 28:01.970 So starting to take vulnerability data and turn it into business impact, business risk, etc. 28:01.970 --> 28:05.890 Yeah, that's kind of quite compelling to a lot of C-suite. 28:08.960 --> 28:10.980 So why do the labeling? 28:11.560 --> 28:16.500 This statement, it's a great statement and it's very true. 28:16.940 --> 28:20.340 Defenders thinking lists, attackers thinking graphs. 28:20.360 --> 28:23.620 If you think about it logically that makes perfect sense. 28:23.620 --> 28:26.480 An attacker doesn't care how they get into an organization. 28:27.200 --> 28:30.300 Yeah, if they can't get in one way, they'll get in another. 28:30.300 --> 28:31.680 That's a graph. 28:31.680 --> 28:38.120 If you think about how risk management businesses work, how risk management organizations work, guess what? 28:38.120 --> 28:42.100 For most part, they're operating on spreadsheets or the equivalent. 28:43.040 --> 28:51.440 So getting to a place where we can help those risk management functions think more effectively in graphs, that's kind of going to be useful. 28:52.020 --> 28:59.280 So when we do the labeling, it allows us to produce documents such as this. 28:59.560 --> 29:22.100 So this I think was from recollection was AWS, but essentially was taking all of the TTPs, all of the threat groups, all of the parts of the attack matrix and map them, filtered as I say through the view of AWS rather than the whole STIX object collection. 29:22.740 --> 29:27.920 But we're now starting to do the same thing with penetration tests. 29:28.000 --> 29:31.020 We're starting to do the same thing with red teaming. 29:31.020 --> 29:34.860 And hopefully we'll get to a point where we can deliver it right across the board. 29:35.340 --> 29:43.000 Every report in my view, this visualization is pretty key to helping people understand what matters to them. 29:45.540 --> 29:48.000 So that's all of the theory. 29:48.000 --> 29:51.700 That's all of the data science from a person that isn't a data scientist. 29:52.440 --> 29:56.940 What I really wanted to do is have a look at how our data maps to the real world. 29:57.140 --> 30:03.440 And I talked about the fact that my background is Unix and big systems and that attack doesn't really help. 30:03.780 --> 30:10.460 So I kind of constructed three hypotheses, which I thought were probably pretty short to evaluate. 30:11.340 --> 30:15.940 I was probably going to be challenged to find useful data to support me. 30:15.940 --> 30:17.840 But it was a starting point. 30:19.260 --> 30:22.120 So I chose my targets. 30:22.220 --> 30:23.400 As I said, Unix. 30:23.400 --> 30:24.600 I built hypotheses. 30:24.600 --> 30:26.500 I validated those hypotheses. 30:26.840 --> 30:32.120 And I'm hoping to start to feed some of that learning back into our reporting. 30:33.000 --> 30:37.660 And I'm certainly more comfortable to talk to some of the missed opportunities that I've seen along the way. 30:38.740 --> 30:45.480 So in terms of targeting, if you're familiar with Portcullis, obviously we're Cisco these days. 30:45.480 --> 30:50.040 But if you're familiar with Portcullis, you'll know we spent years doing lots of interesting stuff in Unix. 30:50.160 --> 30:51.840 It seemed a good place to start. 30:51.860 --> 30:58.080 We've written quite a lot of things that you could consider to be TTPs, if you were that way inclined. 30:58.480 --> 31:02.920 And as I said, we had quite a lot of access to our customer data. 31:03.360 --> 31:08.980 So we were able to do things like, actually, what have we reported over the last 10 years? 31:09.220 --> 31:19.000 And the way we have our data segmented means that our VDB keeps track of how many times a particular issue gets reported. 31:19.000 --> 31:30.280 Even if we clear down the customer data, we still have an understanding of trends going back not many decades, but certainly the last 5-10 years kind of thing. 31:31.420 --> 31:34.300 So the hypotheses I constructed. 31:35.260 --> 31:38.420 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:59.080 And attack is not representative of the TTPs that we, that is the traditional pen testing arm of Cisco, find success with when we go and do professional service engagements for our customers. 32:03.620 --> 32:07.060 So, hypothesis validation. 32:07.440 --> 32:11.460 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:30.220 And, as I said, there's a lack of information out there. 32:30.520 --> 32:35.120 So I was kind of hoping we'd go and have a look at a bunch of incident response reports. 32:35.800 --> 32:39.540 And we'd kind of say, okay, there's loads of useful information in there. 32:40.120 --> 32:41.060 Guess what? 32:41.060 --> 32:45.440 When you look at enterprise systems, that might be the case. 32:45.620 --> 32:50.680 When you go and look at big box servers, far less often does it occur. 32:51.240 --> 32:53.580 So we went back to the drawing board. 32:54.220 --> 33:06.300 Detonations, bits of attack that might be useful, a lot of Googling furiously, and to the point about VDBs, many of our other data sources. 33:09.650 --> 33:12.830 So, hypothesis one. 33:13.390 --> 33:16.310 Attackers are using our tools to target Unix environments. 33:16.310 --> 33:19.930 So, guess what? 33:20.010 --> 33:37.630 It's almost impossible to determine whether, if an attacker was to compromise a Unix box, and they would use off-the-shelf, publicly available tools, it's almost impossible to tell whether they'd actually be picked up. 33:37.770 --> 33:43.430 Unix privilege check was undetected in pretty much all of the cases. 33:43.450 --> 33:49.170 And even where it was detected, it wasn't classified as malicious. 33:50.570 --> 33:51.750 Kind of cool. 33:51.830 --> 33:57.070 I kind of like the fact that I could rock up, I could use this tool when I do an assessment. 33:57.330 --> 34:06.570 But actually, you probably want to know whether it's on your network, even if ultimately you go, it's the pen testers, and they're meant to be using it. 34:10.290 --> 34:12.110 Again, looking for detonations. 34:12.110 --> 34:15.870 I went out and had a look to see if anyone had spotted in the wild. 34:16.870 --> 34:17.410 And guess what? 34:17.410 --> 34:18.290 They haven't. 34:18.970 --> 34:21.630 Is that because it's not malicious? 34:22.010 --> 34:27.950 Is that because people have looked at it and kind of gone, we don't mind, it's only being used by pen testers. 34:29.170 --> 34:42.150 Actually, it's probably because if an attacker gets you onto a system, they're probably not going to pass it through a Windows box unless they absolutely have to, or at least not in a way that a Windows AV is like to pick it up. 34:42.810 --> 34:56.910 Which means that unless you have good telemetry on your Unix estate, both those tools, you're unlikely to see them up until the point that the breach occurs and you start going back through your historical data. 34:56.910 --> 35:14.730 And even then, you're probably not going to see it unless you've got an attacker that's left it in the history, or an attacker who has left it on the file system, or an attacker who is ultimately pretty incompetent. 35:14.930 --> 35:20.350 If I wanted to get those tools onto a Unix box right now, I could do so. 35:20.350 --> 35:31.090 The fact that we don't even have the telemetry to allow us to spot the sloppy amongst us is probably a challenge that we ought to address. 35:33.730 --> 35:35.870 So, science of life and attack. 35:35.870 --> 35:39.010 Well, neither of those tools are mentioned. 35:39.070 --> 35:44.570 Kind of understand why it's not generic enterprise attacks tools. 35:45.290 --> 35:46.570 But guess what? 35:46.570 --> 35:49.830 It's used by almost every penetration tester out there. 35:49.830 --> 35:52.170 It's in lots and lots of tutorials. 35:52.290 --> 35:57.630 And it's even being used by people that we would probably consider to be threat actors. 35:57.630 --> 36:06.810 Phineas Fisher literally mentions it in his paper around how to breach organizations. 36:06.810 --> 36:12.310 Now, you might argue that Phineas Fisher isn't an adversary you care about. 36:12.330 --> 36:13.810 It didn't really matter. 36:13.810 --> 36:21.670 The fact that we haven't even identified these tools exist when our own community knows they exist and is using them. 36:22.270 --> 36:25.070 You know, we talk about offensive security tools. 36:25.070 --> 36:30.410 These are offensive security tools that will be being used by people and we'll just never see it. 36:32.310 --> 36:34.590 So, the second hypothesis. 36:35.050 --> 36:38.610 Attackers are using techniques from attack to target Unix environments. 36:39.310 --> 36:42.390 Like I said, that's pretty hard in a practical sense. 36:42.770 --> 36:51.870 If you look at the stuff that comes up in attack from a Linux standpoint, it's mostly IOT or front end centric. 36:52.810 --> 36:55.070 It's a bit of a chicken and egg situation. 36:55.070 --> 36:59.990 If you can't monitor your estate effectively, you're probably not going to spot it. 37:00.210 --> 37:09.910 And from an incident response standpoint, well, organizations, perhaps they're not going to be particularly honest, certainly publicly, about just how deep breaches went. 37:10.370 --> 37:19.570 But anecdotally, and I'll call back to the Phineas Fisher point, they certainly are doing things that would fall into the attack categories. 37:20.270 --> 37:22.770 Unix backend breaches do occur. 37:23.770 --> 37:28.350 There is almost always some level of application level interaction. 37:28.490 --> 37:32.350 Remember I said the value of any asset is the data that it holds. 37:34.450 --> 37:38.130 Some access are truly incompetent if it's not a Linux host. 37:38.130 --> 37:43.310 We did an incident response engagement for a mainframe platform that had a Unix-like shell. 37:43.910 --> 37:56.010 And the attacker had gone to that Unix shell without really realizing what they'd done and poked around a bit, not had a huge amount of success, and then attempted to wipe their evidence. 37:58.590 --> 38:13.790 If I'm looking at this critically, the TTPs from attacker are actually probably still 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:28.640 If anybody wants to know what a good breach report looks like, this is probably the best one I've found. 38:29.360 --> 38:32.280 It's looking at fast cache on AIX. 38:32.920 --> 38:39.580 And it's not perfect, but it does support the fact that a lot of this stuff is stuff that attack knows about. 38:40.380 --> 38:44.700 Okay, it's AIX, not Linux, but question marks against that. 38:44.700 --> 39:01.520 But it certainly calls out to the same techniques that the fast cache malware was using in terms of persistence, privilege escalation, evasion, persistence, impact, etc. 39:02.760 --> 39:08.300 There's a little bit of speculation on application and entry point, probably not enough. 39:08.620 --> 39:15.000 But this is the kind of thing, in my mind, should be going into the attack matrix. 39:15.300 --> 39:21.280 Or if it's not going to the attack matrix, should be going into the equivalent matrix for business systems. 39:21.280 --> 39:25.720 If we don't capture this kind of information, we're never going to get our socks to start looking for them. 39:28.740 --> 39:30.320 So hypothesis three. 39:30.360 --> 39:32.340 So this was taken from our VDB. 39:33.060 --> 39:40.280 I took the top 10 or so issues that we regularly report to customers when we go and look at Unix systems. 39:40.280 --> 39:47.140 I went and I had a look at whether they were captured inside ATT&CK as it stands today. 39:48.520 --> 39:52.320 Security patches, password reuse, etc. 39:52.460 --> 39:53.960 They're all covered. 39:55.440 --> 39:58.480 Role accounts for interactive logins. 39:58.540 --> 40:04.320 Semi covered, but perhaps not the way I would have viewed it from my standpoint. 40:04.880 --> 40:10.720 That third, fourth one down, that's not captured at all in any useful sense. 40:12.440 --> 40:19.220 It gets us into almost every enterprise Unix box we go and look at. 40:19.340 --> 40:23.380 You get your role account, you get your low privilege user. 40:23.620 --> 40:26.760 Almost every single one of them will get to read through that. 40:28.040 --> 40:41.340 So we ought to make sure that ATT&CK factors that in, describes it, and gives the information that allows a sock to start to detect, to start to respond when those kinds of attacks are used. 40:43.340 --> 40:54.880 So broadly speaking, I guess where we're at, I think we don't have the right level of platform and application awareness today, which inevitably means there's an intelligence gap. 40:55.220 --> 41:08.940 Which means that no matter whether you're doing intelligence, whether you're modeling, whether you're simulating, or whether you're hunting, you're going to be working, I think, from an incomplete set of hypotheses. 41:09.140 --> 41:16.100 Which means that the models that you're working to probably don't relate to the systems that you're actually caring about. 41:16.640 --> 41:22.860 And you're probably not going to be as accurate as you might want to be when you start to validate them. 41:25.060 --> 41:27.560 How do we improve all of this? 41:27.960 --> 41:30.120 It's the million dollar question. 41:33.260 --> 41:35.580 Threat modeling certainly plays a part. 41:35.580 --> 41:53.900 If you were simply to take the approach I did with the vulnerabilities, and use that to drive the threat models for systems you don't know about, you would certainly get to a place where your blue team would probably have a better understanding of what bad is likely to look like. 41:55.480 --> 42:01.520 Once your blue team have an understanding, then they can drive the visibility. 42:02.420 --> 42:08.640 And then you can start to refocus your offensive services to validate that visibility is appropriate. 42:11.020 --> 42:17.140 Ultimately, I would posit that at least some of the problem is there aren't enough bums on blue team seats. 42:18.520 --> 42:32.460 I guess what I mean by that, we need to find a way of making it attractive to have those people that understand those applications, the security models behind them, sitting directly in the blue teams, or certainly sitting adjacent to those blue teams, 42:32.460 --> 42:40.480 so that the blue teams can start to 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:56.640 We probably can work on threat visibility and on target visibility, if we know what we're aiming for. 42:57.940 --> 43:04.140 If we understand the threats, we can better protect our customers and our data. 43:04.860 --> 43:25.720 More importantly, if you can start to talk about individual vulnerabilities, in terms of their impact or threat model on the kill chain, not only can you make sure that your SDLC is looking for the right things, but you can also make sure that the people that are doing the code, 43:25.720 --> 43:33.720 you know, the people that are sitting there writing the web applications, writing the code that interfaces with your message bus, your database, etc. 43:33.720 --> 43:38.420 So they understand why and how an attacker might attack them. 43:38.620 --> 43:46.520 And hopefully we'll get into a situation where less vulnerabilities of note will make it into business applications in G-course. 43:46.720 --> 43:51.300 Ultimately, organizations will have profit motivated. 43:52.260 --> 44:06.740 And if we can talk in language that makes it apparent to the C-suite why it matters, what the cost of not doing X is, 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:17.260 I think there's life beyond Nessus and MITRE. 44:18.440 --> 44:22.980 But that data is still useful, even from a red team standpoint. 44:23.440 --> 44:29.480 I guess we need to figure out how to use it more effectively. 44:30.700 --> 44:41.260 You know, we need to be in a position where we can far more quickly, far more comfortably talk to the kinds of bespoke briefings that organizations want. 44:42.460 --> 44:49.180 Craft war games that are actually appropriate to the things that matter to a business. 44:49.740 --> 44:53.300 We need to be able to articulate all of that. 44:54.000 --> 45:00.560 And obviously, better metadata, visual representation certainly helps with that communication piece. 45:00.560 --> 45:04.420 And we need to refine our assessment methodologies. 45:04.420 --> 45:11.220 I think too much of pen testing today is focused on the break in. 45:11.360 --> 45:31.920 And I think the data I showed around CVSS shows that actually, given that pen tests are still the lowest bar most organizations will jump through, they're actually getting testers to a place where they feel comfortable to talk about the other side of the line. 45:31.980 --> 45:33.760 The system has been compromised. 45:33.760 --> 45:39.500 How do we get back out is something we probably ought to focus more time on. 45:40.980 --> 45:42.940 So some conclusions. 45:43.260 --> 45:44.720 What have we learned? 45:44.840 --> 45:46.360 How do we do this better? 45:46.360 --> 45:47.560 Next steps. 45:49.380 --> 45:52.780 We can automate extraction of hypotheses. 45:52.940 --> 45:57.240 We can build threat models in an automated fashion. 45:59.460 --> 46:10.280 Vulnerability data, no matter how poor you may think it is, could still be useful with the right labeling applied. 46:12.280 --> 46:24.480 Actually, from a tester standpoint, it'd be kind of great if we rocked up organizations and they had a threat model based on their existing understanding of their vulnerability state. 46:25.720 --> 46:34.180 Extract your quality information, build that threat model, give it to the tester at the start and say, this is kind of where we think the threats live. 46:34.540 --> 46:36.120 Help us validate that. 46:38.260 --> 46:49.280 Again, if you can get to a place where you can take your vulnerability data and start to 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:00.740 Ultimately, it's a communication problem, right? 47:00.900 --> 47:11.160 Attack has given us a wonderful tool to help us bridge the gap between red and blue, between operational and management. 47:11.160 --> 47:15.040 We just need to make sure we take the best advantage of it. 47:16.060 --> 47:17.760 So doing this better. 47:19.160 --> 47:21.060 Better consideration. 47:21.380 --> 47:27.200 I know that from a red team standpoint, we would argue that perhaps we're there. 47:27.380 --> 47:41.420 But actually, I don't think a VA, a generic pen test necessarily needs to consider the scope they're given to be an impedance to giving better outcomes to customers. 47:43.140 --> 47:56.680 We do a really good job of collecting awesome information about threats and vulnerabilities, whether it's Reddit, whether it's peer list, unfortunately closed down, or anywhere else. 47:56.720 --> 48:01.140 But even that data, we don't particularly do a good job of enriching it. 48:01.340 --> 48:07.380 Having a platform that allows proper automated enrichment of that kind of information. 48:08.340 --> 48:12.020 Maybe you're lucky and you're sitting in an organization that has it. 48:12.020 --> 48:14.440 It's a bit of a forlorn dream for me. 48:16.040 --> 48:23.960 Personally, getting our database to a point it's fully labeled and being able to run queries against those labels will be pretty kick ass. 48:25.260 --> 48:29.260 Taking that the next step and making it actionable. 48:29.400 --> 48:31.720 I mentioned that we use sticks. 48:31.720 --> 48:36.200 Sticks is good at talking about the types of threats. 48:36.740 --> 48:42.840 It doesn't really capture the level of information that's required for machine action ability. 48:43.320 --> 48:47.380 There are some solutions to that, the Sigma and others. 48:47.840 --> 48:53.700 But we're really not at a point where we define vulnerabilities in a way that's particularly helpful for scale. 48:55.440 --> 49:03.780 And ultimately, if we don't generate for scale, improving EDR and workload protection products is going to be pretty forlorn. 49:03.780 --> 49:23.720 If every vulnerability report that every pen test or security researcher turned out had essentially a cool chain graph that an EDR solution or workload protection product could import and then look for, rather than being reliant upon hashes, IP addresses, 49:23.720 --> 49:28.440 host names, that would take us a huge way forwards. 49:30.400 --> 49:33.500 So next steps, call to action, I guess. 49:35.540 --> 49:41.200 Just because we don't have the capabilities to look for bad guys doesn't mean they're not there. 49:42.600 --> 49:46.400 Attackers, we use the easiest TTPs that get them to the root prompt. 49:46.500 --> 49:49.560 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:08.060 If you're doing Unix stuff, make sure you're exercising those things, because the bad guys certainly are. 50:09.280 --> 50:21.460 And Linux apps, Unix check, I kind of look forward to the day when they appear in a virus title, and they're being detonated and being marked as malicious. 50:21.640 --> 50:27.740 It'll make my job a little bit harder, but actually it'll make Blue Team's jobs a hell of a lot easier. 50:31.080 --> 50:40.520 Finally , a few thanks, my old colleagues, Cisco's wider team, MITRE, ATT &CK wouldn't exist without them. 50:41.120 --> 50:49.420 Swimlane, PyTAC is still the most comfortable interface I've found rather than writing in Perl. 50:49.920 --> 50:56.180 And Blue Team's everywhere, because you do a thankless job, and for the most part, you do it as well as you can do. 50:57.480 --> 50:59.600 And with that, questions?