Subscribe
Share
Share
Embed
On this episode of Hard Problems, Smart Solutions: The Newfire Podcast, Newfire’s Head of Advisory Services Will Crawford sits down with Laura Louthan, founder of Angel Cybersecurity. Laura, a seasoned virtual Chief Information Security Officer (vCISO), discusses how businesses can creatively address security challenges without stretching their budgets. Drawing on her extensive experience with notable companies like Sephora and Equifax, Laura offers valuable insights into building secure infrastructures, managing risk, and crafting effective and budget-conscious security strategies. Listen in for a deep dive into maximizing your security impact while conserving resources.
Key Topics:
- Introduction to Laura Louthan and her background in cybersecurity.
- Balancing security and budget constraints for startups and smaller businesses.
- Finding the right security leadership.
- Unique security challenges within the healthcare sector.
- Educating employees on the importance of security practices.
- Managing third-party vendor risks and evaluations.
- The role of AI in enhancing security tools and practices.
- Implementing an effective incident response plan.
- Advice for future security professionals.
Creators & Guests
What is Hard Problems, Smart Solutions: The Newfire Podcast?
Join Newfire’s engineering, product, data, and people experts as they tackle today’s most pressing technology questions alongside industry leaders from some of the world’s most notable companies. This is where the hard problems you’re facing finally get the smart solutions you were looking for.
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.