Skip to content
NOW AVAILABLE Feature Release! Learn About Our Enhanced Capabilities for Prioritizing Remediation Learn more >>

VIDEO

Track Signal Through the Noise with PlexTrac

PlexTrac is the cybersecurity platform that empowers continuous assessment, automated workflow, and effective collaboration between teams

Series: PlexTrac Demos

Category: Blue Teaming, Product Features, Red Teaming

   BACK TO VIDEOS

Transcript

Welcome, everybody. We’re excited to have you join us today. I’m Daniels, founder and CEO. Plex Jack. We’ll do introductions here in a second, but we’re really excited to be kicking off an actual webinar series related related to measuring your offensive security maturity and how do you stack up and how do you plan for a program related to continuous offensive security testing and what are the components and what are the stages of that maturity life cycle. So we are excited to be able to share this knowledge. We’ve got a great group of folks that have combined decades worth of experience in offensive security, so we’re in for a treat.
And thank you for joining us. And we know your time is valuable. We’ll dive right in. First, let’s do introductions. Let me get my cursor over here. As I said, I’m Dana Claus, founder and CEO of Lex Track. I’ve been in the security space my whole career, was a penetration tester and a web app SEC tester for many years and then started Flex Track a few years ago.

And it’s just been a fun ride to help programs mature from an offensive security perspective, as well as helping people keep focused on fighting the right battles. So that’s who I am. I’ll kind of be the MC for today. Dan, why don’t you introduce yourself? Sure. Thanks, Dan. Then I’ll pass it to the other two. Dan? Yes.
Thanks. I’m Dan Desk. I’m CEO managing Partner of Echelon Risk and Cyber. So we’re a full service cyber security consulting firm with offensive security adversarial emulation as a key component of our service offerings. Also a customer and user of Flex Track. Uses on a daily basis, our teams do with our clients. So extremely happy to be here and talk about offensive security maturity and how to level up your program.
Great.

Hey, Nick Popovich. I was a consultant Pen tester for about a decade, spent a number of years as Red Teamer. Also a customer and friend of Plex Track for a number of years. And I like the sauce that they cooked with so much that I begged Dan to let me work with him. And he is. So I’m acting as the hacker in residence for Plex Trek, giving that offensive security flavor to operations here.
And I guess that leaves me spicy. Dan. So I’m David Schloss, on the managing lead for offensive security at Echelon Risk.

Prior special operations, cyber guy. Had a lot of fun doing that and got injured and they made me get out. So started doing consulting work and whatnot.

Lover of FlexRack. I think it’s a fun little tool to get my teams involved in. And the fun way of looking at my job is I like to say I’m the Emulated mob boss of a group of Emulated criminals. So we’re going to talk a little bit about that today. That’s awesome. That’s good. Very cool.

So, as we mentioned before, we’re kind of kicking off a series where we want to dive deep into different areas of offensive security and what it means to be building a program and having this continuous mentality. So today’s webinar is really setting the groundwork and laying the foundation for the entire series. And what does it mean to have a maturity scale when we talk about our offensive security? So this series is going to be a deep dive into how you get started and how you can measure your progress and measure your success in maturity along the way. Today we’re going to introduce the three pillars of program maturity. It all comes down. We hear this a lot in the It realm or in technology in general. Like, people, process and technology are core to how a program is structured.

We’re going to dive deep into how those apply on the offensive security space and explain the maturity model that exists and what types of activities exist within each of those categories of the maturity model and then really start to relate it back to like, what are the goals that you’re trying to achieve when you’re setting out to begin your journey in the offensive security space? Or if you already are on the journey, what are ways to continue to stay focused on your growth, your trends in the right direction? How do you measure these things and what are the tools, tactics and techniques that you need to continue to show progress and actually show return on investment? Right. There’s definitely a stigma around penetration testing that we want to make sure it gets squelched as well. So we’re excited to have you. We love this topic. Obviously, we’re all either current practitioners or former practitioners in the space and it’s a topic near and dear to all of our hearts. So buckle up and let’s get rocking. So let’s kind of just talk briefly about when we talk about offensive security.

How do the three pillars apply to getting a program started and where do you kind of focus if you’re wanting to begin the process of getting an offensive security program in place, what are the aspects of that? And maybe we’ll start with David or Nick, right? Okay, yeah, I can kick us off. So I think a lot of times when you’re looking at your own organizational maturity, especially around like, an offensive security team, it really comes down to what is your goal as a team.

Let’s say you’re not in the consulting space. You’re working as a business unit for an internal Pen testing team or an internal Red team.

A lot of this will come down to like, okay, what are you trying to accomplish as a Pen tester? Like. Your people can be a lot more broad in the sense of. Hey. We have a lot of general skills when it comes down to hacking a web app or hacking a network. And your processing technologies can follow through with that by being a lot more broad where in the case. If you’re a red team and you need to actually be covert and attempt to emulate adversaries.

You need to find people that truly understand the deepness of each individual section in offensive security. Because cybersecurity as a whole is a large field and has its own specializations across many different sections. So does offensive security, right? An exploit dev is not necessarily going to be the same capability as, let’s say, a really good web app tester. So you kind of have to evaluate what you’re trying to do and match up those skill sets and technologies, especially with the level of covertness and the level of deepness that you’re trying to get into. I think it’s a good way to put it in it. Yeah, I think you really hit on some good points there. And I also like to speak to the idea that organizationally, regardless if you are an internal enterprise security team, consultative, maybe your service provider, I think that the order on this slide makes sense.

And when we talk about people, I think when you’re at the genesis of your offensive security team journey, the first step is first, as David mentioned, establishing the goal and establishing the relationships and the charter and the purpose that the team is supposed to be delivering because then that can inform the rest. As you work with the people, the people you’re going to serve, the people that you’re going to staff, and you start creating a charter and a goal and a mission statement, then you can start to grind smooth the processes and methodologies that are important. Because if you just start shooting from the hip. Maybe it’s you and you get a ten night nine. Or you get a couple of people and you start throwing things at the wall with no process. No supporting technology. It’s going to be a bumpy start.

Especially if the business or the consumers of your services. Whether it’s internal as a provider or a consultant. It’s going to be a rough go. But if you start by establishing a charter, then you have something to measure against. You have your goals and that can inform the rest. How and who you hire can align with those goals. You can measure against those goals, the technology can support those goals.

And similarly, as you evolve and your goals mature, you can then support them. But it really does start with defining what it is you want to do, how you want to do it. And that really starts with communicating the charter and with the people and how the hiring decisions go into that.

I could add in here too, Dan. We do maturity assessments with our clients and we’ve analyzed some programs, some of our clients in various industries. And the very first part that we do is talk to people about what Nick just laid out there, right? Like going out and interviewing different people within the team and understanding if everybody has the same goal, we’ll go and ask the same question to half a dozen people on the team and we might get varying answers back and we’re like, okay, here’s a problem, right? No one really can agree on what the actual goal is. And some people might be, well, we just want to pone stuff and we want to find all the vulnerabilities. Yeah, that’s cool, but does it actually relate to business objectives, business values, and what you’re trying to accomplish for the company? So it definitely all starts there and that’s where we always like to begin when we go through an exercise like that. Yeah, that’s good. This is a good lens to have for the audience too, in terms of like, we lay out this maturity model that we’ll get to in just a second.

But there’s always a combination of do we have the right people that are going to achieve the goals, whether that’s an internal team or an external consultant provider. Like, do we have the right people in place to achieve the goals that we’re setting out to accomplish? Do we have the processes in place to actually do something meaningful with this program? Right? I mean, it’s one thing to just go pay somebody to do a pen test because you got to check a box for compliance or something, but then what are you going to do with those results? Do you have a plan on like, here’s what we’re going to do and here’s some concrete measured approach to actually showing value that comes from that. Just identifying something is one thing but actually fixing it as another. And then also what technologies do you have in place? Right? So have we invested in the right tools, not just done an evaluation of what problem are we trying to solve and then go get the technology? Because I think a lot of folks today just like, oh, I should just go buy this because that’s what everybody else is doing when it may not really be necessary, right? I think these are the good pillars that will kind of shape the lens as we talk through the maturity models. So let’s dive in one other kind of housekeeping item. Everybody, this is meant to be interactive. Feel free to ask questions in the Q and A section of the zoom panel there and we will try to address them in real time if it’s close to topic.

Otherwise, we will also have time at the end for any other questions that may come up during the presentation. So feel free to make this interactive. We love getting questions and things like that. So let’s move on to let’s actually introduce this maturity model that we’ve talked about and we can kind of dive into what are the different phases and how you actually progress. And then I’d just kind of be interested in the panels discussion on is this concrete or is it more fluid. Right? So here’s what we’ve laid out as the Offensive Security maturity model. We’ve got a blog post on the Plex Track blog about this as well, I think.
Nick, you helped write so you participated in some factory. Yeah, I had some insight in some review and PR. I can’t spell too. Good grandma is for, you know yeah, but we really feel like these are these are the steps related to offensive security. And when we talk about offensive security, it’s a proactive mindset. It’s trying to identify issues before they get exploited or before the bad thing happens. Right.

And if they do happen, how quickly can we detect them? So there’s two sides to that coin, right? In terms of not only being able to have capabilities to identify problems, but also to be or emulate or propose a simulated attack of some sort, but also the other side of being able to detect these tactics and techniques that are being executed in your environment. So this is how we’ve kind of laid out what those stages are from a maturity perspective. I’d like to kind of start with David and Dan. What is your take on as you come into customers? How do you kind of approach this? Because you really work with customers, not just from, hey, we’re just going to come in and do a pen test, but you’re a partner with them, right. So maybe explain kind of how you approach these and your thoughts on this model.

Yeah, I can kind of kick things off. I think sometimes we will run into organizations that haven’t figured out some of the basics or really fine tune them or dial them in just yet. And I think when we’re speaking to organizations that are just struggling with vulnerability management, let’s say as an example, we really sort of advise them, you really want to get XYZ tuned up first. Right? There’s a whole actual vulnerability Management maturity model that you can dive into, and there’s different stages to drill down to within that even. So it’s kind of like, yeah, get some of these kinks worked out first. Because we already know if we put our adversarial simulation folks up against your environment, we can already tell you what’s going to happen and how you don’t need to pay for a pen test to see that or to do that or to prove that. So our typical advice is try to get some of these things worked out first and then work your way up that ladder.

Right. So if you’re an organization that’s been getting a commodity pen test for the past five, six, seven years, it might be time to graduate to something like a red team where you give the adversarial folks more leeway in what they’re able to do, give them more runway and let them open the toolbox a little bit more. So for us, it’s asking and talking with our clients and figuring out, where are they at now? Asking a series of questions, maybe even looking at what they’ve done in the past, what the findings have been like, and then trying to make that judgment call, what’s right for them, of course, based on budgetary reasons and what they can afford as well.

Yeah, I think that’s pretty on point. The big thing I always tell most of our clients, especially when they’re talking, is you can’t jump start into a higher level if you’re not already doing something. I mean, in the past I’ve seen it where we’ve had people come to me and go, hey, I would love to do an adversarial emulation. You’re like, okay, cool. And then you come to find out that they’re only running their entire network off of a single VLAN.

They have no Ed at the end points. Right. They’re not doing bone scanning. So ultimately, wherever you are initially or what you’re doing at that time is really the benefit that you’ll get out of these tests. Right. So let’s say somebody wants to buy an average simulation, but they’re not doing bone scanning. Essentially all going to learn from this.

We need to be doing vulnerability scanning. So it may seem like the new hotness is to kind of be up there and have an adversary emulation where you’re taking some adversary like lapses or conte and putting them into the network and seeing what’s going to succeed. But ultimately what you’re going to get out of it is like what Dan said is, hey, you need to be doing this from the get go. We see it too often. And that’s why this is so important to kind of talk about now, is really figuring out where you’re at as a baseline to start improving from that.

How do companies measure that baseline? Or I guess, how do you advise companies like, hey, where do we get started? I think a big portion, at least on my side of the house, is to see what they’ve been doing prior, as Dan mentioned, right, if you’re doing commodity pen testing for six years, okay, yeah, maybe it’s time to be looking at something a little bit more advanced because you probably already learned enough from your pen testing. You’ve reached to a point where you’ve gotten all the benefit through it and to put it out there, you also don’t need to wait six years doing the same tasks to improve. As long as you have a good understanding from the executive level, being able to trade that really well, you can reach from bone scanning to pen testing. Red teaming in three years, right. Like year after year, just constant improvement. But it does come down to just kind of questions, talking to the client, understanding exactly what does the environment look like. I think when it comes down to the offensive security model, internal teams from industry have a little bit easier time figuring out where they exist in here because they’re already in the network.
But being open and honest about what your environment looks like and what you’re doing to improve or secure that security or that cyber security securities is core into understanding where you exist inside the maturity model.

Something I think might also resonate with some of the folks participating in this webinar would be when you’re trying to choose those providers, if it’s an external or internal. But the idea of you notice how the folks from Echelon were speaking and saying, it’s not just a money grab because I’ve also not only have I’ve been a practitioner for a long time, I actually got into being a Pen tester because I was the one coordinating on the other side the Pen test and having to deal with the results of it. And so I was like, wow, I want to do that professionally. What’s interesting is the organizations that are going to care about the quality of services they provide and your security posture as a consumer of their services, those are the ones you want to start choosing because it could be a money grab. They can charge you five times for a red team or an adversary soon, and if you’re not ready for it, it’s like sandblasting a soup cracker. You’re just going to get blasted and there’s no point in that. And then it’s interesting because I’ll be a little selfish and talk about my story about where I am now working with Plex Trek.

Now, the evolution that I’ve seen is organizations don’t just want to do those snapshot of time assessments. And if the providers and the folks who are consuming these services, they need a way to be able to take this data. And it’s not just a PDF from last year or the last ten years. It’s not just Excel documents having a platform that can allow you to then measure. So as we talk about the ability to measure your offensive security maturity as a consumer or provider, the platform that allows you to have a single pane of glass to start seeing trends and vulnerability and analysis. I mean, that is one of the reasons why I wanted to graduate. Not graduate, but I wanted to move in and support an organization that is supporting all of the organizations that are in this ecosystem, the technology ecosystem of both offensive providers and offensive consumers.
That’s where we live. And so that’s really neat to be able to partner them with organizations that can see through a platform that can see the data and you can make data informed decisions on the data that you’re getting through a platform that allows you to collaborate, curate, et cetera. Yeah, I think that’s a good point. I think when we kind of put it in the lens within each stage. If we’re in the lens of people processing technology right. That early on. You’re kind of planning out like.

Okay. Here’s how we’re going to get in the rhythm of doing some form of proactive assessment or an offensive assessment. Whether that’s a vulnerability scan. Vulnerability management. Like we say. It’s kind of an adjacent activity. But it’s still identifying good things that you get into a process of like.
Hey. This was identified and here’s how we go fix it. So it really greases the skids for those penetration tests where they’re much more targeted and you have distinct goals around them. And the team that you’re putting together for that is a combination at the end of the day of both internal and external providers. Right. So that you can have that partnership. We get externalized and then we have internal context of the environment to know.

When I was a security director here, we had a much better idea. Here’s what we know. We’re going to have issues. We’ll see if the red team will find it and when they report it, we’ll say like, yes, we knew about that. And then the goal is that they find something that we didn’t know about. Right. But I think that it’s important that each phase of this lifecycle you need that ecosystem that Nick was saying, that collection of external providers and internal team members.

And that’s also a measure of your maturity as well. Not everybody can hire an internal Pen test team. Right. And so what tools and technologies and processes are you putting in place to help supplement that while you’re also utilizing providers? Looks like we have a question here. Hang on 1 second.

Can you differentiate between this is from Mike. Can you differentiate between commodity Pen testing with a third party, third party tester sorry. And using some of the automated scanning tools in the market internally?

I think that’s a great question.

I think we can all answer that one.

First off, hello to Mike. Thanks for joining. I know Mike so happy you join us today. But Nick or David, do you guys want to take that one? Sure, yeah. It’s a really strong question to ask and great points to bring up here, especially when it comes down to third party testing and automated scanning tools.

Actually, the last webinar we all did together, we were talking about continuous Pen testing and changing up the environment a little bit so that it’s not a snapshot in time. We all see the benefit of it. And ultimately it is great that the industry has moved towards a more continuous approach. I think it’s a good way of putting it. But I would also put at least the automated scanning tools as like a stepping stone between vulnerability scanning and Pen test. And the reason being is at a Pen test level, there is business logic that just we don’t have the capability to write automated tools to dynamically attack. That right.

They’re great for getting a wide spectrum of your network, especially when it’s a really large network. If you’re like throwing out a class b into your network. It’s hard for a pen test team to even get through multiple 24s. But what is more than likely happening across multiple subnets you’re going to see is probably the likely truth for the entire network. So I think when it comes down to commodity pen testing, it’s important to remember that there is an additional like, let’s say 20%, that an automated tool just isn’t going to be able to provide you with as far as like an observation or a finding. And they’re definitely nowhere near the level of where a Red team or an adversarial emulation would be despite what people say. Right? I’m really good at friends with a lot of these devs that write these tools and I love the tools.

But red teaming adversarial emulation as a whole, like you start getting into more covertness, which requires a lot more bespoke development and changing per engagement. And so really going from phone scanning to pen testing, it’s great for it. Pen testing becomes more bespoke and then into red teaming and adversarial emulation simulation, it is unique to each individual engagement.

I agree with what David was hitting on and also don’t want to think that when we talk about commodities, pen testing, it’s a dirty word or kind of disparaging. We’re talking about levels and kind of tiers and graduation. So the difference between a seasoned practitioner who is engaged in a penetration test, who’s going to maybe leverage the tools in their toolbox, which is going to leverage some automation because as David mentioned, the scatter shot wide, being able to identify and categorize and observe things in an automated fashion. But one of the big differences is going to be the skill set, the operator behind the tools. So one of the things that you’re going to get from either trained individuals or consultancy is the difference between that person running a vulnerability scan versus somebody who hasn’t gotten as much experience and exposure to tons of disparate networks and environments and applications, knowing how to tune, knowing how to interpret the results, those types of things. I think a lot of what you get is when you’re getting either hiring expertise or engaging with consultative expertise, is if I just go buy a vault scanner, spin it up on the network and click Go. I’m not using the dozens and dozens of years of experience on how to tune that, how to best find it, those types of things.

I think that’s a big difference because we used to say that when I was a practice director at a large consultancy. It’s like, look, they have to derive value from our work. We’re not just running a scan and passing them the results. If we’re doing that, there’s no point they could just do that themselves. There has to be a value add internally or consultatively. And that’s what I think it is.

I think both add value if you use them correctly. And I think the notion of a commodity Pen test is really kind of like, I think we use that term pregnant kind of more from like what do you say? Hey. We’ll combine some of the automated stuff or maybe 80% of the tests that we’re doing is more automated and we’re kind of filling in the gaps with our manual stuff as opposed to the later end of the maturity model where hey. We’re sitting down and really distinguishing with the recipient of this test whether you’re an internal team or a consulting firm. Hey. What are the goals you want to accomplish? Are we specifically targeting this configuration of this database or something like that? It can get very specific and I think from a business person’s perspective or probably like a security director assist. So it’s also like where does the price change? Right? So I think you can kind of assume that the more specific the test, the more expensive it’s going to be but you’re going to get a lot more value out of that.

I think there’s a place on your internal program for those automated scanning tools as well. And the nice thing is there’s better automation coming out every day, right? We’re getting better pants as a service type tools like PenTerra site, blind spot and then you got your bug bounty programs like Cobalt and synagogue and those kinds of groups. Right, so I think there’s a lot of experience that you can tap into from an automation perspective but you’re still always going to need that manual touch, right? Very good. Yeah, I think that’s a great question and I think it also speaks to the maturity of where you sit in terms of how you look at getting an internal team put together and how the process and technology is going to play there as well as what factors go into your external selection process. One thing that we didn’t do and maybe we spend a little bit of time just kind of distinguishing like we talked a little bit about what a red team exercise is and how does the group, the audience today kind of take away from like, okay, I kind of understand vulnerability scanning. That’s your typical vulnerability management Pen test where it’s more that commodity type Pen test where it’s going to identify things that are exploitable out of the vulnerability scans and things like that. Red teams is going to be a little more kind of black box and what are all possible vectors, where do we distinguish when we’re ready to go into adversary and simulation and maybe kind of distinguish a little bit about what does those mean and what are the tactics and techniques behind them.

Nick, we’ll start with you. Yeah, I was actually going to posit that same question because I wanted to talk through the group’s perspective on are there and maybe this is a little bit outside of the question but something to chew on and hit later. What are the benchmarks or the key performance indicators? When do folks know when they’re so called, ready to proceed? I mean, we brushed real quick when Dan mentioned maybe you’ve been having commodity pen tests for a number of years and it’s time to graduate. But I wonder especially Echelon’s experience, if there are ways to start determining and maybe it’s so organizationally specific, you can’t have big questions like that. But I’d be curious on that.

Once LLMNR poisoning is solved in someone’s network, they can go to Red Team. They don’t have any LLMNR fondant doesn’t work anymore. Time for the Red Team.

Shout out to Flex Track for having those finding databases that you can add to, because I swear it seems like almost every client we hit that on.

No, I think that’s an interesting way question to put forward, right? Like, when do you graduate and what does that look like? And ultimately, it’s really how well you can communicate the need for security to your executive staff. I think that’s every cybersecurity professional pain point is like, how do I justify the cost of adding in some more layers in your defense in depth program? Right? I think a good way of looking at it is like, let’s say you’ve done a pen test or two if you’re going to red teaming, right? If you’re looking to improve in this maturity model is like, hey, we’ve done pen testing. That first one, they found a ton of stuff, we fixed it immediately. Right? The second one, they came back and they were finding little to nothing. Maybe lows and mediums at the best, same team, same capabilities as it was before. If you’re bringing in the third party, then maybe it’s time to go. Okay, well, they didn’t really find a whole lot.

Let’s open up the spectrum a little bit. Let’s let them roam a little bit freer. Because as you grow in this maturity model, the scope gets bigger and bigger into adversary emulation and simulation. I think that the biggest argument here is when does the scope stop? And ultimately, I could tell you as a prior govy doing this for real, right? Like, the scope never stops. Everything is game, especially in adversary emulation or simulation, because you’re only as secure as your least secure endpoint. Right. A good example of this is physical is starting to make its way back into actual apt actions.

Recently, North Korea was caught doing delivering malware through USBs in Europe, right? So to think that physical security isn’t part of cybersecurity is another large mistake. And as you grow in the security model, you’ll start to see like, oh, okay, this is also part of my cybersecurity responsibilities.
Especially coming from red teaming to average scale emulation and simulation. I think it is really important to start realizing that there is much more to your cybersecurity hardness than just like the computer.
Yeah, that’s a good point to add to that too. I would say let the Threat Intelligence speak to you. Right. So as you’re paying attention to what’s happening in your industry, in the marketplace, you’re seeing manufacturers get hit more, you’re seeing government organizations get hit more. You’re seeing these trends play out in real time. I think that is another indicator of, like, look, it’s time for us to protect against that, right. When you start to see things happen to companies that look smell.
I think that’s the time where you take those stories and you tell those stories to your executives and the folks who carry the budget strings and make the case for. Like. Look. We’ve been doing a good job testing out our security maturity through these different exercises. But we now want to take the next step because there’s now data out there to show. Like. Oh.
This apt is attacking industries like US. Health care. Yeah. Hospitality finance. Yeah. And now we know exactly what some of the techniques are, because some of this has been released through Threat Intelligence. Oh, we should leverage that.
Right. Now’s the time to do that. So, for me, it’s all about, like, tying that back to business risk, showing similar stories and using that in your pitch or plea to the leadership. Something that I’m seeing, too, is I think organizations can begin to really gauge their offensive security by the maturity of The Defenders. And that’s why I think the whole reason that we have these here, because if you notice the big differentiator, we have the Plex track offensive security maturity model up in front of you. But it just makes sense that if you’re doing activities that then The Defenders are being able to have telemetry of, react to, and they’re being able to detect, identify, stop, and react and track the activity, you graduate that activity to more closely emulate the genuine threat. So we have that red teaming that gets a little bit more covert.
It’s clandestine. Open scope. Black box or goal oriented or very long term. Then adversary emulation. Taking those known IOC. Those known indicators of compromise or techniques that are used TTP making sure yeah. The TTPs.
The different ways that adversaries are known on the books to be executed by that threat intelligence account of threat intelligence information. And then seeing running those through emulating that activity. Can they detect it? And then to that full on graduation of simulation, where you’re going rogue in that you’ve got apt profiles, you’ve got techniques and tools, but you’re writing your own old days, you’re writing your own secret sauce to go in and simulate an adversary activity at every step of the way. A really good way to gauge that is not only having your platform to be able to look at the offensive security outputs, but that engagement from The Defenders on telemetry. Could they see it? Did they detect? Do they block those types of activity? That’s really the litmus test. I think a good litmus test for knowing your organizational maturity in offensive is how good are your defenders getting based on your activity? I think you hit and we didn’t even plan this. You led right into my thoughts.
I planned it, yeah. I think that we talk about the scale of the capabilities that you would want to be either doing internally or having done on you from an external perspective. But the key is, and this is where I think we’ll definitely dive in as this series progresses is like, how do you measure that from the defensive perspective? And that’s really what it’s about, right. Your offensive security maturity is directly correlated to your defensive maturity. Right. And so bridging that gap is really what this model is all about. Like, hey, yeah, we could come in and do an adversary simulation on day one, blow you out of the water, right? And what value does that provide? So my advice is that once you actually have the foundation of, like, hey, we know we can do pen tests, we know we can start to detect this stuff, it’s okay to dabble in these other areas of offensive security.
It’s okay to pick some TTPs and do some threat informed tests around that, right? And then that helps plant the seed for how do we detect this and get into a process. And then as you continue to grow, then you can do more full scale exercises. So I think that’s an important aspect that if you’re never too immature to start, it’s just how are you going to handle those results and how are you actually going to plan to measure the outcomes, right? Just to throw in there. Too I would say it’s not only the blue team defender side maturity, but also look at the majority of the company from a controls perspective, business orderliness perspective. Too right. So you look at financial institutions.
For a long time, they’ve been following three lines of defense models. So you have your front line people, you’ve got your risk management in the second line, then you have internal audit in the third line. There’s financial institutions that we’re working with, they have their own red teams. They sit sort of in the hybrid 1st, 2nd line of defense, but then we’re seeing internal audit shops, like having their own security testing teams as well to challenge what the red team is doing.
And I think it’s a culmination of the build up of these controls over time in the company’s maturity because of years of regulation, because of years of examiners knocking on the door.
And some of the controls they have in place are purely business related controls. Like, they recognize downstream effects of some of the fraudulent hacks and things that occur. So I think that’s a really important thing to think about. Too when you think of, hey, is our company ready to do this yet or not? Where are we as a company mature yeah. And I think what we’re all touching on is that you have to be purposeful and plan. Right. And I think that phase in the lifecycle is constantly overlooked.
What are we trying to accomplish? Let’s plan this out. And then what are the phases that go into that? Right, so I think you highlighted that. Well, we got an interesting question. I think, Dan, you said you might take it, but I’ll read it and it’s got some acronyms that will spell out. Right. So do you see the push from the EO, which is Executive orders pushing S bombs? Software billing materials will give the attackers the volume information they need to find exploits. Is this being addressed as a simulation? So, Dan, what are your thoughts there? What do you see? Yeah, I think it’s a good thing that software bill of materials are becoming a thing from the executive office.
And knowing what goes into the soup before you put the soup into your environment, I think is a very positive thing. Now, I think the question is, if everybody knows the recipe, will that make it more interesting for attackers, give the attackers the upper hand? I’m always of the mindset of let’s make the information freely available to all and let the chips fall where they may. But hopefully the defenders get the head start on the S bombs and they understand what’s in the soup and what’s in their environment well before the attackers do.
And that head start should give you enough time to make sure that you’re protected.
I think we saw with things like Lockfordj and some of these other celebrity vulnerabilities lately, no one knew what the heck log for J was even running in their environment and on what tools. I mean, even some of the vendors didn’t even know. So as an acquirer of those software tools, if you have an S bomb, I think it gives the vendors the leg up first because as soon as something comes out, you could tie it directly through the S bomb and say, oh, we don’t inventory it. Yeah, you have the ability to inventory exactly his main database. And if you have that, then you have the head start on the attacker, hopefully. And hopefully that gives you enough time to react quick enough. I look at it like this, and this might be smarmy, so apologies for sounding like I have an attitude, but a lot of times it’s not so much.
I mean, ubiquitous flaws aside, we all know lots of Jay.
The reality, though, is usually implementation and configuration of said RFCs are free. We all have access to the same RFCs. I don’t know how many RFCs I’ve pulled through. And you know what? I have read RFCs with semi intelligent eyes, but somebody else has gone through that RFC and popped in ODI from it. Or they go through the RFC. You see a lot of things that says implementation is advised or the vendor should or there’s a lot of goods and shows and whatnot, but at the end of the day, how that company or that.org implemented something from an RFC, you got to get on the wire, you got to sniff it out, you got to check it out, you got to poke and prod. Just the same with these S bomb, there’s going to be a recipe there for the soup and you’re going to see it and everybody has the opportunity.
It’s beautiful that you can put in your inventory. So then when a log for J, when something comes off, you have your inventory. You can rapidly respond to tech, deter, prevent, go on hunt, see if it was taken advantage of, all that good stuff. So yeah, I agree too and I actually was told that as well. A good researcher that used to work with me was like, we all have the same RFCs. Some people read them a little different, some people hope their fingers a little harder. Yeah, well, I think the inventory itself is helpful as just a general baseline.
And I think it’s also like, hey, anytime you’re engaging it with a customer or trying to acquire a new client, you’re going to go through a vendor security review process and they’re going to want to know like, hey, what’s in your environment? How are you testing these things? I think that’s a good baseline. I think it’s also not the only thing, right? And it’s important to know that when we talk about product security, there’s going to be pre configured packages and software that may just be configured directly out of the box like log for J as a part of your solution. But there’s also custom code being written and I think we talk a lot about kind of the TTPs around network penetration testing and lateral movement within the environment. But product security is also an important piece of this puzzle too, right? I mean, it pulls into the same maturity scale and that’s where you really need the understanding of the business logic of the product and the application and how those interact and the API security around it. So you can have that software bill of materials that kind of sets the baseline for your product. But then there’s still a lot of other potential vulnerabilities that exist that would need to be identified through manual means or other scanning techniques. That was actually something that was interesting to me.
I didn’t realize that the P Cert concept and Product Security and Product Security assessors was becoming such a I don’t know if niche is the right word, but such a specialty and focus just with industry events, talking to folks. Yeah, I’m the lead product security for XYZ. And then on the Plex Track side, seeing organizations that are partnering with us specifically to get the Plex Track platform for product security endeavors to be able to track the findings, report the findings, for their products and then be able to take those disparate components, disparate vulnerabilities and flaws up and down the stack and put them in and track them. It’s been a really eye opening for me. I kind of feel like I missed the boat on product security becoming a thing. And now I’m like, oh, wow, this is a real established specialization.
And it kind of feeds into that whole notion of shifting left, right. Just like in a breach response capability. How quickly can we identify that there’s nefarious activity happening in our environment on the product side? How quickly can we identify that we’re about to introduce a security vulnerability in our code or in our product, and can we remediate that before it actually goes to production? Right. So, I mean, same concept, just kind of different techniques, right? Chase that squirrel, Nick. Chase that product squirrel. It’s a deep rabbit hole. Yeah.
We got one more question. One more question right now. But everyone else, please feel free to answer or to chime in with questions. I got about ten minutes left, just as a time check. But this question is, have you seen an increase in demo requests and new clients due to the increased pressure on CEOs to take cyber security seriously? I’ll take that. And then, I mean, dan, maybe dan and you can take it. There’s no doubt that security is becoming a more pervasive topic right across all organizations.
So I would say the obvious answer is how seriously people take it is kind of where that’s continuing to progress. What I call kind of down the corporate stack in terms of early on. It was Fortune Ten companies. People that were big targets. Obvious targets. Like in the financial sector and things like that. Where there was very clear motivation for what they have would be wanted by attackers.
But we’re continuing to see the need and the growth and demand for security awareness and maturity all the way down to the small mid sized businesses. And I think that’s promulgated from a couple of factors. I think ransomware has definitely become the gold standard for, like, here’s why a small business needs cybersecurity in some fashion. Right? And so I think that is an important factor and that this is actually making an impact to the bottom line for small mid sized markets. But whether it’s coming straight from the CEO, it’s hard to say. I think that in general, like, the security industry itself has matured a lot and we’re seeing a continued growth in demand is in offensive security space. It’s one thing to just know you have a problem or know you got off by ransomware.
How do we prevent it the next time? And the best way to prevent something is to emulate it, to test for it, and try to identify where your gaps are before they get identified. What are your thoughts? Yes. I think it’s one of those things where people start to hear and see about something enough, and then they start to think, boy, maybe I should pay attention to this. And I’ve seen a lot of obvious cases where folks that have come to us who maybe haven’t made those types of investments in the past now are making investments. What’s up? Why is it changed a heart? This is great. Our CEO saw XYZ in the news happen to our competitor and called me and said, we got to make sure that doesn’t happen to us. Right.
So I just think it’s becoming so pervasive now just due to a multitude of different threats out there, lump on the fact that there is a war going on both kinetic and a cyber war with Russia and Ukraine. And there was a lot of and it still is a lot going on from a cyber perspective there as well. So all these things are obviously out there in the headlines. They’re making across the evening news quite more than ever before. So when cybersecurity issues become much more mainstream and people see the impact that it could have on people like them or companies like they run, I think that’s when it starts to become real for them and they make concessions and try to find ways to make things happen.
I just had an idea of essentially what we’re talking about now with ransomware and whatnot and tying it into our maturity model up on the screen.
It has become more often asked about, okay, are we protected from ransomware? At what point can we determine, can we prevent an attack like this? Because there is still a misconception out in the world that ransomware is the first action on a target, not the last action. Right. Essentially, like, a lot of these ransomware groups are coming in. They’ll do their entire privilege escalation maneuvers and TTPs, and then once they have the whole domain, then they execute their stuff. So if you were to try to run a ransomware engagement to test, if you could prevent that from a pen test perspective right. You’re really not learning a whole lot because, sure, maybe you can execute your neutered malware of ransomware on the device. All right? Maybe that means you need to tune your AV EDR a little bit more.
But it’s not going through the exact use cases that we’ve seen, like conte or lapsis or others where they take legitimate domain credentials and then find ways to privilege escalate those domain credentials into something that is able to RDP into every host. Right. Let’s say you’re using the administration password. The local admin is the same password across every device. Okay, well, if you’re just doing a pen test, you may or may not see that. Right. If you are at the point where you’re at a red team, though, a lot of times that’s something that’s commonly tested because there’s a lot more bespokenness to stealth and trying to use what is already available in the environment instead of trying to import known malicious tools that would be done especially in a pen test.
A lot of APDs are not just running like medicine float on a few skated. English is hard today.
As you start to grow in your maturity, you’ll start to see like, hey, we’re not necessarily going to be catching off. You skated malware right off the bat. And this ties into what Nick was saying, like, where’s your defenders at, right? Eventually you will be catching those beacons, though, those call outs from Cobalt Strike or Mythic or whatever it may be, like, hey, every five so minutes we get a call to, this is not a malicious url.com. That’s kind of odd, right? And you can start investigating some of that. So as you grow in your adversary or offensive security maturity, you can start validating whether or not you are vulnerable to some of these more common attacks, like ransomware or data extortion.
That’s all I had to add, though. Yeah, no, that’s great. Thanks. So we got three minutes. We’ll kind of jump to the last slide, and by all means, if there’s any other questions, please feel free to reach out. But we’re excited about this series coming up. We kind of laid the foundation in this talk around like, hey, why are we doing this? And why would somebody even want to begin the process of actually creating an offensive security program as opposed to just kind of going through some motions that I think a lot of us are used to seeing, hey, we got to do an annual pen test.
We got to do some of these things. It’s very responsive or reactive, I guess I should say, oh, this just happened in the news. I better see if I can test us as opposed to taking a more proactive stance. And so as we kind of wrap up, I’ll maybe kind of pull the panel and say, like, hey, for the audience, as they’re starting to get an offensive strategy together, whether they’re already doing a lot of these things or haven’t even started, what do you think that those goals should be from getting the process started or getting that strategy in place? What are some of the goals that you would recommend for folks? I could start I think it starts with your people hiring people that are big thinkers but can also be detail oriented when needed. So I think you really have to pay attention to making sure people don’t focus on things that they think, hey, this is a cool thing. I want to try to execute this kind of attack or test.
You want people who are asking, does this make sense for the goals of the organization, for what we’re trying to accomplish, where the tech stack of the company is going, right? If it’s a SAS company, you don’t want traditional network pen testers.
I think it all starts with the people making sure the people are bought in and they have the right mindset and build the right goals.
Yeah, I’ll add to that and say, like, the first person, you have to run it right. And this is kind of a boast, I guess, to myself, because Dan hired is the guy to run the offset side. But really, the first person that you bring in and you explain your goal, your charter of what you’re trying to accomplish, you want them to really have a decent skill set from the get go, right? Like being able to go, all right, yeah, that makes sense. Let’s direct the team in this order, and they’ll be able to fill in the gaps that they may or may not have to improve and get to the point where you are reaching that goal. But yeah, that was a little ADHD right there, I’ll be honest with you. A little out there. But no, it comes down to definitely making sure the first person you bring in really understands that goal and being clear with what is the objective.
If you’ve had an experience of both being in the consultative side as well as on an internal team for large enterprise, what are your thoughts? I mean, I can’t really echo too much more than that. I would say that from both sides, the people matter the most, but it’s also that establishing relationships between the people, the relationships between the business and the newly formed team, and that team’s leadership and the defenders team. And if it’s a client, the people on that team, everybody coming into lockstep and really establishing before you go and build everything out and then come in and try and wedge everybody’s expectations to what you’ve already built, you build based on the needs presented, because the relationship building, that relationship building, you just can’t manufacture that. You have to do it well to divide the point that first hire, they have to be superhuman. They have to be able to be technically proficient, but also be able to lead, gather, create relationships, et cetera. If you can’t get anybody to fix anything right, then your program should be tossing the garbage. If you don’t make friends and you make everybody mad because of your testing, that’s not good.
Yeah. And I think my advice would be coming into this with a programmatic approach, right? Hey, we’re going to start doing this on a continuous and here are the defined goals. We want to actually be able to show progress over time. And that takes, like, whether you bring in somebody that has the offensive security expertise or at least somebody that knows how to start building a programmatic approach to security or to a practice, then you can fill in the gaps on the technical side, either from automation or other team members that actually have that skill set, whether that’s external or internal. I think my advice is coming at it from a programmatic approach like setting distinct goals and being able to show progress over time and having having a mindset of we’re going to do this on a continuous basis is really important in today’s world. Right. I think gone are the days where you’re going to get as much value out of just like your periodic pen test from a random security provider and not really having any internal capability whatsoever.
That will kind of wrap it up. We did have a funny question to kind of close it out. First off, someone did congratulate you, David, on a CVE. So good work there. And then another question pointed out to be he’s the star of the hour. Do I have to have hair like David to be successful at Offset? Yeah. First off, if you want to talk at Beats sides are to you and be successful, which the guy, Jeff who asked the question has, yeah, you definitely need to step up that hair game and head and shoulders will only go so far.
You got to really take care of the hair.
That’s good stuff. We are hiring, though, just to throw that out there.
Awesome. Well, thanks so much for a little bit over time, but definitely stay connected for Plex Track. We’ve got tons of videos and things about our platform and how we can help you in this process. Definitely sign up for a demo. Reach out to Dana David at Echelon Risk to help have them partner with you on your security program and growth. And stay tuned for more on the next webinar in this series. I think it’s going to be fun.
David, Dan, thank you so much for your time today. Nick, as always, it’s a pleasure.
Thank you, everyone. Everybody that stuck around, we’re excited to sign off and see you next time. Have a great have a great rest of your guys’day. Thanks, everybody.