With increasing digitization and the use of cloud-hosted assets, managing attack surfaces continues to be a major challenge. A recent survey report on the state of attack surface management (ASM) finds security teams drowning in a flood of legacy and ineffective tools with limited discovery capabilities. The need for ASM platforms with advanced digital asset detection capabilities is revealed in the survey findings. David Monnier, Team Cymru Fellow, sheds light on the latest ASM platform capabilities and discusses the implementation challenges and success factors.

Time Stamps

00:50 -- I'd like to take this opportunity to welcome David and have him share with all of us some highlights of his professional journey.

03:14 -- What was the motivation? What led to this very important study that y'all conducted?

07:41 -- David, would you like to add anything to that from a methodology and participant demographic standpoint?

09:52 -- The first finding that I'd like to talk about is "the biggest reason organizations implemented ASM is to increase the visibility of Shadow IT in the enterprise." I think this is a very significant finding. If you would expand on this and also describe what Shadow IT means?

14:50 -- Over the years have ASM platform capabilities been enhanced to better monitor cloud-hosted assets? What's been the trend?

19:17 -- Moving along to another interesting finding, which states that "23% of the respondents said that identification of rogue or unclassified assets is the most valuable capability that ASM has provided their organization." I guess my question here is, shouldn't this be obvious? Shouldn't that be what an ASM is supposed to be doing?

20:56 -- What steps should an organization take, should the security analysts, the security professionals take, to ensure that their ASM platform is performing at a satisfactory level?

24:30 -- To what extent is AI being used to enhance the functionality, the capabilities, of these ASM platforms?

27:48 -- So talking about the human component, and in this discussion, we have been talking about attack surfaces, more from a physical standpoint, devices, and so on, so forth. How about humans as attack surfaces, as very vulnerable attack surfaces? Are we doing better in terms of securing this very vulnerable attack surface? Can tools help us secure that attack surface? What are your thoughts?

31:23 -- Is there anything that you'd like to address that you found interesting, or something that surprised you all?

34:22 -- Is there a way of notifying multiple personnel just to make sure that the alerts don't go unheard?

36:43 -- So if you had to make recommendations to potential buyers, or investors of this ASM platform, what does it take to prepare the organization, so they can effectively use such a platform?

40:33 -- I'd like you to share some final thoughts.

Memorable David Monnier Quotes

"You have to approach the tool sets as, am I going to have a tool that's going to show me things I didn't know to know. And that, in my opinion, is the killer feature, way more important, in my opinion, is discovery, than the vulnerability management component."

"If your tool can't tell you that your DNS hosting provider has a poor reputation, or that the IPs around your IP services are bad, if it's not able to show you these kinds of things, then it suggests that you are probably working with an antiquated tool. But frankly, let's use the word static. And if it is static, I think in the information age, that should be a huge red flag to you."

"The number one compromised source is still stolen credentials. And the number one method for that is still some type of phishing, or some type of social engineering, so nothing seems to really be changing there."

"We still work and live in a world where everything is kind of magic. And the majority of people who are relying on technology, still have absolutely no idea how it works, and therefore can't really spot things when they aren't correct, right."

Frankly, there's only so much time in the day. And if you have to pick between defending the mothership or defending a rowboat out in the dock, you know, you're going to defend the mothership, hopefully. So your tool, if it's not aware of that, that's going to be a problem."

"There are entities and organizations that carry adequate insurance to pay the fines for non-compliance because they wholly expect to be out of compliance because they consider the compliance component, a burden."

"So my number one advice to anybody considering to go down the path of implementation of ASM is, one, be willing to do something that you find, but number two, be willing to actually use it because it's going to make your job easier, it's going to make your life easier."

Connect with Host Dr. Dave Chatterjee and Subscribe to the Podcast

Please subscribe to the podcast so you don't miss any new episodes! And please leave the show a rating if you like what you hear. New episodes release every two weeks.

Connect with Dr. Chatterjee on these platforms:

LinkedIn: https://www.linkedin.com/in/dchatte/

Website: https://dchatte.com/

Cybersecurity Readiness Book: https://www.amazon.com/Cybersecurity-Readiness-Holistic-High-Performance-Approach/dp/1071837338

Welcome to the Cybersecurity Readiness Podcast

Series with Dr. Dave Chatterjee. Dr. Chatterjee is the author of

the book Cybersecurity Readiness: A Holistic and

High-Performance Approach, a SAGE publication. He has been

studying cybersecurity for over a decade, authored and edited

scholarly papers, delivered talks, conducted webinars and

workshops, consulted with companies and served on a

cybersecurity SWAT team with Chief Information Security

officers. Dr. Chatterjee is Associate Professor of

Management Information System at the Terry College of Business,

the University of Georgia. As a Duke University Visiting

Scholar, Dr. Chatterjee has taught in the Master of

Engineering in Cybersecurity program at the Pratt School of

Engineering.

Hello, everyone, I'm delighted to

welcome you to this episode of the Cybersecurity Readiness

Podcast series. Our discussion today will revolve around the

state of attack surface management. David Monnier, Team

Cymru Fellow will share his thoughts and perspectives on

this very important subject. Another highlight of our

discussion today will be the findings from a very interesting

research study that focused on the state of attack surface

management. But before we get into all those details, I'd like

to take this opportunity to welcome David and have him share

with all of us some highlights of his professional journey.

David, thanks for being on the podcast.

Thank you, David, thank you very much for inviting

us on to talk about our study. So it's always a pleasure to

come on. Some background about myself. So I'm, I'm from the

United States. In the Midwest, I had started my career.

Originally I was in the US Marine Corps worked as a

noncommissioned officer there. But when I got out of the Marine

Corps, I got into working with technology, just out of

coincidence of funnily enough, a computer breaking that I ended

up fixing, and discovering I had some natural talents, I ended up

going to work for Indiana University, working in high

performance computing. And from there moving on to their

security office working as a security engineer for them,

basically looking after all the campuses around the state. And

then shortly after that, I was invited to help come start the

research and education, networking, ISAC, which is an

executive ordered set of organizations largely geared

around kind of specific industrial sectors. In my case,

it was research and education, networking, there are also like,

financial sector there are itI sec, and so on. But ISAC is an

Information Sharing and Analysis Center. So you could think of it

as groups of people working together to share threat

intelligence. And then after that, I was invited to join Team

Cymru where I've been here for about 15 years. Presently,

working as a Fellow, but periodically helping to spin up

new teams for us and identify new product needs and things

like that. But I've been practicing for, I think it's 27

years now, something like that.

Well, we're delighted to have you on the

show. And thanks again for your service. So David, before we

launch into talking about the various findings, and I find

them very interesting. To set the motivation, the context for

the research study, it's a fact that the attack surfaces are

evolving, the more digitized we get, the more we go to the

cloud. And the hackers are not sitting idle. They're constantly

getting more innovative with their techniques, tools,

approaches. So it's a moving target for organizations to stay

on top of things, I find it almost hard to believe that

organizations can be ahead, but if they can, more power to them.

So what was the motivation? What led to this very important study

that y'all conducted?

Well, very much like you said, so we've been

working, Team Cymru, we've been threat intelligence supplier to

the industry since our inception. It's how we began our

business, we used to kind of boast that we were the best

security company no one had ever heard of, because our research

and efforts went into other people's products. So if you're

familiar with a company BASF we don't make antivirus. We make

antivirus better, we don't make firewalls, we make firewalls

better. You know, this type of slogan, if you remember their

advertising back in the day. And that was really the core of our

business and we observe miscreant activities every day.

It's a byproduct of our analysis efforts. It's a byproduct of our

interest in understanding how the internet is used by society.

We happen to feel that the internet is probably one of the

greatest creations mankind has ever developed and we were

looking at kind of how the security world was moving

towards this notion of attack surface management, where they

were kind of blending a few types of technologies together,

which you could think of as your vulnerability scanning, your

asset discovery. And those things were coming together. And

we felt there was an obvious and useful connection for us to be

able to add threat intelligence to it. And threat intelligence,

you know, when you think of it in terms of, of defense, a lot

of people often just think it's, you know, lists of bad IPs or

things like that. But in reality, it also is, if you turn

it around, it's also lists of IPs of yours, that might be bad.

So when you think of like reputational data, and things

like that, so what became obvious to us is, you know, if

you're doing attack surface management, wouldn't it be great

to know what attacks you may have already been subjected to?

And, and to that end, what devices that you already own,

that may already be compromised? So kind of taking, you know,

that idea of knowing how bad things already are to decide,

you know, is this a system that I should patch? Or is this a

system that I need to completely rebuild, because it's already

been compromised. And we saw that obvious need from an

intelligence perspective. But then as we started to look at

ways that we could apply it to kind of the existing

marketplace, we realized that kind of none of the other

products that were out there, were approaching ASM the same

way we were, they were very much looking at things, most people's

tools seemed very much geared towards, here's your IP, here's

a problem it has, here's something you should do about

it. But without really giving the people the ability to

highlight which IP or what device let's let's use the term

device, actually, because the devices just happen to use an IP

address. But But what devices on the network are most critical to

your operation, you know that these tools in the marketplace,

they didn't really have a way to highlight which ones were most

important. And the devices themselves couldn't really tell

you, which was important. So we also sat down and said, Okay, if

you were going to look at ASM, what's the key value piece

there, and what we concluded was that risk understanding the risk

to your business needed to be a piece that was part of it. So

what we've approached ASM as, is the traditional sense. But what

what we have attempted to bring to the market as a new offering,

is the application of intelligence on top of that,

with kind of user definable values for the assets as they're

discovered.

Okay, thanks for sharing. So just to

let listeners know, that, as far as the methodology and and

participant demographics go, the study was commissioned on March

14 2022. 440 security practitioners were surveyed in

the US and Europe, the survey was conducted online via

Pollfish using organic sampling. All respondents work on their

company's security team. And all these organizations are using an

attacks surface management platform. Their industry

representation is also pretty broad, ranging from finance to

IT to military and defense, among others. The team size

varied relatively little from less than 10 to over 30. So

David, would you like to add anything to that from a

methodology and participant demographic standpoint?

Well, we had originally considered making it

split into, you know, additional slices. So to differentiate, for

example, between practitioner and executive, not that

executive practitioning isn't practitioning of a sort, but we

thought it might be useful to split those out. But in the end,

what we found actually was that kind of the bulk of the world

really isn't divided up that way, it's only kind of the

biggest companies that have those kinds of separations. So

when you think of the folks that took the time to fill out the

review for us, many of which are most of which I should say,

really knew what they were talking about. So to kind of

give you that, you know, value of of what their answers mean,

these are the people who roll up their sleeves every day, and

actually have to reach into the problem and do something about

what they find, you know, not just run the tools, but

oftentimes, these were the folks in particular, those smaller

teams, those less than 10 people teams, they were often the same

person who, who helped manage, you know, the patching program

or, or who helped manage their inventory systems and things

like that. So value wise, these people's opinions are not

speculative that they are the practitioners who were largely

responsible for making things happen based on the findings.

Okay, good to know. Good to know. So let's

discuss some of the finding. There are several interesting

findings, not sure how much time we'll have to go over all of

them. But we can definitely cover some. The first one that

I'd like to talk about is the biggest reason organizations

implemented ASM is to increase the visibility of Shadow IT in

the enterprise, I think this is very significant, if you would

expand on this and also describe what Shadow IT means to the

listeners.

Sure, absolutely. So, you know, Shadow IT is a

side effect, more or less of what you could think of as

necessary growth. So organizations oftentimes have

disparate teams that are spread out in function, but you know,

typically working towards the same goal, you know, keep the

company open, keep the company in business and so on. But what

ends up happening is, as needs change, in particular needs in

the scope of being able to spin up new infrastructure very

quickly, and things like that. A lot of companies don't, don't, I

don't know what the right word is, I don't want to say don't

like to, because obviously, they would, they would prefer to do

it the right way. Um, but a lot of companies find that like

policy around asset controls, hinder or stifle innovation. And

then whether it's real or not, whether that's true or not, you

know, we can't really speak to that I'm sure that some kind of

psychology of the human work experience, but in actual

practice, though, with with certainty, organizations are

hesitant to, you know, have to talk to the IT team, let's and

let me use a practical example. So you have a software

development team who has the need to work with some temporary

data, they don't want to work with data from some live

production database. So they need to set up, you know, a

secondary, you know, temporary database. And these folks, you

know, oftentimes will spin up an instance in a cloud, or, you

know, maybe some new VM even within their infrastructure, but

they'll spin it up, they'll put data for use in that, and then

they'll make use of the project, right? Well, if your main IT

team is unaware that someone on the development team has done

this, you now have an asset that is not under centralized control

isn't, but the organization itself isn't aware of it. And

it's full of, of data, you know, and presumably, if you're

spending the time to develop software to interact with that

data, that data must be important. And we read about

this all the time you read about so for example, Amazon S3

buckets, right? There are these virtual storage instances that

people can spin up very quickly and put information and for

various purposes, right. But it's think of it as file

storage. And there are tools that you can, you know, you

could pull up your favorite search engine and put in and

look for, you know, Amazon S3, open bucket finder, or

something. And you'll see almost every day that there are people

who have left these instances open, so meaning no

authentication, and anybody in the world could identify it,

download the data and do something with that. So this is

kind of the traditional understanding of Shadow IT

right, it's these things that get stood up that people may not

necessarily wholly know about. The organization itself may not

be completely aware of. And the reason why it's such a big issue

to folks is precisely the example I gave data ends up

getting exposed this way. And not just, you know, random data,

who we're talking often legally regulated data, you know,

whether it be personally identifying information, whether

it be health records, whether it be financial information, I

mean, all kinds of stuff gets leaked out this way. So our

intention for this with asking folks that was to see if our

capability, how much effort we should really apply to doing

this Shadow IT identification, because it's not easy, right?

How do you how do you help somebody find something they

didn't know they had? It's not an easy problem. So that was the

reason for us to ask. We saw how many data exposure notifications

go out. If you ever noticed, by the way, those are never

discussed, described as breaches, which if you think

about it, it's it's kind of interesting, the choice of words

that people use around those, but those, quote unquote,

exposures do add up to a great deal of loss, both in terms of

productivity, but you know, every time PII personally

identifying information is exposed, there's a lot of times

where there's government regulatory components on there

where you have to go notify people, or perhaps even a

company has to now provide credit monitoring or identity

monitoring, you know, based on what type of data was that was

exposed. So those kinds of costs were very, very real. And so

that we weren't surprised to hear that so many people

considered Shadow IT to be such a big problem.

Yeah, I mean, doesn't surprise me either

because as as you discussed, Shadow IT gets formed, gets

created because certain divisions, certain parts of the

organization wants to get certain things done. And for

whatever reason Central IT is not able to respond in time or

as per their expectation so, and for other reasons as well. But

that creates a problem in terms of data exposure, and you really

cannot defend effectively if you don't know where all your

vulnerabilities are, where or where your data is residing,

where your applications are residing. So it's great to know

that there is a high level of sensitivity towards towards this

challenge. And one of the capabilities of ASM should be to

increase the visibility of, of Shadow IT. So that's, that's a

very significant finding. Moving along, another finding that got

my attention, which is not surprising, but it it validates

the fact that more and more applications and infrastructure

are in the cloud, and which is what 75% of your respondents

said, but what is interesting to me is the statement here in the

report, which says "ASM, which stands for attack, surface

management, is critical for all organizations, regardless of

their cloud adoption, but should be an even higher priority for

tracking and managing the attack surface for cloud hosted assets.

So I guess my question for you, David, is, and you obviously

have a better understanding of the evolution of the ASM

platform, over the years have they have they enhanced their

capabilities to better monitor cloud hosted assets? Is that

what's been the trend?

Well, you know, unfortunately, not really. A big

component to this is kind of the discovery problem. And how most

vendors choose to remedy this is either by IP space, so IP

addresses, Internet Protocol address that people use to be on

the internet, they are defined and issued out typically, as

network address space, you'll get a range of IP addresses, or

they will tend to classify their assets based on namespace, which

typically is in internet terms would be something like DNS,

where DNS, you put in your domain name, let's use an

example, you know, foo.com. And as you add things in the form of

subdomains, or host names to that, in theory, they start to

become discoverable. Where the problem with cloud computing

comes in is, you know, when you license your ASM product, you're

not going to go out and license a product for and I'm not trying

to pick on AWS here. But Amazon's AWS services, one of

the world's largest and most popular cloud hosting services

in the world, but you're not going to go license an ASM

product to scan the entirety of their IP space, is just not

realistic. So you have to know your IPs. And again, it goes

back to this problem of you know, how will you know, which

are yours. In our case, we also well, we work with IP addresses,

obviously. But in our case, we because we are an intelligence

provider, we see a great deal of information already, in

particular IP, IP space, as well as namespace. But we also see

things like certificates and keys and all this kind of

additional metadata that the internet kind of operates on. So

we saw it as kind of an an easy evolution to help do these

discoveries that nobody else really had. Because the other

products are requiring the user to know in advance all of their

things. Shadow IT by definition means you don't know that you

have some of this. So you know, it's an approach, frankly, that

starts off already hindered. So what we how we change this as we

look for, you know, other instances, and other examples

that we've identified through our other threat, exploring and

threat hunting efforts that appear to be related to other

people's organizations, and we try to highlight those kinds of

datasets to better inform the discovery model.

Okay. Thanks for sharing. Moving along

to another interesting finding, which states that 23% of the

respondents said that identification of rogue or

unclassified assets is the most valuable capability that ASM has

provided their organization. I guess my question here is, you

know, shouldn't this be obvious? Shouldn't that be what an ASM is

supposed to be doing?

Yes, it certainly is exactly what ASM should be

doing. And and I think this highlights the shortcoming that

I just described, right. So the reason why only 23% of them said

that their application of of ASM in their workplace was that

effective at discovering those things is because the rest of

the respondents, you know, the remaining 77%, they are clearly

limited, because the only thing that ASM knows about are the

things they already know about. So if you already know about it,

it's unlikely for something to be rogue or unclassified. Right?

So this kind of static discovery approach, this is the fruit that

comes off that tree, when you take a non dynamic approach to

understanding assets in a very dynamic environment. That is

what I would call modern, you know, computing, you're going to

end up with low numbers like that, because the rest of them,

their tools probably just don't identify rogue devices. And

that's an unfortunate side effect. Again, this was one of

the motivations that led us to to create a product for the

space.

Okay. Now, you know, some of the findings

speak to the challenges of deploying and implementing ASM

platforms. And these challenges range range from lack of

integration with existing platforms, the amount of

training that's required. And also I found it interesting,

where organizations where the respondents said that they feel

that the current platform has become more of a legacy. So my

question to you is as follows When an organization is

investing in an ASM platform, they know fully well that at

some point, it will move towards becoming obsolete. I don't know

if obsolete is the right word, but what steps should an

organization take, should the security analysts, the security

professionals take, to ensure that their ASM platform is

performing at a satisfactory level?

Well, I think the initial steps are are

introvertish. Introvertal steps right? So you have to ask

yourself, Do I know everything about my network? Do I know all

of the devices I have? And if that answer isn't an absolute

certain, yes. Which a hint to the listeners, It isn't. Then

you have to approach the tool sets as am I going to have a

tool that's going to show me things I didn't know to know.

And that, in my opinion, is the killer feature, way more

important, in my opinion, is discovery, then even say, the

vulnerability management and discovery component, right?

Like, if you don't know, to know, then you won't, won't get

any benefit from it. But if you do discover something that's on

your infrastructure that you didn't realize was there, or

that is your system is reliant on, because there are a bunch of

non system concerns as well. Like, for example, you know,

every is every person's network, they get onto the Internet by

way of a set of internet service providers. And what about the

safety and reputation of those folks? You know, if your tool

can't tell you that your DNS hosting provider has a poor

reputation, or that your internet service provider, you

know that the IPs around your IP services are bad. If it's not

able to show you these kinds of things, then it suggests that

you are probably working with something that is, frankly, like

I said, antiquated of some sort. But frankly, let's use the word

static. And if it is static, I think in the information age,

that should be a huge red flag to you. That if this tool

doesn't teach itself to some degree, and I'm the operator is

responsible for informing this, that I probably have a tool that

is not future proofed? Not that our any tool is completely

future proofed, right. But there are certain methodologies that

can help assure a future proofed capability. And this kind of

dynamic discovery is absolutely one of those capabilities. But

in the end, I think practitioner, or decision makers

need to ask themselves, how much is this tool teaching me that I

didn't already know. And I'm not talking about you know, that you

have a vulnerability on some device you already knew you had.

I mean, how much infrastructure is it really exposing to me that

I didn't know before? And even inadvertently, you know, if,

like I said, maybe someone plugged in some new device on

your network. If it's not at least catching those types of

things for you, then I would say you have an older tool,

Right, makes sense. And I'm glad you

mentioned about the self learning capability. So to what

extent is AI being used to enhance the functionality, the

capabilities, of these ASM platforms?

So in our case, we're not really using AI. Not

that we're against AI per se, but we didn't really see a great

need for it per se, relative to machine learning and machine

learning sense, you know, where there's a human who is, I guess

suggesting, to the system, what it should be doing, as it's

doing it, as opposed to AI where they become somewhat autonomous,

you know. So, in our case, though, is a great deal of what

I would call machine learning, where as assets are discovered,

we look at kind of the nuance of that asset, both from a service

level from an IP level, and then from like, what the operating

system looks like, think of it as a very signal focused view,

internet signal that is, and we use what's discovered to kind of

inform the next level of discovery. So for example, if we

discovered a new, you know, domain within your namespace,

say, you know, again, using this foo.com example, but let's say,

yesterday, you didn't have www.dev.foo.com. And today,

we're seeing that name being looked up in passive DNS data,

we know that you have some new asset out there somewhere, and

can then start to go looking for it. And that type of informed

learning is precisely how we approach this, but it's a

continuous thing, you know, what happens 24 hours a day, we

continuously learn about the surface of the internet as a

whole, for that matter. But in particular, you know, of the

asset tools for folks. And then those assets, as we kind of

learned from them, we go to look for similarities. And we say,

Okay, what's just like this, but maybe, you know, isn't

previously known. And we show you, hey, here's these potential

things that we think might be related to you. And we let the

the individual decide like, Oh, this is related to me, or Oh,

no, this isn't me, but sure looks a lot like me. Maybe this

is a phishing site or something, you know, there are other

approaches and other outcomes aside from your own attack

surface, you know, that you can discover using the kind of

machine learning metal method that we use. But I don't know

that AI will ever totally get there for what it's worth.

Because I, I still think that when it comes to ASM, the human

component is required, like aI won't know the difference,

unless you share with it all of your client configurations, AI

won't know the difference, for example, between your primary

active directories host and some dev Active Directory host. So,

they will both appear to be running the same services. But

you as the human know that one of them has your actual users,

and maybe another one has dummy data. So you can prioritize and

say, Ah, this IP, this host, this asset, is my actual Active

Directory directory server, whereas this other one is not.

So don't show this as a high risk show this other one as the

high priority asset. And for that reason, I don't know that

AI will ever really fill in in this role. But we'll see.

Okay, good to know. So talking about the

human component, and in this discussion, we have been talking

about attack surfaces, more from a physical standpoint, devices,

and so on, so forth. How about humans as attack surfaces as

very vulnerable attack surface? What are your thoughts about,

you know, you know, are we doing better in terms of securing that

very vulnerable attack surface? Can tools help us secure that

attack surface? What are your thoughts?

Well, I hate to be a naysayer. But things aren't

getting any better there, it seems. If you look at the SANS

survey comes out every year, if you look at the US government's

breach report, or Verizon, they they publish a report any of

these reports, if you go look at them continuously, for the last,

you know, I mean, since forever since these reports have been

produced, the number one compromised source is still

stolen credentials. And the number one method for that is

still some type of phishing, or some type of social engineering

still, so nothing seems to really be changing there. The

tools and the tactic techniques being employed to gain access to

this type of information, haven't really needed to change

much, because the human element is still you know, largely the

same. And I say this all the time, until listeners who may

have heard me on any other podcast or may tune in who or

who happened to listen to ours, probably have heard me say many

times, but we still work and live in a world where everything

is kind of magic. And the majority of people who are

relying on technology, still have absolutely no idea how it

works, and therefore can't really spot things when they

aren't correct, right. And for the longest time, vendors tried

to implement methodologies like if you recall, you know, It was

always look for the lock icon in your browser window and make

sure that that's always there. And so miscreants just started

to put a block of the locked lock icon right on in the

content of a phishing effort. And people would say, Well, I

saw the lock, so I figured it was safe. And here we are. And

I'm not talking about fools here. I'm talking about, you

know, Board members and C-level operators and decision makers,

you know, around the world, in the largest companies in the

world, the most capable, most successful people in the world

still fall victim to this stuff. So unfortunately, I just don't

know that any of that can be changed, either, you know, where

we move to these concepts like zero trust, or you look for the

behaviors of of specific devices and try to key on that. But

realistically, by the time you're keying in on a behavior,

it may already be too late, right? So the stolen credential,

the credential reuse, so you know, what, however you want to

call them, there's variations of, of the methodology, the

attack, but they all come down to an imposter, if you will.

That still turns out to be, you know, if not, number one, top

three, year after year, way, way back, I remember when it was a

tax where like buffer overflows were the primary method, and

people were, you know, looking for at the software stack, for

what waves to gain entry. And then along the way, somebody

figured out that we don't even need to talk to machines, talk

to the people, and that people will just give you access to the

machines. And that hasn't changed. And unfortunately, I

don't know that it will change. We look to incorporate that type

of intelligence, though, into our ASM to let folks know, you

know, when they have account level risks that are there,

we're looking to add that capability as well.

Awesome. That's awesome. Yeah, I think

that's a very difficult challenge when you're trying to

secure every individual that works for an organization,

whether it's through training, or whether it's through some

some some sort of technology. So that's, that's a very big hurdle

to overcome. But anyhow, moving along, so we've had the chance

to discuss some findings that I found significant or

interesting. Are there any others? Or is there anything

that you'd like to address that you found interesting, or

something that surprised you all?

Well, one of the things that surprised us, I

think, was something that I touched on at the beginning of

our conversation here, we were kind of surprised that we that

we weren't able to just apply intelligence to kind of the

tools that were already out there, we thought we thought it

would be it would be possible for us to like find someone we

could kind of go with our typical business model, which

was being intelligent supplier, we were kind of surprised to see

that none of the offerings out there really met what we felt

were what you would want in the marketplace as the, you know, as

the consumer. And we were surprised that by that because

we weren't in the space. You know, there were already lots of

expertise in the space. There's a lot of people out there who

already have these types of tools, but they weren't seeing

the problem the same way we were. And we're not totally sure

why that is. I'm not, you know, proposing were geniuses or

anything like that. In fact, I can assure you we're not. But it

was interesting to us as intelligence practitioners, how

we saw the world as opposed to say, security practitioners. And

when you think about ASM, you think attack service management,

you automatically think in terms of security, but really what if

you really think about it, ASM is an intelligence tool. ASM is

is being self aware is some type of self aware intelligence

capability that you then key on to other capabilities to the

backup. So as you learn something new, aka as your

Another question that comes to mind

intelligence increases, you then have some action to do. So

perhaps it's vulnerability scan this device, perhaps it's

updated inventory management component, perhaps it's disable

the switch port that the device is plugged into, if you can,

because it wasn't plugged in there yesterday. And it's, you

know, not an authorized device. But any way you look at it, and

regardless of the outcome, that initial step really is an

intelligence step. And that was kind of surprising to us. And I

think it's a side effect of like I said, our approach has been

for lack of a better term intelligence applied to

security, as opposed to security applied to asset management. And

so because we kind of approached it from that step back, I think

we came up with different what I would call killer features, you

know, for something if we were going to make it and then the

end result when we went out looked to see, you know, to make

sure there was really nothing out there like it and discovered

there wasn't. We were kind of surprised by that. Because like

I said, we were you know, I wouldn't say we're late to the

party, but we definitely weren't first people in the ASM space.

based on attack reports that are published in the media, where

So that was kind of a surprise to us.

often times organizations are accused of not promptly reacting

or responding to alerts that they receive from various types

of monitoring tools, technologies, service providers,

various types of intelligence sources. So, going back to this

platform, the ASM platform, which obviously is there to help

organizations have a better understanding of their attack

surfaces provide advanced warning. Now, have you all

thought of a feature whereby, you know, there is some kind of

a logging that certain alerts certain notifications went

unheeded, or went unresponded? Or there is a, there's a way of

notifying multiple personnel just to make sure that this, the

signal doesn't get go unheard? Or do you see my question from

where I'm coming?

Yes, absolutely. And we have, so we're not trying

to reinvent the wheel at every turn. So an AR capability, we

have, obviously, incorporate the idea of external API's so that

you can trigger to, you know, specific systems, or if nothing

else, at least, have the notion of roles or groups within the

tool so that if a specific category of event happens,

notify a specific group of people. Exactly. Yeah, of

course, those capabilities are there. But what we really think

is one of the key differentiators, at least for

our approach is this ability for individuals to prioritize assets

themselves, so that you're not, so that you're not required to

react to every "high or critical event," because you know, not

every device is created equal, not every service is equal. And

frankly, there's only so much time in the day. And if you have

to pick between defend the mothership or defend a rowboat

out in the dock, you know, you're going to defend the

mothership, hopefully. So your tool, if it's not aware that is

going to be that's going to be a problem. So we've approached

them in the terms of both communication level, tuning,

group and role tuning. And then also asset prioritization tuning

as well.

Fantastic, because that's been one of my

concerns, one of my pet peeves, that if you have access to all

this intelligence, access to all these tools, you must have a

good governance system in place where you're paying heed to the

alarms that are being raised. Talking about governance, this

is my final two part question to you. Okay. So let's say an

organization decides to buy or invest in a new ASM platform, as

we all recognize that just investing in a tool is not good

enough to extract the maximum value from it. There is a people

aspect to the implementation, there's a process aspect to the

implementation. So if you had to make recommendations to

potential buyers, or investors of this platform, what does it

take to prepare the organization, so they can

effectively use such a platform, what would you say?

I have a very simple answer to your at least

the first part there, and that is the will to do something

about it. You mentioned compliance, regulatory typically

is that you know, these kinds of policy concerns are usually what

drive people implementing ASM solutions. And those external

drivers are rarely effective motivators, in fact, there are

whole own entities and organizations that carry

adequate insurance to pay the fines for non compliance,

because they wholly expect to be out of compliance because they

consider the compliance component, a burden. So the

first thing that I propose is that be willing to do something

with the findings, you know, don't approach ASM as a

something that you have to do because someone else said so.

But recognize that someone else said so because what you do is

important to the world, to society, to people, you know,

perhaps even you know, to relatives and things like that.

I mean, and think of the impact of what happens if you turn this

thing on and discover that you have something bad going on? A

lot of people are hesitant to turn on a tool like ASM because

they know what's going to come out the other side is going to

be something they're gonna have to do something about. And I'm

not saying that people are lazy, but I will tell you that only

bodies in motion tend to stay in motion, I think is the is the

adage, right? So if bodies aren't in motion to begin with

going and getting an ASM tool isn't going to set them in

motion at all. So my number one advice to anybody considering to

go down the path of implementation of ASM is one be

willing to do something that you find but number two, be willing

to actually use it because it's going to make your job easier,

it's going to make your life easier. And kind of taking the

ostrich, you know, head in the sand approach that doesn't help

anyone. And like I said, think of the people using the service.

Think of why it is that you're running the service to begin

with. Think of those people think of that money, think of

you know, whatever is the driver, but think of that stuff

and ask yourself, how important is this to everybody? And how

willing am I to keep it working and keep it going, and ensure

that willingness is present and communicated to all of your

staff, you know, if you have people, maybe as this tool turns

out work to do, if you have a bunch of other people there that

are going to have to be doing the actual work, make sure that

they understand make sure they are all bought in. But I know

that's a silly answer to a technical question, because it's

not technical at all, if you will, the answer is not

technical at all. It's it's human will. So sorry, that was a

very verbose thing to what I had warned was going to be a simple

answer, but simply have the will to do something about it.

Well, I think that's a very sound

advice. It's a very wise answer. And that's what most

organizations struggle with. It's the softer side of things

that organizations struggle with more than the harder side of

things, not trying to suggest that implementing technology

effectively is any easier, but providing the appropriate

governance, around technology implementation around leveraging

these tools can be equally if not more challenging. And I want

to reiterate what you said about having the will having the

commitment. In my book on Cybersecurity Readiness: A

Holistic and High- Performance Approach, one of the top

cybersecurity success factors, which I share in the context of

the framework that I propose is the top management commitment.

Another related factor is creating and sustaining a

We-Are-In-Together culture where everybody gets involved. This is

just not the SOC team that can make miracles happen. Everyone

has to play their role. So taking this example of the

attack surface management platform, obviously, specialists

will be running this platform, and they have to be adequately

trained. Because if you don't have good training, you can't

get most out of these platforms. But then, as you mentioned, when

you get those that feedback, and I love what you said,

oftentimes, we don't want to probe in a certain direction, or

we don't want to invest in certain things, because we don't

want to know what we don't know. You can go with it in many

different ways. I don't want any further education, because that

will enlighten me on my lack of awareness, right? Absolutely. So

so here we go in the context of ASM, you are investing in it

because you truly care. Because you truly want to do your part

in trying to secure as best as you can, we all understand that

you cannot secure everything and that you will never be in a

situation where your systems can't be compromised. But you

know, putting your best foot forward and doing everything you

can, and constantly monitoring these devices constantly making

sure you have an oversight team, you have a incident response

team or why by whatever name, you may want to call this team.

Bottom line, again, it boils down to asking yourself, the

fundamental question we've invested in this platform, are

we making full use of it? Are we getting what we wanted from it?

And if there is a deficiency, what is it? And how do we

address it? So that kind of active proactive approach is so

so critical. So David, we're running out of time, I'd like

you to share some final thoughts.

Yeah, so much of what we've said today, probably

sounds somewhat elementary to folks. And I'd ask everybody to

kind of consider why that is, like, why does something so

obvious, or seemingly obvious, you know, once it's explained to

you, why is it still so rare? And why is it? Why is it's not

happening in broader scale? And we should ask ourselves these

questions, because we are the people who are the solution,

right? Even if we're just the user, we can go ask the provider

and say, Hey, why are you why are if you're not doing this?

Why Why aren't you and start to kind of apply that, you know,

upward pressure and everything that we're doing, because, like

I said, we're all reliant on technology, this is not going to

go away. I mean, barring some type of Corona event where you

know, we have a sun flare, knock everything out, you know, we're

we're in this for the long haul, you know, capitalism alone is

going to drive things towards lower cost solutions. I mean,

that's just that, that's the direction of that energy. And if

we're not looking at it as an I don't, I'm not trying to paint a

dire picture. But if we don't I paint it as a very, very serious

component of our entire existence, I fear that we're

going to miss something. So when it is that, you know, someone

comes along and kind of upsets a space, arguably, as we have with

these new capabilities, we should ask ourselves, why why

why is that? And? And if that was like that, what more could

we be doing? And of those, what more's, how many of those things

are unknown. So like, if you're out there, and you have an idea,

you think like, oh, man, you could even then go add on to X,

Y, or Z, share that idea, or start up in a solution, because

frankly, the world needs it. We're getting more and more

reliant on technology, more and more of our whole life, data

wise, is stored electronically. And for us to be such so reliant

on something that's seemingly under constant attack and

continuously growing, and just, you know, out of hand, we should

be asking, you know, is everything being done that we

could, and I don't mean just asking of ourselves, but like I

said, we should be asking the people that we take services

from, you know, what are you doing to secure my things that

you, you know, have possession of? So I know, again, that's

kind of, you know, the lofty answer, but I think it really

does, it comes down to mass participation, like you said,

it's that we can do attitude, it's absolutely critical. We're

all subject to the technology. So let's at least make it work

to our will. And that's, that's what I think would be a bright

future. And if everybody got involved, including just every

user, so absolutely,

Absolutely! Well, David, this was great.

Thanks for your time, for your insights, I know the listeners

appreciate it.

Thank you Dr.

A special thanks to David Monnier for his

time and insights. If you like what you heard, please leave the

podcast a rating and share it with your network. Also,

subscribe to the show, so you don't miss any new episodes.

Thank you for listening, and I'll see you in the next

episode.

The information contained in this podcast is for

general guidance only. The discussants assume no

responsibility or liability for any errors or omissions in the

content of this podcast. The information contained in this

podcast is provided on an as-is basis with no guarantee of

completeness, accuracy, usefulness, or timeliness. The

opinions and recommendations expressed in this podcast are

those of the discussants and not of any organization.