Building a Cloud-native SOC: Fantasy? Reality?
The adoption of cloud technologies continues to snowball, and with that, we want to ensure the security of our cloud. In this session from The Modern SOC Summit, you'll hear from Dave Shackleford about building a cloud-native SOC. As CEO of Voodoo Security and security specialist, Dave takes us through the issues that can come up with transitioning to cloud-native and what you can do to ensure security in your cloud.
Dave ShacklefordCEO, Voodoo Security
Girish BhatVP of Security Marketing, Sumo Logic
Girishwar: Welcome to the Modern SOC Summit. I'm Girishwar, I lead the security marketing practice at Sumo Logic. And I'm also the host for today's session. Today's session is building a cloud native SOC. We want to explore is it a reality, that is, can you build a cloud native SOC or is it what I call, is it just a fantasy? As we all know, the adoption of cloud technologies, whether it's cloud native or cloud hosted, continues to grow to solve different business problems. Security teams and security practitioners have been kind of embracing cloud technologies and what we want to also explore is, is this a synergy that's happening more? And what are the things that security practitioners and leaders need to consider in the upcoming years? It's my pleasure to welcome today's speaker Dave Shackleford. Dave Shackleford is a preeminent security specialist and he is one of arguably the most influential and knowledgeable person when it comes to everything cloud security. In addition to not only being a practitioner and an expert, Dave is the CEO of a security consulting firm called Voodoo consulting. And he's been active in the community, working with organizations such as IANS, Cloud Security Alliance and many, many more. Additionally, Dave Shackleford is also a member of Sumo CSSO advisory board. So at this point in time, Dave, welcome, and thank you for speaking at the Modern SOC Summit. The session is all yours sir.
Dave: Excellent. Hey, thanks so much Girish and thank you everyone for attending. It's very exciting to be here. Really pleased to be able to spend some time with like- minded folks in the industry and talk about an emerging, but really quickly maturing topic, which is the concept of a cloud native SOC. So the title fantasy or reality, don't let that fool you folks. The reality is that we absolutely are shifting towards the use of more cloud oriented SOC technologies and the reasons are numerous. And so I'm going to give a little bit of background. One of the other hats that I wear actually over at the Sans Institute is as a course author and instructor, predominantly in the realm of cloud security. But I also do quite a bit of analyst work with that organization. And one of the things that I've had the privilege to be able to work with them on for about the past decade successively are a series of different cloud security surveys. And we go and ask the community folks just like you out there fighting the good fight, what's going on in the world of cloud? What's actually happening out there? And what are you guys facing? What are the challenges? What are the things you're doing? And so sort of progressively over the years, we've been asking this question," Hey, what kinds of data are you putting into the cloud?" Now this is probably not going to surprise any of you today, but over time, the answer is really everything. So organizations are much more willing than ever before to put sensitive data types into the cloud, ranging from employee records to intellectual property, to financial data, health records, even payment card information across the spectrum of various types of data, categorically, and certainly highly regulated data. It's all shifting out into cloud- based scenarios fairly rapidly and has been for quite some time. So starting with that premise, you have to think," well, what about all the security controls and technologies that we've relied upon to protect that data, wherever it may be?" Certainly we're seeing that the attackers know that that data is moving to the cloud as well. And so if you really take a look at the leading types of let's call it relatively agnostic reports that are being issued out in the industry around breaches and attacks and attacks scenarios. Well, it's telling the same story. The Verizon data breach investigation report, which I'm quite sure many of you have heard of is telling us that well, the attackers know we're there. So they've been targeting the cloud significantly more over the past several years. In fact, one of the things we've seen is that at the beginning of the global pandemic with COVID- 19 as more organizations immediately and very quickly had to shift off into remote work scenarios, they rapidly accelerated a lot of their cloud based projects and cloud- based initiatives. So if you were thinking about moving towards the use of collaboration technologies and various SAS services, and even the use of quite a variety of different platform and infrastructure as a service types of capabilities. Well, we saw a lot of data going out there. We saw a lot of organizations moving workloads, moving data, moving applications, building new applications. And of course the end users are interacting with all of that. That's where these attackers have gone. So we saw a significant increase in breaches and attacks, targeting cloud- based assets and the very recent 2021 data breach investigations report, for the very first time ever, noted that more attacks and breaches occurred in cloud- based environments than in others. And that is a really significant data point because we finally tipped over, right? That tipping point has happened where we're seeing so much use of cloud, that the attackers are focusing there as a priority. And I expect that trend to continue over time as well. So what does that all lead to? Well, what it leads to is the fact that we've got to get our act together and actually start making sure that our cloud environments are adequately protected and protected in ways that have parody with the types of controls and control stacks that we've relied upon both to meet regulatory requirements and just general security best practices. If you take a look at some of the additional data from the SANS cloud security survey that came out in 2021, which incidentally is available for free out on the SANS site, if anybody's inclined to go check it out. We saw some really big issues cropping up, and none of which I think are surprising either. So unauthorized access is a concern. The lack of skills within organizations around cloud services is definitely still a big issue, one we're tackling over there. The lack of visibility into what's being processed and certainly configuration challenges. The control plane is huge, has lots of different configuration options. All of our different assets and resources are mixed in with that as well. So that's all great. I mean, we can worry about anything we want to. The bigger question is what was realized, what kinds of concerns, in fact, manifested in the form of breaches or even just attacks. And we saw significant numbers around configuration issues. We certainly saw a lack of training and skills as really almost a third of the respondents coming back and saying," Hey, this is happening." But unauthorized access is close to 20%. So yeah, it is actually happening. And so I think this aligns nicely with what the folks at Verizon came out with. Not only are we worried about the attacks and we're worried about the kinds of things that could manifest in the cloud, we're seeing it. We're seeing this type of stuff actually happen. And the Cloud Security Alliance confirms this as well. So you look at data breaches and misconfiguration challenges, things like insufficient credential controls and key management. Sure. This is by the way, from one of the working groups over at the Cloud Security Alliance called the top threats to cloud. I actually co- chaired this working group up until about 2019 and the team that's running that group now is phenomenal. They're really skilled. They're getting some great data from the community, and this is the most recent list of the top threats or issues. The pressing issues that are facing the community when they're moving into the cloud. And I don't think that this list is probably surprising. It is in priority order. So data breaches naturally being the number one concern, but right behind it, misconfiguration, inadequate change control. In other words," Hey, people are moving faster and faster." The DevOps movement has most certainly taken hold. We've got really rapid deployments happening all over the place. And we don't have our security controls in place, we don't know exactly where it's going, what it's doing as it's making its way. It being of course, a workload or dataset or application stack, whatever you might come up with. We're going to have major challenges down the road. So I think all of this data is starting to really tell the same story. But that comes back to the issue, what are we going to do about it? So it's great to talk about issues. All of us in the security industry can do this all day, but at the end of the day, we've got to come up with some options and some answers. And I think going back to the SANS survey that we conducted, what I really wanted to know is, where are your big issues? What are the big challenges that you're facing internally as you're trying to adapt and to collectively sort of bring this together? I could talk about any one of these data points at length, but I'll try to highlight what were the big sort of storylines that came out. Number one, there's really still a struggle to feel as though we're getting the degree of visibility in the cloud that we've had on premises. And I think that's across the board. It's at the workload level, it's at the network level. It's just collectively this challenge that everybody's feeling." Hey, we just don't feel like we can get all that visibility that we've worked so hard to get on premises. So can I get logs? Can I get network packets? Can I get any other sort of data that tells me what's happening in my environment?" And the feeling right now within the cloud is that that's still a bit limited. But then the other thing is," Hey, where's it rolling up to?" And speaking at the enterprise level today, things like SIM and the ability to take that data and correlate it and put it together into a workflow that makes sense... The way I always think about collecting data and collecting things that increase visibility, it's to help you tell a story. So if I need my analysts to be able to look at the environment and say," Hey, what's happening here?" and do it quickly. And then take actions based on that story that's being told from that data. That's critical for most security teams today. And when people were coming back and saying," Hey, we can't do this well in the cloud." That's an alarming trend. So not only do we have that, but we've also got immature processes built all around that as well. So coming to the topic of the cloud- focused, and cloud- based SOC, I think our work is cut out for us. So we know it's time to start making that move because for a lot of reasons, and we'll talk about some of these here momentarily, you can't necessarily take what you've done on premises and drag it, kicking and screaming out into an optimized cloud- based scenario. And I think a lot of people have tried to do that as a starting point. I mean, if you've labored within the bowels of the data center for years and years, to try to get that visibility, get those correlation cases built, put it together in such a way that your sort of first tier, second tier, third tier analysts have their workflows cut out. They know what they're doing. It makes sense that you would try to take that and just bring it to the cloud and work that way. But what we're finding is that it really doesn't tend to work out that way that often. So looking at the SOC and what's changing, I think there's a broad range of concerns that have bubbled up both in the trenches, the engineers and analysts that are sort of again, fighting the good fight. And of course, across security executives and technology executives too. They're having to report to the board, what's your state of maturity with regard to detection and response in any of the environments that you're operating in. And if they're not comfortable with the state of things, that certainly doesn't look good. And so, yeah, lack of skills is a big one. A lot of the traditional vendors that we've relied upon on premises just haven't made it there in the same way. Lack of cloud detection and response workflows, just lack of visibility overall. You could go down this list and of course my tongue in cheek ending point here," what are containers?" All that is, is to illustrate is that there is this immaturity, this kind of lack of knowledge in many, many, many environments and teams out there about the technology stacks in use by DevOps teams and cloud engineering teams. And you really have to have at least some basic understanding of what people are building and how it's being deployed and used before you can start going and attempting to defend and protect those types of assets as well. So just to hit the sort of high points, if we look at the SOC then, and we look at the SOC now, I mean, classic SOC, it was all within the walls of the data center. You had servers, you had confined and closed networks. You had a SIM platform, typically as an enterprise. You might have some threat intel coming in, you've got a response team on technologies that were wholly under your control, or at least mostly under your control in most environments. But what does that look like now? We've got everything based in software. We've got assets that might only come to life and hang out for an hour or maybe a day. So highly ephemeral assets based on the DevOps workflows we're seeing today. We've got cloud enabled technologies and products that don't necessarily all sit within one environment. So it's very easy with APIs and application focused infrastructure to combine and conjoin numerous cloud technologies. That is a radically different look and feel than what we've had in the past. The regulators and auditors are becoming more comfortable with the use of cloud as well, but they do want to see some governance changes and that doesn't always happen at the beginning. What I always tell people when I'm giving talks about cloud security is," Hey, if I'm addressing all of you guys, I would love to say to you,'Hey, guess what? It's exciting that you're moving off into the cloud. Here are these great things that you should do in the background before you go there.' But we all know that you're probably already in the cloud." And so the question becomes how far along are you with regards to this sort of governance shift that needs to happen? And if you've got people working in silos that needs to change as soon as humanly possible, truthfully. Security teams need to work with DevOps teams who need to work with risk management teams who need to work with procurement teams who need to work with... You get the idea, right? So I don't need to belabor that point and drag it out. But there needs to be a lot better alignment in terms of number one, assessing the risks within any respective cloud environment that you're planning to deploy to. But all the operational teams really need to be on board with what's being built, where it's going and what the strategy looks like, so that they could be apprised of what they're protecting or what they're tasked with protecting and get their technology house in order as well, to go along for the ride. And I tend to find sadly than in a number of organizations, the SOC team is close to the last to know, to find out exactly what's happening, to find out where things are going to find out even what types of workloads are running and what kinds of data are being propagated into the cloud and being built there. And that is not a good situation. So if you have the opportunity to get everybody on the same page, build out some type of governance structure and strategy that at least gets that conversation flowing more readily, all the better. I think it's definitely in everyone's favor to do that because let's face it. The cloud's not going away and it's only going to continue growing. And so the first thing, let's get to the brass tacks of this. If you're going to be going and trying to build out a cloud oriented and cloud sort of specific SOC, which I'm are arguing, you probably should. You have to make sure that you're thinking in terms of event data. In other words, what's happening in those cloud environments. And if we've been having this conversation, I'd say even five years ago, this would not be an easy conversation at all because it wasn't simple to extract a lot of that data from even the leading providers. I think AWS pioneered this to some degree with the use of cloud trail, but it wasn't really very long before GCP and Azure came along and offered their own API logging capabilities and services. And you can tap into that and there's a lot more APIs and flexible ways to grab that data. When you move into SAS, wow, it's all over the place. And I would love to say, oh yeah, all these leading SAS providers make it super simple to get logs and events, but I would be lying to you. And for some of you that are in the trenches and, and sort of working towards this yourselves, you know that that's the case. There are some that are better than others. Certainly the use of some types of brokering services can help by generating consistent logs and events across sort of any of the varied types of SAS access that you're dealing with. But I think SAS still has a way to go. But the short sort of description of what I'm describing here is focused on event data first, without it you're really going to be behind the curve in terms of getting your cloud SOC established and getting that visibility that we just described meeting for moving in that direction. And these are just some examples, looking at things like cloud trail events. So I love this because I am actually that person who, and this is dating me, I'm sure, but probably decades ago, I actually remember writing Perl script. That dated me right there actually. Perl scripts to parse log data and pull that stuff in so that I could assess and evaluate the types of events that we were seeing in the environment. Fortunately, we don't have to do that anymore. We're going to chalk that up as progress. But when I first found out years ago about this service called cloud trail, I was blown away because it really feels to me as though this is the equivalent of a master switch in the data center that says log everything. And if you had given that to security teams, who knows how long ago, they would have been better off for it, and here we are today. So there are some distinct benefits to cloud. As it's a software based fabric, you can log everything and you should. So if you see events like stop logging, it could be a mistake, but it's probably something that you want to go and pay attention to. If you see someone saying, authorized security group, ingress or egress, I don't know, you might want to check that out. It looks like you might be adding some firewall rules into your environment. So it's good to get familiar with the varied events that are happening within your respective environments. Again, here are some other examples of serverless functionality, things like remove permission. Hmm. That sounds interesting. Someone's removing permissions from these functions or from the types of serverless environment that I'm running, or adding permission or deleting functions. So I won't read all these to you. Nobody needs that. But what this is serving to illustrate is that these are new to the cloud and SOC teams need to gain some degree of familiarity with events of interest and priority, depending on what you're running. And there's no substitute for experience and just getting in and finding that out as you go along. Here's another one deactivating multi- factor devices, again, could be a mistake, might not be a mistake, but it gives you something to latch onto in terms of event names and start building workflows around. So in the back of your mind, you think to yourself, well, if you're the SOC team and this event rolls in, what do you do? What does this trigger in terms of a workflow for traditional type of detection and response team out there today? So I would say, yeah, that's interesting. But really it's just an example. All of these are examples and every single cloud environment has a wide range of these. So make sure as a SOC team that you're comfortable with the events that are being generated in your clouds, and you need to understand what's running in those clouds as well. So if you don't know the types of services that are enabled and in use, that's no good. I think just getting hands skills for the SOC team is critical and there's lots of different types of training offerings out there. Certainly there are some specific ones for technologies, but there's also some stuff available from the cloud providers themselves. Obviously SANS, other types of training institutions offer this, but get as much training as you can. But again, there's no substitute for just going and signing up for some of these accounts, get an AWS account, get an Azure subscription, go and sign up for GCP, maybe an Oracle or whatever types of clouds you're operating in and start getting comfortable with things like infrastructure as code, automation strategies, and also those types of events that I just covered.
Girishwar: I've had some experience with automation, building natively, as well as standalone SOAR tools. What I've realized Dave, I would love to get your opinion on this, SOAR tools do a great job integrating across the ecosystem. IT, security and everything related to security as I like to call it. That serves as starting point to do the evidence gathering, to investigate, to detonate in sandboxes of whatever the use case specifically is. So I'm seeing more and more adoption of SOAR like technologies. I just wanted to get your thoughts on how that's playing into the concept of a cloud native SOC these days.
Dave: Yeah, that's a great question. And I think the SOAR space has definitely matured, but that the name of the game with SOAR is integration, right? And having APIs that work with cloud environments and other tools and technologies. And there's so many examples you could give, right? I mean, some of these might be a basic blocking and tackling. We see some really unusual traffic that absolutely is malicious. Why in the world would people have to go spend a bunch of time deciding whether or not to block that particular domain, right? You could automate that. You could say," okay, while we figure out what's going on, let's just put an automatic block rule in place within our security groups or some other technology that we're using for access controls. Or let's initiate some collection of evidence or information from a workload based on the fact that it's behaving unusually. I don't want to go do that manually. I shouldn't be doing that manually." And so I think I look at SOAR as almost kind of the security glue that helps us define much more programmatic workflows and initiate them. So you still want smart people in the mix. Looking at things and going," Hey, that's not normal." But after that, do you really want your super skilled analysts that are already stressed for time to have to go digging around looking for this, looking for that? No, no, no, no. We can automate all that. So build it one time and make sure it works right. And then automate the heck out of that. And I think SOAR is the answer to that. So I'm excited to see this emerging and coming along, and I think it's a natural fit for things like SIM that work within that software fabric of the cloud. I think those can work together very nicely and yeah, there's some elbow grease up front to sort of get it in place and make sure that all of your workloads are sort of the right ones. But that's really good time spent because it'll save inordinate amounts of time later on. So I'm a big fan and I'm excited to see where it's actually headed.
Girishwar: Yeah, perfect. That's what we are seeing. And if I put my Sumo lens on which I don't want to do for the session Dave, that's the direction we are headed as well. Thank you, back to you.
Dave: Absolutely. Yeah. And I'd be surprised as a leader in the space if you weren't. So look, let's just wrap up talking about what to do in terms of training the team and I'll keep this brief. But the whole idea of really getting your team in the trenches, getting their hands on it's all about game days. And this is the term that AWS in particular has been very vocal about. In fact, if you go dig into some of their well- architected framework and some of the best practices that they espouse, game days are right there as well. Because they're acknowledging, and I think we all are, that there's really no substitute for real world, sort of hands- on practical practice and experience. And this goes beyond the idea of something like a tabletop. So you start with that concept, but tabletops tend to be paper tigers," Hey, we're sitting around in a conference room with a whiteboard." Fantastic. That's a good start, but why don't we take that time and better spend it on building out something that we can actually test and have your own sort of test environment set up. So, like I said, spin up an AWS account, spin up something in Azure. And it gives you the opportunity to review your plans, test assumptions, find where there are gaps and also get those skills firmly embedded in the SOC team. And so these are just some simple examples, and I only pose these to get you thinking. So," Hey, somebody has an S3 bucket that was accidentally changed in a way that exposed data. We don't necessarily know what that looks like, but let's think about it." So what would I take as actions thereafter? I want to identify the bucket and look at attributes. In other words, what does it look like now. Is logging turned on, is versioning turned on, are the data and maybe the bucket itself encrypted, what are the permissions in place? And by the way, what is the root cause of this in the first place? So I got to go back to the events around that bucket and say, who in the world made this change? What's going on? Was it malicious? Was it an accident? Did we see follow up access that would indicate a breach? Or did we get lucky and simply discover something that was accidentally changed and we can quickly change it back and count our blessings, that it didn't turn out to be a disaster inaudible, right? So these are all the things you would think about doing, but this is a great scenario to start with. Certainly exposed S3 buckets aren't a new topic in the industry and to sort of wrap us up and sort of think about those next steps and where you want to go. Key things to take away, right? Align your SOC with risk and security assessment teams, make sure that you're doing things like threat modeling exercises. That's always good. Make sure you have SOC accounts and subscriptions enabled so that they can get to the assets and they can see what they need to see. And even potentially perform response actions. Look for tool alignment, where you can get it, but really consider a more cloud native and oriented SIM and whole set of technologies that's built for that explicitly. A lot of the tools from yesterday that were on premises, weren't designed for this. And they're trying to adapt of course, but if you're really proliferating assets into the cloud, look for technologies that can help. Obviously any other sorts of brokering tools, inaudible and posture management services, et cetera, might be useful in certain scenarios, but then build out those detection and response workflows. And of course, use automation where it makes sense. So just to sort of give the final points, go get cloud event data. Get it. You know where to go. Go find it and figure out how you're going to assimilate that. Number two, find out what's interesting in those cloud events. And again, there's help for you. This is the good news. So it's not as though you have to go just pouring through logs manually. I don't wish that upon anybody. But number three, and most important, once you've gathered that information, make sure that you're automating and updating your workflows to better represent the cloud scenarios that you guys are actually in. So, thanks so much for attending again. I think if you haven't completely made that shift towards a cloud SOC, there's no better time than right now.
Girishwar: Thank you so much, Dave. This was so informative. I'm mentally taking... I curiously took many mental notes about roadmapping. Not only the gamification, as well as some of the recommendations. Just chock full of information. Thank you so much. And my takeaway is, we're heading the right direction in terms of the cloud evolution. And there are great tips here for anyone who's wanting to build a cloud native SOC or head in that direction. Thank you very much Dave. Very much a pleasure.
Dave: Thanks for having me.