hey what's up everyone alyssa knight
here i want to thank nina ali and the
rest of her team at biohacking village
for inviting mitch and i to come speak
on my recent vulnerability research on
hacking fire apis and health apis so i'm
going to start out with the view from
the attacker my tactics and techniques
and the results of me hacking these m
health and fire apis and then we're
going to transition over to mitch who
will give his side in perspective as a
defender and cso so without further ado
let's get it started
just so quick about me if any of you
want to reach me you can feel free to
reach out to me on my email at ak knight
incmedia.com follow me on twitter
subscribe my youtube channel
hit that bell icon to be notified of new
uploads i publish
every week as well as live stream and
that's the best way that you can support
content creators and influencers in
cyber security is to subscribe to our
accounts and follow us and retweet it or
re-share it so with that being said i'm
a recovering hacker of 21 years so i've
been in this for a long time
um i'm an entrepreneur i've published a
book on hacking connected cars i'm also
working on a new book hacking apis i've
started and sold two previous cyber
security startups and buy side and m
sell side m a transactions so
i've been around the block i've been to
the show i actually started out with in
the bbs scene in seattle a long time ago
many moons ago and i wrote a multi-node
bbs and actually got started in hacking
on irc
so for any of you who've been around
long enough to remember that um
i also run in a venture capital fund m a
night capital
m a night entertainment so i'm in the
process of actually writing a screenplay
for a new tv series and also run knight
inc which is a content marketing company
i'm a cyber security filmmaker and
content creator so i work with cyber
security vendors brands challenger
brands to create what i like to call
adversarial content meaning that i
create content from the views of the
attacker
and
that is a new type of content that
really shows content in the efficacy of
a product in it being able to defend
against the hacks that i'm running
against it so if for example
approve who's the sponsor of this
research i thought well instead of just
writing writing a boring white paper or
doing a boring video on your features
what if i were to hack apis and show how
your product would have prevented it and
that's exactly what i did and that was
the impetus to my presentation to you
today
my api hack so i've kind of branded at
this point as an api hacker in 2019 i
hacked 30 financial apps and apis 2020 i
hacked m uh 30m health apps and apis
2021 i hacked federal and state law
enforcement vehicles and
2021 this year i'm hacking fire apis and
also connected trains so i'm very
passionate about hacking embedded
systems everything today from the
plumbing of our financial system now to
our healthcare system with the fire
deadlines
uh
are all communicating with apis so i'm
really excited to talk about that today
and give you a little bit of a brief
background on fire
and
okay so as i mentioned approve sponsored
this research into hacking healthcare
apis um so you can actually go and
download the report from approved.io
and one thing that i do want to mention
is
and i'll go into this in the final part
of my presentation but
the apis that i hacked many of them were
behind laughs and i'm going to talk
about the dangers of using the wrong
tool for the job
when you're not using an api threat
management solution that's been purpose
built from the ground up to secure apis
you're going to be under a false sense
of security so
take a look at the research hit the
website and download it today
okay so
many of you will be
hearing me refer to smart and fire or
smart on fire and i want to really help
you understand the difference between
those because they're actually not one
and the same
some people may even conflate the two
terms they're actually separate things
so fire provides a set of models to
standardize the representation of
clinical concepts such as allergies and
medications and an ehr other clinical
data store basically what that means is
fire
creates the skeleton if you will for the
ehr data and what i'm going to go to in
later slides and i'll explain this later
but when you go to a hospital prior to
fire and prior to these these apis that
just kind of allows these systems to
talk to each other you could go to two
different hospitals and they'll be using
different ehrs or emr systems
in this case cerner or epic
and if you go to one hospital they're
going to have all of your data and let's
say you get sick the next day and you go
to a different hospital and they're
running a completely different emr
um they will not be able to talk to that
other system at that other hospital
creating concerns over life and safety
so
it's a real problem
so i i don't want you to think that oh
alyssa is saying that fire is bad um
what i'm saying is that this is very
important that these systems are able to
talk to each other and i'm a huge fan
but i want to make sure that it's done
securely because this is our phi this is
our protected healthcare information and
it needs to be secured smart
standardizes the process through a
third-party application could so a
third-party application can plug into
the data store and access that clinical
information it basically applies oauth 2
and open id connect so what that means
is smart basically turns our healthcare
system into an app-based economy so
originally when smart first started out
it actually was very similar to fire and
was in essence competing against what
fire was
going to be and so the the team
basically took a step back and said hey
you know what um
what they're doing over at hl7 or health
level 7 international and i'll talk
about that in a minute but what they're
doing is is great and and you know this
competing against them doesn't make
sense so let's change the the mission
for smart and let's make this about
authentication with oauth 2 open id
connect and really giving third party
app developers the ability to make apps
for these for fire apis
um and so that was a large part of my
attack surface actually were the third
parties that came along making apps for
fire aps i simply put fire standardized
while
and secures data access so think about
smart as like the authentication and
authorization on top of fire
you might be wondering hey listen why
smart why didn't fire just do this well
an app developer can write an app once
and expect that it will run anywhere in
the health care system that's the
importance of this right so if i wanted
to start an a startup company and begin
building buyer apps i know that anything
that supports fire is going to be able
to run that app anyhow i can go to any
hospital and sell my app to them i can
go to any healthcare provider and sell
my app
um
it's creating a new economy of companies
which was really interesting uh it
basically creates an app store for
health
uh smart on fire provides a health app
interface based on open standards
including agel seven's fire oauth2 and
open id connect so that's fire so let's
actually get into the weeds now
this is a screenshot of the approved
fire client that skip built for me i was
greatly appreciative because i wasn't
going to sit there and build a fire app
so
basically you can see here and if i
expand this out it actually will expand
all the json
results from the api containing all of
the information for this patient
so these are the testing phases in my
research so in 2020 i did static code
analysis of these fire of these mhealth
apps and 20
i also did traffic analysis basically
using what i call women in the middle
attacks to intercept that traffic and
look at it to understand how the api
worked
then i actually did fuzzing
and then static code analysis in 2021 so
now i'm basically have downloaded the
apps from the smart app store and
there's actually a list
and i began doing static code analysis
of those looking for things like
hard-coded keys and tokens and all the
other bad
stuff
including stuff about the back-end api
and how they work
then
traffic analysis was performed where i
did network interdiction of the traffic
in order to understand how the backend
api worked and how what it expected in
order to find things like broken object
level authorization vulnerabilities
and then did fuzzing
i want to take a moment to talk about
the importance of fuzzing apis i've been
talking a lot about this lately and
coming soon here
you'll be seeing me talking a lot more
about fuzzing apis and the importance of
that so
having said that
what fuzzers will do is they'll
for example like kite runner or wrestler
will allow you to import in swagger file
uh like with wrestler it'll allow you to
import a swagger file and it will test
that back in api against that swagger
file um with kite render for example the
developers have used like thousands of
different swagger files out there on the
internet in order to build kind of like
this content discovery system for apis
if you don't fuzz apis i guarantee you
you will miss vulnerabilities fuzzing
apis is so important it's not like you
can run nessa scan or
wipe out any other web application
scanner against a back end fire api or
any api uh the most effective tool that
you can use against the target api is a
fuzzer okay so um this was the actual
different phases of my research the four
most common vulnerabilities that i found
in my research which you can read in the
report were broken object level
authorization broken user authentication
excessive data exposure and mass
assignment now um in this particular
case
um i'm going to explain what you're
looking at in this drawing so a patient
goes to a hospital running cerner for
example
and then
that individual patient goes to a second
hospital uh that's running epic um here
in this case in my um
diagram i actually targeted both apis uh
attempting to gain access to patient
records that i shouldn't have had access
to
um
several organizations over the last two
years have come up and
told me that they wanted to support my
work and get involved and i'm very
appreciative including the emr companies
so i want to say thanks to all of those
companies that did get involved and help
support this there's definitely less of
an epistle relationship between
vulnerability researchers and companies
today than there was 20 years ago
so
you guys are all you guys and girls are
all here for the actual results so let's
get into them so
here you can see the architecture of my
attack uh in this mobile app uh i you
can see that i've pulled i've logged in
as a clinician and these are the
patients that i was supposed to have
access to
um doing network interdiction i learned
that this was the api request that was
going to the api by just basically
clicking every button in the mobile app
and then you would it would really
return that patient record but then i
took those api requests and i loaded
them into postman which is an amazing
api client that i absolutely love
postman if you're listening you guys do
an amazing job and have made an amazing
product so thank you
um
then i i basically paste those into
postman and then change the requests
from
patient one zero zero one which is what
i should read access to
two one two three four and i had because
of a bowl of vulnerability had access to
tens of thousands of patient records and
here on the right hand side you can see
the screenshots of postman that allowed
me to send those requests to the backend
api
and download those reports pathology
reports x-rays all of these reports were
available to me and here you can see the
hard-coded keys and tokens that were
found in those mobile apps so
definitely a lot of vulnerables were
found and what's neat about
postman you'll see it here in the
screenshot is and i didn't know it could
do this but when i started requesting
endpoint documents so actual pdf files
from the api endpoint
of course i got the pdf that i was
requesting back um but
postman lets you save that to a file
which was really neat so over here is
the screenshot of the actual pathology
report that i downloaded from the api
endpoint
pause for
sound of that pin drop
sorry i have a real dry sense of humor
um hard-coded api keys and tokens was a
real problem i found
104 hard-coded keys and tokens in the
mobile apps um a lot of them were not
only just keys and tokens to the apis
api secrets to the aps for the mobile
app but also to third parties like
payment processors
um
so a lot of hard-coded nastiness and
those mobile apps that were able to be
reversed once i loaded them into my tool
called mob sf here i was targeting a
hospital and was able to download
admission records for different patients
that were admitted into the hospital
here i've redacted a lot of this but you
can see how much data is actually stored
in these
in these patient records the interesting
thing here was i was able to actually
download a lot of patient pictures
so this hospital was taking pictures of
patients as they were stored as they
were processing them
um i think i i strongly believe that
this is why phi is worth a thousand
times more
than a
uh credit card number on the dark web in
a dark web marketplace is because of the
fact that there's just so much data on
an individual in a patient record and
not only that but when i was going
through this i found that i was actually
able to access data for their next of
kin and other family information so
you know once this happens that's the
other thing is that if your phi is
compromised it's not like anyone can
send you new phi
um like if your bank card is compromised
the bank can send you a new bank card
what happens if your phi is compromised
no one can generate new phi for you
okay
this was a really interesting
vulnerability so what i found was that
when
you were
in a lock session on an iphone
whenever you unlocked it with your face
the mobile app would send the secret and
that string of letters and numbers never
changed so
like weeks would go by keep locking and
locking my session and i looked at
packets and it was the same key every
time
so
what i found was this was hard-coded and
like weeks later if i pasted that same
secret to unlock that session
it gave me the results of all the
patient records
so you know
why the developer did this i don't know
um
but it was a pretty big finding i was
pretty proud of it this slide is for all
of you who want to know how to actually
properly secure these things in my
testing the only api i wasn't able to
breach was protected by approve i do
want to say that so
i tested a number of apis and then
approved worked with several
organizations to
stand up in installation and secure the
api with approve and all of my tax
failed basically the way it works is you
have to
compile your mobile app with your sdk
and what it does is it basically
prevents anything from talking to your
api unless it's been compiled with that
sdk so for those of you who are actually
here looking for an api security
solution um it's it's amazing it's
absolutely amazing so especially if you
have a mobile api i believe in their
most recent version they added some
support for some web apis so take a look
at it um authorization vulnerabilities
were everywhere uh developers were
remembering to authenticate the requests
um but they failed to authorize there
were a bowl of vulnerabilities in every
one of the apis i tested
ensure scopes are being used with tokens
so what developers would do is they
would implement tokens but they wouldn't
apply scopes so
i had a token i was supposed to be there
i was authorized to be there but i
wasn't authorized to request the
vulnerability the
data that i was requesting and because
there were no tokens or scopes uh sorry
there were no scopes in place uh it
prevented that from uh it allowed me to
be able to do that
jot token should really have short time
to lives i i saw really long
ttls for jot tokens um they really
shouldn't be longer than five to ten
minutes so that will really help with
the whole you know women in the middle
attack stuff and the other thing about a
previous they have this ability to
actually
um
help you to better manage
certificate pinning so i spoke to a lot
of developers when i asked them like hey
almost all of these apps didn't
implement pinning why and a lot of the
developers said they were afraid of
pinning bricking the app
so you know
the ability for you to better manage
pinning is available and improved so i
would definitely click that that's a
concern of yours use refresh tokens just
remember that refresh tokens
can be revoked but access tokens can't
so if an access token is compromised you
can't revoke it but a refresh token you
can so just remember to use refresh
tokens and as an alternative to keys
approve is specialist and protecting
apis consumed by mobile apps um it's
challenging to secure since anyone can
download your mobile app hence a
dedicated securities need for this
challenge so
that's the thing that's the scary thing
about mobile apps is anyone can download
them anyone so if you're storing
anything sensitive in that data in that
code in that apk file
a hacker can download the apk file and
reverse it back to the original source
code and view it so keep that in mind
and
a previous specialist in protecting
these kind of apis
use hard-coded api keys and tokens as
app identifiers and not as app secrets
ensure that a second factor such as
mobile application mobile app
authentication is needed to use them
so
okay
i've had that whole religious debate
with developers about
if i'm not supposed to store these keys
and tokens in the code then where the
hell am i supposed to store them
you can store them and you can obfuscate
the code okay fine but
use multi-factor authentication don't
just rely on just that token just that
key for authentication also authenticate
the app so make sure that your api
security solution can authenticate the
app as well
remember that fire is a specification
and doesn't mandate how it's secured
vulnerabilities or implementation okay
this is really important for me to make
clear
so nina and i can both implement a fire
api
but my implementation of the fire
standard
can be completely different from hers
and mine can be full of vulnerabilities
whereas hers wasn't
so you know
just because i found vulnerabilities or
issues and and these apis it doesn't
mean
that there's a vulnerability or problem
in the fire standard okay it's always
going to be down to the implementation
and that's something for all of you to
remember
so again the research is available at
approved.io and again
i want to thank nina ali and the rest of
our team for inviting me to speak here
along with mitch and mitch over to you
so my part of presentation thank you
again alyssa is how do we approach this
from the provider's side
so a big thing i always talk about is
history i always like to talk talk about
and lead off with some examples from
history
and
one of the
most apocal periods in history was late
18th century and back then
a learned person only needed to know
what was in a few books to know
everything they needed to succeed in the
world
the books about chemistry physics
science and business you could fit on a
bookshelf
we are not in those days
we are in a significantly more complex
environment however our social
structures really haven't evolved that
much
since the late 18th century
and another way that
we haven't really evolved has been with
our work environment so back in the
early 1900s frederick taylor did a lot
of studies time studies
in factories in philadelphia to
determine how long it took someone to do
work
time series analysis
and
that is the fundamental metric by which
people have measured work ever since
but taylor had one challenge
his challenge was that the work
environments were not adversarial they
assumed an ideal environment where the
worker would always have supplies and
there weren't people trying to take the
workers items
so that's not the case what we have
today and we've built these management
structures we've built business
around the absence of adversaries
trying to break down what we have which
makes it a lot harder for us to be able
to fit into the concept of business
the idea of defense
so we need to embrace that nature to
provide that critical eye
this means we need new capabilities
we've built a lot of our electronic
systems around how we've originally
worked in business
the absence of adversaries
so we're moving from the pushing and
pulling predictable of information to
now full
programmatic interaction
and so in healthcare right now we have a
obvious major change
everything used to happen with
predefined blocks of information
going along predetermined sequences
and the level of interaction was push
pull
now we're moving to full api level
interaction with fire
and oauth in healthcare
so
we need to build
knowledge of how to
address adversarial issues
into our environment in two areas number
one detecting the api issues and number
two preventing them
and right now we can't get the push pull
right and now we're changing the
complexity significantly and adding more
on top
so
what are some of the challenges that
we're seeing what are we seeing from my
vantage point
we have a lot of privacy issues with
these new applications using fire to
connect to get patients medical records
so i put the link to healthcare dive
here for people to take a look at
and
most of the apps that this group
research group found
had significant issues with privacy
also we had the issue of a lot of these
developers developing these apps are
small and what they can do is they
monetize the information by selling
those details to marketers
there already was one case where a
healthcare application the owners of the
application sold data on women's
menstrual cycles to marketers
i can't think of a greater invasion of
privacy than bats
and a lot of the powers that be in
healthcare a lot of the big providers
aren't really taking a look at this
because the use of that data once it
leaves their environment
is out of scope according to the cures
act final rules wording
so
what's our goal today our goal is that
we're going to change that
so what i always like to say about
privacy issues is that when there's
privacy issues there's security issues
so today where there's smoke
there's fire
so what other types of issues do we
anticipate seeing
so a lot of these applications remember
the programmatic applications we expect
them to see malformed requests that
don't handle context changes
so back about 10 15 years ago we'd
handle malformed hl7 in test you
wouldn't see it in production guess what
it's in production now
insecure client application code yeah
not much of a change you're just going
to see a lot more of it
and you're going to see the use of fire
to transfer data between your electronic
medical record systems a lot of
unprotected local repositories and a lot
of insecure cloud locations and now also
with the fact that people do incredibly
crazy marketing things you'll also see
it on social media and the app builders
out there are building these apps
they're not going to have the security
resources that you can call upon of your
google or microsoft or one of the large
gmr companies
even if these small companies hire
ex-employees of these big companies
they're not going to have the resources
to do it right
and a lot of these small companies need
extra help
i know this because of the position i'm
in my organization
i deal with several hundred application
vendors and i talk to them about source
code analysis i talk to them about
devsecops and new technologies they can
use
and one of the challenges that i have
working with these organizations is a
lot of them don't even know what to do
or if they do a lot of them are
significantly under resourced
so
what other issues do i expect to see
i call this one guilt by association
if there's anything big healthcare
organizations are very protective of
it's their brand
and i expect there to be knee-jerk
reactions the second that one of those
unprecedented protected cloud
repositories breaks
and the next thing you know patients
medical data from their facilities ends
up in an unprotected cloud environments
it's not going to be a breach because
technically it was already it was
downloaded from the healthcare app
however if it's got a healthcare
system's brand all over it there's going
to be challenges and also
integrating that data with social media
we expect there to be outcry over that
and when the first record starts showing
up when people do
integration and use it for marketing
they're going to want to take some
action
so what else do we expect
we also expect that there to have the
api security holes caused by having
those fire front ends to the legacy
environments
so these apis we're talking about that
provide fire data to these applications
there are front ends for other systems
and a lot of them both on the legacy
ones too
aka those systems you can never get rid
of that are probably going to outlive
you
and they'll be around when your kids are
old enough to work in i.t
and so one of the big things we always
talk about with api vulnerabilities is
the ability for them to execute code and
lead the pivot points that you can use
to attack other points on your network
which is a technique we see from a lot
of ransomware threat actors these days
nice front ends however if you can get
in there run code and attack the back
end it becomes significantly more
difficult another mimi for that coming
up
so you've got xml or json with large
binary blobs handling your healthcare
data
what could possibly go wrong
so bring it back to some more history in
healthcare because healthcare has
evolved
not as much as the rest of it however
healthcare you started out in the 80s
you had your it guy they knew hardware
and software very well in the 90s they
started differentiating between each
other and in the late 90s software
development
forked between client server and web
and then
security kind of grew out of a hybrid of
the two in the early 2000s
so now these days finally in the 2020s
we're starting to see that reconvergence
of security and development yet again
and we consider this to be a good thing
however healthcare always lags a little
bit behind so
we're going to try and make that
advancement happen a little bit quicker
there today
so how are we going to address the
challenges of these fire apis and the
security issues that alissa and i have
been talking about
first of all we've got to change how we
operate with developers and help them
understand it's not about the lines of
code you complete it's about how well
you complete them against adversaries
and to think in terms of adversarial
attacks
we have to take a look at how we scan
for vulnerabilities because healthcare
has done it one way for years and now we
have to do it another way and we'll talk
about that
and
third-party risk the conventional way of
giving your vendors a huge questionnaire
to fill out
really doesn't work to mitigate risk
anymore
and trying to hand it off to a third
party aka
paying the people in nice suits that
come up to you at big conferences
and tell you how they can address your
third-party risk issues or relentlessly
spam you in your inbox
that's not going to fix your problems
here either and we'll talk about that
so let's move on a little bit here
big thing we need to really talk about
here about security is
blindly using those off-the-shelf
solutions or the ones that claim they
can fix most vulnerabilities before
they
even hit your servers
they don't fix the root cause i don't
think they fix much of anything and what
happens when you use them is you put
yourself in a situation where even
though it says it protects you
it does so at the expense of your
functionality and it doesn't address
where it breaks your stuff because it
will and guess what when it breaks your
stuff guess whose fault it is not the
vendors it's yours
and also these big wafts because of the
fact that they are so expensive to
license in a lot of cases they don't
address the connectivity between your
internal systems so you've got something
where if you can get in and get binary
code running on an api server
it's not that hard to go and
brachiate like we used to do in the on
the bars at school
and go across the environment you've got
your way in
and finally a web application firewall
doesn't address the root cause aka
insecure code so we have our challenges
here we have to and this is how we can
start addressing them
so
a lot of people are going to think well
mitch
all our vendors are high trust certified
will high trust help us
no
i like the high trust people however
their certification is not a swiss army
knife
it's really great for controls testing
and accounting type work however it
doesn't help developers as much as we'd
like
and it doesn't help the architectural
issues
and also it really doesn't help if you
drop a high trust certified solution
into a legacy environment where you've
got systems running from when reagan was
presidents
really will not help you
won't help with bush clinton or bush
junior either
so
that's the situation you're in high
trust is great however
when it comes to integration doesn't
work the greatest for the environment
that it's in to get the full benefit you
have to be fully high trust certified as
well and there are very few healthcare
delivery organizations that are that
have actually done this
even the large ones that i've spoken to
have only certified part of their
environment
so this means we need to change our
service model
so a lot of your major emr companies
when they offer up those apis they give
sandboxes a testament those sandboxes
are great however
they're not testing the entire app
that's accessing
the apis they're not testing the
gateways to legacy systems
that app can be completely conformant
and again can be horribly insecure we've
proven that
a lot of code that's written for apple
and google
for those devices
code can be broken we know this
and
no questionnaire no piece of software
they're not going to help you address
the root causes of these issues so you
have to modify how you test and we're
going to talk about that
so
another challenge we find is mutually
assured security
so large design pattern that we've seen
that's been supported by the major
software development platforms has been
the emergence of these distributed
technologies
now you have the extreme of people still
doing things legacy way all the way to
full running on smart contracts in
blockchain
and distributed technologies in
healthcare kind of lean towards more a
small evolution from where we were
legacy systems
and a big concern we see with that is
you're only as secure as your weakest
link
especially internally
and we have to be concerned because
these apps that are now
accessing
our systems using fire contain our
patients protected health information
and even though
the responsibility goes away
as soon as that data gets downloaded
we still consider even the mere
existence of those apis the first place
to be a major risk for our organization
and again it's one part of a distributed
chain which is how we look at it so we
have to really think about it in the
context of
it's one part of a chain not some
isolated little system whose scope drops
off like the mariana trench
so
what we have to take a look at here
and again i'm going to talk more about
third-party risk companies here
we don't go to companies that give us a
score to make decisions about third
party risk
you actually have to do something about
that and i don't care if i piss these
companies off today why because i'm a
defcon
so
what you have to do is you have to do
some pretty serious purple teamwork to
be able to ensure your apis are secured
and that
you've done a good job making sure your
environment in total is secure not just
your apis
so what you do is you can figure out
some test systems to do the testing
that are configured like your production
environment on a similar network which
is much better than testing the apis in
the sandbox why because when you go live
all the fun stuff happens and you see a
lot of errors you didn't think you'd
ever see before and if you just test
against the sandbox
i can guarantee you 100 you're not going
to know what to do
if
i give you a sandbox to play with that's
a test system and a similar network
environment
when you see errors the probability of
you knowing what to do and being able to
address the issues is significantly
higher
and again
this is not something you pay the people
in the nice suits to say nice words
about
this is something you've got to do on
your own because you are allowing
programmatic access to your environments
this is not downloading pdfs like a
patient portal this is not downloading
html occupation portal this is
systems interfacing with yours that are
not yours and you have to be very very
careful here
so if you find issues you gotta let your
leadership know first
and here's the deal and i'm going to say
some things you're going to piss off
some cios right now
if they ignore the issues or if they're
profoundly ignorant and i have sadly
found a lot of people in healthcare
leadership positions that are profoundly
ignorant
do it anyway make sure the right people
know and document the living heck out of
the security issues that you find
and i'm going to go on record saying
this
ignorant leadership is no reason to
avoid
security what i've done in my career
has been tell cio's
you're not doing the right thing
this is what you need to do to mitigate
risk to your patients
and if they tell me don't do it a couple
times i've had to do it a perfect
example when i rolled that helped roll
out windows 7 at my last job many many
years ago i had the cio tell me to stop
work on it
i told them no
because i had people telling me
i'm buying laptops now that don't
run windows xp they only run windows 7.
so i need to have windows 7 or we can't
get people taking care of patients
laptops
so we made the best choice for the
patient and eventually the cio came
around to it but the way i look at it is
ignorance is no reason to stop security
work
and if you are dealing with leadership
that is being ignorant
do your best to protect them from their
own best interests and keep the interest
of your organization and patience in
mind
thankfully my organization i have a
really good boss in tim tarnowski
and i don't have to do this with them
also
we take a look at patient advocates
patient advocates are
[Music]
an
underutilized resource in health care
they've helped
many people
deal with
complex issues
and
concerns at the worst times in their
lives
so
i know a couple of them they deal with
people that have breast cancer or more
advanced forms of cancer that is the
absolute worst time in your life when
you have advanced cancer you need all
the help you can get
these are people that are susceptible
these patients are susceptible to scams
they're susceptible to all sorts of
things of people
with bad intentions trying to drain
their wallet
patient advocates deal with adversity
and adversarial behavior
better than your average healthcare
organization does
so here's the deal
i as a representative of a healthcare
organization cannot stop a patient from
downloading some of these applications
that prepare to help them with
healthcare data using fire that may have
privacy and security issues without
potential information blocking penalties
and complaints to the federal government
patient advocates do not have the same
restrictions that i have
they're not providers
they're neutral they can advise they can
warn
this is a new area and realistically
when you're dealing with a sickness like
cancer or covid
you're not in the best place to make a
judgment call
you're thinking about other things much
such as
how long am i going to live
or what's the quality of my life going
to be
and we need to make sure that these
patients get good guidance at the right
time in their life when they're at their
most sensitive
and one of my greatest concerns with
these applications is that people are
going to let the marketing buzzwords
take over instead of using something
that works
so we historically haven't engaged
patient advocates the way we need to and
i think now
they have the potential for really
helping us out
especially with these threats to patient
data
they and again i look at it this way
they're used to dealing with the
adversarial environment that can be
healthcare
i think they have some skills that can
transfer over to help patients out and
making the right decisions with the apps
that they use
so i look at it this way
keep them informed of everything you
find in privacy and security issues
there's nothing preventing us from doing
that
so what can we do besides informing
patient advocates of all the fun things
that we find
first of all we do our vulnerability
scans
we start with the outside the inside all
the vendor connections all the vpn and
rdp that no one thinks that
the it organization knows about
and also do a scan of your software so
many people have installed your caseta
agents
or others
and also take a look at your container
environments and all the work that they
said they did to security containers
because i can tell you they didn't do
that work
i have found one of the biggest new
challenges in healthcare has been with
people putting software in docker or
kubernetes and saying it's secure and
the only difference between that and
insecure software in a linux box is that
it's in a container
so what can we do next let's take a look
at what these fire apis are going to
connect to ultimately
and take a look and do a data flow
analysis so
patient connects with an app
sends a fire api call what systems is it
going to connect to
what dependent systems along the path is
it going to hit
and it's going to light up like a
christmas tree
because
what you had before was oh it's only
going to connect to this one system
well you're going to realize there's
about 20 systems in the path and you
have to understand what they all are
and one of the big challenges we found
in healthcare was that a lot of people
like to reduce scope to minimize risk so
they look better on the risk assessment
before they handed in senior leadership
i can tell you
there is no greater way to look like a
failure than to do that
this is not a time for reducing scope
especially with the existential threats
that we're facing to our businesses you
have to take a look at security along
that entire path
and so for all those dependent systems
you find from your dataflow analysis
do your analysis and assessments of
those systems that you find
don't descope because here's what's
funny i first started doing risk
assessments 12 years ago
it seems like every system that i was
told to scope by leadership mysteriously
ended up back in scope
later because of some other reason for
risks so the scoping leads to re-scoping
anyway so don't do scope
and so what you want to do based upon
your risk analysis is develop some good
short and long-term remediation plans
for these systems
so big one here patch
firewall segment change those default
passwords
turn off your unnecessary services
if you've got
privileged account management like
cyberark use it and develop good
operational plans take good backups and
store them somewhere else
and for your long term yes security is
now think in the long term
get current develop your plan to update
and upgrade every so often and keep a
good budget for running the system
well
and with
it we haven't seen a lot of good
long-term thought we're really trying to
change that here but again
that's your short and long term that's
to basically maintain the system
now we get to the fun part which is api
testing so you've got to develop plans
to do full api testing we recommend
using that purple team approach
again thanks bryson
this approach works incredibly well
because it helps you work with your blue
team to
go in there try and break these apis
trying to understand how these systems
work
and really try and programmatically look
at them
from an adversarial point of view
and if you can't do it yourself there's
a lot of great companies out there some
of whom are watching today who will help
you do so
and they'll help you develop that
testing plan and help you test
but when you're done testing you've
actually got to follow up and keep up
so you discover some high and critical
issues you got to address those
immediately you got to log them ticket
them and track the resolution if you've
got third party vendors you're going to
be following up
treat your third party vendors like you
would your internal systems
and again the approach that my
organization is taking
and the one that we recommend all
healthcare organizations take is to do
that purple team test at least annually
and when you have a major system upgrade
because here's the deal
what we've found with a lot of these
apis has been that
when you upgrade systems sometimes you
have some pretty bad regressions on
security issues a lot of organizations
aren't as agile as they need to be
when it comes to pushing fixes they
found or made
back into the next version of the
product that's still under development
so a lot of companies have done a great
job improving on that microsoft being
one of them google being another
but not all companies are microsoft and
google
so
we've got to make sure we're on that and
we keep doing that
so
with that
i'm going to follow up here and thank
you all for your time today
will you open up for any questions and
here is my contact information
so thank you all for your time thank you
alyssa for the incredible presentation
that led into this and have a great day
everyone