Unspoken Security Ep 8: Let's Get Serious About Intelligence Requirements!

Intel goes both ways though. It's external and it's internal, right? And a lot of people forget that, like you can run, you can look at your own organization and say, like, if this were to happen, what's the likelihood? So you have disaster recovery doing intel that you need to collaborate with. So if you say, if this happens, you know, let's play this out. Tabletop exercise is a great way to start developing intel requirements. So like, what would happen if, I don't know, do we even have a response to that? Do we even have a corporate policy on whether or not we're going to pay a ransomware, you know? Threat. So it's like, these are questions.

Welcome to Unspoken Security by ZeroFox, 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. For those who don't know me personally or are first-time listeners, I'm a traditional intelligence guy who spent nearly 20 years in the intelligence community, both within the United States Air Force and then as a defense contractor. Most of that time was spent at NSA. I've been in the private sector for about 8 years now, primarily building or helping other people build effective intelligence-driven security practices.. I'm passionate about intelligence, security, public speaking, mentoring, and teaching. I'm also deeply committed to servant leadership, which is why I completed my master's degree in organizational leadership at Gonzaga University. Go Zags! Now, the goal of this podcast is to bring all of these elements together with some incredible guests and have authentic, unfiltered conversations, even debates, about a wide range of challenging topics. This is not going to be your typical polished podcast. You might hear or see my dog. She's around here someplace today. People may swear, we may argue or debate, and that's, that's all okay. Like, think of this podcast as the conversation you might overhear at a bar after a long day at one of the larger cybersecurity conferences. These are the conversations we usually just have when nobody's listening. So today my guest is Brian Moore. Uh, Brian's the CEO of cybersecurity company RecFast, a good friend of mine. He's, before his life as a tech company founder, which is the brave life I can't even imagine, frankly. Brian served over 15 years in the United States Marine Corps, so couldn't get into the Air Force, I'm guessing. And, uh, he had a couple stops along the way in the private sector, you know, where he's been focused on threat intelligence. So, you know, Brian, that's a really quick, you know, brief of, of your history. So is there anything else, anything I left out, anything you want to add as far as, you know, who you are and where you come from?

The only thing I would add is when I left active duty, I was thinking of going into the reserves, and I actually went to the Air Force, and they told me that I had too much of a military mindset. And so they wouldn't accept me.

Just thought I'd bring that up. I, I, I am not surprised or, or offended by that, actually. That sounds about right. You know, the military— listen, all the branches are useful. They're all valuable. They're all important. We all have jobs to serve. You know, for anybody who's not military listening, we all poke fun at each other. Obviously, I have nothing but love and respect for the Corps. They do all the things that I neither want to nor could ever do. So, you know, but yeah, yeah, I can see how you might not have been the greatest cultural fit after 15 years in the Corps. Although, I don't know, you're pretty laid-back guy.

Well, yeah, I've been in recovery for what, 8 years now?

And I just doing well. Well, it seems to be going all right for you. So listen, today's episode, the title is Let's Get Serious About Intelligence Requirements. Now listen, I'm a career intel guy, so are you, you know, and I spent a lot of time now, and I have for all these years I've been in the private sector, I spent a lot of time talking about the importance of intelligence requirements, you know, how they're a foundation for any successful intel program. So to be truthful, I'm really, really excited to hear someone else get on the soapbox with me for a change. So let's get into it, right? When we talk about intelligence requirements, what are we really talking about? What's an intelligence requirement?

Well, it's the start of the cycle, right? And I will say this in almost every conference I've spoken at and every class that if you are, if you have an intelligence program that's not based on requirements, then you are wasting your time and your stakeholders' time and money. Right?

So it is 100%.

It is your reason for existence. Intelligence is two things. It's decision support and it's a customer service, right? Your customer, your stakeholder needs to make a decision and they need information to make that decision with confidence, right? Your job as the intelligence person is to provide that information and your measure of success comes with whether or not they were able to make that decision with confidence and the more confidence, the better, right? The only way you can show that is if you actually write those requirements down and then go off and do the work against that. Anybody who's in the customer service business understands this process. So it's a little curious to me that even now, after all these years, you and I are still having this conversation about the importance of intelligence requirements. Well, you've never gone to any customer, other customer service industry and said, well, why do you want to know what your customer cares about? And so that, here we are.

So yeah. Yeah. I mean, that's, it's a, you know, it's a good point, right? So to me, I, I gotta be honest. I always thought it was obvious and, and maybe that's, that was my ignorance going into the private sector, right? You know, you grow up in Intel space and you go, well, yeah, you get your Intel requirements first and you go out and get things. I'm still surprised it's hard for folks to gather sometimes because I don't know any other business that doesn't have this. They just don't call it that. Maybe, you know, if you're building software, there's these giant documents people go through with software requirements, what do customers need and, you know, huge Excel spreadsheets and all these other things, right? I think in most anything you do, hell, if you're launching a business, right? If you're an entrepreneur, what's the market need? Like people talk about the need first before you go do something. Is there a need? And then document that and say, okay, well, how do we go meet those needs? It seems like it's understood in most industries, but intelligence, I guess, is this magical mystery world for a lot of folks. So when you talk about intel requirements, it seems to get lost. And I often just hear, well, just your job's to tell me what I need to know, which is, you know, really important.

You're the intel person. You tell me what's important. That's not how this works.

So, right. Imagine if that was the truth for anything else. Well, what do you need in a, in a sales support tool? I don't know. You tell me what I need. Well, no, I need to understand what you, how your process works. What's the sales process and what do you do and what do you need? What are you struggling with?

Right.

You know, I will say before we move, you know, we have a few questions today before we move to another one. You mentioned briefly, you know, I said what's the intel requirement sets the start of the process. So for those who don't know the intel cycle, right? We should probably at least quickly reference it for people. I know you and I know it and we talk about it all the time, but the intel cycle, you know, the 6 steps of the cycle, there's planning and development first, you know, where you get into talking about intel requirements and stakeholders, right? Who are you serving and what are their needs? And then from there, you can get into collection and discuss, you know, what do we need to gather, et cetera. And then the cycle continues to go on for anybody who wants to Google intelligence cycle. It's easy to see all these graphics, but I think it's important for people to know that first step, that planning and direction piece. Is where you talk about intelligence requirements. What do we need? Which starts with stakeholders, which, who are we serving, right? They have to tell us our requirements. Now, a lot of times, I, I'm going to ask you this, but I, I know from my experience, this is what I've worked with a lot of times. A lot of customers don't know this, as we've mentioned. So oftentimes, if I've got a customer, listen, I've no customer, few customers I will say are unique, right? A banking customer, they have their own things, but banks are banks too, you know, healthcare, you know, different industries. So a lot of times we are able to come in and say, well, here's what a lot of folks in this industry need. So we at least have a baseline and if they can customize, do you, do you do the same thing? I assume when you start talking about intel requirements, it's really like, here's some, some places to start.

Well, we also, I, I focus now on, if you just say, what are your requirements? You usually get a blank look, right? And so I say, okay, who's your, who's your primary stakeholder? And it's like the CISO, who's usually the number one answer. And it's like, okay, what are the decisions they're trying to make? You know, and then what actions are they trying to take? And then that's how you kind of backwards your way into intel requirements. So like if they need to make, take this action or they're trying to choose between courses of action, you know, what is the information they need in order to do that? So you kind of get away from the list mentality and kind of focus on the customer's actions of what they're trying to do. The military was easy, right? For at least on the Marine Corps side, it was like, okay, the colonel wants to be on that hill in 3 days. We're in the kind of backwards plan from that. What are all the things that we need to do to get on top of that hill? Or From the defender's standpoint, like, how likely is that guy going to try to get over our hill? And what do we need to know? Starting from the weather and you work your way out. So there's really no difference. It's just, you're asking different questions and there's different, you know, things. And when people say actionable intelligence, it's easy to understand on the military side, because usually something explodes and that's, you know, action. On the cyber side, it's like, here's a list of IPs, go, you know, a little bit different. But I find that if you start tying it to dollar amounts of like the budget, you know, is a big one and the CISO needs to decide where to put her budget. Allocate dollars, there's some decisions there that you might want to be part of as an Intel person. And I would rather be part of guiding that conversation than being the target of the budget cut. So I tend to focus on the action and work backwards, but yes, you're absolutely right. It always, you have to start somewhere. And usually you can say, okay, this is a list of things we normally provide. What appeals do you want here? And then that will start the conversation. You shouldn't go in there with nothing and just say, what do you want to know?

Because we all know how that works. That's all, you know, really important, right? So listen, you talked about a couple things I really want to dig into, a couple important pieces. The first one that you mentioned that hit me was documentation, which we started talking about, right? And then the other one you talked about was that need for, you know, showing that the delivered intelligence, you know, actually met those needs. And so what I hear when you talk about mapping intelligence to needs, you know, and decision-making is what I'm hearing is value, frankly, which we hear all the time from customers, right? You know, it's, it's, Anybody who ever says, well, you know, they didn't renew because we cost too much. No offense to anybody in sales out there, but I've always said that's bullshit. You know, it's not that you cost too much that you didn't deliver value. Nothing costs too much if it delivers more value than it costs, right? So I find, and you mentioned the CISO who's often the buyer on this, I find that's the biggest challenge with intel a lot of times is the two pieces you mentioned, documenting intelligence, but then also how do you tie intel to deliverables and what was the action taken and how do you measure a value that goes with that? So, you know, digging into those further, how do you document intel requirements? Like, how do you personally do it? How does your org do it? How does your company do it? And how can we use those? How can we use that documentation to measure the value of intelligence? Because people are paying a lot of money for this. And that's our big challenge. I think we talk about budgets. You don't want to get cut. It's expensive. And I find it really challenging to help people understand value, right? To put a metric on it and say, this is, you spent this, but you got this, it saved this, whatever it might be. So, you know, how are you guys documenting intel requirements and how are you using that to measure value is where I'm trying to get to here.

Yeah. And most of the industry, I would say 99% of it, requirements are tracked via the super spreadsheet, right? You have lists and lists and other lists of stakeholders and lists of requirements and lists of, you know, reports that you've sent out and you try to match them up. That's all great, but that's usually where it falls down when you try to operationalize that.

And that's even assuming they have intel requirements. Like, that's not including the ones where you walk in and they have no requirements, right?

Yeah.

You're already making the assumption they have something.

And even if they have requirements, they're usually just lists of keywords, right? They're not tied to anything like, oh, here's my list of, you know, dark web of, you know, APT34, because that's how those guys refer to themselves on the dark web.

Right. In the dark web, they often talk about themselves as APT34.

Hey, number 28, how are you, sir? You know, hey, Fuzzy Panda, what's going down? Yeah, they're not handles, right? So, so it's like this weird list of keywords that aren't tied to anything. So when I work with customers and in our platform, we have, yes, the statement of what's the requirement of, you know, talk about threat actors discussing intent of targeting whatever. But there's an endpoint to that. There's a why. What decision are you supporting? What's the stakeholder? What are they trying to do? In fact, I encourage in our stakeholder profiles to say like, what's important to them? What are the decisions that they have to make? What are the actions that they're trying to take? So when the analyst goes and say, okay, if this is the requirement and this is the stakeholder, This is what they're trying to do. That is going to color their, you know, their viewpoint and flavor of what they actually report to that stakeholder. Now, instead of just writing, uh, these, you know, Microsoft says it's bad and we agree, it's, this is bad because this could impact these operations. And, you know, the stakeholder has now a point of reference. And so you always want to like anchor what you're writing to relevance. And that starts with the requirement. It's the, what is it you want to know? What is it you're trying to do? And how do you tell us if this is successful or not? And that's where you start getting into the value. The more you can tie dollars spent in intelligence to the dollars made in revenue, you know, you're doing a lot better. Most people don't do that because they forget they're part of the business. Um, and you start with value by understanding how you fit in with the business.

And so, yeah, I mean, that's, that's, you know, that's a really good point, right? And that's, to me, that's been the big challenge. You know, I've been, I've been in the private sector I don't know, 8 years or whatever now. And, you know, when I came out from the intelligence space, like I said, I thought intel requirements would be simple and obvious, and it wasn't. Which on the one hand made my job really easy. People thought I was brilliant. Oh, this is a great idea. It's a great concept. I'm like, well, this is pretty basic, but yeah. Okay.

Thanks.

Yeah. So I'm always like, well, I always remind people like I didn't invent this. I don't want, I don't want, I don't want someday for somebody to wake up and go, holy shit, he's a fraud. He's been telling us all these, we've been patting him on the back and this is all just available. So, you know, I always talk about JP2-0 and, you know, the ICDs and all this kind of stuff so that people know this documentation exists. But, you know, getting out there and saying, okay, here's Intel requirements, but then getting that value piece. You know, I learned it didn't take long to figure out how budget works in the private sector and how metrics-driven almost every company is, which a lot of cases I get and it makes sense, really does. But it tends to be really, really challenging for Intel, at least my experience has been, you know, and I've often told people. You can't think about us the way you think of your, your SIM or your firewall or something like that, right? It's, we don't develop those kind of metrics. I tell people to think of Intel a lot of times more like physical security or say health insurance. You know, if, if you run a bank and you haven't been robbed in 5 years, I doubt you're gonna fire all your security guards and shut off all your cameras. 'Cause clearly you're just wasting money. Nothing bad has happened, but there's an ROI there in deterrence. It's understood that if you are a bank and you have money, people will want to rob you. And if it's known that you don't protect yourself, you'll be robbed. I haven't had, knock on wood, I haven't had a heart attack. I haven't had a stroke. I have health insurance, costs money. I don't just cancel it. Well, I'm clearly not getting value out of this health insurance because someday something bad's probably sadly going to happen. That's how the world works. But that's not good for metrics, right? Figuring out where the value fits in. So you talked about impacting decisions and finding out how to How to tie that back. And I've seen, I don't know about you, I'll ask you here in a second. I've seen some progress in that space and being able to say, well, what did you do with the intel? Well, we took this intel and we changed this policy, we changed this procedure, et cetera. But I still, are you having more success than I'm seeing in the next step of that? Being able to say, hey, we did this and it changed an action, it changed a decision is great, but what did that decision save us? Would we have been attacked otherwise? How much would it have cost, et cetera? If you're doing proactively, which ideally with intel you could do more of, that's the goal. How does that— and I hate to put you on the spot, it may be a hard question, but are you seeing the way that turns into value? Or is it just a matter of being able to say, hey, listen, you said these were your requirements, we delivered X number of intel against those requirements, that's your value prop, and that's good enough metrics to show that what we're buying aligns with what our needs are, not necessarily the outcomes?

No, because those, I would call those the efficiency metrics. Not helping you get into the efficacy metrics, like, does this actually matter? One thing that Intel failed, or Intel teams almost across the board are failing to do is actually collaborate with other teams. First and foremost, you need to collaborate with the risk side of the house. I have seen it where some Intel teams have actually been pulled out of the SOC and put into the risk side of the house, which I think is a great idea, or at least build that relationship because the language that the risk organization Speaking to leadership, leadership understands that because it's usually wrapped around dollars. Understand, as an intel team, you need to understand how risk is communicated to leadership, and then you need to communicate and work and collaborate with risk in that same language. You need to change from IOCs to, you know, potential loss. There's a definite vernacular and there's an understanding of what is impacted here. So. When I look at like alerts in the SOC of like, oh, this system is getting attacked. What system is it? And then how does that system, what applications are sitting on that? And if those applications go down, I'm sure there's a business continuity or disaster recovery team that has assigned a dollar amount to those systems and understands exactly what happens when those systems are down for 30 seconds or 3 days. You now, there are dollars available that you can assign to what those alerts are saying, hey, we stopped this attack. We stop this system from going down, yes, there's a dollar amount there. And Intel always struggles with that. You know, if nothing happens, how do you show value? You know, but if something happens, how do you prove that it wasn't my fault? You know, um, and it's no different in the Intel community, right? Like there's always somebody, you know, there are beans to be counted. And we talked about this earlier as requirements or like, how are you satisfying those requirements? But then it goes beyond that if it's not just the requirement, but like what's behind that. Everybody asks, you know, a few years ago it was all about context around IOCs. It's like, no, no, no, no, it's the context around the risk. And then you work your way, eventually you'll find the systems and the IOCs are damaging that. But really you need to start with the dollar amounts to the business and that's how you show value. You'll never show it from just data logs in the SOC. You have to work with other teams and come back in.

That's a, that's a really good point. It's also really, really difficult. I think most people know that, right? Of course, you have to know you can do it.

Yeah, it's all relationship building. And then, then you start uncovering other people's dirty laundry. Like, what do you mean we don't have a risk register? Oh, it's on our roadmap.

It's like, oh, okay. Yeah. Yeah. Risk registry is a good one. Yeah. It's funny. I talk a lot about configuration management database and crown jewels assessments. And again, those are things that really align. Intel needs these things, frankly. We need, we need to exist and we need to know where they are. Cause if I come in and say, hey, there's a really dangerous threat, you know, valid actor, they're talking about us. They have the capabilities. And then the question is, well, what does it mean to us? All right. Do we have this software? I don't know if we have it in our systems. Well, that's a problem. I can't tell you what it means to us. Or we have it, but I don't know where it is. I don't know. Is it just in an air-gapped lab somewhere where you say the risk is really low? Or is it tied to our crown jewels? Well, we don't have a crown jewels assessment. Oh, well, that's—

Well, then how am I ever going to provide you value? Like, how am I going to tell you what matters if you haven't even established what matters? And that's— those are difficult conversations to have. And oftentimes the team that's, you know, 5 levels down from the CSOC shoved in the SOC somewhere isn't going to be able to have that conversation. So that's, that's tough. And that's one of the reasons why Intel has been relegated to IoT management. And sadly, that's, you know, have a whole bunch of people that are underutilized, especially when you're bringing people in from the intelligence community that have all this experience, but they also have experience with infrastructure that's been in place for, you know, about 60 decades or 6 decades or so, 60 years, you come into the private sector and they're like, we don't have a listed requirement.

We don't have a risk register.

I can't tell you what the crown jewels are. We, you know, we're just now standing up asset management and they're expected to demonstrate value. It's like, whoa.

Okay. Yeah. It's really hard. One, you also mentioned they're often buried low. And obviously this is self-serving for me because this is one of my topics for the last few years. But, you know, I wrote an article called Rise of the CINO, Rise of the Chief Intelligence Officer, a couple years ago. And it goes around circles. And I still am a big believer in that. Part of our challenge is we bury intel so deeply, you know, they, oh, we gotta have an intel team, but then they're gonna bury it in the SOC under some defensive operations senior director or director or manager or whatever. And that's so many layers removed from where you need to be that you can't have the influence you can have. You know, one of the things I had, at least in my experience in the intel community going back, you know, in the military or in private sector as a contractor was we weren't far away from the decision makers. You know, I wasn't buried 6 layers deep. You know, we wrote intel that went to the 4-star or the 2-star or the SecDef or the White House or wherever. So we were considered their counselors. That was the point of having intel, you know, and that's what I wrote with this Rise of the CNO piece was that, you know, intel, there should be a chief intelligence officer along with the chief legal officer. They should be the consular areas basically for the CEO, which also would change a lot of this. It would provide direct access to talk about what corporate level requirements are, not just security, but across the board. And better direct resources to talk about what's really needed and get away from this, you know, just IOC management buried deep in the SOC because that's what the SOC manager, SOC director, whoever needs, right? It doesn't really get into the bigger picture piece. So you're not getting the value. I talk a lot about this stuff. Intel costs money, but you can get more value if you elevate it. So that's back to my own soapbox.

One thing I, you know, one, one message I, you know, blare from my soapbox is that everybody already is doing intel. Intel. They're already making decisions at every level from down in the SOC all the way to the board. They're making decisions. They need information to make those decisions. They go and get it. And then they realize like, I need more information. This is good enough and move on. Everybody's completing that cycle, but they're not doing it the same way. Right? So like your intel organization, that chief intel officer, which would be fabulous, would kind of coordinate that. Now, understand that there already is an organization in most of these, you know, huge companies, they have business intelligence. What has BI been doing for decades and decades? They've been taking large amounts of disparate data, running some sexy queries against it, and then, you know, suggesting courses of action for the business to take, you know, whether it's from building a data center in this country or where to put a product in the aisle. It's being done in your organization. Why are you reinventing the wheel for your CTI? Like, why wouldn't you put CTI very closely together with them and say, okay, if we want to do this, What are the cybersecurity concerns around that? It's a missed opportunity. And it's just, I don't know if it's a paradigm shift. They're like, well, Intel is Intel, right? It doesn't matter what you risk intelligence, fraud, physical security. It doesn't matter.

It's all that's why I think they all should be together. I agree with that. Absolutely. I think the chief intelligence officer, all those should be under the chief intelligence officer, business risk, you know, strategic intel, tactical intel, operational intel, um, you know, all these bits and pieces, physical. Should be tied in there as well. I mean, physical will be more of a customer, but all of these are tied together, right? As, as one unified piece.

And even if it's nestled under the CIO, like the CIO's chief of staff, right? Like, wouldn't just, because what is it? Chief Information. That's what we're talking about. We're talking about managing and creating a system of record and historical database.

Yeah. Yeah. I mean, I could live with that, but don't screw this up for me, man. Chief Intelligence Officer needs to report to the CIO. Don't downgrade this. Don't screw it up. Let's swing for the fence. But no, you're right. Even upgraded to to being under the CIO. I've seen one under CSOs, but then the CSO's often under legal and it just, you know, you start burying them down. But every time I find an org that says they have an intel team, you find it's like one person wearing 7 hats that's buried in the SOC and, you know, they're a manager level or not even. And you're like, well, you're checking the box of intel because somebody said you had to have an intel team, but you're not doing intel. You're not doing this person any justice. You're not investing significantly enough to have the impact you you really need to have from this. And then you're expecting things you're not going to get. And often that's the same company that's going from vendor to vendor to vendor too. Every year they blame the vendor and they move to another one and nothing really changes.

And then they say, well, all these vendors are the same.

None of them can produce what we need. And the challenge is you didn't have intel requirements. You didn't put your org in the right spot. You didn't man it up or woman it up. You know, take your pick. I'm not trying to be gender specific here, but you didn't put the people in place that were needed. And, and sadly, like you can't have that hard conversation with a customer a lot of times or a prospect because it sounds insulting and I don't mean to, it's just, they didn't know. Right? They didn't have somebody come in and say, this is the way it's done. This is, this is your plan. This is the best way to do it. And by the way, it's going to cost a lot of money, which gets back into intel requirements, gets back into the value of the whole discussion we've been having. Right? And if you're lucky enough to find somebody who gets it, you know, you get a CISO who understands or somebody that sees or trusts who understands or a C-level or whatever, and you start building this, right? And you pitch this whole program and they buy into it and they go, then that person leaves, you know, that person finds another job. Comes in here, sell it all over again. And they may or may not get it, or they may or may not believe in it, or the budget might just change. And everything just seems to revert a lot of times. So it's hard to get somebody who buys in, believes in this, is committed to it, and then also stays put because people move around from company to company.

Which I do see a change. I see more CISOs that are, you know, leaning towards getting MBAs versus CISSPs. And I think that is an opportunity for Security companies that are going to try to survive, you know, the next few years as budgets decrease and consolidation happens. It's how do we start speaking to that CISO and supporting them as part of the business? We talked about budget planning. There's a great opportunity there because that's intel, right? You're making a decision. You need information. Where do I put the dollars? He or she will need to have a process in place. And so if you are an intel company that's just pushing out, oh, Fuzzy Bear is at it again. You know, like what decision are you supporting? How are you helping anybody accomplish the, like, what is Fuzzy Bear at it again?

What does that mean to me? Right. Yeah, exactly.

Unless you're articulating that, you're just noise, right? That's right.

You're telling the people the news. You know, I tell all the time with Intel, it's tell me what it is. Tell me why it matters. Tell me what I can do about it. If you're just telling me what it is, you're just the news, which is fine. News is important, but I don't have time to read all the news. I certainly don't if I'm an executive trying to keep the company safe.

Tell me what it is.

Tell me why it matters and really why it matters to me. Like, that's what I really want to know. Not just why it matters globally. Maybe sometimes there are reasons to know things that are not actionable. Some things are just informational because they lead to it. But tell me what it is. Tell me why it matters to me and tell me what I can do about it. And if the answer is I can't do anything about it, that doesn't mean don't tell me. That's still important to say, hey, this is it. This is why it matters right now. You can't do anything about it.

Well, there's the what, there's the so what, and then there's my now what. Most of the industry is shoved in what? Every once in a while you get around to the so what, but the problem is it's your internal team that tells you the now what, you know, a third party can't tell me how I'm supposed to action information to mitigate risk because threats are ubiquitous, risk is personal, right? So your intel team should be the now what, like this is what we're doing because of the so what, right?

And then you got to be able to keep all of this documented, right? So you got to have some sort of a living database that's going to last longer than the people. Because as you said, the people move on. So you have to have a database that shows here's our requirements, here's what this means to us. It's modular. It can change over time. Here's what we put into it. And maybe some documentation also says here's why it matters. Here was the thought process that led us down the path to buy this database or build this database, whatever it is, right? So that when you do have a leadership change, you have a better chance of selling the new person if they didn't come in already believing in what you had. On the idea that this is, this is all the work that went into getting us here, sir or ma'am. So this is why we would like to continue down this path. This is where our value is. And if you don't have that, which spreadsheets are not the same thing and disparate documents all over the place don't work. Or if you, again, you have it on one person's shoulders and there's some very junior person that C-level may not listen to them. So it has to be elevated to a high enough level that has, you know, some, some gravitas behind it. If you don't have that, it all just evaporates anyway. So, You know, I, I, I feel like that's what RecFast, what your company, I feel like that's the gap your company has been trying to fill, right? Is not only help people understand all this and build all this, but also have an enduring database and be able to do all this, you know, and I've worked with you a bit in the past, obviously, and even before you were RecFast, you had a different name previously. And so we go back a long way, but, you know, it's, it's frustrating that it hasn't caught up more, obviously. So, you know, it seems to me that there just, there aren't enough companies that are willing to invest, you know, very heavily in this. There's just, there's a lot of small teams or one-offs. I mean, I'm surprised how many Fortune 100s I talk to and you find out their intel team is not a team, you know, it's, it's one or two people and it's their secondary job behind a bunch of other things.

And then we see these massive breaches happen and you realize, you know, but they didn't have intel teams, it sounds like, but, you know, well, I think it, I mean, it's a, it's a, uh, they're willfully not investing in process, you know, so they're investing in people, sort of, they're definitely investing in technology, but they're failing to invest in process and like everybody's quick to automate. But if you don't have a manual process to automate, what are you doing? You're just adding more confusion to your tech stack. One thing I like to see is when IR teams, incident response teams, you know, have playbooks that they actually update regularly. And a playbook is a great opportunity to start building on, like saying, we do this because of this. This happened before, this was the result, and that is why this is now an item in the playbook. So like, if you have a playbook, great, but you also have a huge opportunity to build on that and put the historical reference and the documentation behind that. Companies have to be willing to enforce documentation. They have to be willing to enforce that investigative discipline of, you know, you did something, now check the box and fill out why. You can see it in their, their tickets in the SOC. Like if they're not telling their analysts to be, you know, verbose in why they did what they did to close out a ticket, then yeah, they're going to get breached. I mean, because if you're not putting in the time and effort, and that comes from leadership, that's part of like, that should be part of the job. Like you and I both know on the human side of the house, for sure, that if you did anything for like, you talked to a human for an hour, that's 3 hours of paperwork that you had to do on the backend. Same on the technical side. There's always, you were, there was a whole bunch of C and CYA paperwork that you had to fill out because that was your job. We don't require that in the cybersecurity industry. And it's the only industry that I know of that as part of a business gets away without having to count their widgets and show where the money went.

Really. Which is, which is really challenging because you're talking about an industry where there's never enough time, right? We all talk about this, you know, this is endless, right? Adversaries are growing every day. They're bigger. They're stronger. They're, they're more voluminous. Now we've got AI coming in. So everything's faster and more dangerous. Listen, if I don't have to do documentation, it's probably the first thing I'm going to I'm going to skip on and save my time on. Oh, this is done. Check the box. You know, market complete. Oh, there's more. There's a field where I can add details. No time for details. Let's move on to the next thing. And then you have nobody who can go back later and even say, well, what did we do? Why did we do it? How did we do it? Oh, I don't know. That's all been lost. That's in the ether because I'm on to the 68 other things because I've only got 10,000 alerts to go through today and I've got, you know, 8 hours to do it in.

So the fact of the matter is you're, you're not going to get through that 10,000. Let's at least do the 100 that you do that day and do them well. Because that will be more valuable to your organization in the long run. And especially as you're bringing AI in on the vendor side, you got to train it on something. If you're training it on open ticket, closed ticket with no details behind that, you're going to get what you pay for, right?

Yeah, you're not getting any better. I know I've spent a ton of time and effort and I continue to, and I like to, by the way, but I spent a lot of time and effort, you know, trying to help people understand. The whole thing, the Intel cycle, how Intel feeds in proactive security, all this from a more systematic approach. Yep. But it's really hard. I, I find it to be just insanely difficult to get the right people to understand the value. Yeah. And to understand the, the time and the effort this is gonna take to do, you know, why you need to invest money at the value of process and documentation and standardization for building a sustainable intelligence program. And, and listen, the payoff is the only proactive solution to security is Intel. I know I say this in It seems like every episode now, but it's true. There is nothing else proactive by definition. Everything else is reactive. Intel also helps the reactive. If bad things have happened, we can hopefully, you know, shorten your, you know, your time, you know, what does it mean? Time to discovery, mean time to, you know, remediation, those kind of things. But intel's the only thing that can stop you from being compromised. If I know a bad guy is doing things to a company like you, that you're, you know, and, and we know, go in the dark web or whatever, they've chatted that, that you're on their target list. We know what they do and how they do it, and we know that you actually are vulnerable in these spaces. And as a result of that knowledge, we can help you make those changes and you, you get ahead of the curve and the adversary shows up and can't do the thing they've been doing to everybody else. You can only do that through intel, but it takes a lot of time. It takes a lot of effort. It takes money. It takes patience. It takes investment, which may not have immediate return. I often tell people, you're going to do a lot this year, but by the end of the year, you're probably going to have at least one, if not several non-breaches that you're going to be able to report and say, well, this is, this is why we do these things. You know, uh, customers who weren't hit by WannaCry years ago, I had customers. And when WannaCry went live and cost everybody so much, we had 40-some-odd customers where I was working at the time and nobody was hit by WannaCry because we wrote an intel report 2 months previously. The team did, I didn't write it, that told people about BlueKeep and our customers read it and took action. So WannaCry shows up, costs it, you know, billions and billions of dollars and, and our customers aren't impacted. That's what intel will do for you. But next year, how do you sell that on the budget? Right?

So, you know, intel goes both ways though. It's external and it's internal, right? And a lot of people forget that, like you can run, you can look at your own organization and say, like, if this were to happen, what's the likelihood? So you have disaster recovery doing intel that you need to collaborate with. So if you say, if this happens, you know, let's play this out. Tabletop exercises is a great way to start developing intel requirements. So like, what would happen if, I don't know, do we even have a response to that? Do we even know, do we even have a corporate policy on whether or not we're going to pay ransomware, you know, threat? So it's like, these are questions, those are intel requirements, or that's the start of it, you know? So yeah, it's There is an investment there and it doesn't, it's not flashy. It's not exciting. And I always joke, you know, people are like, hey, how, how is Recvast doing? I said, well, I sell process accountability and transparency to the cybersecurity industry. So it's just flying off the shelves. Right. But I still do it. Maybe regulators can help.

Yeah. Maybe, maybe regulators can help with some of this. I do find finance is the best at this. I think, I think part of that's because I say it all the time. It's a cultural thing that, you know, I mentioned internalizing, right? Listen, if you work at banks, you work in finance, that's a culture forever. Banks have been robbed since there were banks. People understand robbery and they understand banks and crime. So they always have a bit more of a security mentality, I think. You know, I pick on healthcare a little bit, not intentionally, but just culturally healthcare is different. Healthcare is about helping. It's about openness. It's not— nobody ever grew up in hospitals worrying that somebody might steal their patients. It's just not—

the doctors hate putting in passwords and they just want things to work, right?

Oh, they want—

yeah.

And they need efficiency. Like it's not just a want. I get it. Sometimes it's life and death. They don't have time. Let's just go, right? And they do incredibly meaningful, you know, work. But as a result, the cultures are different. The security culture in healthcare lags behind, right? And I think that's, you know, that's a challenge that we run into that, you know, you were sort of hitting on there a bit. So, all right, with all this said, and it's frustrating, and we've talked about some of the negatives, but also some of the opportunities here. Listen, you're in the market. You guys have been in business now just past 5 years, I think, right? The RecFacts been out there. So, You know, what are you seeing in the market as far as acceptance for the need of intel requirements? Are we getting better at this? Is there a level of maturity needed before people, you know, catch on with this thing? Are there certain roles that are more receptive than others? You know, what, what are your thoughts across the board in this area? What are you seeing out there?

Yeah, so I definitely see, I'm seeing more conversations about it and I'm having, you know, more requests for, you know, consult, you know, consultation to come in and like help them build a program. So the conversations are there. People actually now are acknowledging there's a need. There's still a lot of, still a lot of work to be done in how do you actually take a requirement and put that into action and then show value behind that. But at least the language is there. I think the marketing that we've done for the last 10 years finally has shown people that a lot of it is just marketing and there needs to be something behind that. I had a friend of the business that said that we were really good about being all hat and no cattle. And I think the time to bring the cattle is here. I see, especially with cyber insurance and things like, and, you know, breach dollars, I think the money is finally there to push this market, you know, this industry forward to be a value. But that's on us, right? And so example of cyber insurance, the underwriter has a list of things that they're going to look at. To determine whether or not we're going to give you an insurance policy. That list is exactly what the CISO probably cares about on a daily basis. And the likelihood of an insurance payout is pretty important to the board if they're hinging their entire cybersecurity policy on cyber insurance, right? So I see dollars as driving this conversation forward because like, okay, we know we need intel, but how do we make this useful? Well, okay, what's the requirements? What is a requirement? Well, it's what you need to know to make a decision. All right, where are you going to write that down? So I see improvements in the process, but it's still, there's still a huge disconnect between what is happening in the SOC and what's happening in the business and how do we bridge that gap. And I think we're not doing ourselves any favor by utilizing a lot of cybersecurity jargon. I think we need to start speaking more in terms of the business and we'll see some improvements.

Improvement.

I also see, you know, breaches are happening every day. Nothing's stopping them, no matter how much you invest in technology. So I see a lot of consolidation. I'll see a lot of companies going out of business. On the cybersecurity side, you're seeing layoffs on a daily basis. I think the industry, just like any other industry, has to figure out how to show value. And no matter how much you posture and show, I don't know, we'll stop all your breaches, like you're not going to do that. From a third party unless you get involved in training your users inside the company and how to do that. So I don't know. I, I see a lot of the same and that's sad, but I do at least people are having the conversations now. I'm getting a lot more requests for coming in and talking about the Intel cycle and how do you actually apply that. So that's good for me. Will it be fast enough? I don't know. And then AI is definitely going to change things quickly for the better and worse.

So, yeah. Well, yeah, AI is, yeah, it's a whole nother episode of Onset Security for later.

I'm sure. Invite me because I'd like to soapbox about that as well. Yeah.

I don't, like you said, better or worse, you know, it's going to do a bit of both, I think. And, and I'll leave you that for now. But I think, you know, you point out that it is good that you're seeing more prospects, more customers that want to talk about this, that know what the terms intelligence requirements mean, that know what the intelligence cycle is, right? And I'll, right. I'll take my very, very tiny fractional credit for that because I've been out there screaming about it for years and on stages and talking about it. Me and several, several other people, of course, out there saying these things. So it's nice to hear somebody who's out here every day say, I've seen a tangible change. That tells me there's some market change. And I've seen some of the same, but it's just my little sliver of the world that more people understand these concepts and at least talk about them. That's a really good start, right? I don't know. Keeping up or not, but you know, you've been doing this for, for a while and this is all, to my knowledge, this is all RECFAST does, right? You're not, you're not doing this and 28 other things, right? So we have a lot of vendors in the space who are intel requirement adjacent, let's say, you know, they're, they're intel providers, whether it's technical data, whether it's strategic intel, operational, something in the middle. And so they would benefit from knowing the company's intel requirements, be able to push intel to meet those requirements, but they may or may not be developing those requirements. They may not have access to them or they may not have a system which might be the most important thing, or a platform that can tie them, right? So if a vendor is delivering intel, if I'm a vendor delivering intel to somebody, I might even know their requirements. Maybe they're mature. We've had this discussion. I know they care about, maybe not all, but I know they care about APT1, let's say. So I know I'm sending them intel on APT1 and that's great. But I don't, if I send them other intel that I think is interesting, I don't know if it actually meets the requirement or not. I don't know how to tag it. I don't know how to get it into a system where they can quickly match it to their requirements. So they've got all the metrics and the data that goes with that. You know, and are vendors building more of this into their technologies? Are they partnering with you to do this? Are you a side piece to this? Like, how are, how are all these going to be put together? You mentioned all these different orgs you got to be able to work with. You got to work with risk and you got to work with, you know, policy and you got to work with whoever's doing the crown jewels assessment and who's got the CMDB and, you know, all these other organizations, patch prioritization, the SOC, it just goes on and on, right? But there's got to be a place where all this gets stitched together, all these requirements, the business intelligence requirements, all these things get stitched together.. And I don't know any vendor that's above all of those things, right? That has that in their platform. Is that where RackFast fits in? Is that where you fit in? Or is that still a gap we're trying to get to?

That's where we try to fit in because every, like, we want to sit kind of above all that. So it's not just CTI, like we track risk requirements or fraud requirements or physical security, intel is intel. Like it doesn't matter to me. When we first designed this, we first started, we sort of had a large financial CTI team in mind to, market too, but our very, one of our very first customers was a vendor because why? They had a bunch of disparate customers who all had different needs and they were sending stuff out and how are they tracking? And they needed some way to provide a feedback mechanism to say, this customer is happy with this. This customer is happy with that. Sure. At the same time, they had providers because they were kind of a middleman for a lot of information. So they needed to have a way to like, hey, vendor, other vendor, we needed this from you. You didn't provide it in a timely manner. So that they needed some way to get metrics and feedback there as well. So we were kind of surprised when a, you know, provider was our first customer, but it really made sense. And so we're, you know, we're customer industry agnostic where whether you were the intel team, that's a company providing information or you're the internal team, it really doesn't matter to us because once again, intel is intel. If you're risk intelligence, fraud intelligence, and so that's kind of where we fit in is we, We manage the requirements. Are we delivering against those requirements, customer service? And then what are the metrics around that? How do you show dollar amount and how can you present that to leadership in a meaningful way? Nobody else really does that. Most providers that we work with out there, they'll have a mechanism to record a list of requirements to stakeholder, but there's really no operational, you know, it's not really tied into what they're doing in Jira. It's not really like, so where's your tie to your operations? Where's your case management? Start providing. That's, well, that's not entirely true. I have seen some progress. Finally, some of the Intel platforms out there start adopting this and this is great. I, yes, is a competition sort of, but I'm happy that they're doing it because they should have been doing it 10 years ago. I'm glad to see that they have finally seen the writing on the wall that we should probably track what our customers want to know. And if we're delivering against that, that to me, I have no idea why as an industry, we're all not doing this from day one. Your sales engineers certainly are writing down success criteria. How come you're not passing that on to your providers and analyst team, right? They actually wrote down, that is a customer requirement. Like, why is that sitting in Salesforce and not in your day-to-day, you know, profile for your analysts? There's your free tip for the day.

Right. Well, it's a good point. Customers only know two things, like CISOs at least, and C-levels. You know, either, either lower my risk or improve my bottom line, right? Which is either lowering costs or, or, you know, raising revenue somehow. Right. And so Intel fits into that, right? We should be able to help people lower risk, but that requires a lot of things you're talking about and, and people either aren't documenting or they're not going that step further. And, you know, I, I'm with you that I think platforms, listen, I, I used to work for a threat intel platform. I've been in the space a while. Obviously I've been advocating for platforms to have Intel requirements for years in their, in their technologies. You know, as an Intel guy, when I write Intel, it's nice to be able to tag it back to the Intel requirement and the customer knows where it goes and it gives us our metrics, et cetera. So I'm, I'm with you that I'm happy to see more vendors going in that space, even if it does create some competition for you. It sounds like you're more holistic anyway and go beyond just the Intel requirements to the whole corporate requirements piece. And I assume, I don't want to put you on the spot, but I assume you plug into a lot of other enterprise databases as well, or, or are probably working on that at least. Working on that. You know, all the different things that are out there, the risk registries and the, and the ticketing systems and the, You know, all the things that go in there, right? Right.

Yeah. So working on it. So yeah.

Yeah. Well, that's a big process, right?

I mean, everybody's different. That's the problem. It's not like I can make a one size fits all platform. So there's a lot of bespoke work and that's part of the struggle, but the fundamental problems are all the same. It's just the technology is changing. And so we believe in sticking to the process, overall process, and then we'll just find individual ways to like. It's hard to scale that way, but so be it.

So absolutely. Well, listen, I should have mentioned this at the beginning of the show for anybody who's been listening this whole time. If you want to know more about ReqFast, it's actually spelled R-E-Q-F-A-S-T. Ryan's a great guy. As I said, you know, he's a Marine, so he's not as great as some of us, but he's still a great guy anyway. And listen, their technology is really cool and what they do is really cool and there's a big need out there. So, you know, if you're looking for more on, on his company, on him, on what they do, you know, reqfast, reqfast.com, or is it .io? Which one is it, man? .com. .com. Okay.

reqfast.com is a place to find him. Find me on LinkedIn.

Yeah. Or find him on LinkedIn. Right. So I could keep talking about intel requirements all day, especially when I talk to somebody who, you know, sees it the way I do. That's great. But I don't, I don't get to do that. So like I said, if people are looking for more, I hope they reach out to you or, you know, reach out to me. Uh, you can find me on LinkedIn. You know, I'd be happy to talk about intel requirements. And, you know, how to build intel programs, the intel cycle, how it starts with the requirements and stakeholders, all these things, and how to help people get more value, which starts, again, you got to know what your needs are, you got to tie intel to it, tie your spend to it, tie the results to what you got, so you're able to say this is the value. So I think, I think, I think you nailed it. I think we're on the same page on this one, which I appreciate you taking the time to come in and explain it to folks. And hopefully more will reach out to you. I got to get to the point of wrapping up here, unfortunately, but With that said, so the closer question for everybody on the show, you know, the name of the show is Unspoken Security. So, you know, with that in mind, I always close with the same question, which is tell me something you've never told anyone, something that to this point has gone unspoken. What do you got, Brian?

The one that came to mind was that I, especially during the Marine Corps years, I always carried around a copy of The Catcher in the Rye, and that was because it was my one time password cipher. I didn't write anything in it, but if I had, you know, a password hint, it would say, you know, 88 and 10, meaning I would go to page 88 and count the first 10 letters, you know, the starting of each line. And that would be my password. And then of course I knew what my little, if I need this special character in the number, I would always use the same one, which is great, but at least I would put those little 2 at the end of it. And so my password hint was always just page number and a length of the password, but nobody knew that that's what I was using as the base of my, so, you know, another book that I happen to have is, you know, 1984, don't use that anymore, but, you know, so if the password was like Bank of America, I would say 27715, and that way I would know I would have to count down the first, I'd go to that page and count down the first 15 letters. And so that was how I tracked my passwords.

What a, what a really interesting concept. So I, listen, I've. I mean, I'm familiar with ciphers and codes a little bit, of course. And I think most everybody frankly is, whether you're in intel and you're familiar really directly or you watch movies, whatever. But this is a really interesting idea. So, so you carried around Catcher in the Rye, which of course, if you ever lost one, you can go get another copy. Like, it's a relatively—

as long as I knew what that edition was. Yeah.

Well, that's a good point. You better have the right edition because it changes, you know, spacing and everything changes with it. Right. But, but being able to find that book, you know, should you lose it is good. So, so you would just, like you said, like you, you'd say, okay, you know, page whatever, and, and then a number and that's how many. And now I, I assume you picked a page where the first word started at a certain place, like you were in the middle of a paragraph or whatever.

Yeah, it would always start in the upper left-hand corner and it'd be the first letter of each line going down, but then you'd get a mixture of capitals and lowers and it wouldn't create a word. So it wasn't creating something that, you know, would be in a rainbow table.

Wouldn't work now though with alphanumerics and special characters.

Only if you, well, that's what I'm saying is that I always knew what my, I would pick like you know, asterisk 7 or asterisk and percent. I just knew that that would be what I put at the end. So I do the 10 letters and then I would put my special characters at the end.

Got it.

Got it. Granted, using those isn't great, but once again, if nobody knows what your base is, then yeah.

Now, do you still, obviously I want to switch books, but do you still do things this way?

Or are you just like, no, I have a password manager. And also I'm getting older. I forget where I put stuff, so I can't carry a book around.

Where did you, where did you come up with the idea? Like, did somebody else speak it to you? Was it just a random thing?

It was a random thing. I kind of, I came up, like, as going through intel training, learning about one-time ciphers being, you know, as long as each person had that one-time pad, it's being the most secure, and they're still considered one of the most secure ways to do it. I thought, well, what could I use if I'm— where's my one-time pad? And I just happened to have a book on me.

Very interesting, man. It's a really cool concept I haven't heard of before. For anybody out there who's trying to figure out a way to handle passwords. I guess you could do that. And I guess at that point, like, I use a password manager too, but you could easily just have a notebook that said, you know, Citibank 2129 or whatever, right? I mean, you could do all those things. You could write them down if you want, because somebody has to know the cipher first, which is what it is. Absolutely. But I, for what it's worth, I wouldn't recommend that, folks, because if somebody figures out what your favorite book is, you're probably in trouble.

That's a problem. So yeah, don't advertise it.

Right. It's super interesting though. I'd have to go through somebody's whole library. I know people own thousands of books. It'd be impossible. So really cool, man. I appreciate you sharing that. I, I'm, I suspect somebody out there is going to decide to start using this actually with whatever their book is. I think it's a really cool idea. I'd never heard of it before. And one-time ciphers, as you said, are really safe. So it's really a, you know, it's a neat concept anyway.

It's also an analog solution in a digital world. Like there's, you can't get a book hacked. So as long as they don't know what that book is and they're not tracking you personally.

That's a good point. And we're seeing more people go back to some analog solutions, as you said. So, all right, listen, we got to wrap it up here. We're, we're out of time. I want to thank you, Brian, from, for coming on today. Thank you for taking the time to talk about Intel requirements. Of course. Helping understand, you know, the value and the importance here. I think you, you brought up some points that I haven't had people talk about too much before, myself included, frankly. So I think it's really interesting. I think RecFast is really interesting. I hope people, you know, come and check you out. Any last thoughts before, before we wrap up today? Is there anything we missed? Anything you want people to remember going out the door besides wreckfast.com, wreckfast.com, wreckfast.com? But anything else, you know, for you, man?

Oh man, I think you pretty much covered it. But just remember, intelligence is decision support and customer service. And as long as you understand those two things, I think you'll do better.

Yeah, man. I, I second that emotion. All right. So again, thanks for the time. Really appreciate you coming on the show. For those who are listening or watching, If you like Unspoken Security, please do take the time to subscribe, to, you know, to like and thumbs up or whatever, whatever all the ratings are, right? And, you know, let us know. Feel free to contact me directly if you've got feedback. You can find me on LinkedIn or you can find me through emails and let me know how the show is. The show isn't about me, right? The show is about you, the listener. It shows about, you know, Brian and guests like Brian coming on and being able to share things. So, but I need to make sure it keeps going. So please subscribe., you know, give the feedback, you know, talk to us if you've got an episode in mind, you got something you want us to cover, like, let me know and we'll see if we can get that in there too. But until next time, thanks again for listening and watching Unspoken Security. We'll look forward to talking to you all in the future.

Cheers.

That's a wrap for this episode of Unspoken Security, brought to you by ZeroFox, the only unified external internal cybersecurity platform. If you enjoyed this episode, follow us wherever you listen to your favorite podcasts. See you next time.

This is how legends are made.