CyberWire Daily - The future of security validation – what next? [CyberWire-X]

Episode Date: May 3, 2022

Security executives need visibility into their real cyber risk in real time. But with the flood of vulnerability alerts, how can organizations pinpoint impactful security gaps? To meet this challenge, security teams are shifting to an exploit-centric approach to security validation to expose potential threats from ransomware, leaked credentials, phishing, & more.  On this episode, of CyberWire-X, we explore how automation can help teams make this shift to prioritize remediation based on bottom line business impact. Rick Howard, the CyberWire's CSO, Chief Analyst and Senior Fellow, discusses the topic with Rick Doten, CISO, Carolina Complete Health and CyberWire Hash Table member, while Dave Bittner, CyberWire podcast host, engages with Sponsor Pentera's Jay Mar-Tang, Sales Engineering Manager for the Americas, about automated security validation. Learn more about your ad choices. Visit megaphone.fm/adchoices

You're listening to the Cyber Wire Network, powered by N2K. Hey, everyone. Welcome to Cyber Wire X, a series of specials where we highlight important security topics affecting security professionals worldwide. I'm Rick Howard, the Chief Security Officer, Chief Analyst, and Senior Fellow at the Cyber Wire. And today's episode is titled, The Future of Security Validation, What's Next? It's clear that security executives need visibility into their actual cyber risk in real time. But with the flood of security alerts, it's tough for organizations to pinpoint impactful security gaps. To meet this

challenge, security teams are shifting to an exploit-centric approach to security validation. In other words, they are looking towards adversary group emulation, the process of imitating the tactics, techniques, and procedures of a specific adversary in order to assess and improve how resilient an organization is against known adversary attack sequences. In other words, red teaming. In this episode, I've invited two subject matter experts to the CyberWire hash table to discuss the current state of red teaming, blue teaming, purple teaming, and penetration testing. A program note, each CyberWireX special features two segments. In the first part, we'll hear from an industry expert on the topic at hand,

and in the second part, we'll hear from our show's sponsor for their point of view. And since I brought it up, here's a word from today's sponsor, Pentera. The scale of digital transformation in the enterprise also brings along a massive expansion of the attack surface. Whether known or unknown, this new attack surface introduces key security gaps that teams are unable to bridge using traditional vulnerability-centric approaches. vulnerability-centric approaches. Instead, consider using an exploit-based approach to constantly evaluate security readiness across the entire attack surface, both inside and out, to know your real security risk at any given time. Safely emulate real-world attack techniques to pinpoint the most impactful gaps in your security posture so you can prioritize patching with a risk-based remediation roadmap. Learn more about automated security validation at Pentera.io.

And we thank Pentera for sponsoring our show. I'm joined by Rick Doughton, the Carolina Complete Health CISO. He's an old friend of mine and a regular here at the Cyber Wire Hash Table. Rick, thanks for coming on the show. Thanks, Rick. Always happy to be here. So we're talking about red teaming today, and I want to distinguish the idea as being something different than penetration testing. So do you want to take a crack at explaining the difference between the two activities? Yeah, absolutely. And it's funny because two years ago when we did a hash table talk about this, I really didn't understand red teaming. And I ran penetration testing teams

for 10 years in the late nines to late 2000s. And so I'm like, and it also answered a question that I had from 20 years ago, because I had hired people out of the NSA red team. And when they did their first pen test and they're like, well, what can I do? What tools can I use? I'm like, you can do whatever you want. It was like, really? It's like, well, what's the scope? It's like, hey, it's this range.

It's like, really? I can do anything? I'm like, yeah. And I'm like, wow, they're real excited. They must be really limited. And then it occurred to me now 20 years later, oh, that's because they were red teaming. And so penetration testing is here's a target,

do whatever you can to get in and exploit it to get as far as you can. Red teaming is mim so penetration testing is here's a target, do whatever you can to get in and exploit it to get as far as you can. Red teaming is mimicking a very specific adversary using their tools and their tactics and their techniques to be able to do it. So if you're like, hey, I'm trying to imitate this particular campaign, their leverage is kind of tool, they go this way, this is their entry point, then we're seeing how well we're going to defend against that particular adversary. And so that's the difference between red teaming and pen then, you know, we're seeing how well we're going to defend against that particular adversary. And so that's the difference between red teaming and pen testing, which honestly, two years

ago, if you would have asked me, I said, eh, that's just a different word for the same thing. Well, I don't know about you, but I don't find a lot of value in pen testing. Pay some NSA red teamers to come in and find a hole in my network. Yeah, they're going to find a hole because, you know, that's what happens. But if you want to go after something specific, like here, I improved this area of my network. Can you guys get into that? You know, limit the scope.

Or like you said, what a real red team does is emulate somebody like Fancy Bear and see if their tactics, techniques, and procedures will actually work against my network. That is something useful that I can use. I don't know. Do you agree with that philosophy? Yeah, I agree. I agree with the exception of compliance. We're a healthcare payer. And so some of our Medicaid state contracts require us to do this yearly.

And so there are things that you have to check the box to do that. And it's also kind of good just to get a feel as you go around the network. But general pen testing, yes, it is better as a validation step because we have no problem finding things. Our challenge is fixing things. So, like, let's work on the process to fix things, and then let's validate it by then trying to find if there's anything we missed. I agree with you, right?

I don't need someone else to find more things for me to fix. You know, my list of to-dos is endless. I already know a bunch of stuff I got to fix. And to pay somebody, some group, an awful lot of money to come in and tell me some more things, I don't find a lot of value in that. And I don't find a lot of value of putting my own folks on it too.

Because like you said, we should spend those resources fixing things, not finding new things to go do. I mean, there's value in finding new things, but that's not the first thing I want to go do. Yeah. I mean, I remember, you know, also like maybe 15 years ago, companies stopped doing internal pen tests because we do an external pen test, which was like a certain range and internal, and we get as far as we can. And the internal pen test reports were hundreds of pages of like real things. And they're like, listen, I don't have time to fix all this anyway, so let's just

stop doing that. And I bring that up only because just recently this came up in another CISO roundtable I was on that they're like, hey, should we be doing more of this? But again, focus more on the asset configuration management, vulnerability management stuff you have. And then maybe as a validation step, do that. But that's also like the variation between a vulnerability assessment and a penetration test, right? You know, vulnerability between a vulnerability assessment and a penetration test, right? You know, vulnerability assessment, you identify vulnerabilities, penetration test,

you exploit them and see how far you get. Oftentimes, I'm fine just knowing that it's there. I trust that it can be exploited. Yeah, I don't want to spend a lot of time figuring that out. So, you mentioned earlier that you ran a pen testing team, a commercial pen testing team. What's your best story about those guys? What's the craziest thing they ever discovered? One of my favorites, I guess, was that the team, this is about 2005, and we had the team in a cube farm. And when they're all huddled around somebody, you know something's going on. So I kind of looked down, they're like, hey, what you guys got? And so I go down, it was a Friday evening, and I go down and they're like, hey, they're testing this online bank mortgage application. And they had already, I knew, like did a snail mail DDoS.

You know, we had like 500 rejection letters show up at our office, you know, letter letters. Like, okay, that's not good. Well, letter letters, those things still exist, yeah. Yeah, I mean, this is 2005. Okay, yeah, that's right. I mean, this is 2005. Okay. Yeah, that's right. It was a long time ago. And so they were saying, yeah, what we have is, okay, when you fill out the form, then it says, okay, here's everything, check and make sure it's good.

And then you hit submit. But when that one place where they say, here's your form up on the top far right is they had the URL had the database record number. And so all you did is very easily like back off a few numbers and then poof, there's somebody else's record. And you can then script to like go through and harvest ones that give you a good feedback and not a 404. And so they were like getting, it's like,

hey, we can pretty much get anybody's application that had known by just going to database just because of this. And it was in 2005, this was not an uncommon thing to be able to find. So at the time I'm like, okay, we need to call the customer and tell them they need to take this down and we need to maybe do forensics

and see has this already been exploited and they may have to have a reportable event and blah, blah, blah, being the manager, I'm saying these things. And so I call my point of contact who was a friend of mine and he was like, wow, that was a friend of mine. And he was like, wow, that's a good one. He goes, well, it's Friday and it's probably been there for a year or

so. So we're going to just, we'll address it on Monday. It can wait a whole weekend. And I'm like, I strongly suggest not doing that. And the reason why I use this example is like technical people don't make business decisions. It's not the CISO's decision to make this decision. It was like, you need to let the business know and they will decide based on risk. And so that's like one of my favorite ones because it's also a lesson. Well, I agree with that. And it goes back to what we were saying before, right? I already have a list of high priority things I got to fix. And I'm just going to throw this one in the pile and put it in adjusted appropriately. But yeah, I'm totally on board with what that guy decided to do.

I don't know. But let's take it back to the red teaming itself. What I really like about red teaming, the idea of it, is that we pretty much know a lot of what's going on in cyberspace in terms of adversary activity. If you just look at the MITRE ATT&CK framework, they're tracking some 250 adversary group campaigns and very detailed knowledge across the intrusion kill chain

on their tactics, techniques, and procedures. So why would I go find something new when I need to go make sure I'm protected against everything we know is already out there? So new, I guess what you're saying is like, if a human pen tester is like coming up with a new exploit to get somewhere, or they use one exploit and then traverse and live off the land and kind of do things i think

that the concepts are still the same as what's defined in the tax framework you know whether you're doing a buffer overflow or whether you're taking advantage of some misconfiguration whether you can see certain things those are all like you're still doing it but that was the thing i always loved about pen testing i actually was a pen tester for a couple of years. And then people that were better than me, and I'm more of a manager anyway, so I moved into management, is that it's one of those things where you're doing something that no one's ever done before every day. And there's a certain personality type for that. And that's great. And the reason why I'm going down that thread is that keeping pen testers happy is giving them work to do that's interesting that they can still like try to push themselves every

day. And when we were doing like commodity online baking applications that we've been testing for five or six years that are pretty solid and we're not going to find anything new, then they just get frustrated. You know, so I guess that there is something to be said for the baseline of like, make sure you don't suck. And then there's the, all right, is there something that's interesting? And so that's why I had some customers who only want like a three-day pen test, like,

because they know that if they find something, it's going to be right away. And then the level of effort, and it's always talked about cost of attack, right? So a, you know, top tier pen tester after two days would find like anything that was severe. And then maybe in a week they'll find something else, but that's enough for the risk level that they're willing to accept. I agree that the personality type of a pen tester versus a red teamer is slightly different.

But the thing I like about red teaming is the idea of combining it with the blue team. These things called purple operations. Yeah. Purple team stuff. Yeah. So the red team emulates fancy bear. The blue team doesn't know they're operating and hopefully is alerted to their presence.

And then there's a push me, pull you about how they react and all that. And then once all that's done, then they can compare notes and say, well, we did this here. What did you guys do? Well, we did this other thing. So it's a huge training exercise on testing your incident response process. So do you see a lot of people having the resources to get that done? No.

Yeah, that's it. Yes, I was gonna, I thought you were gonna say, what do you think about that? Yes, I love them. Purple teams are great. Everyone should do them. Very few people do for that reason.

It's like, you know, you can get some outside pen test team to be the red team and then you test your purple team and sometimes people do it in testing their managed service provider and those kinds of things but i think it's something that's not used as much as it can be or oftentimes it's used um more just to make them look bad you know sometimes it's like you know hey our defense is really bad we're going to do a blue a purple you know, hey, our defense is really bad. We're going to do a purple team and show that. Or our defense is really good in the purple team. And so,

I think they're great. So, purple teams can be done internally, like you said, right? Your own, you can hire out a purple team exercise. And I'm seeing discussions now of firms using, you know, becoming SaaS services that you can just automate a fancy bear attack where there's no humans on the other end. It's just a simulation. Are you seeing any of that as you talk to your customers and your peers out in the industry? Oh, yeah. I talk to a lot of vendors, as you know, and a lot of startups. And this attack simulation, continuous attack simulation is something that's becoming more popular. And they're doing these specific like right from the matter attack,

right from the MITRE attack framework, like you mentioned. And let's just automate those things. And then we'll just do different segments. And that's an easier way without having higher expensive pen testers to be able to kind of test what you're doing. It's like, all right, well,

let me run these modules for these types of things against this area of this type of the MatterTech framework and kind of see how I go. But then it goes back to exactly what you said at the beginning about like the value of red team. It's like just doing it for the sake of doing it may not be very helpful. And knowing that you're going to fail may not be helpful unless it's to really improve. It was like, well, that was bad. Okay, well, now we know. Like, we're going to do anything about it?

Nope. We're just going to now know, which then could also be a liability because that's why some pen test teams go through third-party counsel so that pen test report is covered under client privilege. So it can't be disclosable because like you know about it, that's kind of bad.

So Red Team, in my mind, has two benefits, right? One is it tests your defensive controls against known adversary activity. I like that. So if we run an emulation or simulation or even use humans to do it, we'll know the things we put in place specifically for Fancy Bear, let's say.

They actually work. So I like that. The second thing, though, it tests your internal teams. How come you didn't pick these guys up? You've been watching for them for a year. How come you didn't pick up any fancy bear activity? So those are two positives. But what you said before is important. This is not something done by startups and people with no resources, right? You have to have done a lot of other things to make your defensive posture mature. And then I would take on red teaming. Red team exercise and purple team exercise is a higher up on the maturity scale. If you were just still doing

your security programs based on tools, I put in EDR, I have this thing, I'm watching this thing, I have this other thing, and I'm using encryption and multi-factor, then you're not doing security operations. You are just kind of managing tools and keeping them up to date. When you then kind of elevate to, all right, now I have security operations. I'm watching, I'm responding, I'm recovering. I have teams to be able to do these things. And now I'm looking for stuff and then getting more proactive

into like threat intelligence and threat hunting. Then we're starting to get to the point where all right, now we're ready to do this. So you're right. I always kind of use it as a pyramid and there's fewer people as you get to the top. And this level of maturity is like in the smaller part of the pyramid. It's not just some any, when I was a CISO nine years ago for a 2,500 person company, pen test rent teaming was really not that useful.

We're just trying to keep our head above water and make sure we're covering all the doors and windows. Good stuff, Rick, but we're going to have to leave it there. That's Rick Doughton, the Carolina Complete Health CISO. Thanks for coming on the show, Rick. Next up is Dave Bittner's conversation with Jay Martang, the sales engineering manager for the Americas at Pintera. So today we're going to be digging into the topic of security validation. Can we start off with just some high-level stuff here? Can you give us a little bit of the background? How did this start to become a thing, and what led us to the place where we find ourselves today? this start to become a thing and what led us to the place where we find ourselves today?

Yeah, I think security validation has always been an initiative in organizations. What we've seen is though, and then the challenge is that the way this was typically done before was it was all done through penetration testing and manual third-party efforts, or whether that is third parties coming in because you don't have the expertise in-house, or you're starting to and have to build a team and rely on this expertise internally, and then those offensive exercises can partake. But the challenge is, is how often are you doing them? How much time is it taking? And again, are you able to acquire the talent necessary to test all those controls? And that's really what it is. Using offensive exercises and the offensive security approach to understand all the investments,

the layered defense that you've put in place, are those controls working? And not only are the controls working, but are the processes and procedures that surround these controls, are they working as you expect them to? And what you don't want to do is assume and just wait for a breach to say, oh, are we ready or are we not ready? Hmm.

Is it fair to say that my perception is that, you know, if you're bringing in someone from outside, that you're really sort of getting a snapshot of that point in time, as opposed to an ongoing real-time sort of evaluation of where you stand. That is 100% correct. So, and there's many talented people out there, right?

So that's not a knock on the talent as much as it's a knock on how often you can do it. And you're exactly right. You're taking a snapshot in time. Maybe you do it once a year, but you do a penetration test. And then next week, you might make a change in the environment. I mean, the environment in itself is dynamic. You're adding new infrastructure. You might be adding identities. You might be adding technologies, or you might be adding policy. And all of that can fundamentally change the way an organization is positioned from a risk posture perspective.

So describe to me what you're advocating here. When we talk about automating our security validation, what exactly does that entail? Right. We're talking now about automating the offensive exercises that were once done manually, enabling someone to hit a button through automation, be able to take those motions, those steps, those procedures, and do it at any point in time and not necessarily have to be the expert anymore. So imagine being able to do this on the weekly, hit a button, run offensive exercises,

understand and validate, are there any gaps in the posture? Yes or no. And validate that the controls are working as expected. And then be able to go back to the business, whether that's an auditor or just upper level management or just in general, be able to answer the question, are we ready? Yeah. Well, we did this a week ago, or maybe we're not ready, but we understand the steps and what the gaps are in order to get to

the point where we are going to be in a better place. And not having to wait once a year to do that is extremely powerful. And that's what we're advocating is to always know, are you ready or not through automation? Can you walk us through how the setup of something like this works? I mean, how do you get it configured? Yeah. I mean, what we notice is that, and I think it's a trend overall in the industry is no one wants to deploy agents anymore. And then there's already a lot of security agents for different purposes. And again, they have their place. But if we can do this agentlessly, that's an advantage. And it's also more true to life because to be quite honest, attackers aren't using agents. They're not going to say, oh, well, we need to put

this agent on this machine and then we're going to have system level access. No. Attackers need to acquire that system-level access. So what we're looking to do is start with the assume breach mindset as well as come from the outside. So take two angles. It's almost like a jab on a right cross, right? We need to understand from both angles, are there gaps and what controls are going to stop and work and work well. From the outside, right, it's really using open source intelligence and seeing what is exposed externally to see where a potential foothold could be, where can attackers essentially breach the perimeter. On the inside, you can use something, just software, right? With that assume breach mindset,

they say, all right, well, if we're at this part of the network or in this VLAN or this area, typically you like to start where users are because as we know, there really is no, the perimeter isn't that wall that we thought it was, right? many, many, many years ago. The perimeter is now really porous.

There's holes all over the place. And you want to know what those holes are? It's our people. And that's not to say that they're bad people. It's just that you get a phishing email or you go to a website that you typically go to that is now compromised. And all of a sudden, there's an exploit kit and there's malware on that machine. It's very, very easy to breach that perimeter. Again, whether that's coming in from the outside or your users are just clicking links, something's going to happen.

So taking it from there, from where users sit, especially privileged users, because attackers are going to, they're going to do reconnaissance and they're going to say, well, who's working for the organization? Oh, well, let's just go on LinkedIn. And we have, oh, we have some database people. We have some developers. And oh, look at all these C-level executives. And understanding from that perspective, with the compromised identity, what would an attacker be able to do? Would they be able to listen on the wire and find credentials?

Or would they be able to, again, with a compromised identity, with a certain level of privilege, now move laterally or be able to get around? That's where we like to start with the goal, of course, being seeing if we can easily compromise critical assets. And that is going to do change fundamentally based on the industry vertical. Every industry has critical assets. It's based on the vertical vertical. Every industry has critical assets just based on the vertical. What are those assets?

And those assets could even be something that is relevant to businesses or companies that you do business with. You might just be part of a supply chain, which we often see as well. You mentioned that an organization is a dynamic thing, that there is always change. And it strikes me that the adversaries are dynamic as well. They're adjusting their techniques. How does the security validation, when it's automated, how does it adjust in a dynamic way as well? Well, I think the dynamic portion of it, whether it's organizations or attackers, what we need to focus on generally are TTPs, tools, techniques, and procedures. And by that, I mean, we're not looking for the newest hash of or signature of a specific piece of code, right? I mean, when we think about

and when we talk about vulnerabilities, vulnerabilities are ones that we just are aware of and vulnerabilities that are just, when I say aware of, the ones that are disclosed. So if SolarWinds doesn't disclose, right, or Mania, right, Fire doesn't disclose or whatever, and if anyone who's been or had experience with incident response, probably agree in the fact that there are a lot of incidents that are happening that are not being disclosed to the public, which means those

vulnerabilities aren't out there. So I think it's important when we talk about dynamic, whether that's the organization or the attackers, we need to focus on those TTPs and what are those TTPs. It's a combination, all different attack vectors and ways of getting around the environment, which is very challenging. I'm not saying it's easy, but I think we need to take a holistic approach in that regards to figure out, well, it's not just a point in time. It's not just one thing. It's a numerous amount of techniques. Think of it this way, right? A good fighter doesn't rely on just a strong right hand. It's a combination of jab, jab, cross, right hook, uppercuts, dodging, head movement. All of that, you can consider the TTPs in the environment. That's what we really need to focus on

because everything, it's not black and white. There's a lot of gray. You know, I think there's a tendency, perhaps even a stereotype, when people hear of automation, they fear that they're going to get a fire hose of information shot at them. How do you separate the signal from the noise here? I think what's important to focus on

and what we need to realize is that we're not looking to exploit vulnerabilities in general, right? There are thousands and thousands and thousands of vulnerabilities, and vulnerabilities are just a means to an end. You can't exploit something unless the vulnerability exists and if the vulnerability is exploitable. So I think focusing on exploitable vulnerabilities, and not only the exploitable vulnerabilities, but the exploitable vulnerabilities in the environment itself, helps eliminate all the noise. Because at that point, when we're looking at what has transpired in the network, we know with certainty that this happened. And then if we can prioritize based on impact, which one should we focus on? If one domino, right? Maybe we have

many dominoes here. Think of a table. We have multiple, a lot of dominoes. And if one domino caused thousands of others to knock over, we need to prioritize that first. So the fear of having all this noise doesn't really apply. It's not as applicable when we're talking about things that just apply from an exploitability perspective and that's very unique to the environment. And then when we focus on the ones that matter based on the impact, we can get the biggest bang for our buck,

the lowest hanging fruit, right? All those fancy terms, right, that really mean we're going to really make our return on investment from a time perspective matter. What are your recommendations for an organization who's looking to set down this path? Someone who doesn't have a whole lot of experience with this. What's the best way to get started? Well, I think any organization, the best way to get started is to have a solid understanding of their business. And by that, I mean, we need to have an understanding of what are the critical points in the environment. domain, domain controllers, as well as the privilege identities inside that environment.

We need to understand then after that, what are the critical points of that business? What if, you know, if certain assets were to go down, does that mean certain doom for our business and our organization? So we need to focus on those next. And then the same way that we've built the fence in depth around those critical assets, we now need to start validating those controls in depth with that same mindset. Start with critical and then move our way out. That was Jay Martang, the Sales Engineering Manager for the Americas at Pintera. And we'd like to thank Jay and Rick Doughton, the Carolina Complete Health CISO, in helping us gain a bit more clarity about the function of security validation. And finally, a special thanks to Pantera for sponsoring this show. CyberWire X is a production of the CyberWire and is proudly produced in Maryland at the startup studios of Data Tribe, where they are co-building the next generation of cybersecurity startups and technologies.

where they are co-building the next generation of cybersecurity startups and technologies. Our senior producer is Jennifer Iben. Our executive editor is Peter Kilpie. And on behalf of my colleague, David Bittner, I'm Rick Howard signing off. Thanks for listening.