start	end	text
0	6440	So, yeah, I'm here presenting today on Cloud Native Attack Detection and Simulation.
7280	11400	It's an expansion of a talk I did at Forward CloudSec, and we've spoken previously on some
11400	15060	of this at some other conferences, too. But this is the first time I've had the opportunity,
15060	19540	really, to gather it all together into one big presentation. So I'm really happy to be here.
19540	24720	Hopefully, everyone will get something out of it. So there's a few key things to go through
24720	29880	today, really. The first thing is that I want to spend some time kind of comparing and contrasting
30000	36660	on-premise detection and cloud detection, what the key differences are between them, and some
37260	41800	critical architectural differences, but also just in terms of what an attacker's likely to try
41800	48620	versus what they did on-premise, how a lot of that varies. Yeah, exactly, digging into the
48620	54160	likely attacker activity, we're going to see what that actually comes out as on the cloud side of
54160	59520	things, what you should be looking for, where you should be looking for it, and so on. And lastly,
59520	64480	the simulation piece, sort of buzzword is this is the idea of bringing DevOps to detection.
64660	69320	We've seen a real strong uptake in a lot of the DevOps tooling in the cloud space,
69320	74400	because it makes everything easier if you can automate stuff. So we've spent quite a lot of
74400	79740	time building out some tooling that we've open-sourced to do just that, and we'll talk
79740	85580	through that in some more detail. But just before we get started, I'm sure pretty much everyone's
85580	90800	seen some sort of threat actor pyramid. I've got a slightly different take on it to what you often
90800	94500	see, in that rather than putting sort of China and Russia at the top and a bunch of script kiddies
94500	100320	at the bottom, we're talking more about capabilities than we are about individual groups.
100440	105420	So what we've got at the top is bespoke tactics, techniques, and procedures, things that attackers
105420	110220	are developing and designing specifically for whatever campaign they're on. And the middle
110220	114460	bracket, custom tooling, is where attackers are in a position where perhaps they're not
114460	118500	developing their own ODAs or doing their own security research, but they are building their
118500	123420	own implants, their own tools, and so on. And sort of the bottom end of the pile is people grabbing
123420	128500	tools off GitHub and firing them off willy-nilly across the world. And the reason I bring
128500	134640	this up is because, to me, the interesting part of detection sits at the top end there, at the bespoke
134640	139900	TTPs, the custom tooling. And realistically, that's also a very expensive place to sit if you're
139900	146260	trying to build detective capability. And so a lot of what I do is around driving the costs down
146260	154360	or making it easier for organizations and for people to pick up the top end, the advanced
154360	158780	end of detection, and use it within their organization. And that will come up quite a
158780	166240	few times through today's talk. So first off, on-premise versus cloud. So there's quite a few
166240	170620	key differences here, really, when it comes to attack detection. And one of the biggest is just
170620	176160	in terms of the telemetry that we've got. So on-premise, historically, the vast majority of the
176160	183640	useful telemetry and data that we'd be threat hunting in sat around the endpoint. So we're
183640	188360	running endpoint detection response products, you know, pick your favorite from CrowdStrike, Tanium,
188360	193480	Cyberese, and those sorts of things. And so we'd be running those on all of our endpoints, probably
193480	200580	our servers too, and gathering information like process execution trees, you know, what's
200580	205320	happening in memory, looking for specific syscalls and Windows API calls that might be malicious.
205580	209760	And we do a lot of our detection on that. If you've paid dark trace or vector a lot of money,
209760	214300	you might also have some network telemetry, but it's usually a secondary source. Likewise, with
214300	219340	data you might be getting out of your applications. The one key exception there is I'm going to class
219340	225440	Active Directory as an application in this little diagram here. Active Directory, obviously, is one
225440	230160	of the big points we can get a lot of useful detection information out of on-premise, especially
230160	234000	when it comes to sort of lateral movement and privilege escalation. But by and large, still,
234000	238860	you know, we're focused in really on the endpoints of the servers. Now, when we go to cloud, we've
238860	242240	still got all of that to some degree, especially if you're still running virtual machines in a lot
242240	247280	of your cloud environments, you know, you're running containers, we've got container security
247280	251660	monitoring solutions now that work with that. But actually, we've now got this box that sits around
251660	257320	it all, which I'm going to call control plane telemetry. So that is data that we're getting out
257320	264400	of the cloud itself and from a given cloud provider about what's being done from an administrative
264400	268980	perspective inside the cloud account that you're looking at, or the Azure subscription or Google
268980	275060	Cloud projects about who's creating, modifying, destroying what resources, where, when, and how
275060	282020	they're doing that. And so that really actually forms then the core of your detective capability
282020	286920	in the cloud. Attackers are still going to do some of what they used to on the endpoints
286920	292180	and at the network level. But really, a lot of the threats we've seen, and in fact, a lot of
292180	296580	the successful attacks, Capital One springs to mind, you know, happened against the control plane
296580	303240	where an attacker's got hold of some credentials for the AWS account, the Azure subscription,
303240	310920	and they're targeting that. Now, what comes with that is just a dearth of knowledge, really,
310920	315100	in terms of what that actually looks like. We've had sort of 20, 30 years to build up an
315100	319520	understanding of what an attack on premise looks like. We know what an attacker is going to try
319520	324980	on a Windows network full of, you know, Windows laptops connected to an Active Directory
324980	328980	infrastructure. It's all pretty well understood. And new techniques come out all the time.
329020	333080	But at the end of the day, the broad attack vectors and a lot of the stuff we should be
333080	339980	looking for are all pretty consistent, or at least reasonably well known, even if not
339980	345000	always that easy to spot. The problem then comes when we move to the cloud. Not only are we
345000	348740	dealing with more platforms than we used to, but also we just don't really have an idea of what
348940	353580	a lot of this stuff looks like now. Attackers aren't targeting workstations and virtual
353580	363060	machines. We're targeting serverless functions, Kubernetes clusters, the control plane. And so,
363060	368660	what that looks like. What an attacker is likely to try. And it's just nowhere near as well
368660	374940	understood. That said, from my experiences working in this space, I think there's a few key things
374940	382180	to call out, really. One of which is that there's this concept of uncertainty of malicious intent.
382660	387620	On premise, there's a lot of stuff that's very malicious and it's easy to signature off. That
387620	391440	doesn't really exist in the cloud. We'll get into that in a bit more detail in a second.
392020	397480	But one of the other things that comes with it is that context is key. Understanding what an
397480	401580	attacker is doing in a specific environment rather than just what they're doing in general
401580	407080	in a Windows estate. These things vary an awful lot in the cloud, whereas they didn't historically
407080	410860	on premise to anything like the same degree. And again, get into that more in a second.
411020	414140	And one of the big wins from a detection perspective in the cloud is that visibility
414140	420280	tends to be a lot easier. And so, if you look at Google Cloud, for instance, we can turn on
420280	425840	audit logs. In fact, they're turned on by default. And we can feed those into a Google Cloud
425840	431760	organization-wide log sync and get all of the logs for all of our projects at the control plane
431760	436280	layer fed straight into a single location and ship it from there off into our scene.
436440	441380	And there's no more sort of, we've got our EDR on 90% of our laptops, but there's these 10%
441380	445740	of legacy Windows 2000 boxes that we can't do anything with. There's nothing like that.
446340	451560	The problem comes, actually, that now shadow IT is even more of a problem than it used to be,
451560	455440	because it used to be that if you had shadow IT in your on-premise environments, you could probably
455440	459940	still walk around to a switch and have a look at what was plugged into it. And now you've got
459940	465260	pretty much zero visibility of marketing walking out to one of their third-party suppliers and
465260	470000	saying, hey, build us a website for this marketing campaign. Here's an AWS account that we registered
470000	474300	yesterday with one of our credit cards. Keeping track of that's really, really hard. And actually,
474300	478140	one of the tricks we've seen a few organizations use is to get really friendly with the finance
478140	483820	department and ask finance to essentially report all transactions for the cloud providers. And then
483820	487540	you can chase down which teams are doing what that way. It's a bit of a low-tech solution by
487540	494340	our usual approaches, but it works pretty well. And lastly, while we've got this fantastic ability
494340	500820	to automate lots of things in the cloud now with all the APIs they expose, the problem now is that
500820	505940	we're not the only ones leveraging that, right? Attackers are also automating a lot of what they
505940	513440	do. The classic example here, again, with AWS is attackers leveraging access keys that are linked
513440	520000	to GitHub for Bitcoin mining. You can subscribe to a public feed of commits to public GitHub
520000	525000	repositories, and attackers tend to feed that straight into essentially their own continuous
525000	529540	delivery platforms, which monitor the commits to public repositories, look for things that look
529540	535400	like AWS access keys, and feed those straight into a system that will then deploy Bitcoin miners in
535400	541380	the account of the compromised creds. It's gotten bad enough now that the meantime to compromise
541380	547160	between keys hitting GitHub and Bitcoin mining startings, about 20 to 30 seconds, and Amazon
547160	552860	themselves started monitoring that same feed and revoking keys when they find them. So while
552860	555820	obviously that's pretty low-tech and in the grand scheme of things not that interesting,
556640	559800	the fact that we're seeing that automated makes me think that in the long run
559800	563860	we're going to start seeing attackers building out tooling and capabilities that focus on
563860	567680	getting in and doing as much damage or as much of what they want to do as rapidly as possible
568240	570920	before the defenders have woken up and realize there's a problem.
572600	578380	And so I mentioned mindset shift here. We have this idea of uncertainty of malicious intent.
578380	582680	So there are some things that we know are obviously bad. If you've got Mimikatz running on a system,
582680	585820	that's probably not supposed to be happening. Likewise, someone accessing
585820	591300	LSAS memory or, you know, there's a variety of fairly common things that are obviously bad and
591300	596540	we can signature on them, right? That's how antivirus has been working for the last 20 years.
596940	602740	Some things are usually bad. HTA spawning PowerShell is a classic example there, but
602740	608560	actually that's not always bad. We were doing some threat hunting on one organization's estates
608560	613940	and found that when we ran a query for PowerShell being spawned by MSHTA files,
613940	618720	we got like 15,000 hits or something. So we immediately thought there'd been a major
618720	622160	compromise and started digging into it. And it turns out that actually Hewlett-Packard
622160	628080	enterprise printer drivers for a certain set of models work by, or the driver installations work
628080	634480	by using an MSHTA file to spawn PowerShell to do the installation. So it's probably bad,
634480	639880	it might not be. And then you've also got things like users requesting Kerberos tickets for
639880	645240	services they've not spoken to before, you know, network comms that isn't normal, but doesn't
645240	649480	immediately stick out as malicious and things that bear further investigation rather than things that
649480	653860	you immediately signature on. The problem in cloud is that there are very few things that are
653860	660840	obviously or usually bad. There's a few, but there's not many. The vast majority of what I'd
660840	665320	expect an attacker to do and what I see people doing when they're doing offensive security
665320	672080	testing revolves around abusing legitimate functionality, API calls that the cloud
672080	679620	providers expose to, you know, install persistence mechanisms, escalate their privileges, access
679620	684480	data they shouldn't be, all of these kinds of things. And so everything becomes about context.
685780	692820	So let's say we've got a, we're in AWS, we've got an IAM user, we've had some access keys added to
692820	698820	that IAM user. In principle, that might be okay, that might not. So we dig into it. It turns out
698820	704540	that was made, or that change was made by a user account or a set of access keys associated with
704540	709640	some kind of continuous delivery pipeline that we're running on premise. Okay, that's probably
709640	715500	fine. You know, actually that might be expected in this environment. But if we've got a change
715500	720100	made by an administrator from a weird network location, maybe without his 2FA that you'd
720100	724840	usually be using or something else, that actually might not be. And so we might want to further
724840	730300	investigate. But that might well be entirely dependent on the environment. And there are two
730300	734980	things that will come out of this. One of which is that over time attackers are going to become
734980	739880	more and more context aware. I'm already seeing that sort of continuous integration, continuous
739880	744480	delivery systems are favorite targets of a lot of attackers. I'll get into that in a bit.
744940	749680	And so being able to masquerade as sort of known trusted entities will become more of a thing over
749680	756840	time. But equally, that then presents a real problem for managed detection and response
756840	763140	providers or MSSPs who are trying to monitor a wide variety of client estates. Because there's
763140	768220	no such thing anymore as, you know, we detect known bad and that's great. We've got to be able
768220	774400	to monitor on a per environment basis, not even per customer or client. And so that's where things
774400	778520	like user behavior analytics starts becoming really useful. You know, is this behavior normal
778520	783120	for this environment, for this specific entity? Or is this something that we've never seen before?
783380	787280	Even just things like least frequency analysis, you know, for this environment, how often do we
787280	791700	see this particular API call made? You know, if it's never been called before, then that might
791700	796280	warrant some investigation. If it happens 500 times a day, then well, it's probably fine.
797480	801620	Equally, the other thing that comes out of this is that there are some things that just don't
801620	808120	exist from on premise in terms of actions and attackers likely to perform. And so let's say,
808120	814820	again, we're working in AWS, we've got an attacker who comes in and they run IAM create policy version
814820	821020	to create a new version of the policy document for one of the policies that's attached to them.
821020	826600	And so this is changing the permissions they've got by altering the permissions definitions,
826600	832280	basically. And actually, if you can do create policy version on any resource, and you have
832280	837500	policies attached to you, then that essentially gives you admin access. There's a concept that
837500	841340	doesn't really exist to the same degree on premise. So there's a number of these sorts of actions
841340	845520	where we don't really have an on premise equivalent. And these are kind of new techniques that
845520	847560	defenders are going to have to get their heads around.
848780	852960	This is then massively complicated by the fact that your average enterprise really isn't
852960	858320	one cloud provider with a few cloud accounts these days, right? I can't remember the last
858320	864020	time I went to a client and they said, we're just in AWS or we're just in Azure, and it turned out
864020	870480	to be true. F-Secure is a great example for that. In fact, we use AWS very heavily, but we have got
870480	875700	bits of Google Cloud and Azure lying around as well for various reasons. But even if you're
875700	881620	just looking at that, that's a fairly complex thing to deal with in and of itself. Multiple
881620	886260	cloud providers and completely different technology stacks and different log formats, all of that kind
886260	891140	of thing. When you then expand that to include everything else that exists in most organizations,
891140	895260	cloud estates these days, you know, we're probably pulling container images down from Docker Hub,
895260	900360	storing our source code in GitHub or something like that. We're probably using Slack for
900360	906780	comms and we've got Office 365 for our emails and all of these are fairly juicy targets for
906780	911340	an attacker in one respect or another. And they all need monitoring to some degree, which presents
911500	914400	a pretty big problem for a lot of organizations really, just getting their heads around all of
914400	921900	this. So when it comes to actually designing how you do detection in the cloud, I think it would
921900	927040	be worth just pausing for a second and talking through a few key observations that we've made
927700	933740	about how to successfully try and integrate sort of that much of a disparate estate, you know,
933900	940600	a wide variety of technology platforms. And the big one really is to centralize everything.
941000	945820	Have a single scene that handles your on-premise, your cloud, your everything, ship all of your
945820	952160	logs into it from everywhere, you know, all into the same single place. One thing that we've
952160	957740	definitely noticed is that if you have a security operations center or a threat hunting team,
957740	963160	what have you, who are monitoring quite a disparate estate, the more things you make
963160	967380	them go look at, the more likely it is that some things are going to get missed or people
967380	971700	aren't really paying as much attention to one thing as the others. So put it all in one place.
971860	974640	And the other thing you'll note here with this diagram is that for each of the major cloud
974640	979340	providers, there's like one account that we're shipping logs off to before they go into the scene.
979720	983980	And there's a few big benefits to this, really. One of which is that if we're shipping all of
983980	988960	our logs to a centralized location, we can lock that down to some degree so that only our security
988960	994640	people can access it, which means that all the logs, even when they're in the cloud still,
994640	998020	are in a place that an attacker probably doesn't immediately have access to if they've compromised
998020	1002920	one of the project's accounts. And it means that it's then relatively straightforward as well for
1003380	1007480	defenders if, let's say, there's some issues with the scene or they need more data than that's
1007480	1012220	actually being shipped off to the scene for various reasons. Spunk charging per gigabyte
1012220	1016880	is usually one of the examples there behind why that doesn't happen. You might need more data.
1016880	1022060	So you go into this one location for each cloud provider, and that's where that data lives.
1023380	1027860	And there's also a few key data sources to be looking at here. And I'm going to pick a couple
1027860	1032960	out to dig into in detail. But you'll notice from this table, the control plane audit logs
1032960	1037200	have bolded at the top there. And there's a very good reason for that. And that is that,
1037200	1042840	in my experience, something like probably 70-80% of attacker activity is going to show up in those
1042840	1047340	control plane logs when we're looking at the cloud. Just because even if an attacker is targeting
1047340	1050700	virtual machines or what have you, they're eventually likely to want to pivot out into
1050700	1055540	the underlying control plane layer and start messing around with other resources in the
1055540	1060000	environment, data stores, or escalate their privileges or anything like that. That's all
1060000	1067700	going to come down through the control plane. So for AWS, you've got CloudTrail, you've got audit
1067700	1076120	log in both Azure and GCP, and actually Kubernetes has that for the Kubernetes API too. And as we
1076120	1082460	say here, this logs almost every control plane level event. I say almost because people keep
1082460	1088560	proving me wrong with that with AWS CloudTrail. We've seen a few people now digging around trying
1088560	1092620	to find API calls that aren't correctly logged, and there are a few here and there. AWS do their
1092620	1097960	best to catch them, but I'm sure that same issue will exist in Azure and GCP. But by and large,
1097960	1103200	you're going to get logging for pretty much everything that happens. The key thing to
1103200	1107720	remember here is to make sure that you have it all turned on properly. AWS is particularly bad
1107720	1111460	for this in that CloudTrail has a number of different knobs and settings you can tweak
1111940	1119320	that vary what it logs and how it logs it. So often we find that either multi-region logging
1119320	1123360	hasn't been turned on, which means you're only getting data for US East 1 or wherever it is
1123360	1127480	you've got the trail deployed. And equally, if you don't have global events enabled, then you
1127480	1132080	don't get anything for IAM or a couple of other critical services. So it's well worth digging
1132080	1135520	into your provider's documentation and working out exactly what you should have turned on there
1135520	1143300	and making sure you've got that. Now, Cloud Native Detection Services. So GuardDuty is
1143300	1147640	probably the big name here, but you've also got Advanced Threat Protection from Azure and
1148780	1152800	Security Command Center from Google has some of this built into its tool.
1153000	1159000	And what we've got here is automatic detection of lower sophistication attacker activity.
1159620	1163780	And what I mean by that is this is essentially sort of antivirus for cloud. We're spotting known
1163780	1169700	bad things like network communications to known malware command and control addresses.
1170220	1177360	In the case of GuardDuty, it'll detect when someone tries to run commands from AWS API commands
1177360	1182180	from Kali Linux if they haven't changed the user agent on the basis that obviously everyone using
1182180	1187700	Kali Linux must be bad, so therefore we should be firing alerts for it. And while they have their
1187700	1193440	flaws, actually they're still a pretty cost effective way of detecting sort of low complexity,
1193440	1200360	low sophistication attacks. So I would always turn it on. I just wouldn't rely on it. You know,
1200360	1203040	you need more than this to be able to spot more advanced attackers.
1204580	1209380	I'm also leaving out Sentinel when we're talking about this. So Sentinel is Microsoft's scene
1209380	1216300	that they go with or they pair with Azure. And actually Sentinel's pretty capable by and of
1216300	1221760	itself. And there's a pretty great team of people building some pretty serious capability into that
1221760	1225080	that goes well beyond what we've seen in GuardDuty and what they've got in the
1225080	1230580	advanced threat protection package. And so if you're in Azure and you've not got anything like
1230580	1234900	this set up yet, I'd definitely be looking quite hard at Sentinel. We've been pretty impressed with
1234900	1241980	it where we've been running into it so far. Service specific telemetry is the last one I
1241980	1246940	want to dig into here when we're talking about log sources. So here we're talking about the kind
1246940	1252000	of logs you get out of things like storage accounts, access and object logs, executions
1252000	1259000	of serverless functions, audit logs from your key management system keys, this sort of thing where
1259000	1264100	we've got specific telemetry about what's happening inside a specific service or set of resources.
1265000	1270120	This is a bit of an interesting one because everything here is going to be case by case.
1270520	1274680	Sometimes this data could be extremely valuable. Sometimes it could be basically useless.
1275280	1280280	So you're going to end up needing to tune this on a per environment basis and choose what to turn
1280280	1284600	on and where, you know, as relevant depending on what use you think you're going to get out
1284600	1292780	of the data. So one good example here is S3 access logs in AWS. If we've got an S3 bucket that's
1292780	1299580	doing nothing but hosting images and CSS files for a static website, we really don't care who's
1299580	1304300	accessing it. On the other hand, if you have your organization's most important data in some S3
1304300	1309040	buckets, it's probably well worth having those logs turned on so that you can spot who's accessing
1309040	1315000	them where, when, and how. So, yeah, this one takes a bit more thought. But once you've got,
1315000	1321080	like, the key main sources turned on, the audit logs, that sort of thing, this is well worth
1321080	1328660	looking into, I think. So next up, one of the real problems we've got at the moment is having
1328660	1335400	talked now about what data you can get to detect attacks with, we've got to work out what an attack
1335400	1339380	actually looks like, right? I've spoken a little bit about that to some degree, but we've got a
1339380	1343580	real problem actually at the moment just in terms of getting hold of data to show what attackers
1343580	1348800	are actually doing in the cloud. So I've been talking on and off to MITRE's cloud team about
1348800	1354080	this for the MITRE attack framework, and they're doing their best, but they're really struggling
1354080	1357740	to get their hands on decent threat intel, and I think the rest of the industry's in the same boat.
1357740	1363500	So this is the on-premise attack framework on the left, and the cloud one on the right, for those
1363500	1368420	who aren't familiar with MITRE attack, it's a taxonomy of likely attacker tools, techniques,
1368420	1374140	and procedures, TTPs, things that attackers likely to try in a given environment. So the one on the
1374140	1377520	left, as I say, is Windows. As you can see, there's a lot of things in there that we've
1377520	1384200	noted attackers doing over time. For cloud, much less so, as you can see on the right there.
1384760	1389940	And so if we were to purely rely on what we know attackers are doing actively,
1390920	1393980	we're barely going to spot anything, because there's just not very much information out there
1393980	1399560	about this. And where we see reports of, oh, we think an attacker might be doing X, Y, and Z,
1399560	1403480	it's actually often really hard to validate that. You can't just sort of jump onto Google and dig
1403480	1409040	out an old Mandiant or CrowdStrike PDF, you know, from the last APT29 report or whatever,
1409040	1412440	and there's a lot less information sharing on this. And part of that, I think, is actually the
1412440	1417560	cloud provider's fault. I have to say, we've not had great experiences working with some of them
1417560	1424460	on this. They're always very keen to hide any evidence of sort of real malicious activity,
1424460	1428300	just because it's potentially damaging to their reputation. But that doesn't help us
1428300	1433820	from a defensive perspective. So that said, you know, there are a few places you can draw
1433820	1438040	inspiration from, I think, for working out what an attacker is likely to do in your environment.
1438840	1443500	Certainly Scott Piper at Summit Root is going to be one of the big ones for AWS,
1443500	1447360	and the guys over at Rhino Security have been putting out some great research for years in
1447360	1452120	this space. If you're a fan of Google Cloud, then GitLab's internal red team have done some
1452120	1456040	pretty fantastic stuff there. And there's a variety of tools, too, that are pretty useful
1456040	1464600	for working this out. AWS especially, Paku from Rhino, is full of modules of things that an
1464600	1469280	attacker might want to do. And so given how powerful it is, you know, we use it pretty
1469280	1473120	frequently when we're doing offensive security testing of one kind or another. It's pretty
1473120	1479220	likely that a lot of the lower skilled attackers or people using public tooling are going to be
1479220	1484420	taking Paku and trying to do stuff with it. So if you can signature on most of what Paku's doing,
1484420	1488020	or at least be in a position where you've got the right data to be able to spot it if it does
1488020	1493720	happen, that puts you in a pretty decent place. So go have a look at a lot of the existing tooling
1493720	1498500	that's out there, and see what penetration testers say they're doing, you know, read around
1498500	1504440	on the blog posts they publish, and base a lot of your detective activity on what looks like it's
1504440	1508500	most relevant from what you see that way. And that's a pretty great way, in my experience,
1508500	1513400	to expand beyond sort of MITRE ATT&CK and the other common industry frameworks.
1514420	1518560	But even going beyond that, we can take a look at a bit of a high level as to what an attacker's
1518560	1524880	actually likely to do. So there's four key areas, really, that I think I see
1526660	1531360	us, other pen testing firms, red teams, and so on, exploiting on engagements.
1531560	1537440	The big ones really are identity management, pivoting around between environments,
1537440	1542080	source code management, continuous delivery, and application vulnerabilities.
1542740	1548460	You know, we'll dig into those one after the other. So first up, identity management exploitation.
1548460	1553580	So here what we've got is where we've got an attacker who's managed to get hold of some
1553580	1558840	credentials in some fashion or another, either from access keys they've stolen out of source
1558840	1563260	code or what have you, service account details that way, or they're targeting a single sign-on
1563260	1567880	mechanism, they found some credentials somewhere and they're doing that. What we end up with
1567880	1572480	is an attacker leveraging credentials to get into the environment and start doing things from there.
1572480	1578860	So this is pretty common. Verizon's 2020 data breach investigation report reckons that
1579420	1586220	somewhere in the region of about 80% of cloud breaches involved lost or stolen credentials.
1586480	1589400	So this really is the big ones we're paying attention to.
1591020	1595280	This also comes up in another context, which I'll get into in a minute, but actually
1597080	1600900	making sure that you've got sensible procedures around how you handle credentials, enforcing
1600900	1606360	multi-factor authentication and so on is really important. The other thing to note here is that
1606360	1611040	these credentials are often found in what seem like fairly stupid locations.
1612520	1618800	Performing penetration tests and stuff, we've often found them in file shares, SharePoint sites,
1618800	1624520	source code repositories to a degree too. People leave them lying around. And so that can be
1624520	1629180	pretty problematic. But even in cases where people haven't left the credentials lying around,
1629180	1636740	actually, a lot of the single sign-on tools that are used, a lot of the ways we do identity
1636740	1641500	management in the cloud aren't as well understood as some of the legacy on-premise equivalents.
1641500	1647000	So people make stupid mistakes, or say stupid mistakes. People make mistakes through lack of
1647000	1652020	education, lack of understanding of what's going on. In this particular case, we had an organization
1652020	1657940	deploy AWS Cognito, but pretty much by default and with the default configurations enabled.
1658580	1663860	For those who aren't familiar, Cognito is a single sign-on user management tool that's designed to be
1663860	1668120	integrated into web applications. So the idea is that you can use this to do your user management,
1668120	1671000	so you don't have to implement that in your own web app, and there's an AWS service that
1671000	1676680	takes care of it for you. You can also plug it into a few AWS services natively. So in this
1676680	1682700	particular case, they'd used it as the front end for a fairly large data store. And because
1682700	1688020	everything had been left at default, you had open registration enabled, so anyone could come
1688020	1691780	along and register an account. It's what you want if you've got a public-facing web application,
1691780	1697120	probably not if it's the authentication mechanism for a sensitive data store. And then it turns out
1697120	1703020	that by default, if you don't configure multiple user account groups, then everyone goes into the
1703260	1708540	default group, and the default group is administrator in the data storage thing that we were looking at.
1708540	1713620	So we essentially just registered ourselves an account coming in from the internet and had admin
1713620	1718000	access to this big data store. And so the important thing to note here is they'd not
1718000	1722020	deliberately misconfigured it. They'd not even accidentally misconfigured it. They'd left it as
1722820	1727780	default, and it turns out the defaults had really bitten quite badly in the back side in this case.
1729440	1734780	Next up, pivoting around between environments. So this is quite a common one we see.
1734780	1739980	Sorry, and we find that it's really common, obviously, for attackers to go in with phishing
1739980	1745920	campaigns, either for phishing for credentials or getting a foothold on a network with, you know,
1745920	1750220	pick your favorite impromptu, Cobalt Strike, Covenant, whatever, and pivot around from there,
1750220	1757700	move up into the cloud. And so actually, that can be a pretty effective route. We're seeing it an
1757700	1763320	awful lot that way around. We have also seen a few cases where attackers have somehow breached
1763320	1768940	the cloud environment, either for an application vulnerability or something else. And they've been
1768940	1774320	able to pivot around inside the cloud until they get to, say, an S3 bucket or some other data store
1774320	1780760	that's got something sensitive in it. And in a couple of cases, we found either sort of SSH keys
1780760	1787160	that allowed us to pivot back on premise over the VPNs they had set up in the cloud, or credentials
1787160	1793020	to sort of third party management solutions that they were using, that we were then able to go in
1793020	1797060	and manipulate what was happening there. So actually, the danger here is sort of in both
1797060	1801740	directions, as much as not in the diagram. You can either start on premise and pivot into the cloud,
1801740	1806460	or you can start on cloud and pivot on premise. And you'd probably pivot between cloud environments
1806460	1811060	as well. Not something I've ever done personally, but I'm sure it'd be feasible. And so as an
1811060	1816060	example, one thing I've seen pulled off on a number of occasions now, why I generally recommend
1816060	1822260	not using Active Directory for your cloud single sign-on, is that we've seen cases where an
1823100	1827060	organization's on-premise Active Directory has been compromised, or we'd compromised it as part
1827060	1833120	of a red team. We've got ourselves in, we've added some users that we have access to, to the
1833120	1839920	right groups in Active Directory to get cloud access, AWS, Azure, what have you. And then by
1839920	1844300	virtue of having that, we then become administrators in the cloud, at which point we've owned the cloud
1844300	1850040	as well. So either it's well worth investing in hardening your Active Directory, if you are
1850040	1856080	going to do Active Directory single sign-on to the cloud, and especially Azure AD. Or equally,
1856080	1860880	we've seen a number of organizations now go out and buy Ping, Okta, some other third-party single
1860880	1865200	sign-on, and use that for their cloud access, completely separate to all their on-prem stuff.
1865400	1870160	But it's definitely worth segregating or separating your Active Directory environment
1870160	1875520	and your cloud environments as much as possible, given how weak most legacy AD environments are.
1876900	1883160	Next up, source code management and continuous delivery. And so here, this is where we've got an
1883160	1887220	attacker who's targeting code repositories or the pipelines that are deploying these things into the
1887220	1892560	cloud. We're manipulating code being deployed as applications, or we're manipulating infrastructure
1892560	1897240	as code that controls the cloud environment itself. And if we can commit code, we can have
1897240	1901760	the pipeline push it out. If we can manipulate the pipeline, we can modify the code as it goes
1901760	1907080	through the pipeline. Essentially, your cloud is as secure as the things deploying the applications
1907080	1911460	and infrastructure. And that's something I think often gets overlooked. It's really important to
1911460	1918760	also take a look at your source code repositories and pipelines. Next up, application exploitation.
1918760	1924360	So we've got an attacker coming in from the web, and we're going back to sort of the early days of
1924360	1928300	application security, where SQL injection and remote code execution was something you found
1928300	1933440	on a regular basis. Obviously, it's a lot less common now. But we've seen new classes of
1933440	1937840	vulnerabilities crop up, or we've seen things like server-side request forgery become more relevant
1937840	1942980	now than they used to be on premise, thanks to instance metadata services and so on. But
1943580	1948880	being able to pivot into the cloud via an application attack is something that is obviously
1948880	1953620	very useful to an attacker, but it's something that gets exploited a fair bit, too, in my experience.
1953620	1959340	It's usually vulnerabilities in commercial off-the-shelf components, or open source apps
1959340	1963220	that are being deployed that have been misconfigured, in my experience, and we see a lot of that.
1964680	1969780	But generally speaking, obviously, this is still a significant threat, and that's why
1969780	1976140	companies still keep investing in AppSec teams. On the plus side, though, when it comes to
1976140	1979640	application exploitation, it's generally a lot easier to spot this stuff in the cloud than it
1979640	1985080	was on premise, or at least a lot easier to gather the right data for it. In this case,
1985080	1990840	we're running an Azure Kubernetes cluster, we've got some applications running in, and by the
1990840	1994800	time the traffic hits the application, we actually exploit it, it's passed through probably a web
1994800	1999260	application firewall on the front, we've got some kind of API gateway, we've got the ingress
1999260	2004700	controller going into the Kubernetes cluster, we've got the logs from the pod, from the container that
2004700	2009480	the app's running in, we've got whatever application logs are being generated, and we can ship all of
2009480	2018180	those out into our scene, and we can monitor and react to that. So there's quite a lot more we can
2018180	2023760	do here than on premise. Also worth noting, if you do decide to go down the route of detecting
2023760	2028800	against things happening in your applications, you should probably focus in on looking at
2028800	2033520	authenticated traffic. I'm sure we're all aware that most applications on the internet get
2033960	2039620	bombarded with SQL map scans and all that sort of stuff. The easiest way to discard all that
2039620	2043980	and focus in on the interesting data is by looking at what your authenticated users are doing.
2048140	2052100	So we talked about a variety of different things that an attacker is likely to try,
2052100	2055600	and this is essentially the paths we go down when we're looking to work out what we should
2055600	2059760	be spotting in a given environment. And threat model your environment, and work out what an
2059760	2063180	attacker is likely to try, how they're going to do it, what the likely attack paths are,
2063640	2067140	prioritize those based on what you think is most likely to be exploited, either because it's easy
2067140	2073500	or because it's the most obvious or whatever else. Then define those attack paths, ideally in some
2073500	2080040	sort of code format so it's easy to share around or machine read. Verify that the right logs,
2080040	2083740	telemetry is available to defenders, and then go in and do some actual testing to see whether
2083740	2088920	if we fire these test cases off, we get the right log data, we get something that we can action.
2091650	2095890	But if you're not familiar enough, really, with your cloud environments to be able to jump in and
2095890	2103490	do this, or you don't have the ability to do it at the scale your organization is working at,
2103490	2107890	you've got to pick somewhere to start. And one of the easiest places, some of the biggest quick
2107890	2114030	wins, are around either the objective end of the kill chain, where an attacker is looking to get
2114030	2118810	access to key data sources or to start ransomware-ing everything or whatever else, and look
2118810	2125570	at what those are, put key monitoring around that, but also look at infrequent actions that are
2125570	2129430	generally highly privileged or affect your security model. Things like anything that
2129430	2134290	involves turning off or altering the telemetry you're getting, modifying cloud trail, turning
2134290	2140890	guard duty off in AWS, changing your audit log configs in Azure, or anything around manipulating
2140890	2149350	your permissions model, your IAM policies in AWS, RBAC in Azure, anything that's modifying
2149350	2154490	any of that. Those will make really good points to build out some initial detection around.
2157890	2163170	So let's say now we've got some detection that we've built, and we think we've got some use
2163170	2168310	cases implemented to spot some stuff. How do we validate those? As I say, by this point,
2168310	2173070	we should have a set of likely attack paths identified, so we know what we're testing for,
2173070	2180330	we've got some use cases for that. We then go and execute those attack paths, usually manually,
2180330	2185410	and we then review whether we actually fired off some alerts or not, and then we work out what we
2185410	2191970	need to do next based on how much of our detection actually worked as expected. Now, some of this,
2191970	2196870	actually, we can quite easily automate, in theory at least, certainly executing the attack paths
2196870	2201390	where it's targeting the control plane layer or we're targeting things like Kubernetes that are
2201390	2207070	designed to be automated. It's generally fairly easy to automate the attack paths as well.
2207070	2211190	One of the more interesting ones is doing an automated gap analysis, essentially spotting
2211190	2215490	what fired that should have done, what didn't fire, and so on and so forth, so that we can
2215490	2220970	essentially track over time in an automated way our improvements, what's working, what's not.
2222370	2226790	And so these are all great ideas, but actually the industry is still mostly working on a manual
2226790	2233750	basis for all of this, especially in the cloud. So one thing I think, one really important lesson
2233750	2239270	to take away from the rest of the cloud community is treat everything as code. DevOps guys have
2239270	2244110	really got this down, and we're starting to see the security industry get on board as well in the
2244110	2248470	detection space. And the big reason for that, really, is that if all of your detection is
2248470	2252770	defined as code, it makes it much easier both to share knowledge internally, because anyone can
2252770	2257190	just take a look at your rules, and if they're in a common format that they already understand,
2257190	2260150	you know, some people have written some new ones, they can just go in and they can start reading it
2260150	2264910	and get their heads around it. And if we have reasonably common code formats, it also makes it
2264910	2270130	much easier to share. And so if we can share information on how to spot, you know, what given
2270130	2275590	threat groups are up to, specific TTPs, and we can either post those on GitHub or share them between
2275590	2280910	sort of some of the closed threat intel sharing groups, it means that everyone's detection gets
2280910	2285110	better for comparatively minimal effort on the part of an individual organization.
2285390	2291470	A few big things to pick out in this space, Sigma by Florian Roth. So we've got a set of
2291470	2297330	seam agnostic rules, essentially, that there's then a compiler for that produces your Splunk or
2297330	2304050	your QRadar or your Elasticsearch queries off the back of this common rule set. So someone
2304050	2309810	writes a Sigma rule for a particular TTP, and then you have the ability to use that in every
2309810	2314690	platform going pretty much. There's a lot of compilers in there. The other interesting one
2314690	2319030	in this space is Jupyter Notebooks. So this is more sort of threat hunting, you know, proactive
2319030	2327390	investigation rather than reactive alerting based on known TTPs. But the idea of a Jupyter Notebook,
2327390	2331530	for those who aren't familiar, is it's essentially a way of having a document with Python embedded
2331530	2339770	in it. And so you can run code inside your documents, basically, and tie explanations of
2339770	2344290	what's happening and the data that an analyst is seeing, and directly to the executing code,
2344290	2350490	which makes it quite a nice way to share information, share threat hunts. And the Spectrops
2350490	2354850	guys in particular have been doing some fun stuff with that. But it's starting to take off now. It's
2355150	2360910	a data science thing, but it's been quite nicely repurposed now. And if you're looking for another
2360910	2366830	conference talk to watch, John Lambert's the GitHubification of InfoSec from T2 last year.
2366830	2371250	It was a really interesting presentation on how the industry needs to work better together
2371250	2378650	to start making it more expensive for attackers to compromise organizations by sharing knowledge
2378650	2386640	better than we do right now. Now, one of the interesting problems we've had historically
2386640	2391820	in the cloud is that a lot of the existing solutions for automatically testing attacker
2391820	2397160	activity don't extend to the cloud. They're entirely focused on on-premise at the moment.
2397160	2402980	So things like MITRE Caldera, Atomic Red Team, there's a number of tools out there that have
2402980	2408160	been very successful at automating attack simulation on-premise estates. But actually,
2408160	2414100	we didn't have that for the cloud. So I went away and built one called Leonidas, which we've
2414100	2423340	open-sourced. So Leonidas is essentially a web API where we have a variety of different
2423340	2428760	attack definitions defined within it, and each API endpoint is a test case you can execute.
2429220	2434320	So under the hood, actually, the way it works, we took a slightly different approach to how a lot
2434320	2439980	of these tools work in that it's been designed to make it as easy as possible for you to share
2439980	2445180	the ability to execute these test cases and to detect them between your team members internally
2445180	2449540	and within the wider community, too. So let's say we've got a security team, we've got some
2449540	2454460	analysts, we've got some red teams, purple teams, whatever, and one of them's read a new blog post
2454460	2458880	about some new TTP in the cloud that they're interested in. So they sit down and they define
2458880	2465040	this in our format. We've got like a YAML-based definitions format. And you write the TTP,
2465040	2471140	it gets checked into a Git repository. We then have a CICD pipeline that essentially builds out
2471640	2477840	a copy of the API based on the definitions that are in the Git repository. And that runs as a
2477840	2482520	serverless function at the moment, a Lambda function AWS, but we're building out support
2482520	2489260	for Azure and GCP, too. And so you've then got this API exposed, and we can have some target
2489260	2494660	resources that we're looking to attack. Your purple team comes in or your red team comes in,
2494660	2499080	executes some attacks against these target resources, and we have our logs shipped out to
2499080	2505620	our scene. And so we can then verify whether when we triggered this new TTP, whether we
2505620	2508920	have the right logs in place, whether we spotted it or not, and whether we need to tweak things
2508920	2518960	further. So from these definitions, we define the actual test case itself. In this particular case,
2518960	2523640	this is an AWS test case. We're looking at enumerating cloud trails, which as an attacker
2523640	2527700	you probably want to do to see if you're being monitored or not. And so we've got a single
2527700	2536580	line of code here, Python calling the describe trails API function on the cloud trail APIs in
2536580	2543120	AWS. And behind the scenes, the framework abstracts away a lot of things around what identity we're
2543120	2549060	executing this as, which region are we targeting, all these kinds of things. And so the actual
2549060	2554260	code that's written for these test cases is pretty minimal, which obviously then makes it easier to
2554260	2559380	write a lot of these quite fast, or make it easy for less skilled analysts to get involved in
2559380	2566940	developing these. We also define what you need to detect the use case as part of the same definition
2566940	2572120	file, right? So we've got both the test case and the detection case defined together. Here we've
2572120	2579980	got a detection case that says we've got a event name of describe trails with a particular event
2579980	2585560	source, and we're likely to find that in cloud trail audit logs. So we can then compile that,
2585560	2589220	well, we usually compile it down to Sigma and then rely on Sigma's compilers to compile it out for
2589220	2596500	the different SIEM solutions. But we can also easily compile Lucene queries for Elasticsearch
2596500	2600260	or pretty much whatever you want off it. You know, the data's there, it's just a case of writing
2600260	2605100	something to generate the right queries. And also because we try and be responsible about these
2605100	2609140	things, we define the permissions that are necessary for Leonidas to execute a specific
2609140	2615140	test case. And so what we actually do here then is generate the right IAM permissions for AWS,
2615620	2620220	or the necessary permissions for your service accounts in Azure or what have you,
2620220	2625140	in order to allow us to execute the test case as safely as possible. And we can also set
2625140	2629380	restrictions on which resource it can target and so on to make sure you're only, you can only
2629380	2634220	leverage it against test environments rather than your production accounts. Or we can also generate
2634220	2639480	some documentation off the back of it. All of this is defined in a reasonably human-readable
2639480	2645400	but not necessarily friendly file format. And so instead, what we do here is we then generate
2645980	2650560	markdown files off the back of that and use mkdocs, for those who are familiar with it, to generate a
2650560	2654760	pretty website, which makes it a lot easier for those who are less familiar with some of this
2654760	2659360	stuff to understand what's actually happening, what this test case is, how it works, and ties
2659360	2662520	it back out to the MITRE framework. So you can click on the MITRE links there and it takes you
2662520	2671720	out to the relevant TTP there. So we can do quite a lot really with it. So in the spirit of this
2671720	2679600	being both a presentation and sort of a tool demo, it's demo time. Let's hope this works.
2679640	2687220	So what we have here is a case configuration file for Leo, which is essentially a Python
2687220	2692560	script that allows you to easily talk to that API and comes with it. So we can just define some
2692560	2698200	fairly simple test cases here that say we're going to do an AWS attack path that's going to work out
2698200	2704320	who we are, have a look at some defensive measures that might be in place, set up some persistence,
2704320	2712420	and then steal some secrets. So what we're going to do now is actually run that.
2725660	2730140	Fingers crossed this actually works. Let's hope the demo gods don't bite me in the backside.
2739540	2746400	Here we go. So we're hitting the endpoint and we've got here, we've got Leonidas hosted up
2746400	2751020	as a lambda function behind an API gateway. So we've run a test case to work out who we are,
2751020	2758000	and this has come back with us being Leonidas. So we've now had a look and see if we've
2758000	2762600	got any guard duty detectors running. We have. It's not ideal, but we're going to carry on anyway.
2763460	2768700	We just hope that we can move faster than the defenders can. So next up, we're going to
2768700	2779970	enumerate the cloud trails that we've got running. And so this was with the idea of spotting whether
2779970	2786390	we've got anyone who's actually monitoring us, who's going to be hunting down our attacker
2786390	2794590	activity within that. There we go. So we've got two cloud trails running here, both of which are
2794590	2798350	probably going to pick us up, but that's fine. We'll carry on anyway. So we've now added an IAM
2798350	2804410	user in this particular case, Defcon user here. And that's to allow us to come back later on if
2804410	2809350	we wanted to. Let's add an API key to it. And so we've got programmatic access. So that's come
2809350	2813810	back with some access keys and things, which I'll be deleting straight after this talk.
2814410	2817550	We then have a look and see what secrets we've got running in secrets manager.
2817810	2821650	And so in this particular case, we've got a secret in here already that I created
2822260	2828350	another time. And we're then actually going to execute the access commands to then actually dig
2828350	2834570	out the secret value here. And you can see we've got a test API key lying around inside the secret
2834570	2844350	string. So we just run a essentially seven-step kill chain here with a short YAML file defining
2844350	2850850	what test cases we want to execute. And that's all just hitting an API that's running up in AWS.
2853070	2861790	So now on top of that, we can actually just interact with it through the Swagger interface
2861790	2867750	if we wanted to. So you can test out the test cases here if you wanted to as you're developing
2867750	2872990	new ones. And you can run all this locally as well as in Lambda, obviously. And this is just
2872990	2878230	really to help with development. But you've also got Swagger definitions here if you wanted to
2878230	2883530	import that into something like Postman or Insomnia or build it into other tooling.
2883830	2888850	And the API is pretty easy to work with. And the other thing that is worth me calling out
2888850	2894550	quickly here is that Leonidas actually generates its own logs. So I'm just going to take a quick
2894550	2907910	look. Let's load up the CloudWatch log streams from what we've just done. No, in fact, we won't
2907910	2916230	be doing that. So we'll get into that in a second. But one of the really powerful things
2916230	2923650	with this, then, we've got an API. We've got a set of things we can execute automatically.
2923690	2928890	And we can then build that into pretty much any other security testing that we've got going on,
2928890	2933150	especially some of the on-premise testing that we're already doing. Let's say we're using
2933150	2936970	something like Caldera or Atomic Red Team to do on-premise simulation already. Actually,
2936970	2942830	we can tie this together, and we can have simulations kicking off on-premise. Let's say
2942830	2947530	simulate some phishing, a bit of lateral movement, and some Active Directory privilege escalation,
2947530	2951550	and then pivot into the cloud from there, and then start using Leonidas to trigger
2951550	2956790	cloud test cases off the back of that with the credentials that we've just stolen in the
2956790	2961710	simulated attack on-premise. And to me, that's really exciting. We've been able to do
2961710	2966950	on-premise automation for a while, and we've done a fair bit of manual stuff in the cloud like this,
2966950	2972090	but now we can tie all that together and execute hybrid kill chains in a completely automated
2972090	2981050	fashion. So with the log data that I mentioned, Leonidas generates its own log telemetry on
2981050	2986210	I executed this test case, this identity, these parameters were passed in, this was the resulting
2986210	2993730	data that came back, and that all feeds into a CloudWatch log stream in AWS with Stackdriver
2993730	2998590	or Azure Monitor for the Azure ones. And so we can ship that out somewhere ourselves and monitor
2998590	3003110	that separately. And one thing that strikes me as being really exciting here, or some potential for
3003110	3010470	some really exciting work, is then integrating your seam alerts and your tagged notables, whatever,
3010990	3016990	that are being generated by these test cases, and essentially performing automatic gap analysis,
3017690	3022570	working out for every Leonidas test case that's fired, as denoted by the Leonidas logs that are
3022570	3026950	coming in, did we get what we expected out the other side of it? And we can then track over time
3026950	3032990	as we write new detection cases and tweak things, how much better we're getting, which gives us some
3032990	3038290	nice data both to make us feel good about ourselves, but also it helps justify to whoever
3038290	3042070	it is that's signing the paychecks, and that what we're doing is worthwhile, and that we're improving
3042070	3048590	over time, and we can demonstrate that, and then so on and so forth. So one of the reasons I bring
3048590	3052970	up that sort of continuous integration aspect specifically is that what we've got here is the
3052970	3060930	ability to support us on a continuous journey. We can consistently improve our detection capability,
3060930	3064970	write new use cases, write new test cases, embed them in Leonidas, immediately start
3064970	3069850	simulating them alongside all the other ones we've already got, and it supports us on that
3069850	3076350	journey. Detections are moving target, attackers are consistently coming up with new techniques,
3076350	3082690	new mechanisms for targeting you, new tooling, so on and so forth. So we need to be able to move with
3082690	3087630	the times as well, and being able to define all this stuff as code and automate as much of it
3087630	3093970	as possible makes it easier to get better faster with fewer people. And so it's worth actually
3093970	3100690	treating your detection improvement projects as a software dev project. I find that that works
3100690	3106730	pretty well. You want to be identifying new threats and risks on a continuous basis,
3106730	3111690	or at least taking the time to do that regularly and feeding that into some sort of design process
3111690	3116650	to come up with new use cases for you to detect with. We then simulate that, we evaluate whether
3116650	3121630	what we've changed as a result of that actually made some improvements or not, and we cycle
3121630	3127450	round and round. And that's how you get better at this stuff over time. So there's a few things to
3127450	3131930	conclude on there, I think, really. First off, actually, like the cloud brings a lot of benefits
3131930	3136950	from a security perspective. And loads of people have been talking about that in the prevention
3136950	3142430	space for a while. There's a lot from the detection side as well. We've got visibility
3142430	3146610	like nothing we've ever had on premise before. If you've got a list of all your cloud accounts,
3146610	3151530	actually, you can get all of your log data comparatively easily. And we don't end up in
3151530	3155510	this situation where we've got some visibility of some things and not of others. And we lose
3155510	3160930	attackers because they've pivoted off the box that they landed on and they persisted inside
3160930	3165390	some legacy printer with some old dodgy firmware and we've got no monitoring for that.
3165390	3170730	We don't have those kinds of problems in the cloud anymore. The problem that comes with that is
3170730	3177290	all of this, the benefits that the cloud bring, all of the APIs and the automatability, means
3177290	3181430	that our attackers are already automating this stuff. We were talking about the crypto mining
3181430	3184890	earlier, but that's going to become more and more of a problem over time. We're going to start seeing
3184890	3191610	attackers automating more complex, more interesting kill chains to go after potentially
3191610	3195830	more damaging things. At the end of the day, Bitcoin mining is not great. You don't really
3195830	3201830	want someone having you pay for their cryptocurrency. But it pales in comparison
3201830	3208150	to attackers automating, like stealing loads of really important data or defacing someone's
3208150	3212450	front page of their website or whatever else. And we're going to start seeing attackers doing that
3212450	3217750	in the long term, I think. So we need to get better at this now. We need to be in front of this whole
3217750	3223070	cloud detection thing from the go. And we need to be getting better at this as an industry.
3223770	3231170	And so to go along with that, we released Leonidas, which is a tool for automating a lot
3231170	3235790	of this stuff, both the attack simulation and the attack detection piece and write the detection
3235790	3243010	cases. Right now, AWS only. We are not actually that far off Azure and GCP now. We're starting
3243010	3248870	to test some of those out. There's currently 40 test cases in there, 41 for AWS. But we're
3248870	3254910	pushing more out all the time. And you can grab it over our GitHub now, fsecurelabs.leonidas.
3257830	3260930	So thanks for listening. And at that point, I'll take questions.
3260930	3263150	Just one question from the audience.
3263370	3269550	What do you recommend they use for an identity store other than cloud SSL?
3269910	3277530	So basically, I'd recommend anything that's not Active Directory. And so we've seen a lot
3277530	3286250	of organizations pick up things like Ping, or Okta, or Auth0, Authy. And there's a number
3286250	3291650	of providers that offer single sign-on platforms that are designed to essentially do single sign-on
3291650	3297590	for large cloud estates. And the reason that I recommend that is purely that it breaks that link
3297590	3303490	between your on-premise legacy identity store and the cloud. And while that brings in a bunch of
3303490	3307550	extra overhead from a management perspective, all of your sort of HR joiners, leavers, processes,
3307550	3311910	all of that kind of thing, you know, it's extra steps to add to that. It also then means that
3311910	3317730	if your Active Directory is breached, you don't get immediately owned in the cloud as well,
3317730	3322470	which is something that, you know, in my experience working with Active Directory
3322470	3326170	over the past few years, is something that would happen to quite a few organizations, I think.