Unspoken Security Ep 17: What's the Purpose of Attack Surface Management?

In the concluding segment of the Unspoken Security episode, host AJ Nash and guest Jeff Foley discuss the importance of coding skills for security professionals, emphasizing that while coding is a powerful "super‑power" that can open career opportunities and enable automation, it is not a strict prerequisite for a successful security career. They explore the "build vs buy" dilemma, noting that many organizations oscillate between purchasing third‑party tools and developing custom solutions, and how a lack of coding ability could affect job security in a build‑centric environment. Both hosts stress the value of expanding one's skill set—whether through programming, reverse engineering, or other technical capabilities—to increase marketability and resilience against economic shifts. The conversation shifts to community engagement, with Jeff promoting the OWASP Amass project as a central tool for attack surface intelligence, inviting listeners to contribute via code, advocacy, testing, or speaking. AJ reinforces the invitation, mentions Jeff’s presence at DEF CON, and wraps up the episode with a call to action for listeners to subscribe, provide feedback, and support the Unspoken Security program. The segment blends career advice, practical industry insights, and a promotional plug for open‑source collaboration.
Chapters
I mean, we've all seen the claims, right, where they say attackers spend 90% on the recon, 10% on pulling the trigger for the attack. But it's true, right? They spend a lot of time understanding the target so that when they finally move forward, it's going to work.
Welcome to Unspoken Security by Zero Fox, the raw and gritty podcast for cybersecurity professionals who want to understand how threat actors are leveraging the internet. In each episode, your host AJ Nash engages with various industry experts to dissect current trends, share practical insights, and address the blunt truths surrounding security. Ultimately, the lessons learned will enable security professionals to take an intel-driven, proactive approach to physical and cybersecurity that extends past the perimeter. Let's get started.
This is how legends are made.
Hello and welcome to another episode of Unspoken Security, brought to you by ZeroFox, the only unified external cybersecurity platform. I'm your host, AJ Nash. I spent 19 years in the intelligence community, mostly at NSA, and I've been building maturing intelligence programs in the private sector for about 8 years. I'm passionate about intelligence, security, public speaking, mentoring, and teaching. I also have a master's degree in organizational leadership from Gonzaga University. Go Zags! And continue to be deeply committed to servant leadership. This podcast brings all these elements together with some incredible guests, and then we're going to have these authentic, unfiltered conversations on a wide range of challenging topics. It's not your typical podcast. You know, it's not gonna be all polished. My dog has made occasional appearances on the show, and people argue and debate. We might even swear here. I sure will. And that's, that's all okay. You want to think of this podcast as a conversation that you'd overhear at a bar after a long day at one of the larger cybersecurity conferences. These are the conversations we usually have when nobody's listening. So today I'm joined by Jeff Foley. He's the founder and leader of the OWASP AMASS flagship project, an adjunct professor, adjunct lecturer at Utica University. Oh yeah. And he also happens to be the vice president and distinguished fellow of research for us at ZeroFox. Before joining ZeroFox, Jeff was the global head of attack surface management for Citibank. He's been an adjunct professor at the State University of New York, uh, and he's held various roles across nearly 20 years. He's an old guy like me, uh, within the government defense sector. He has a bachelor's degree in computer science from SUNY Polytechnic Institute. So that's that State University of New York I mentioned, and a master's in cybersecurity from Utica University. It's a, it's a hell of a bio, Jeff. Uh, anything I left out that you want to add?
Oh, just that for many years when that career started, it was with us, like yourself, the government space pulled into cyber warfare where the focus was superiority, uh, understanding the battle space, you know, things that maybe you don't quite hear, uh, in commercial cybersecurity. But I think as we'll get to later, when I came out of that world and saw how different it was in the commercial world, it was eye-opening and caused some of these things to happen that I'm known for today. And, uh, you know, the past lives that you just mentioned from the bio.
Yeah. I mean, listen, I know, like you said, you came outta the government space. So did I. And some people get ruffled by that, I guess. You know, I, I hear that occasionally, right? I mean, NSA is in my bio and that's all well and good, right? The truth of the matter is there's a lot of great talent in the government space and the government is a great place to learn and how to build things. The government does plenty of things wrong. There's plenty of people who can have lots of valid complaints about the government. It doesn't mean everything's wrong. Uh, the truth of the matter is, if you talk about security, if you talk about cybersecurity now, physical security before, warfighting, whether it's kinetic or cyber, that's, that's been the government's domain. That's where it comes from, right? So it makes good sense that a lot of really good talent comes out of there. But it'll be interesting to dig into it with you and talk about what you did learn there, what you've been able to apply, you know, as you said, to the commercial sector, to the private sector, because terminology's different, motives are different. The opportunities are different. Hell, the legal requirements and authorities are different out here, but some of the goals are the same, right? Our goal is to try to keep ourselves safe, you know, to protect ourselves from people who want to hurt us or steal from us. We don't do as much of the offensive as they do on the government side. There's some laws in place there, but a lot of the things that the government has to do to keep people safe are the kind of lessons we want to learn and bring into the private sector. So, you know, I'm excited to dig into this with you and learn more about attack surface management and what you've learned and what you've built and where we're going today. So with that, we really should just jump right in, man. The topic today is what's the purpose of attack surface management? Because a lot of people hear about attack surface management, ASM, or extended attack surface management, or external attack surface management, all these different terms. But it's really important to talk about, you know, why this even matters, you know, and frankly, who better to ask than the guy who founded OWASP, Amass. So that's why I want to jump in. But before we get to the why, With most things, you really want to discuss the what, right? Not everybody who's going to listen to this knows what attack surface management is, or maybe they think they do, and maybe their definitions aren't entirely correct. It happens. So I want to just level set here. I want to get this baseline with the expert, and that's you in this case, Jeff. In your words, what is attack surface management?
Hmm. Putting that simply, right? Well, if we're trying to keep that as simple as possible, I'd say visibility, but of course that word's so overused and it can mean so many things. But what I've been telling people for as long as I've been involved in trying to promote this or advocate for the importance of this is it's the adversary, adversarial perspective. It's looking through the adversary, adversarial lens, really. So, and why is that important? Well, if you've ever seen a vulnerability management program where they don't have all the assets on the list, right?
Right.
That's right. That's monitoring everything. I mean, but this happens to almost every company. They miss some or they need to add some new ones that they just found out about. But if you are only looking at it from that perspective of, well, we're watching what we've been told to watch or what we think we're supposed to be watching. But see, adversaries don't do that, right? They just find out. They just go dig it up. And for the longest time, companies were not doing the same due diligence, I'll call it, right? Where it's, well, let's assume nothing. Let's just look at it as if we were going to put this organization in the crosshairs. And what do we see? Like an attacker would, because all too often what we find, or I can say every single time I've ever done this for any organization, what I find is there's more out there than the company realizes. So that's what ASM is. There's a lot of benefits that come from executing that or performing that periodically, which we can get to later.
Yeah.
So, so you're saying it's— well, first of all, I'm going to jump into the terminology, right? And you and I didn't invent this term, by the way. I think everybody should know that and probably does.
I—
but I'm going to attack it a little bit, I guess. Attack Service Management, from what you just described, There's not a lot of management involved in that, is there? Like, no offense to everybody.
I certainly didn't coin the term, right? I'm not really a big fan of it.
Neither am I, to be honest. And no offense to everybody out there in the world who, whoever invented this and all the marketing folks, including our own, frankly, who still talk about it as attack surface management. I've repeatedly said I'm not fond of the term because there's not much management to it. What you're saying is, if I'm hearing correctly, seeing yourself through the adversary's lens. So. You mentioned there's a lot of stuff out there people don't know exists, right? This, I think people call it shadow IT a lot of times, right? So no shock that people spin up new servers, new websites, even, you know, all sorts of new things in the name of the company. Maybe it's in cloud, right? They spin up new buckets in cloud and people don't know it exists, right? And this has been going on a long time. You know, that challenge, I've been on stage for years talking about Intel and I start by saying the, CMDB, you know, the, the configuration management database, which is supposed to be an inventory of everything you have, right? Every, every computer and all the software on it and all the versions and all the everything. And every time I've stood on stage and said, everybody raise their hand that's confident their CMDB is, is accurate, nobody raises their hand. Half the people laugh, which I think is kind of sad, frankly. And I just sit here going, well, how can you defend things you don't even know what you have? Like, you don't know your environment, you don't know your inventory. As an intel guy, it scares me because I can tell you this is scary adversary. They are, you know, they're very dangerous. They've got these tactics and techniques, you know, and they're interested in companies just like us and they've just come up with this new tactic. But I can't tell you if it really matters to us cuz I don't even know if we have that software system or we have that version or if we're patched or what our compensating controls are or, you know, what's exposed to the world. And people just shrug it off and kind of giggle sometimes that the CMDB is outta whack and. From what you're saying, I mean, this, this extends, right? You've got adversaries are able to just find stuff that we don't know exists. How do you defend things that you don't know exist? And so being able to look through the adversary lens, as you put it, and as you astutely also said, adversaries don't, they don't follow rules, right? They don't really care. They just go out and find shit. That's kind of the deal, right? Whatever means necessary to go out and find things, cuz their job is to get into our back pocket. And steal from us. Like, they don't have to follow the rules. So, you know, I think it's an interesting piece, that adversary component, as you said. So attack surface management is not management. Uh, it's visibility from what you're saying. Like, I've even argued it's a form of intelligence, like attack surface intelligence.
Yeah. I mean, that's what I would call it. If I could rename it, I would probably call it attack surface intelligence. It is intelligence. It's able to be turned into actionable intelligence. I mean, that, that's what we're really dealing with here. And like you said, that's how the adversary is using it. I mean, it's find out what we can about the target. That's in the form— if we're looking at this through an operation, right, it's understand the battlespace. So it's your job to understand your side, which would be like the blue side, but you have to understand the red side as well. It doesn't matter whether we're talking about because you're a defender or an attacker, both sides are necessary. You have to understand both sides in order to then start making decisions to say, we're either going to defend like this because we think it's likely that they are going to do this. Or if you're on the other side, the attacker's side, then you're going to look at the blue side and say, well, we believe they are set up to defend themselves in these ways. So we will choose these attack vectors. To increase the likelihood that these attacks are successful, they won't be detected, whatever your priorities are. So it requires this intelligence, a lot of times called reconnaissance, in order to make stronger decisions. And that's what we're now bringing to corporations and any organization for that matter that's on the internet is we're saying, you really need to do this to yourself so that if this was being done to you, You would know what they're going to see. If you don't like that, well, you have a problem and you need to fix it. Right. Because we, yeah, when it's all over, what you should be saying when this is a well-oiled machine is you should be saying, I do like what I'm seeing. I'm comfortable with what I'm seeing. And I think that's the position we want to be in as we continue to defend this organization in honestly a, contested environment. I mean, that's what the internet is, whether people want to admit that or not. It's a contested environment where there's a cost of doing business in a somewhat dangerous or, you know, a risky place. So you need to be coming to this conclusion that we've accepted the risk now, we're comfortable with the level of risk, and this is the way we want to keep it as we continue to accept the cost of doing business.
Yeah. Well, that's a good point. You talk about accepting risk, right? I mean, that's one of the biggest parts of being a CISO, you know, is risk, right? To be able to quantify the risk, be able to communicate that risk to leadership, be able to own or accept the risk, or be able to, you know, make sure that somebody else, if it does, the CSO perhaps, or the, you know, CIO or the whatever who ends up being, but being in a position to be able to own risk. It's really hard to own risk if you don't actually know what the risk is. Or it's really dangerous to own risk you think you knew what it was and it turns out there's a whole lot of risk you didn't know. You know, that shadow IT that's undefined, undetected, and suddenly that's the attack vector. That's the door that somebody gets in to your environment. You know, S3 buckets come to mind all the time in, you know, yeah, when we get into cloud, right? Misconfigured S3 buckets or extra S3 buckets that aren't supposed to be there because organizations didn't have policies in place or maybe had policies but didn't have controls in place. And lo and behold, you know, an organization might think that they know what their risk is and they say, well, we've, we're an acceptable risk. And the truth is you're carrying a whole lot of risk you didn't know about because you didn't know your own environment. So yeah, it's, you know, it's, go ahead.
So we, we've engaged a lot of organizations over the years and what we do is we assess them through the attacker's perspective and we come to the, you know, to the table and then we show them, well, this is what you look like. To an attacker on the internet. How much of that were you aware of? Or show us your asset inventory, right? To, and the thing is, it's completely common that even a company with a mature security program probably only knew about 80% of what we show them. Some, quite a few are at 50%.
And the risk ratings are all wrong then, right? I mean, obviously if they don't know half the stuff out there, their risk rating couldn't possibly be accurate any longer.
I don't know. It's, and it's, in some cases we've even seen 25%. Oh, Jesus. Is, is all they were aware of from what we were presenting to them.
And has anybody ever gotten like 100%? You ever had one they mapped out and they're like, yep, we know everything. But it, has that ever happened yet?
No, not a single one yet.
Not one yet. Even small groups, like even the tiniest companies, there's something out there they didn't realize, like an old piece of equipment or something.
I'm waiting. I'm waiting for the day.
Well, challenge, challenge laid out there for somebody. If anybody thinks they, they know 100% of their inventory, Reach out to Jeff Foley. We'll, we'll give you his email address and, you know, maybe we'll, we'll, we can call it some kind of a prize if somebody can actually do that. If we can do an ASM scan and they come out with 100%, you know what, I'm gonna do it right now outta my own pocket. Maybe this gets edited out. Let's hope so. Don't have money, but I'm gonna offer a $500 gift card right now. Like Amazon. I'm gonna pick a company so you can't get it from anywhere you want. $500 Amazon gift card. First company, first organization. Don't be like your home. System. I'm not interested in somebody from house saying, check my house, not that kind of bullshit. Come on, help me out here. But you work for a corporation, you got more than, I don't know, 20 people in a company. I'll go really small. And you can reach out to Jeff and you can prove that, you know, he did a scan and 100% of your stuff was accounted for. And I'll give you a $500 Amazon card. I'm only doing it once, by the way. So it's first come, first serve. I'm not made of money. So we'll see if that picks up, you know, when it comes out. And I'm going to regret this later probably, but If nothing else, Jeff, your story will change. At least you'll be able to say there's one, there's one company out there that proved to me it can be done.
Yeah, that'd be great. I appreciate that, AJ. Yeah. I mean, at least—
inclined to think I'll keep my $500 though.
At least these days, a lot of people are aware of the Amass project and the fact that they have a place to go if they are willing to take on this responsibility, right? Or attempt to address this. Whereas, I mean, we've been helping people for, all the way back to 2017, roughly, when unfortunately a lot of people didn't even realize they should be doing this, or it just seems like not part of a security program. Now, again, coming from my background in cyber warfare, this was just— you, you couldn't come to the conversation, right, if you couldn't, right, say you were up to speed on this information or intelligence. Frankly, you'd be kicked out of the room if, if you attempted to chime in on, uh, the decision-making when you didn't even know what the battle space looked like. But, uh, when, when I came to the private sector and this was the norm, at first I didn't believe it. Honestly, I thought it was just exceptions or edge cases, but it turned out no, it was, it was the norm. And that's when I, I said Wow, we, we need to do something about this. We need, we need to help change this. So that, that's where, you know, our initiative came from with the open source work.
Hmm. Well, that's a good, I mean, I'm glad you mentioned it, right? And yeah, you're right. Getting laughed outta the room. Like, it's like showing up for, imagine being a, a general who's showing up for, you know, meetings. We're gonna discuss an invasion of another country or whatever, and it's a land war and they can't tell you how many tanks and people they have. Oh no, we don't know. We've, they're over there somewhere. Well, what about this platoon? I'm not really sure where those guys are. Yeah. What about these guys? I wouldn't know. They're still part of the Army anymore.
Yeah.
I mean, it would be impossible, right? It wouldn't even come up as an idea. Of course, you know where all your inventory is and where all your weapons are and where all the things you have to defense are, you know, where all your forward base operating bases are and all these things are. And I'm with you. I, when I got in the private sector, you know, similar experience on the intel side when I realized how much wasn't known. At least on Intel, as they would say, well, you know, Intel's just moving into the private sector, makes sense. But when I started learning, and for me it was CMDB right away, was the first thing I was getting into as an Intel guy. I was like, all right, well, I gotta know what to defend. I gotta know what we have, et cetera. And when I realized I was working with and for people who didn't know, and it wasn't a panic, it wasn't like this is the top of our list of things to fix. It just was like, no, we don't really, we don't really know. We've got this database, but it's all out of date. And they just accepted it and moved on to the next thing. I was like, how, how, how's that okay? I don't understand it. I still don't. And it seems to be a bit of the norm, as you said. I find very few organizations that feel confident that they have their inventory sorted and they just go about their day. And I just think, well, your house is on fire. But as you said, moving into the private sector, you realize this was like the norm as opposed to just this outlier of these edge cases. So it brings me to the next question we want to talk about today, which is, now that we've talked about what attack service management is, despite the fact that it's not really management. Why was ASM created independent of the other programs like CTI, vulnerability management, red team? I mean, it sounds to me like it should be part of red team, right? It's, it's understanding what the adversary sees of us, so it's emulating what their vision is, and then you'd go from there. But why is ASM independent of all these things?
Yeah, it's a good question. And I, I imagine there's some people that would say, well, ASM could live within a red team function because the people, uh, that are performing red team exercises are definitely familiar with the process of collecting that kind of information about a target, right? The thing is, I would argue they're not usually intelligence people, right? There's a— right, there's a little bit of a gap there. So they're good at collecting it and then using it to do additional security assessment.
Mm-hmm.
They're used to that. And if they're given ample time, you know, most red teamers are even very good at u— using OSINT, you know, open source intelligence.
Sure.
To try to paint a more complete picture, as complete a picture as they can about their target. So the, these are not foreign concepts to them.
Mm-hmm.
But they're, they're not used to collecting all of this and making it very consumable by other security functions. So if you do put it in a red team function, I think what tends to happen is the data tends to stay there. Right. And, okay. I mean, you could probably fix that or adjust that if you were to prioritize it, but I think you're taking a chance that if you try to bring it to life within the red team function, it may end up staying there. Also, uh, security assessors are often used to keeping the information they collect about security private, right? Or they're—
sure, sure—
pretty good at keeping it to themselves. But ASM is information that needs to be shared with the rest of a security program, similar to threat intelligence. And again, therefore, the— almost like the culture doesn't quite match You know, the function.
Yeah, that's exactly what I was thinking. The word culture came to mind, that it sounds like it's more of a culture that doesn't fit red team. Red team sounds like they should be one of the primary customers of ASM, you know, feed into them to say, hey, this is, this is, we did a scan here, you can have this, it'll save you the trouble of having to do your own recon. We've already done the recon part for you. And then from there they can move on to the next things because they have a recon, you know, result. They have a report that already looks like what the adversary is seeing, and then they can get into How are we going to attack these endpoints and these assets as opposed to having to go find them first? But I'm with you. It seems to make sense culturally. You know, an organization does more of the reporting out and the sharing. That's not really a red team. I mean, they do their reports after they finish their operations, but that's about it. It sounds like it fits more within that intel piece, which is what we already talked about, which is why I think it shouldn't be called attack service management. It should be attack service intelligence because it's another form of intel. It's intel on ourselves from the adversary's point of view. And then, you know, we can layer the other intel pieces on it, I think. So it sounds like it makes sense. Like you're saying, it's a cultural difference. But what about like vulnerability management, any of the other organizations that it could have been tied to? Why is, why is it pretty much, you know, why is it different from vulnerability management? I guess it's a good question to ask in here.
Yeah. And a lot of companies have tried to stand up an ASM function within a vulnerability management function, you know, some sometimes with success, but I guess it also depends on how you're measuring success of your ASM function. So if it's only to expose the unknown unknowns, which we kind of talked about that, right? These, this percentage of, uh, assets that the organization's not aware is out there. Well, then ASM could do quite well finding those and feeding that to vulnerability management. So then VM can put eyes on those assets. But there's a lot more you can use ASM and/or ASI for than just making sure that your vulnerability management capabilities or vendors or what have you are looking at all the exposed assets. So I think again, the problem is if you put it there and it needs to get used or consumed by someone else, vulnerability management will probably have little motive to support that, right? They're just going to be looking at. Well, our job is to monitor these assets and make sure that they don't need to be patched or, you know, the correct security controls are in place. And as long as that's happening, then we're checking the boxes or meeting our, the expectations on us. But what about all these other potential consumers of the data? They often now don't get access to the data or the whole picture because again, this is a, an intelligence sharing capability. That's what this needs to be at the end of the day, not bring the data in and now make sure we're not missing anything and then call it a day. It's bring the data in and make sure all the right people are getting it the way they need it to take the appropriate action.
Got it. Okay. That makes sense then. Right. So Volns has their job to do. And like you said, their job is to find the Volns, monitor the Volns, not necessarily share information around. Red team, their job is to understand the environment from the adversary's perspective and then try to take action to uncover problems. But again, they're only reporting really as after-action reports for the most part. So I, then you got the intel space, right? And, and so on the intel side, and you and I both mentioned, you know, our belief this really falls in intel. Hell, you, you even just said ASI, which is attack service intelligence, I'm guessing is where you were going with that. So, but here's a, a piece here cuz I have my own bone to pick on the intel side. Most people who know me know I don't, I rarely have ever used the term cyber threat intelligence or even threat intelligence for that matter. I normally just call it intelligence. And the reasons, you know, for that are threat is a subset. People can call it CTI all they want. They're probably not gonna get me to buy into it. Threat is a subset of intel. It's not its own thing. And I think it's intel, then you have physical and you have cyber and threats are just all part of that, right? And that gets into risk too. Risk is your, you know, your threats and your vulns, right? So. That means that ASM or ASI, as we're starting to call it here in this conversation, that, that won't fit under a CTI program then. It's not a threat intel program because threat intel tends to be about threat actors, you know, tactics, techniques, and procedures, things like that. But if we talked about the larger intelligence program, which I admit is me getting on a soapbox, I've talked about for years how this should be elevated under a chief intelligence officer, et cetera. But if we do that now, it sounds like it unifies. You've got your threat intel component. You've also got your, your strategic intel is out there. You've also got your attack surface intel could be there. And you've got all these other diff— different forms of intelligence that could then be unified, you know, fusion intelligence center at that point. Would that make sense to you if it ended up moving in that direction? Then would it be something that would fit under an umbrella of intelligence? It's not under threat intel, cuz I, I think that's just, you know, monitoring TTPs and, and maybe actors in and of themselves. But in the greater scheme of intel, would it fit better as like attack service intel within a larger intel umbrella.
Yeah, I'm really glad you brought that up because— me too, because I've seen people try to put an ASM program under a CTI program and it kind of worked in that people understood that culture was there, right? To bring the intelligence in and disseminate it to the right people in the organization. Great, but the priority was on the threat intelligence, like you said, that subset, right?
Mm-hmm.
So the ASM kind of took the back seat or the back burner, and it still made it kind of hard to get it to the right consumers within the organization. So I would still say, be careful with that. I don't know if I would advocate that people put their ASM or ASI program under CTI, but like you're saying, when, when it's a larger program where this is about the fusion, the fusion, bringing it all together for the more strategic, uh, vision or, uh, visibility. Now I think we're talking because I've seen that done as well. Unfortunately, only in a few companies where they had, say, a large enough and mature enough program to, like, I assume they've been burnt a couple times. Trying to get this right.
Mm-hmm.
And then they realized, wait, this is the only right way to do this. And then they finally managed to build that out in what they called the Cyber Fusion Center. But it, it worked, right? Because now it brought all the data together. It identified the overlapping information or, or associations across the different kinds of intelligence, allowing you to paint the more complete picture. And it was great. It also made it easier to pull the, you know, what I'm going to keep calling ASI in for business intelligence or business decision-making, not necessarily just InfoSec, right? Because it's great that you now have, you know, I'll say visibility on the battlefield or for the assets that are exposed on the internet, but there's different ways you could use that. Right? There's a lot of ways you could pull that information into your decision-making processes and enhance your situational awareness for different— I'll call it challenges or problems that your company could be facing.
Sure. Well, yeah, I mean, I think that's— it's nice to know we're on the same page on this one, I guess, you know, that if this is elevated up, there's, there's more opportunities there. And you point out from a business standpoint, right, which is The goal of intelligence is to improve decision-making. And ultimately the goal of almost everything we're doing is, is from business standpoints. You wanna lower risk, you wanna increase profitability, which comes from lowering risk and lowering dangers, I suppose, is part of that concept, right? And also intel, and we talked about that culture component, the part of the culture for intelligence is understanding your stakeholders, understanding their requirements, and then delivering against those requirements. And this is another aspect of that where, as you said, you've seen some success if they do it as a fusion center, right? If you have ASI, you know, attack surface intelligence tied into a fusion center along with your threat intel and your strategic and all that, I suspect those organizations are pretty mature, which means they would have an understanding of who their stakeholders are, who their customers are, and what their requirements are. And then you could distribute to the right people. So our attack surface intelligence, our scan. Well, okay, well, that's going to go to the red team so they know how to emulate the adversary because this is what the adversary sees. It's also going to go to our vulns team, I suppose, to say, this is what we found that you might not know existed. You know, it could very well go to the CISO as well, you know, to talk about the full risk ratings or whoever's handling risk for that organization. Maybe the policy organization is going to see that, say, hey, your policies aren't being enforced properly, or do you have policies? People are spinning up all sorts of things. Do you have a written policy that says they can't? And if so, has it been distributed? And if so, how are you enforcing it? You know, all of these things become normal, you know, normalized for intelligence folks because that's our gig, right? We, we understand we, the stakeholders, the requirements, we deliver against those requirements. We monitor that. We measure that for effectiveness. Uh, and you can see impact and results, whereas a lot of these other organizations aren't designed or built that way. So I'm going to keep banging the drum on that, obviously, that, that we should look at this greater picture of intelligence. Because you're also getting all that context gets tied together then too. The Volns team will get the intel to not just know, hey, do you have a vulnerability? But what's the likelihood it's going to be compromised? What adversaries out there are capable of doing so and have the motivation to do so and have that motivation against your specific company, or at least, you know, your industry, your geography. Otherwise, I'm not sure how they're deciding how to prioritize things other than just, well, this looks scary, so we should make it number 1 versus number 3 versus number 212. That's never going to get done. And I've seen a lot of that. Like we see that same thing, fragmentation where the intel team knows a lot of stuff and the volun team worries about a lot of stuff and they don't talk nearly enough. And you get sort of the civilian equivalent of a 9/11 eventually, not nearly as devastating, of course, but in terms of when somebody looks and reviews, they go, well, geez, we had all the information. Yeah, but the right people couldn't talk to the right people because nobody knew. Nobody knew what they knew and or what I knew. And everybody lived in their own little silo. And we're seeing that in cyber. I don't know if you have, you've been out there a bunch. I'm guessing you've seen some of the same things. Where bad things happen, you realize it was preventable if all the right connections had been made.
But yeah, like you said earlier, the attackers don't have this problem, right?
Right. They don't get together and have meetings on calendars and have to schedule things out and take 2 hours to decide the next policy decision. They don't do all that kind of stuff.
Well, they're going to look at the whole company, right? All the different kinds of intelligence that you could collect in order to have as complete a picture as possible. And we've all seen the, the claims, right, where they say attackers spend 90% on the recon, 10% on pulling the trigger for the attack, right? But it's true, right? They spend a lot of time understanding the target so that when they finally move forward, it's going to work, right? And to your point, they want the most complete picture possible, right? To understand what exactly is that asset? Is it important? Is it going to get me where I'm trying to go? Are they likely to be watching it? Is it part of the, the crown jewels? All these kinds of questions which require big picture visibility of the organization, like not just information security or IT, but what, what is this company doing with these assets? What does it mean to the organization? Things like that. We, we need to make sure that these internal programs are collecting the data or the intelligence in the same way. So we're getting that more complete picture. When people ask questions for Intelligence X, that it's, it's actually enhancing our, say, the completeness of our, our view for the other types of intelligence, right? They're, they're complementing each other. But that's oftentimes not happening, right? Like you said, this is being done in silos. Everyone's keeping their information to themselves or close, you know, close to the chest, and it's not helping anybody.
Yeah, well, it's ironic, you know, we talked at the beginning of the show, right, about you and I both come out of the government space, and there are people that have all sorts of biases against government sometimes and aversions to talking about it, and some are well-founded and some aren't, and that's all fine. But this is a perfect example where I just kind of chuckle sadly to myself and say, geez, I feel like I've heard all this before. I have, and we all have. It's, this is, this was the pre-9/11 world of intelligence, right? Where that's what the 9/11 committee came back and said was failures in the community, which, listen, you can make a lot of arguments about that. And I don't know anybody who failed personally, but the system was set up to fail as it turned out, because everybody had their bits, right? And there was some sharing going on and some fusion in some relationships, but a lot of it wasn't. A lot of it was, I've got mine, you've got yours. I've got things to get done. I don't have time to worry about what you have to get done. We all have our own missions. And of course, then you throw in some politics, budget, you know, same things are happening now. We see it in cyber, right? Organizations, I'm going to focus on my responsibilities. I've got my KPIs and my OKRs and all this. And, you know, on my budget, which I have to defend against losing because budgets get cut. And so, well, geez, if we unified, if we did a fusion, system, well, who's going to be in charge then? I run my own org now and so do these other 3 peers of mine. If we fused it, I'm going to work for somebody else. I'm going to lose my job. I'm going to lose my budget. There's a lot of that I think that's happening. Not everywhere. I mean, some of it's just people haven't thought this way, but I suspect there's some of that going on. And let's face it, if you've got 3, I don't know, directors, senior directors, whatever it might be that are parallel, they're not going to run to the CISO and say, hey, I really think you should unify this and fire 2 of us. You know, they're not going to do that, right? And if the CISO hasn't given it much thought because they're buried in a thousand other things, they're probably not going to think to do it either. And I'm not saying, by the way, that you have to unify and fire people. That's not really my point. But there's a lot of reason for folks not to elevate this up as an idea. People don't like losing status. They don't like losing title. They don't like losing their jobs, obviously. They don't like losing income. And if they've got their own little lane and they continue to build the walls around it and that silo gets stronger and stronger, and they deliver results because the OKRs and the KPIs all say they are, delivering what they were supposed to deliver, they're not going anyplace. But the organization as a whole still has these giant blind spots and still has these inefficiencies. They may be overspending. Hell, how many times have you gone to an org and found that they had 2 or 3 different licenses for the same company, the same tooling that they didn't realize, and they're, they're double and triple paying.
They don't have any different companies to offer the same.
Yeah.
Very similar, you know, a vendor that has similar offerings. Yeah. All the time. I mean, actually, and they don't even realize it, right? They don't because they just don't talk to each other. Right. See, what you said earlier, I think— I'm pretty sure I heard you say Chief Intelligence Officer or something like that.
Yep, yep.
Right. I mean, if that were to become the norm, the directors could stay right where they are. Absolutely. Just, they'd be reporting to the right person is what I would call that. And, um, the specializations could stay in place, but We now have the right officer to make sure that all that's being brought together to that more unified view for the org and disseminated disseminating it to all the right people. I think that's part of the problem is we're, it, this is so important, but yet it doesn't reach CRO and that's why it's dysfunctional in a lot of ways for a lot of organizations.
No, I agree. I mean, that's, I wrote that paper a couple of years ago now, the rise of the CINO, the CINO, the chief intelligence officer. And, and that was exactly the thinking. It wasn't to replace anything. The truth of the matter is, I, I wrote it in the paper at the time and I say it repeatedly, it's not even the most novel idea other than it doesn't exist in the private sector. It's what happened after 9/11. It's, I'm not gonna lie about it. It's the Office of the Director of National Intelligence. This is where same concept. You need somebody who's a unifier. And what I had said is the, the C-level should be set that way. And the, the Chief Intelligence Officer should be the consigliere to the CEO, basically, along with the Chief Legal Officer. And then the other side, you got all your business folks. And that's where you get your intel requirements. You get them from the C-level and all the subordinates. There's all your intel requirements. So you got somebody in charge of all that. And then everybody else is a customer. They don't work for the CNO. Nobody's losing their jobs. Nobody's losing authority. Nobody's losing credibility or title or money or any of that. They're all doing what they're doing. It's just all aligned to enterprise-wide intelligence requirements now. And they are driven by the C-level, which means they also will include the business intelligence., right? The, the long-term strategic goals, not just from a security standpoint, but business. It'll include when you get into acquisitions, right? Mergers and acquisitions. There's not enough intel tied to that. And ASM would have a role to play in that too. Hey, let's run an ASM scan on this company and see, uh, what their footprint really looks like. You know, it would work on third-party risk. You could run, you know, attack surface management, uh, scans for third-party risk and have the same results. So if you're gonna acquire a company or if you're gonna merge with a company or partner with a company or Hire a vendor. These are all things that can be tied together. None of that's happening now to my knowledge. I don't know anybody who runs an attack service management scan on a vendor before they do business with them. I, if, if you know of one, let me know. Maybe I'm missing it. Is it starting to change? Am I just not seeing it?
Yeah. Supply chain security is, is getting a lot more focus, thank goodness now. And it does, it is including, well, if we can't trust them to tell us what they're doing, we can at least look. Right, right. Similar to the M&A where there's only so much you can ask them prior to the, you know, the closure, closing the deal. But there's nothing stopping you from looking, right?
Yeah. Well, and that's an intel function right there. You're doing research recon on an acquisition target or on a partnership or on a vendor. That's all what intel does, right? So yeah, I'm obviously, I keep banging this drum. Eventually we're gonna get there. We're having some discussions. I've, I've talked to some larger organizations about doing this intel component. You know, this, the CNO thing, it's hard to get there, right? There's politics, you know, organizations don't want to have a C-level. When I first floated this idea and wrote this paper, I have no doubt that people thought it was self-serving. I know how convenient you're putting yourself in a position where you could be a C-level now. Doesn't have to be me. Look at it. It's, I wrote the thing 2, 3 years ago now, maybe 4. I don't remember now. I'm still not a C-level, by the way. And in fact, I know a couple people who now have the title of Chief Intelligence Officer. I'm still not one of them. So if it's been self-serving, I'm really damn bad at it. But I still believe in it. I think it's going to be the solution. I think eventually we're going to see large organizations, somebody's going to take a swing and it's going to be a, it's going to work and we're going to see these improvements. Maybe it's going to take something more catastrophic. I don't know. Again, the US government didn't get there until something terrible happened and then everything changed. I think we'll see it here too. Now I want to jump to the third question we had prepped for today. And admittedly, we've already started going there. So I, you know, we're kind of repeating some of it, but I'm curious to get more. Thoughts, you know, we talked about attack service management or attack service intelligence. I'm just going to start calling it that. Hopefully people won't get mad at me for it, especially at our own company. But how do you see the relationships between attack service intelligence and the rest of the enterprise? Again, we already started talking on this path because it's a natural discussion, but how are those relationships? You know, CTI, we've already said, okay, they're not in CTI. Vulnerability management, we've already said they're not in vulnerability management, but what about digital risk protection? What about HR insider threat? The business intel component, how are all these relationships? Is this going to just go back to the CINO discussion, which would thrill me, of course, but how are they today in working together with one another?
Well, if we're strictly talking about how do all those functions work with an ASI function, right? Like what's that relationship look like? So I would say similar to how CTI probably has to handle this. I mean, from my experiences. You're collecting all this, but your consumers perhaps need the information or intelligence in different, I'll call it formats, right? Or, or delivered differently because it means different things to different parts of the organization, right? So there's an, the part that no one likes about ASI is that it's not as simple as monitor the assets, put it, you know, store it in a database somewhere and call it a day. That's just the beginning. That's like the, um, the technical side of the work.
Mm-hmm.
But a lot of what really makes it successful is it's all the relationship building, right? It's, it's all the understanding who the consumers are, understanding what this means to them, making sure they're able to get it in that format they need it in and timely when they need it so that now it has that positive impact on their function. And you, you become a supporter of what they're doing, right? So that takes care and management, right? To really make sure that all those relationships are in a healthy state, that they're getting what they need. And they could change what they think they need, right? Or they, you could expose 'em to more of this and they could realize that this could help them even more than they understood. Previously. So that's what I would say this feels like or looks like when you're really executing this correctly.
Mhm.
Which is why I also think it does make more sense to have it up a little higher, so to speak, like you're saying, right? Where it's not over in the corner or like this, oh, this neat thing that maybe they could take advantage of. It's more like something that a lot of the company is taking advantage of and If they don't, it will seem silly, right? Just like any other major type of intelligence that's driving business decisions. It also needs to be available to everyone, right? So it could, that could mean your vulnerability management program or your red team. It could also mean the CISO. I mean, there are a lot of, um, people at that level just want to be able to ask the question, what does this actually look like out there? So when I'm talking to a director, and I say, what's going on, that what they're telling me lines up or matches with what I'm seeing. Like almost a way for them to have their own little set of binoculars to say, well, I'm, I'm going to be watching, so you better tell me what's really going on out there. It could be consumed that way. And as you've already pointed out, by completely different parts of the company that are focused on building partnerships, taking risks on new dependencies,, you know, from business, you know, B2B. These are big decisions that need to be fueled by as much data as they can get their hands on to, to make strong, smart decisions here. So it can't be something off in the corner of an InfoSec program where it feels unreachable to the people that are in those very different roles. Again, to what, to your point, I think that's why we need a Chief Intelligence Officer or someone who could say, well, it's not a problem. It's part of my program. We'll make sure you get it and we'll get you that complete picture you need to make those important decisions. Where if it's part of InfoSec, strictly InfoSec, it can make, it can make it feel out of reach.
Sure. That makes sense.
I don't know if that answers your question, but the, the two, the two pieces to this, or what I tell people they have to at least be ready to take on, is be ready to, to monitor all this. It's, it's a lot of, you know, it's a lot of work to watch all of this exposure and make sure you're not missing anything. And there's a lot of elements to how do you do that successfully so you're getting, you know, you're still not missing anything. And then how do you get that to all the right people or consumers within the organization so that there's no point in collecting all this and having this excellent picture of what's going on out there if no one's making use of it, right? So you need to be working that other side, which is disseminating the intelligence effectively throughout the organization.
Yeah. No, I think you made some good points in there. This is different for different organizations, right? And that ability to process needs, to determine based on those needs what we should go get and how to report it back in what format is really important. And there's a lot of organizations that probably are left out right now because, as you said, this ends up in a corner someplace. So, you know, maybe they're doing the, the ASM scans, you know, the attack surface scans, and they're saying, okay, well, we know vulnerabilities needs to see this. And, you know, maybe they're going to policy to say, hey, we have a lot of architecture out there that shouldn't exist. What are, what's going on with their policy or the enforcement of those policies? But are they having a discussion with insider threat, for instance, to find out, are these being spun up maliciously? You know, are they having a discussion with marketing to say, hey, you've got a whole lot of websites out there that shouldn't be there, or a whole lot of, you know, things that don't exist? Are they having discussion with business intel? Probably not, if I had to guess. You know, is this getting used in M&A? You're saying it's starting to improve there, which is good, but it's certainly not widespread, I would say. You know, so yeah, the ability to elevate that up, you know, Intel isn't, Intel's not a product. Intel's a service. I tell people that all the time. Products are the output, but Intel's a service. You have to understand people's needs and you have to meet those needs to improve decision-making, to improve business impact. That's about all the things you're mentioning. That's that big dissemination piece. You have to know what people need and then give it back to them. And it's across the entire enterprise. So yeah, I think we're on the same page that elevating this and being in a position where this can be across everyone, because that accessibility matters. You mentioned not getting things reported. We talk about all the time in the intel space, intel's not valuable if nobody ever reads it. If it's so highly classified nobody can see it, then it doesn't matter what it is. If I had the cure for cancer, but I wouldn't share it with anybody. I haven't actually cured cancer, just so everybody wonders. Uh, nothing's changed, right? You know, if I keep it to myself and then I die, I guess cancer still hasn't been cured. You know, with intel, if you know the thing and you don't tell anybody the thing, you haven't done anything. It hasn't changed. You know, later on you're gonna say, oh, I knew that, and nobody's gonna believe you anyway. Dissemination's a key component to all of this. You know, I talk about it in the Intel Cycle a lot. All the greatest intel, you gotta get it to people. And that's hard to do with programs that get buried in basements. You know, whether it's, uh, tax service intelligence or threat intelligence or strategic intelligence, whatever it is. If it's buried in the wrong organization under somebody, a leader who doesn't see their role as a service role beyond where they are, beyond what their OKRs are and their KPIs are, et cetera, then they're not going to go further than that. They're just not. That's people work to meet the metrics they've been given, which is nothing wrong with that, by the way. It's a great way to build your career and it's smart. The metrics just need to change and this thing needs to be elevated up so the metrics are different. So somebody's meeting a different set across a wider audience within an enterprise and you'll get more efficient results as a result. You'll get better intel, more actionable opportunities, probably save some money on some of these enterprise licenses, or as you said, multiple vendors that do the same thing that you could knock out if you just got together and had somebody high enough to go, why do we have 3 vendors doing the exact same thing for 3 different orgs at triple the price? Well, we just had one vendor that did it all. And of course, yeah, listen, I work for a vendor. So do you. We work for the same vendor in this case. People are going to argue that's self-serving. That's fine. I can live with it. It's a business world. Yes, we have a platform that does all this. Yes, I believe it's a good thing. And yes, I believe somebody should look at it. That's it. That's the end of our sales pitch here. We're not in sales. I've been on the other side though. I've been a customer. You know, the fact of the matter is people are spending a lot of money on a lot of things, probably the wrong way, because it's all fractured and it's buried in corners. So anyway, one thing you asked too. Yeah, man, go.
Oh, you said like, how does this fit with, uh, DRP?
Mm-hmm. Oh yeah.
So I, I actually had this discussion at DEF CON a couple years ago where the question was, Well, should ASM remain internet infrastructure? Like, you know, again, kind of what vulnerability management tends to focus on or just keeping it within the, say, strictly infosec world, right?
God, I hope you said no.
I did, but it was—
I'm out here advocating for something totally different.
But it was met with pushback. I mean, like initially. The feeling was, let's not make this more complicated than it already is and then cause it, you know, people to stop thinking about it. But I said, you know, I don't think we want to set this on the wrong path. ASM should be anything that's exposed on the internet that could have an impact on your security posture, period. Like, I don't care what it is, even if that's individuals, right? I mean, anything.
Right. Social media accounts. We've talked about some of that stuff, right?
Yeah. All of it. Accounts, credentials, anything out there that it could come back to impact your security posture or program. Well, then it needs to be considered as part of the intelligence collection that we're talking about. And when you combine that with what we're already learning from CTI, where now, now it's like you can create customized prioritization, right? Where we know what's out there, uh, that's relevant to our organization. We know what people are doing that would align, or, or their ATT&CK preferences like TTPs would now line up with the ATT&CK opportunities or vectors that we know exist within our environment or exposed to environment. I mean, now, now you have very prioritized to-do lists, right? I mean, people, people tell me all the time, we've had a successful vulnerability management program, but now we have a pile of data that we could, you know, we're never going to catch up with, right? And we don't know how to prioritize it to answer the question of what should we be doing on Monday, right? Like, that's the big question. That's, that's what everyone is irritated about is We have tons of data, more than we know what to do with, right?
Mm-hmm. Mm-hmm.
Well, if you start bringing this intelligence together, I would argue it gives you a very good idea of what you should be doing on Monday. So, because now you're addressing the things that are truly like high probability that these are going to actually happen, right? Again, looking at it because you're looking at it from the attacker's perspective, you're You're answering the question of if someone actually tried to do this, what would they probably do?
Well, yeah, and you get those 9 boxes, right? You know, the, the, from the most likely, most dangerous to the least likely, least dangerous, and then everything in between. You get those 9 boxes to say what's, what's going to be the outcome here. And that gets you your prioritization, which I listen, anybody listening to this who does risk probably already knows this, obviously, but that's how you get that prioritization. But as you said, it's intel-driven then. It's your assessment of which box this fits into gets better if you're able to say not just what we have for a vulnerability, but also, uh, what we have is a likelihood that an adversary is going after it. Well, we have adversaries who've done it before. We have evidence of that, that they're capable of doing it, that they're motivated to do it against us would raise the probability even further that they've been successful. And, and, and then where is that vuln? Is it tied to our crown jewels? Because you have to have a crown jewels assessment because you have to have a proper CMDB because you have done all this work that we just talked about. It's a big difference between saying, hey, there's a bad guy out there, or saying, hey, there's a vuln out there, and be able to pull those together and say, hey, there's a, there's a vuln that's currently exposed. There's a bad guy out there who's capable of attacking it. They have attacked companies like us in the past in our geography before. They've been successful. And oh, by the way, they've said on the dark web they're planning on doing this. Well, that's 9 on the 9 box. That's, that's the top. That's most likely most days. Oh, oh no, I forgot. There's a piece that makes it the 9. By the way, if they attack that thing, it's directly tied to our crown jewels. They will steal the Coca-Cola formula. Now it's a 9, right? Now it's everything, right? We've, we've put all this together and said, this is the right bad guy, the right time, the right place, the right capability, the right motivation, and the right content they're going to steal. That's the top. I don't know many organizations. I don't know many organizations that pull all of those things together.
No, they don't. I mean, because so many of them, if you look at how they're spending, so That's another thing that I did when I came out of the government world and I started helping commercial companies is helping them do the gap analysis on their security programs.
Yeah.
Oh, fun. But so many of them are focused on building the bigger walls.
Mm-hmm.
Right? Not what you just said, which is, I'll call it understanding the battle space so that you could just make more intelligent decisions. About is this what we should be focused on or not, right? Another thing too that they did, a lot of these companies didn't realize is once you're looking through the attacker's lens, you can start answering questions that you just couldn't before, like how expensive will it be for them to discover these things?
Sure. Is it worth the adversary's effort, right?
Well, or you could say for the flybys, is this something they're just gonna see, you know, as they take a look, or do they really have to have us marked as we want to go after this organization before they're gonna be able to find these things?
Right.
But that could still help you understand what are we gonna clean up first, or what are we more concerned about here?
Sure. Well, yeah, there's an interesting target of opportunity and somebody who's directly going after you. If you're the defense, you know, sector and you have the next great stealth technology, and you know that there's a nation state that wants you, they're gonna put a lot of time and effort and money into it, right? You know that. Whereas if it's, you know, just the local retail shop and script kiddies are gonna come by and find some open, you know, port someplace, it's totally different, right?
Yeah.
Your target of opportunity versus a directed target, you know, can affect, as you said, like how you're gonna prioritize these things.
Yeah.
But how would you know which assets of yours fit into which, say, cat category or bucket? If you haven't looked at it yourself this way to say, well, how hard was it to, to find these things?
Yeah, exactly. And, and it's frustrating that we're not seeing more of that. I mean, we're seeing some, I mean, you said at least, you know, it's, it's encouraging to hear that people are using some of this stuff for, you know, third-party risk and some of it for M&A. It's nice to see that there's some improvements there. It's just slow, man. And frustrating after a while. And, you know, I feel bad that I say the same, some of the same things over and over again about this, you know, greater intelligence picture, et cetera. But things aren't changing fast enough. I'm impatient. You know, things have gotten a lot better in the 8 years I've been in the private sector, but I don't have 80 more of them. So I'd like to see some things move faster. And I think this is, you know, one of the big ones. And this ATT&CK surface intelligence concept and all the things it could be doing is a big component to this. So listen, we gotta wrap up. We're running outta time, so we gotta get to the closer. And as you know, the name of the show is Unspoken Security. And with that in mind, I ask every guest the same question. You don't get a pass just cuz we work together. You need to tell me something that is unspoken so far, you know, that you haven't told other people to this point. This is something for you that's been unspoken.
All right.
Don't confess to a murder. We are recording, so I'll keep it light.
Yeah.
Um, well, I feel like, uh, in the information security community, I hear a lot of people throwing the claim out that if you're gonna be in cybersecurity, you don't have to know how to code. Yeah, maybe, but the secret or unspoken truth would be, um, I don't quite agree with that. Um, well, and so much of it probably is just because I'm biased because my history, uh, with all this was I didn't go to school when I was going to college to become an infosec expert or, or enter the world of information security. I just wanted to be able to write code for the internet, right? Like, that was the way I looked at it, was— so I, so I pursued network programming, distributed systems, telecommunications, and computer science. But the, the point, or the real interesting thing, is every major success I've had in my own career tied automation into it, right? Like every single thing we did that became important was codified, right? So we, we figured out something important and then it was codified to make it so it could be automated or become part of a, a system to provide automated response and things like that. Or to do things that, for instance, like sub-second frequency that, you know, humans just never would've been able to. Keep up with. Sure, sure. So looking at it through my perspective, I would say there's so much opportunity though if you're in security and you know how to, you know, write the code to automate, you know, the techniques, I'll call it. There's so much opportunity there. I don't know why anyone would want to give that up, especially since this is the part I always try to encourage people to consider is it's probably not as hard as people think it is. I think they should give themselves more credit and assume they can handle it because it's not, it's not that big a deal.
Okay. So I rarely challenge people's unspoken security, unspoken part, right? You're gonna be actually, I think you might be the first. I hear what you're saying and, and I think there's incredible value in being able to, to code, right? I don't think it means you have to be able to code to be in security though. And that's, that's what a lot of people talk about is you don't have to be able to code to be in security. Well, you don't. Listen, I don't code. Uh, I think it's safe to say I'm somewhere in the security community at this point. I don't code things. If I did, I'd probably be better. I'm not gonna lie. Yeah, it'd be a great skill set to pick up. I'd also be better if I knew how to build furniture or if I could, you know, be a lot of things around the house so I don't have people working in my house all day because I have to pay them to do things I can't do well. It doesn't mean I'm not a homeowner though. So I think, I think your, your point is really valid and powerful in that there are a lot of amazing things you can do when you can code, and automation's a perfect example of that. And you're probably right that a lot of people think it's scarier and that they talk themselves out of doing some of these things, myself included, frankly. But also keep in mind, you've been very successful doing this. You may underestimate how hard it is because for you it wasn't as— you're very good. And I think some of us make a mistake sometimes of thinking if something isn't hard for us, it means it's not hard. I've had to learn that over the years. I, I had to find different ways to tell people how to do, or offer people advice on how to do, like public speaking, for instance, because my advice doesn't work for some people, it turns out. You know, things like, ah, don't over-prepare, just sort of show up and wing it. Not great advice for a lot of people. So, you know, people, some people are very afraid of public speaking and just like some people are afraid of coding. So I think, I think you're right in that it's a powerful thing. Like people who are capable of coding, who really understand networking, you know, networking well and the technical details. They're definitely going to be better in certain areas and smarter in a lot of areas. But there are, I think there is a lot of space in this community for folks who don't code. Just team up with those people like I do. Like I team up with guys like you and say, hey man, I need to get this thing sorted and I don't know how to do it. And the time it would take me to learn the coding necessary to be successful and do great automation at this point in my life as an old dog. Nah, I'm just gonna find somebody who's smarter already does it cuz that's just more efficient. I'm just gonna make good friends and I'll trade beers or you know, whatever things I'm good at, uh, with them in exchange for, you know, and I'll barter through. So I don't want to scare people away from the industry, but I do agree with you that if you're capable of coding, uh, and you're good at it, I mean, the power is remarkable. It's, it's a, it's a superpower in my opinion. But it's interesting to get your perspective. You know, I'm careful. I rarely push back on these, but yeah, it's an interesting point. I think there's room in the community for everybody, but certainly if you can code and code well, yeah, you got a leg up on people like me. You know, maybe, maybe there won't be room for people like me in the future. Maybe we'll all be thrown out eventually.
I don't know. I think you're saying it right. I, the right way to share this with people probably is not that I'm trying to say you can't be in this occupation without those skills, more that you hear people all the time saying, well, how do I get an advantage? Or how do I ensure that I'll be able to get a job or, or get a more interesting position somewhere? I would say, well, consider expanding your skillset, like make it so you're not just an analyst or someone that can work with certain vendor products or solutions, but now you could potentially build your own solution if that made sense, or a customized solution for your employer. And this will just make you that much more valuable in what you do. And it could open up opportunities as well when problems are, you know, the organization is facing problems and you could raise your hand and say, well, I'm pretty sure I could help with that. You know, you're just gonna be that much more valuable. So yeah, to, to what you're saying, not to steer people away that find this intimidating, but maybe something to consider tackling if you want to expand your value to whoever you're working with.
Oh, that's a great point. Especially in a, in a competitive marketplace, we are seeing people who are saying, how do I get into the industry? How do I set, How do I separate myself from other candidates? How do I ensure my career? I think, I think you hit it on the head with that. Yeah. Add that skillset, you know, to put it in other terms. Yeah. If, if I worked, well, let me use my house as an example. If I needed a kitchen table, I can buy one currently. And that's fine. I'll solve the problem with that. But boy, if I could build one, then I can solve the problem even if all the stores were closed, right? You're talking about, you know, people who instead of being able to find a solution, to buy a solution, to work with somebody else's paid solution, could build a solution. Yeah, that's a whole separate set of powers. A lot of orgs are in the build and buy pendulum. They go back and forth. When they're in the build phase, you can still work with the tool they want. If they can't afford that and they want to go, or in the buy phase, I should say, and if they can't afford that or they want to go into the build phase because they decide that, you're not out of a job. In my case, frankly, if our company went to all build versus buy, I'd probably find myself in a lot of trouble because I don't build shit. I buy shit. And I work with people and I manage things and I lead things. But if they said, no, you're going to build it from scratch by hand, I guess I'd be looking for something else to do with my time. So I think that's a really powerful point. If you want to get into the industry, if you want to separate yourself, if you want to secure your future, more skill sets, more ability to build from scratch, which is all code in our industry, really. Yeah. It's people who are great at coding, pick a language, you know, Python's the big one, right? But pick, you can pick several, you know, languages. It goes over time. Or people who are great at reverse engineering, which is the next step a lot of times. Yeah. Those people don't have a hard time finding a job. They're not sitting unemployed for very long usually. They don't worry about the economy shuffling like a lot of us do. So I think that's a really powerful message too. It definitely puts you in a better spot and you can follow Jeff Foley. You can be like him. Jeff's never out of a job. Look at his resume. Guy's always working. All right, man. Listen, we got to wrap this one up. I appreciate that. I appreciate you taking the time, you know, to be here with me today and to talk through this stuff and talk a little bit. As it turns out, we got to battle a little bit on the last piece, which rarely happens. That was kind of fun though. I think we got the same point. Place. I don't know if there's any thoughts you want to add to wrap this one up. Is there anything we left out you want to close out with? If we covered everything, that's good, but I always like to give, you know, the guest one last shot to—
I mean, maybe just a quick plug if it's not, not a problem.
Plug it, man. Plug it.
So, you know, we had a great talk here about attack surface management slash intelligence, or hopefully intelligence in the future. And if whoever's listening finds this interesting or something they would like to help I'll say fix in the private sector, or these days I would say in all of the information security community, please don't hesitate to come to OWASP, right? OWASP AMASS is the flagship project that now is focused on this. It's a whole chunk of the portfolio at OWASP, which is you have to know it's out there if you're going to do anything about it, right? Even OWASP, who's been focused over the years on application security, quite a bit admits, well, there's not a lot of good we can do with application security if we don't know where the applications are sitting, right? So if you'd like to help with this, or you'd like to open the world's eyes to the importance or urgency on around this, please find our Discord, you know, come to our GitHub. There's lots of ways you can reach out to us, and, uh, we, we are always welcoming contributors or people that would like to support what we're doing, which does not necessarily mean coding, right? There's lots of ways you can support advocating, testing. You could go out and speak about this. So there's all sorts of ways you can work with us to bring this to more organizations and help them wrap their arms around, you know, understanding their attack surface and making better decisions based on that.
Yeah. Oh, that's great, man. I appreciate, uh, you mentioning that. And, and I agree, you know, anybody who's interested in getting involved in helping, you know, Jeff always a great guy to work with. It's a great guy to reach out to, you know, check out OWASP, uh, and the AMaaS program. If you're gonna be in Vegas this summer, I'm sure Jeff's gonna be at DEF CON. You know, he's there every year, so you can catch up with him in person. Otherwise, just drop him an email and, and, you know, it's an important project and I'm, I'm thankful we had the chance to chat about it today, man. So with that, listen, I, I, again, I wanna thank you one more time. Appreciate you taking all this time to, to get together with us. For those who are listening, you know, I wanna appreciate you listening or watching. Thanks for taking your time to listen to us and to support the program. Please subscribe, download, tell your friends and neighbors how great it is. If you hate it, don't tell anybody at all. Go away. Do all the things that help us continue to grow this program. Also provide feedback. If it's positive feedback, I like it. A little more negative feedback, if I'm gonna be honest, especially publicly, but I, I'll take all of it, you know, and DM me, message me if you want this program to change. If you got a better idea on how to do format, if you got guests you wanna bring on. Whatever it might be, please contribute. We want to continue to do this. This isn't about me. It's about guests and the community. So again, thanks everybody for your time. Appreciate it. And until next time, that's been it for this episode of Unspoken Security.
That's a wrap for this episode of Unspoken Security, brought to you by ZeroFox, the only unified external cybersecurity platform.
This is—
if you enjoyed this episode, follow us wherever you listen to your favorite podcasts. See you next time.
This is how legends are made.
More from AJ

Unspoken Security Ep 61: Should We Be Afraid of Artificial Intelligence (AI)?

Unspoken Security Ep 58: Stolen Credentials, Fake Hires, and the New Insider Threat








