Welcome to Hard Problems, Smart Solutions, the Newfire podcast, where
we explore complex challenges and innovative solutions with leaders in
the healthcare industry and beyond.
I'm Will Crawford, Head of Advisory Services and Chief Technology
Officer at Newfire Global.
And your host for today's episode.
In each episode, we engage with top innovators and decision-makers,
talking about some of the toughest issues across industries.
So whether you're here for fresh insights or to learn from the best, you're in
the right place, and let's dive in.
So today, I'm thrilled to welcome Laura Louthan, founder of Angel
Cybersecurity and a seasoned virtual CISO.
Laura specializes in risk assessment, IT compliance, and innovative
information security strategies.
She has over 15 years of experience and some really notable roles at major
companies like Sephora and Equifax.
Throughout her career, she has successfully built secure, compliant
infrastructures, managed third-party risk, and crafted effective and
budget-conscious security solutions.
We've gotten to know Laura here at Newfire over several years while collaborating
with her and with some of her clients.
So, I once had an entrepreneur tell me that they wished they'd invested
more in security and compliance when they were just starting out.
Uh, but he also said that all the companies that did make that
investment didn't actually make it.
Uh, so when, like, when building a company, every decision is
about maximizing your resources.
Uh, so today I wanted to talk with Laura about how you can maximize the
impact of your security program, uh, without spending a fortune or at least
without spending a fortune at first.
So today, we're going to discuss how businesses can approach security
challenges creatively and effectively even if the budget's a little restricted.
Uh, Laura, welcome to the podcast.
Thank you.
I'm looking forward to it.
So, data security in healthcare is an increasingly complex challenge.
Organizations are constantly trying to balance protecting patient information,
being regulatorily compliant, uh, but also facing a very, uh, adaptive
and complex, uh, risk landscape.
Uh, but before we dive into all of that, can you just tell us a
little bit more about your work?
And what's your mission, and what drives you to help organizations tackle
some of these security challenges?
Sure, so I have been a vCISO now, so virtual CISO or fractional CISO, however
people want to call it, for, it'll be eight years, uh, this coming April.
And, so I started doing that in 2017, and I was in, uh,
full-time in security since 2011.
And then, I was in IT before that for really, uh, uh, very many, very many years
going into the previous century, which is just weird to say, but there it is.
So I've been in the tech world for a long time, um, and I really do
like being in the virtual CISO world because we probably all know people
that work in big organizations, big organizations that both need and can
afford full-time security people.
But there's just this huge, there's a plethora of these small organizations
that hopefully know they need security, or at least if they don't, I will tell
them they probably need some security.
And, you know, there's a real opportunity to right-size the amount
of security you give to people, so that it's not more than they can take.
And I would say that's probably one of my approaches is to make sure that,
that you're only giving people as much as they can stand, and that's both from
a budget standpoint and also a kind of culture standpoint and just being
pragmatic about what's a possibility.
Because there's absolutely no point in trying to boil the ocean
if you're a small organization.
I've been doing, uh, so with the vCISO thing, what I do is I'm
typically there to build a security program in some shape or form.
So there's either no security or little to no security.
There's probably nobody in the security team, no full-time security people.
There's probably some poor soul who's been given the job of being the primary
security person and is probably on the paperwork as the information security
officer and is likely in charge of the tech in one of the areas or is the best
software engineer that knows the most about security or whatever it might be.
It could be anyone.
And so what I will do is work with everyone in the team.
So work with the businesses, uh, the business leaders and work with the
leadership and work with the technical teams, work with the HR teams if they
have them, and again, a lot of my clients are not big enough to have HR
people either, and just help set them
on a path to becoming more secure, because no one is ever completely secure.
A lot of people are probably completely insecure.
And so just getting from one end to closer to the other end
is, is where I head typically.
So, what advice would you have for, I mean, and I've been that
person who became the security officer, whether he liked it or not.
What advice would you have for people who are in that role?
I mean, obviously I'm selfishly going to say is that you shouldn't
try and do it all on your own.
A little bit like with, you know, Newfire and obviously we've had, uh, mutual
engagements where people have said we don't have the right software engineers
or the right DevOps people, we're going to look to people that can provide us
with that expertise that's not us, right?
And so, if somebody knows it's not them, that's actually a really
great place to start, right?
If you know it's not something you do.
I do not fix my own car.
I probably could tinker with it and break it worse, but it's not practical.
And so, you know, there are a lot of vCISO organizations.
Um, there are a lot of IT outsources that do things like typically
look after laptops and stuff that, and a lot of software vendors
that are selling vCISO services.
I think I probably have mixed opinions about those, but there's a lot of people
out there that, that the thing that is a vCISO is becoming much more common now
because there's a great market for it.
People need a little bit of us.
They don't need a full-time us.
And so they can reach out to a trusted partner or a trusted colleague or somebody
that says and say, have you ever reached out to someone for a little bit of help?
And then they can start that process from there.
So, within the healthcare space, I mean, is there anything that you've
worked with a lot of healthcare companies, as do we here at Newfire.
What sets those organizations apart, and maybe the flip side of that
is, what doesn't set them apart?
Obviously, the first thing you think of when you think of healthcare
is you think of patient care.
But it isn't always that, right?
There's a lot of healthcare adjacent.
So they may be providing tools to then sell on to healthcare organizations, so
they're not providing direct patient care.
They may be providing direct patient care.
But ultimately, what, what they're all going to have in common, most likely, is
that they're going to be having to deal with protected health information or PHI.
They're probably also, uh, particularly in America, going to have in common
these large payers as the covered entities who are going to sign them
up with a contract that says you are taking appropriate care of the PHI to
meet all of these regulatory frameworks or best practices or whatever it is.
So what they have in common with each other is the PHI problem.
What they have in common with all smaller organizations is there's
some data security that needs to happen of some shape or form.
And actually, when you look at something like HIPAA frameworks,
the HIPAA compliance framework is not a particularly high bar.
I mean, arguably, you have to take better care of credit card data,
which it sort of doesn't make a lot of sense, not in all respects.
They are going to be held to a high standard by their ultimate customers.
And for my clients, I'm typically working with B2B clients.
So they're going to be held to a high standard by people who won't
really accept much leeway in the, listen, we're not doing it now, but
we will be, we promise in six months.
So for the small organizations that are starting out, really the sooner you
get your security staff in place, the easier those conversations are going to
be with those big potential customers.
And maybe to go a little deeper on that, so what's worked well for you
supporting your customers in that sales cycle with those B2B customers?
I think one of the advantages that I have over possibly internal experts they
may have at the organization is that I've been on both sides of the coin.
I am for them asking their potential vendors the security questions and
doing the due diligence and just seeing if the report, puff the sniff test,
and you know, there's just like with everything else, there's a certain
amount of due diligence you do if you're a very small organization.
And if you're a very large, very regulated organization, you're probably going to
take a little bit of a heavy hand with it, but just someone really understanding
why the question is being asked, because I've also asked that question.
And so understanding the intent behind the question and then understanding
what's the best way of getting my client
to meet the intent, which is ultimately being around being secure,
but there's various levels of that.
If I just pick a sort of very lame example, there's a question, let's
say, that says, all your hard drives must be encrypted in your laptops.
So everyone says, okay, yeah, Rob, fine.
Well, we'll roll out a tool and we'll do that.
But why are they asking that, right?
We all know they're asking that because if your laptop gets lost, uh, you don't
necessarily, and it, and you can prove without a doubt that it's encrypted that
just gets you off a whole lot of hooks that you don't want to be on, right?
So understanding why each control is there and it helps also that I had
probably about 20 years in IT that um, I just get where they're going with that.
And then it means that when you're on a call with the let's say the large
insurance company's security team, and they ask the question, you understand
why they're asking the question, you understand what answer they want to hear.
And I'm not telling anyone an answer they want to hear if it's not true,
but there are definite ways of getting to the point in a way that gives
people a better level of comfort.
And also being very frank about things that maybe aren't in place,
with equally a way of saying, and here is our plan, because if I know
that they're going to have something fundamental that's not in place, I'm
going to make them come up with a plan.
We want to get there, because it's just, it's all about, ultimately,
it's all about securing the data.
But for the small organizations, they've got to sell those contracts
to buy, to get the money, to buy the stuff, to secure the data.
It's not like they've got 10 years of capital funds that, that are
going to come into play there.
I had my list of questions here and I'm going completely off
script because everything you're saying is triggering something.
So I'd love to hear about the flip side of that, which is actually educating
the workforce at your clients about the importance of security and why some
of these things that might feel like they're going, they're jumping through
hoops, whether it's mobile device management on developer laptops or
having to re-login to Microsoft Teams every 15 minutes is actually high value.
So how do you educate employees on the importance of good security practice?
It's not always easy.
I'm not going to say security awareness training because there's all
sorts of mixed feelings about that.
And obviously it's good.
And security awareness training helps people become more aware
of security in their personal lives as well as their work lives.
So it's never a bad thing.
But it doesn't typically, it's typically generic, and it doesn't
typically say, okay, company X, here's why we're doing this.
We're not just doing it because our potential client Y is going to ask
us if we are, and we'd prefer to say yes than no, but also because
if we do this control, then this backs up with control, and ultimately
it boils down to risk mitigation.
Part of the problem about being a virtual CISO, though, is you're typically
directly working with a much smaller team.
When I was a full-time CISO, I'm going around people's desks and
leaving them literally little presents going "don't forget about security."
Um, and I'm involved with different teams and helping literally buy
software for different teams if they, in exchange, would help some
of the projects I was working with to, to mature the security program.
So, it was absolutely total bribery, that's how it works.
I had a budget and I needed their help so we just made a little bit of bargaining.
And that kind of relationship building I don't get to do for most
of my organizations because I'm typically working with a core team.
And they will say "reach out to Laura, Laura's our, our vCISO if
you have questions," and sometimes it happens, sometimes it doesn't.
But I think the main thing is about the clients I have.
If they've reached out to me, it's because somewhere, somewhere along
the line they've understood that security is something they need.
It may well be a third-party influence, like it may well be their big client
that said you have to have a SOC 2 or an ISO or whatever, or they may
have had a breach of some sort or a security event of some sort that's
kind of put the frighteners on them.
And so typically they're in a sort of frame of mind where they're
wanting to get better, right?
Or to improve.
Um, and hopefully that spills out, um, to the rest of the teams.
And we do, we will do, uh, targeted awareness messaging.
So I'll get someone, whoever's the most, the most senior person in my leadership
team that I work with directly, to send out an email, which I have basically
written that at the end says, reach out to Laura, if anything, 'cause I want
to try and get in there and wrinkle my way in, wrinkle my way in somehow.
So they know I'm there.
So picking up on that theme, can you think of any organizations that
have done a really good job of tying security into, into an overall mission?
And I think in healthcare, of course, there's lots of opportunities to do that
because of the impact ultimately that these companies have on patient care.
Realistically, the most recent kind of blatant issues that we've had coming
out from a standpoint of security issues have been from healthcare ones.
Because if there was a major ransomware issue in a pencil making shop, nobody
would care because everyone's much more concerned about what's going to happen
to their data if somebody might know that they've got some medical issue that should
forever remain unpublic and now won't
because that data has been compromised.
Even Microsoft was saying that they're all about security and then they had
the issues with the logs that they had recently and some other stuff with keys.
And so everybody is struggling with it because security is quite hard.
And the main thing is that if I think every organization should
be proud of themselves, if they really can genuinely feel that their
stakeholders, which include employees and everyone in a flow has at least some
understanding that security matters.
So whether it's through periodic messaging or whether it's through encouragement,
there's a lot of historical problems with security being the kind of naysayer
and the grumpy people in the room and getting security out the punishment corner
into they, listen, this is, a business driver for us, or if nothing else, it
might be a marketing advantage for us.
And so, I think if they can help make people not feel punished by
security and supported by security, that's going to be a win somewhere.
And I don't know if I could particularly name one, but I'm sure
there are a lot out there who might recognize themselves in that comment.
I hope.
I had someone suggest to me once that their company run a marketing
initiative around how secure they were.
That sounds dangerous.
Do you think that would be a good idea?
Well, probably no, because the thing is, the minute that you say, "oh
my, aren't we so secure," something bad's going to happen, either because
someone's going to pick on you for saying such a foolish thing, or because
Sod's Law, as we would call it here.
I don't think so.
I think what you have to do is you have to back up those kind of statements
with, we have got a, independent audits, uh, from a variety of auditors, we are
constantly making improvements because if anyone ever thinks that they can
rest on their security laurels, they're really going down the wrong path there.
And from a standpoint of when I am talking to potential vendors and going through
the security grilling of when I'm doing the grilling as opposed to the one being
grilled, I just want to know, do they have someone or a team there, depending
on the, you know, the size, depending on the appropriateness of the size of the
company, that really understands what they're trying to do, and they may not
have done it yet, but if they say, "no, listen, we are not doing infrastructure
as code and running it through some kind of security review, but we really
plan to, we've got it on our list" and it might be a complete fabrication, but
at least they know what you're asking
and they're trying to get there.
And it's that kind of thing is nobody is completely secure as I've mentioned.
I have talked a lot in my days and actually when I had my previous
full-time job was about the security maturity swoosh, right?
So the little swoosh, the little hill.
So little organizations are typically going to be on the
bottom end of the swoosh.
And if you're a legacy, a highly-regulated industry, you're going
to be on the top end of the swoosh.
And you still may have a whole barrel of problems if you're there, but at least
you're more likely to know about them.
And so if you're talking to a vendor that you know has only got four people
working for them, and they may have.
got their SOC 2.
And, and some, you may have some questions about it because you, you wonder why
their SOC 2 keeps on mentioning all these massive teams that you know they don't
have, but you're saying, where are you?
And you, you get that thing where you feel that they know what they're talking
about, even if they are not there and that they know where the gaps are.
Knowing where your problems are is really important, as much as then
subsequently fixing those problems.
Thank you for that, because I did in fact tell them that I thought that that was
a pretty terrible idea, and that they probably shouldn't do it, um, but, uh.
Yeah.
No, it's a weird thing.
It's tempting fate.
And it, and security is relative.
Are you more secure than everyone else selling your product, or more
secure than you were at the beginning?
Or what are you putting yourself up against?
So for organizations that would like to do some kind of thing like that,
they're going to have to do a pretty good benchmarking exercise to say, "I
am super secure, we are super secure," which again, they should never say.
But they should be really honest and have someone come in and do an assessment.
An independent person come in and do an assessment and turn over a few rocks and
go, you're pretty good, but you've also got these major issues here or some minor
issues and then you'd be even better.
You touched on third-party assessments, uh, and yeah, I think we've all, any, any
of us who have had to work with those in the past are aware that there's a range,
and certainly with the SOC 2, a lot depends on what your covered surface is.
For smaller companies that are maybe making decisions about when and how
to pursue a third-party audit, what, what advice do you have for them?
I would say that they need to figure out who their customers are or who they want
their customers to be, because depending on who those customers are, there's
going to be either a 0 percent or 100 percent chance that they're going to be
asked for an independent audit report.
And, um, if it is becoming, for good or bad, much cheaper to get a SOC 2 report.
There is unfortunately new types of auditors coming out that are
asking fewer questions in the audit.
I've worked with a large variety of auditors from very big to very small
and obviously if you're a very small organization and you don't have a
great deal of budget and you are trying to get your report, you are going to
probably deal with a cheaper vendor who, because they're cheaper, is also
not putting that much effort into it.
And so the report that you get at the end of it may be in an independent
order report, but you may secretly know that it really, that they
didn't hardly ask you anything.
And it concerns me generally, and I know there's a, there's some people on LinkedIn
who talk about this a lot, it concerns me that the value of a SOC 2 report
is going to be diminished as a result.
Because if people like me who are reading SOC 2 reports feel that the reports
are becoming less, I don't want to say truthful, but maybe less detailed or
they are, you suspect that the auditor, because perhaps you've worked with
them before, didn't really look under the covers as they're supposed to,
then how much faith can you put in it?
So it puts us in a bit of a sticky situation.
Having said that, it is still a baseline requirement, really, is a SOC 2.
You can have a type 1, but you better have a plan for your type 2.
Because, obviously, people, organizations, customers, want to
know that you can maintain your controls over a period of time.
Longer than a quarter, which is what everyone does, is they do their SOC
2 type 1, and then they do three months, and they get their type 2.
And then you've got to maintain it.
So you've got to have budget, you've got to have planned ahead, you've
got to have your controls in place.
Most people will end up using one of the DRC tools that
makes that a little bit easier.
If you know that you're going to have an institutional customer, then you're going
to have to get going on that very soon.
So let's actually talk about third-party vendor risk assessments.
That I think is the, probably the biggest surprise for people who are
getting involved in implementing a security program for the first time,
especially if they are coming from more of a technologist background.
When you're launching a vendor risk assessment program yourself,
what are some important things for smaller teams to keep in mind?
I would imagine that everyone would be hard pushed to come up
with a list of their vendors.
Even a really small organization, that list stables very quickly.
So for smaller organizations, they should start making a list, even
if it's just a list of names very early on of who their vendors are,
that are important in the flow.
Like it doesn't matter who delivers your water bottle if you have an office.
or other things.
So, bill.
com, right?
Bill.
com is an important vendor for most organizations because they
want to pay, get paid, but they typically isn't involved in the
production data or application flow.
So it does not need to be added to the list of vendors you really
want to take a good look at, especially not in early phases.
When I'm launching a third-party risk management program, we start
with the list, but in parallel, we're starting to do the reviews
of the vendors we know we have.
And for the most of the small organizations that I'm working
with, they're using some sort of cloud infrastructure.
A lot of them are using outsourcers like Newfire, for example, and
they might be using IT outsourcers,
they're going to be using a lot of the common tools, the common bigger tools.
But what becomes a little bit trickier is if it's a slightly more niche type
of vendor and then they're starting to use slightly more niche type vendors
themselves who may not have a SOC 2, who may be involved in an environment
where, um, nobody's asked for them to come up with anything like that before.
And then you have to go through a little bit more of a manual process.
But what I do with the clients as well is, is let's track the vendors.
Let's track what kind of data they get.
Let's assign them a risk based on usually what type of data they get, but
also if they're providing a security tooling or something that's a critical
piece of something for the company.
Let's give that a high rating.
Let's figure out what we're going to do with them as part of the review process.
Let's figure out how often we're going to do it.
And even things like, let's track what kind of authentication
mechanism we're using, because does it support single sign on?
Because if it doesn't, every time someone gets on boarded and off boarded,
that's an extra step that we need to remember about so that somebody doesn't
have inappropriate access to data.
So there's, there are a few important columns in my vendor spreadsheet.
So, for newer companies that have managed to build their infrastructure almost
entirely in the cloud, is there any way for them to think about when they might
have to sort of break the glass and bring in self-hosted systems and all of
the infrastructure that goes with that.
There are very few situations that I have come across where organizations that have
already started their life off in the cloud would need to do any self-hosting.
And in some cases they don't even need to.
They don't, they can run off serverless infrastructure in the
cloud, not all of them, to be fair.
And so most of my clients will have some sort of operating system
they're dealing with in the cloud.
There are so many negatives involved in self-hosting anything, whether it's your
own network or your own data center, or even, dare I say it, an EC2 instance with
an operating system running something that you could also get as a SaaS solution.
That I wouldn't ever particularly encourage it unless there were no option.
And typically there is an option.
You need to have specialized tool sets.
Sometimes you need to have specialized skills in your staff.
It just seems a waste of money if you can find, and by money I think I more
generically mean resources in general, if you can find a hosted solution.
It does mean you have to trust the vendor, and of course that's
part of the problem, isn't it?
So if you're going to put your most precious data on a third-party tool
because you don't want to host it in house or can't host it in house
or whatever in-house is to you, then you have to hope that you're
placing it with the right vendor.
And certainly we've seen that people that we thought were the right vendor
ended up having security issues.
But my kind of standard, uh, expression for that, which isn't, is not an answer,
but it's a statement, is that if this company goes down in flames, you will be
going down in flames in very good company.
If you know that there's going to be very large organizations that have picked
this vendor, why wouldn't you have?
So stay out of US East 1, but otherwise we're okay.
Well, you know, is that stay out of databases, RRFs, whatever, hosted by
your mate that just spun up a data center around the corner in his cow shed,
there's just things you shouldn't do.
And that's why part of the due diligence piece is so important because there's
a very easy ways to rule things out.
And also that's, I think, helpful when you're, when you've become
part of the company's structure, even as a virtual CISO, people know
where you can ask you or something.
I will say, if you're doing a beauty contest between three different vendors
that are going to provide warehouse management systems, and you're kind of
torn because they're all the same to you, let's look at the security piece.
That can feed into the matrix that you're running in the bake off.
If one of them has a security score of 1 and the other one is 10, I'm
obviously going to prefer you're going to pick the one that's 10.
And if not, we know that we need to go back to the one with 1 and
give them some really stringent
contract wording, which they may not go for.
That security review can feed into the early on stage of picking
vendors for my clients just as much as it is on the flip side.
So, of course, we can't have a Newfire podcast without talking
about AI at least a little bit.
How are the companies that you're working with thinking about the
impact of AI on their security, on their security programs overall.
My newest client is actually a client which is using AI
as part of their product.
So obviously they like that.
For most of the rest of my clients, they are probably not thinking about how AI is
going to help them with their security.
They're probably looking at tools that happen to have AI to provide better
something, whatever, better log reviews, better vulnerability scanning, better
something, but I think realistically that's been the case for a long time.
Right?
So we've had machine learning and that's been in a whole bunch of security tools
for a long time, and now it's effectively being rebranded and much improved.
My client for smaller organizations, they're just trying to figure out
how to patch and how to do MFA and how to do some basic functions.
Don't they and their functions don't really lend themselves
particularly well to AI.
And certainly there was a conversation I was having with some of my peers on
a vCISO Slack channel when people were going, well, how has AI helped you?
And for the most part, most people go, it really hasn't because we're there
having conversations with people about why something, and for sure I will spin up
ChatGPT and go make this policy a bit less boring.
And there's a lot to be said for that.
But realistically, a lot of the things I do is not assisted by AI.
But I do accept that the tools that we're looking at are in some shape
or form going to be assisted by AI.
It also really irritates me that everyone has just jammed
AI into their product name.
Like it's going to miraculously make that product better and more
suitable for a given organization.
And It's like the new FUD, when you used to sell stuff to people
because you said if you don't, you'll immediately be hacked tomorrow.
It's the, you must buy this because it's got AI, so therefore it must be better.
And it just doesn't apply in all cases.
Generally speaking, I would say that I think it's going to be
very helpful because it does help provide information to people in
formats that can be more consumable.
Related
to AI data, small organizations again, may be building their first data
warehouses, building their first BI and reporting platforms, and making the
transition to having data that might be available to very small parts of
the organization now have to be made more broadly available within a team.
How do you think about, how do you and some of the companies that you've worked
with think about extending that security and compliance envelope to broader use
of information assets within the company?
Well, I've had that very specifically with one organization
who were using Tableau, BigQuery.
Yeah, there's, there's a lot of things out there where you're providing some
sort of dashboard or portal for people to see things that they need to see because
obviously the marketing department needs to see if they have, let's say clients
in area X, they don't necessarily need to know their clients' names though, right?
So, hopefully, there's an option to provide some field-based access.
So access is really important for all of that stuff, right?
So what's appropriate for people to see?
What is appropriate for teams to see?
And is there a way that you can put some kind of filter and
then nearly always is, right?
So there's some sort of, some sort of filter in front of reports or output.
So in some cases it's, we only let two people write the reports.
So only two people know which fields the people need, or not know which fields
they need, but have the ability to create a report that creates an output that
may have sensitive information in it.
And they know that that output has to go in a different folder, or a
different group access, or those ways to make sure that that data
stays in the business-justified world that it needs to live in,
right?
So, uh, if you can't justify your HR people having access to
healthcare data, why would they?
That is not employee healthcare data.
Uh, then you make sure that they're not in the group that has that.
So access is super important.
It'd be super important for AI as well.
What, if you've got APIs, you, what are those APIs able to access on the back end?
Are you again saying they can only see de-identified data?
Are you saying that they can't see anything at all?
You have to think about that in the beginning because you don't want
to build it wrong and then realize you have to turn off the tap after.
So a common business model for productivity focused SaaS
applications is to come into a company at the end user level.
I know Tableau and team really pioneered this.
How do you think about shadow IT where people bring in tools that they want
to use that may not be blessed by the company as a whole and certainly aren't
part of the overall security program?
There are a couple of aspects to that.
So one is knowing that they're using it at all, right?
And that's really quite tricky.
So there's a couple of new tools out there that some of my clients are using
that do things like read every email to say: "Hey you, this is your new user
account from shadowit.com product here.
Um, here's your login and don't forget to look at the report."
So it can, it looks at all of those emails says, okay, so just so you
know, your shadow it list has now included this particular tool.
And that's always been a problem is to identify what is being used.
Hence the shadow, I suppose.
Um, because so many of them can come in with a free trial that it no
longer becomes a thing of is it on your corporate card because probably
not because it's a free trial.
Hopefully people are at least using their single sign on for logging into it because
that is another way to actually see what tools people are using because it is not
entirely straightforward but there are again tools that make it a little easier.
You can see who has been logging in with your angel cybersecurity.
com to which products.
So then again, it's about building the list.
So first problem, do you even know who they are?
Second problem, it's not that it's a bad idea that people are using these.
They may have used them in a previous job.
They may know that they do a great, great job of what they need it to do.
And they don't think they're necessarily doing anything wrong by
bringing it into the organization.
So what you have to do is get out in front of that with some education and
say: "Hey, everybody, we love tools.
We want to get things done.
We want to do it right.
However, we have contractual obligations, regulatory requirements.
We cannot share data with these tools without it going through
our vendor review process."
So here are some guardrails.
So actually we've got a document, I've got a document that we use, it says "Yeah, if
you want to try something out, you can try it out, but you can't use any real data.
Not our real data, not employee real data, not any real data, right?
So give it a whirl, and if you like it, share it with your team if you like it.
If you all like it, and it's budget for it, if it costs anything, then we'll go
through the vendor process because we want to use tools that people want to use."
Because it's just as bad if security says, Oh no, thou shalt
use this tool that everybody hates.
So it's awareness and education around making sure you give people the tools
they need to do the right thing and then it's also capturing the information
about tools that, that half the time they didn't even know was shadow IT, right?
They think they're just using a little app somewhere and they don't think of
it as shadow IT and they don't think of it as having access to company data.
So you have to help them understand that, that it is.
So I've always been very interested in, in how you set up a great
incident response, um, program.
And I know we've, I've had to spend a lot of time in previous companies
training that skill set into people as well as putting in the right kind
of an infrastructure so that when there is, and frankly, it's usually
a production incident rather than a security incident, that we have
the right people in the right place to be able to respond to that.
And it's always been a little bit of a bespoke process.
So, for companies that are building their incident response program
for the first time, what do you recommend that they focus on first?
So, the thing that I focus on first is the contact list.
Really, I mean, and it sounds straightforward.
If you're the CMO and you're on a call with me once every
six weeks, you know I exist.
Do you know how to get hold of me?
Do you know how to get hold of your main software engineer
who might be outsourced, right?
So do you know how to get hold of the people because something has gone wrong?
And so the contact list is very important and obviously it's quite easy to get
to, but it also includes things like to do you have cyber insurance, hopefully.
If you have cyber insurance, how do you get hold of them?
Because chances are they're going to be your forensics team because
small organizations are typically not going to have a retainer with a
forensics organization from the get go.
So you've got your contact list, you've got law enforcement because you
should be notifying law enforcement.
The subsequent piece of the contact list is do you have
categories you need to notify?
Because you should know who they are and what their
expectations are of notifications.
So one person might have contractually required you to notify them in 24 hours.
Someone else might be 72 hours.
Ultimately, you'll probably do them all at the same time.
But if you've gone a week, and you've known for 24 hours, you know, that
you're going to have an issue with.
So the contact list is very important.
And actually, even the process of building the contact list gets those
teams for the internal security and response team, which we're going to decide
who that is as part of that process.
What is in the response document, I'm not going to say it doesn't matter because
it does matter, but what really happens when an incident happens is that everybody
gets on a call and just makes it work.
And you have to know who to talk to, and you also have to have very clear
guidelines about who is allowed to talk to who, because what you don't want is
is the junior customer services person who only started last week to get
on the call with someone saying, no, I'm sorry, we've had a breach, right?
You just, you've got to be very clear about who does the communications, who
approves the communications, whether it's internal, external media, customers, law
enforcement, all of those things have to go through layers of approval so that
down the line, it doesn't put you in even hotter water than you might be in.
So I have an instrument response document that links to the contact list,
which should be in more than one form.
So if somebody eats your, your storage space, you've got, you
still got those numbers somewhere.
And also it says, these are the things we need to think about.
So if something's gone wrong.
So here's the tracker.
We're going to start recording the timeline because the timeline
might become quite important.
It's typically important.
We have to start tracking this.
We might not even think it's a security incident.
We just don't know.
So we're just going to start taking notes and it could be in a Jira ticket.
It could be anywhere.
But recording that kind of being described as typically a stated role
in an instant response document.
So who's going to call who?
Who's going to write stuff down?
Who's going to start bringing things back?
Because to your point, in a production incident, everybody knows who's going
to bring your stuff back, right?
Whoever's closest to the button to push the button to make it come back.
In a security response, um, there are a lot of, uh, there's a, there's
a lot of overlap, but there's also a lot of, of specifics that you
might not want to to get wrong.
Uh, and I'm sure there are with production as well.
But so for me, it's just important that everyone who's on the team
knows that they are part of the team.
So we do the desktop walkthroughs, which are always interesting.
So you'll come up with a scenario and I'll come up with scenario.
We'll talk it through with the team.
And there's always something that we thought, oh, we haven't done that.
And that is part of recognizing where your gaps lie, right?
So my job is not
making people secure because it's impossible.
My job is risk mitigation and that involves going through a tabletop
walkthrough of an incident scenario and saying, how do we not know that
we don't know the number of the person who is going to be able to approve X?
Right.
And so having that documented it might be out of date in six weeks, but at
least we've got it and we know that there's a list and we, we know that
there are things that we need to do.
Um, so really that one's kind of a knowledge based stuff.
I mean, I've lived through some incidents and they're never fun.
And I'd love to say that everyone immediately pulls up the incident
response plan, but that isn't the case.
So what I'm taking away from that is print it out, get it laminated,
stick a copy at your in-laws house.
That's basically our rebel when I was in, uh.
Was it my last IT job?
I think my last big IT job I had, which is before I started working at Equifax,
and we had the disaster recovery manuals, which were done by an entire team.
It was a very big, uh, regulated industry, and there was an entire team doing
the incident response, and we all had three-inch ring binder in our cars because
that's where we were supposed to keep it.
So that's one way of doing it.
At the very least, if you think that your contact list might get eaten
by a piece of ransomware, do you at least have those people, most of
those people's numbers in your phone?
And there's only so many things that we can do, but luckily we now have, we
have many more methods of communication than we used to back in the day.
So on that note, what's exciting to you in the field right now?
I like what I'm seeing with the GRC tools I'm using, and GRC always, yeah,
I feel like everyone just yawns when they hear of governance, risk, and
compliance, but what's new and different with the tools that I've been using in
the last couple of years is their ability to hook into just about everything.
And to start pulling out low hanging fruit, right?
So you can hook it into your Google and go, why is it this
person's been inactive for 30 days?
And you know, you, because you don't have a full team of people managing
access and seeing who's been inactive for 30 days, you can have a tool
send you a message into Slack going, someone's been inactive for 30 days.
And it's just really, they are very useful for avoiding stupid
slippage and stuff, right?
So somebody set up a new S3 bucket and didn't something by default,
right, there's a sort of umpteen things that it could be checking for.
And those tools will just tell you, and it's just easy and it's
part of what you're paying for.
And obviously they do a lot of other things that help you get to and
maintain a decent compliance status.
And I do try and emphasize security over compliance, but the reality is, if there
are a lot of things on the compliance list that people wouldn't ordinarily choose
to do first because they're boring, but they do provide a big security uplift.
So I like those tools.
I'm sure they're using a bunch of AI as well.
And we'll continue to increase that.
But I like the way that for less than 10,000 dollars a year, a small
organization can get a tool that really does quite a lot of things,
um, in their security maturity, um, plan and, uh, compliance
ability to reach their old plan.
Um, so those are great.
I wish everyone was doing serverless because nobody needs to be patching EC2s.
There's just, the cloud has come out with so many opportunities for then everyone
to build products in the cloud that moving away from having to go and reboot
a firewall in the middle of the night is possibility for just about everybody.
And obviously that's, that's been around for a long time.
But for small organizations, integrations between tools have made it just generally
much easier to do the right thing.
Laura, before we wrap up, is there, especially in this post change
healthcare world, is there one piece of advice that you'd like to give
to healthcare leaders or founders of companies, specifically in healthcare
technology, but even more broadly, around their security programs and posture?
I would say they shouldn't consider security an expense.
They should consider it a marketing advantage because if they don't
have it, no one's going to buy it.
It's a slightly bold statement because that's what I'm seeing.
I think that I'm astonished still by the clients that come to me that still aren't
doing some of the incredibly basic things.
It feels like we've gone beyond the point where people don't have multi-factor in
place, and yet I can say that we're not.
And my job is effectively telling people to do more or less the
same five things, and I'm still having to tell them to do it.
And I think as technology gets more advanced, and tools are super
cool, and everyone's telling them something fancy, it's not the fancy
stuff that's catching people out.
It's just not.
It wasn't with change.
So, you need to make sure, and again, be very honest and actually check
that you're doing the boring things, like scanning for vulnerabilities,
patching the vulnerabilities, putting multi-factor in place, making sure
people aren't leaving with your data.
Like, none of this has changed for years, and yet it's still a problem.
Get those things done so you don't have to worry about them moving forward.
Because, for the most part, most of them are pretty quick and easy.
And any advice for people who are looking to build a career in the security field?
Oh, it's really tricky because, you know, we're all so well aware that,
that we need more people in the security field and we're also equally
well aware that an entry-level job in security apparently doesn't exist.
I, like a lot of my peers, got into security through IT.
I would say for everyone, if you're looking at security, join
up with any of the available groups that are in your area.
Nearly everything is free, right?
You don't have to go black cat, but you might be able to
get sponsored to go black cat.
And also, find out what part of security interests you, because if you want to
be an ethical hacker, there's no point learning a great deal about GRC, because
it's just going to bore you mindless.
And, you know, like, for me, I'm not an ethical hacker.
I've never claimed to be able to do anything with coding, so I'm not spending
a great deal of time delving into that.
Understand what the different parts of security are, the security world are.
Think about which ones interest you, because that's going to put
you down a slightly different path.
You might have to go and do a little bit of, um, software development, go
and work for Newfire, do some software dev and then spit out Intersect DevOps.
That's great.
If you're not super technical, it doesn't mean that you can't get into security.
You can.
Coming through auditing ways, although it's always helpful if you're, if your
technical action helps when you're auditing with technical control.
There are ways to get in there and you just need to persevere and be aware
that in the security field, we're just rubbish at creating entry level jobs.
And we take, we steal people from the IT teams all the time.
And that probably is going to continue.
So try and get into security through another team.
Laura, thank you so much for joining us today.
Uh, you know, this has been a fabulous conversation.
I've learned a lot.
I think our listeners are going to learn a lot, too.
Building a security program from ground up is I think one of the things that
founders don't recognize that they're going to have to do when they start
the journey of building a company.
And it's something that leaders don't necessarily realize they're going to
be responsible for when they make that switch from a functional role to something
that's more focused on general management.
So, being able to cover so many of these different areas, I hope it's been very
interesting to you, you who are listening.
If you are facing similar challenges or looking to improve your data security,
obviously, we'd love to talk with you.
Laura would love to talk to you.
So feel free to reach out.
So Laura, it's been an absolute pleasure having you on Hard Problems,
Smart Solutions, the Newfire podcast.
Thank you again for sharing your knowledge and inspiring us to think a little
creatively about security and innovation.
And to our listeners, thank you all for tuning in and we will hear you next time.