[Music]
hi everyone and welcome to my bio hack
panel i am very fortunate to have
two friends with me today ken carter and
eric dolphy and today we want to talk a
little bit about red versus blue versus
green the logical disconnect between the
different teams and large organizations
uh gentlemen please go ahead and say hi
to the crowd
i'll go first hey i'm eric i work at a
medical device manufacturing company
and i currently position in an
enterprise role helping oversee and
mentor teams build their applications
and get them out in the public app
stores
my name is ken carlo i'm a technologist
uh i split my time between boston and
washington dc
i like to do a lot of different things
around security i came from the finance
and healthcare background so i spent a
lot of time thinking about not just how
to keep data secure for individual
companies but for individuals themselves
well i thought we're going to talk a
little bit about the red versus blue
versus green
now from your experience how do you
think in a large organization's
these three teams tend to work together
do they do this well do they struggle
and what are some of the commonalities
you see in those struggles
well erica
i'm gonna let you take a swing that's
even on mine sure yeah so i
it really depends on the team my my
background i came from a business unit
that specialized in
devices that
one of the panelists here is very
familiar with
and
working with teams to build maintain
release these applications
across several different releases doing
things like penetration testing
taking that feedback in and making
mitigations or making corrections and
such
when when you get to large teams uh my
my experiences have been
mixed depending on the project where it
is in its life cycle is it a new product
or is it something that you know is
going through maintenance releases and
different kind of situations where
maybe there is a dedicated security
engineer
on the team ejected in the project from
day one
or maybe you have another project where
due to rollover or things like that you
know people leave the company
and and we have to onboard um the
security engineers into our new product
or our existing products so it can be
hit or miss and it's i've had
a number of different experiences but
a lot of really good ones uh we're we're
working hand in hand um in groups and
it's it's definitely been an evolution
for me as i've been at the company the
last seven years
um right out of college
where it's like you know i'm i'm trying
to just absorb and meet all these
security engineers regulatory engineers
privacy engineers
these seemingly different silos
at least for me my experiences have been
that um
i've i've been fortunate enough that
they've been broken down as in in some
fashion and i i get good visibility and
collaboration with the different teams
i think my experiences are pretty
similar to yours but at one point in my
career path i decided to really
specialize in things through how to
learn and do offensive cyber so that i
have a better idea of
how to secure it
and i discovered that
most companies really don't accept nor
invest into red teaming with a lot of
stuff like chaos engineering so
companies are perfectly happy being
situated with the notion that if a risk
occurs i have a mitigation effort
and when the risk does occur
i'm liable for this amount
so the
solve is never for
keeping something safe the solve is for
how much can i lose and expect to
survive so it's a very different world
for me on the red blue green team versus
risk management so from a pure security
side it's really fascinating where
i often find people who do invest in red
teaming to really understand criticality
and vulnerability in their business
model
versus those who don't
i think when it comes to vulnerabilities
here
one thing at least the person sometimes
tends to forget is the
person on the other side that has the
device the one that that
inevitably is at the end of it all
um what i have learned from my
perspective is that we often speak
different languages and we have
different perspectives and context
and it's only now recently that i've
learned thanks to eric a little bit
about the green team straight stresses
and pressures and context that i was
able to shift and i do believe that if
we understand the whole ecosystem or all
sides of it that we are able to actually
communicate effectively
now i have another question and this
might be a touchy subject in terms of
looking at the recent breaches in
healthcare
is there
one instance that you can say you know
this was handled well
that to say i can't think of an instance
where
a security side was handled well
but the
mitigation so the legal impact of the
business that's handled pretty well
right so you know at what point can we
get enough lawyers to
fight against the company going down
that part is happening really well from
a business aspect from a security aspect
i think the better question to ask is
why are we prioritizing different parts
of security over another when the
objective is to secure something and
that fundamental objective wasn't
accomplished
but i mean it's often said that you know
security gets a budget once the breach
has occurred but it's little it's often
little too late
um
in the whole instance of things eric do
you have anything to add to this um
yeah i don't i don't have any personal
experience um with any intrusions or
breaches
in in the industry as you know as a
consumer
being a affected you know your email and
password or whatever
for any number of things whether it be
personal applications health
applications fitness applications
anything that is you know private
information phi pii location information
it's it's a real drag to consumers
that
application developers
you know either they don't know or they
don't care or there's
other constraints like it you know maybe
time cost money etc where things just
don't get built the way that they should
be from the get-go
and one one thing that i i take pride in
my work is you know when i
get a penetration test result on an
application
i'm going to go read these and not only
like understand but plan to make actions
on them before an application were to be
released
or
if i obtain this information and provide
it to other teams to say hey this is
something that you know might be a
common mistake if you're a new team but
building out a new application and you
just don't know any better so let me
enable you to make the right decisions
to
have that long-term success so i i don't
have any experience with the breach more
of the you know preventing things
um so that they don't happen or you know
if if they do you know we've got
mitigations put in place that it's
things like if there's a denial of
service it's a single individual it's
not a systemic thing building uh privacy
by a design and security and design from
day one
if i may pull on that rather that's
really really beautiful i love that
pattern and to kind of pile on that for
me the way i think about screw today
even outside the healthcare just in
software in general is to be able to
bring that teaming to the beginning to
be able to have security as a
fundamental principle day one i prefer
to take my security folks instead of
having a separate team to embed them in
each software dev team so that because i
can never expect
or
even
anticipate any software personal
developer it's going to be a security
access i can't count on that so to hedge
that i'd rather have skateboards
inserted they want
yeah if i look back and reflect on a
requirement that i had reviewed in the
past
from a security engineering colleague
and it was you know very vague and
generic and in my background as a
software developer
i don't have a formal security training
background i don't have
that number of years experience dealing
with these things it's like like i have
to ask
well what do i do about this how how do
i do this
and whether it be you know reflect on
open source to find a library that does
what we're asking you to do
or you know leverage another team it's
it's really good to
be efficient at communicating and
collaborating with the individuals that
know and not having everybody
responsible to know everything
so i'm kind of like crusading at the
moment to try and teach developers
security and forensics
so building in the information that we
need to detect prevent and investigate a
breach
and that is only done because i mean
let's face it we are good at defense and
you know attack but we're not the ones
building the software
uh we're not the ones influencing the
code or what is getting written that
that's in the hands of green
so i think i almost see blue as
red basically strengthening the code
that's produced by influencing the
knowledge that's passed on how do you
guys feel about that
i think that's a really accurate read on
being able to divide and conquer the
team but to have the one cohesive team
to be able to move forward with the
entire stack going forward versus having
separate responsibility i'd rather not
have this waterfall event of thinking
security after the fact i rather think
about it way ahead her though
yes so you i agree completely there with
you that we should i sometimes feel we
do a thing that i call dev opsec where
security is always lost in the line
where we should be doing
devsecops all together as one team as
one collective
i often feel like we're trying to fix
things at the end of the pipeline where
it's super expensive for an organization
for a development team to handle it
but we don't address the things right at
the beginning
now i have another question for you guys
um taking into account
the context of um
[Music]
medical devices that have been involved
where do you see the future of this
going in terms of dealing with legacy
devices that at some point become
vulnerable
do you guys think that will be a problem
or do you guys think that it's not going
to be a problem because we're solving
them and updating them at the moment
so
to step into the light of
new devices coming online at
my workplace or in competitors or in
just in the medical industry in general
bluetooth being a really popular
technology because it's on everybody's
smartphone everybody's got an app for
their product
these devices are going to remain
connected to the smartphone as long as
the smartphone is in the embodiment that
it is but to your point about the legacy
devices
um these these devices are going to
eventually be phased out you know they
have a certain life expense expectancy
for for batteries and support and things
like that
but but there's always a risk of you
know every every device it just takes
time and money
before you can find something and we can
only do our best to to make sure that
the legacy devices get just as much care
as the new products do as we go forward
i think it's also a really complicated
balance between the consumer and what
devices can be easily changed at what
can
vice the
support of the limited devices even
google has now made a statement of how
they're going to discontinue
connectivity to older android versions
because of circuit risk and i imagine
that while bluetooth client insulin
pumps could be changed out because
they're external a bluetooth connected
uh pacemaker or even the heart control
device i think may be a very very
different problem
so i think there's gonna have to be a
balanced somewhere
of how to prioritize what you are going
to support legacy wise i think that
might be the best thing i could think of
to try to
help humans live longer
like one of the things that i learned
very early on in my research was that
yeah these things are connected to
patients i mean i've never done since 19
but you know sometimes it's a question
to patch or not to patch um
these cardiac devices end up in surgery
for a patient that wants it to be
removed due to security constraints i
think it's very important how this
message gets communicated to those
patients affected a lot of them are
elderly or a lot or not technologically
savvy but now do you guys feel that the
medical you know their health care
professionals have actually caught up
with medical technology and are able to
explain cyber risks and advisories to
patients
um how do you think
that could be combated if it's not done
as we expect which should be done
i feel that that's a matter of what that
person's priority is i think that a
medical professional priority is going
to be explained the health benefits and
risk
and
i think there's gonna have to be ways to
quantify
cyber risk is part of health risk for an
md to really care about and be
passionate about explaining it and also
have the bandwidth to even try to get to
the adaptive why it's critical
so for me
when when we're thinking about
education to our patients within our
systems within our applications
um
there's a couple of different
personas that kind of emerge individuals
that just simply don't care you know
they put everything on facebook they put
everything on the internet they use the
same password for every single thing
because that you know maybe that's how
they remember it or they just
don't know any better or don't care and
then there's individuals that
you know only like like myself i only
buy apple products
i have the mindset that
my data is better protected in this
ecosystem compared to the alternative uh
but i i make this
conscious choice about it and you use
password managers use the
secure private email all these kind of
things that
um as as we see more and more devices
being introduced the market that are not
just for the elderly because you know
there's there's new
diagnoses there's new technologies that
you know innovation every day uh we're
going to start to have more and more
users that have more of the
the mindset of i'd like to know what can
i do
and for that we can certainly provide
education whether it be materials that
is directly
to a user within the application like
when you're setting up your email and
password just mentioning you know it's
got to be this number case sensitivity
length strength etc and please remember
it please don't make it the same as
everything else or when we're educating
clinicians and field wraps about how the
technology works to kind of make sure
that there's no concern and the patients
really get that peace of mind because
they are trusting us
to
keep them going or or to help them in
any any way that we can through the
device or therapy that we're delivering
so there a lot of that education comes
in where
you're you're teaching and providing
that information is a really good way to
achieve that
so i i i have some questions
specifically aimed at the two of you um
because i think the perspective that you
come from is defensive can
what motivates someone to look into
hacking medical devices now i get asked
this question a lot and people look at
me strangely like this should be
something wrong with me right what is
your motivation behind you know doing
penetration tests on medical devices
and so you know breaking into them
sure my personal motivation is to uh
help a lot of my friends wear these
devices right like since i am of a
security-minded person i rather kind of
give the shot to c or the
vulnerabilities i can expose
and there are and the second half of
that is that responsible disclosure how
can i communicate with these companies
to effectively disseminate information
in a secure way so i don't actually risk
human life so my personal motivation is
to help friends help human life
so no plans of all domination yet
now eric say same question just slightly
different frame for you
how does one become a
software developer or engineer for
designing medical devices and what is it
like knowing that you are designing
something that has a physical impact on
someone's longevity
so a couple of my personal experiences
for me
you know fresh out of college having a
computer
engineering degree working with
microchips and
regular computer code and
whatever may be in college getting
getting a job lined up out of school as
an associate very entry level
but very quickly becoming attached
because i have
family members extended that
have our devices and then you know
friends and colleagues that do it as
well and so there's there's a personal
connection that
is a drive and has been a drive for me
to accelerate and achieve in this space
but generally speaking you know
you you can do things like learning
about security learning about building
reliable applications learning about how
to build something that's private by
design
and not you know collecting data
unnecessarily just to be able to make a
profit that's not at all what we're in
the market for
because we're in the life-saving
business not in the data selling
business
so it really it really depends on
where you're looking to get into things
if you want to be more developing the
product i can speak to mobile
applications you know i'll just dive in
a ton of resources online to get into
mobile technologies
can't really speak too much about the
embedded firmware devices
or the implantable devices in terms of
how to get into that game or that space
but it is certainly
a different way of thinking uh even from
a mobile's perspective
like if i compare some individuals that
work on server technologies you know the
server will scale we host things in the
cloud every company does it um you know
you just put more money in the server
will scale you got more resources you
work in a mobile space well
you know your application is limited to
what apple and what google want to give
you you go over that budget you know
they're going to terminate your
application and then the user has to
relaunch it to resume whatever they were
doing and then the embedded devices you
know being very very particular about
every single bite of memory management
so there is different levels of
scrutiny and different areas and
different constraints depending on which
part of a system you're building
that are all
very very interesting and equally
different in their own way
i think what is very obvious is that the
motivation behind this is
into making it safer more securely and
better built
even though we come from very different
backgrounds for me it's more about
how do we detect
and investigate that something's
actually happened on a device do we have
the capabilities to forensically look at
these devices and even know that they've
been a target of a cyber attack
that's kind of where i my passion lies
and the reason being is we don't know
that there hasn't been a cyber attack
because we simply don't have the
information to do so
but again also i have a device so i
wanted to know that
my heart is safe in the hands of the
people that bolted
and i actually got to meet the developer
behind the firmware on my device and it
was a very emotional meeting because
you're looking at the person's
mind that's sculpted the thing that
every day saves your life
now looking at what we can do better
going forward can you you talk to big
organizations that medical manufacturers
are big
how do they successfully navigate
building secure software and and
navigate this torrential
road to
success
that is a enormous question and one i
think about all the time
to a point where i am actually starting
to write something about it so there's a
lot of processes out there today right
there is iso at 31 000
uh there is the traditional risk formula
right like is it you know what's
likely versus what's the
level of consequence probably both is
the is predicated upon the quality of
data inputted and still gets the best
it also it largely ignores the treatment
process so i've been thinking about my
experience writing software and how i
produce software and how i put my
security embedded and i've been coming
up with a concept called the risk budget
and the risk budget is really the is the
how do i talk to people equally on both
sides how do i have my security team be
able to express security problems to
your concerns and how do i have
non-practitioners the rest of the
organization who are not having a
security to be able to come to the table
and still have a conversation so that's
something i'm reframing recently and
kind of
run writing out the process that's been
successful for me
but at the end of the day what a risk
budget is this you want to subtract
the
logistical problems from actual security
problems and do the actual security
around what's important critical because
you can't secure all the things all the
time and you sure cannot secure
everything all at once for
prioritization criticality and a plan to
go forward
so in in my role there's a couple of
different things that i can do i'm doing
planning on doing
things like you know if you look at
certificate pinning to prevent man in
the middle attacks on on your network
stack this is something that you know
you're not going to go and read about if
you're checking out apple developer
android google developer websites
they're just going to show you how to
make the network call they're not going
to tell you why you need to do this
you're only going to know why if your
security engineer your your colleague
that's done it before and
for either reaction or preventative
measures has told you you need to do it
then you go do it things like that where
it's it's simple enough and it's
it
takes a lot of risk out of play just do
it
make a standard uh build in tools that
you can inspect you know hire pen
testers
do internal testing make sure that your
environments are set up to you know
manipulate in such a way that you can
prove that your application is doing
what it's supposed to be doing other
strategies you can put into your
applications for other security
mechanisms like preventing denial of
service on on your implantable device or
maybe denial of service on the
application that connects to that
implantable device these are more ideas
that you can rinse and repeat across
projects but not necessarily have the
same implementation because as you know
like as an example a
cardiovascular implantable device is far
different than a diabetes pump in terms
of what it does you know one delivering
electrical therapy another one
potentially
delivering insulin or or other
devices just in general maybe they don't
do any kind of delivery of therapy and
they're just reading data
so
between creating reusable components and
tools that you can put into place and
enforce advise encourage teams to
implement
and then building more of a here's a
documentation strategy on setting
yourself up for long-term success making
sure that you're checking the right
boxes and doing your due diligence
and then be maybe uh to call you out on
a couple of things
the conversations that
you know that we've been working on
um we're
talking about developing logging
as a first party
feature of an application for any number
of reasons whether it be the developer
the forensics engineer friend that
you've got
or it's the field tech support who
whoever whoever it may be
building robust logging solutions to
enable you to analyze items during
development
during your initial release and all the
way through
your production
and through legacy and retirement to the
device monitoring things at all points
in the life cycle of that product
so i i kind of thanks for calling me out
like you know i'm the one that's hitting
the panel i'm not supposed to be called
out well played um i think what i
realized is we all do instant response
all of us red blue and green and i you
know how i came to the conclusion is
like eric was explaining to me that they
do in field investigations when they
have to debug something i don't think
but that's type of incident your
incident is that your device or your
application start functioning
and then as i thought from when i've
done some you know paint testing and
reverse engineering well that was an
incident as well i was investigating how
to break into something and then you
have me on the forensic and incident
response side that looks at a security
breach
so we all end up looking at the logs
but often the logs are designed by
developers board developers not
necessarily taking into account what we
need for security
or what we need for
uh investigation and sometimes even
leaving trails for red team to find
i don't know if you guys know the
statistics on insensitive information
disclosure and data breaches recently
it's said to be 80 sensitive data is
disclosed
during a data breach and a lot of that
information comes from the logs
why do you guys think that there's so
much sensitive data being leaked into an
application log
so one one thing might be
the
understanding of trust between systems
like you know if if i am putting a log
on my app and i i send that log to my
server you know i
in in theory it's encrypted
during rest and it's encrypted during in
in transit
um and if if i'm naive and don't know
any better
and just assume trusting everything then
you know i'll go about my business but
uh if if you've had conversations at
length
um with another member of another color
team you might realize that you know
it's it's intended to be placed in this
data warehouse or secure storage but you
know somebody might by accident
find some information come across some
information
or you know if you're analyzing
a
bug
in a mobile app and you look at the logs
and there's information that a developer
put in there
not knowing or not considering that it
was
example phi or pii one of the corrective
actions you can do is in your logging
requirements
design it such that you are not putting
that information in there maybe you're
hashing identifiers or you're
obfuscating these pieces of information
that is a one-way hash algorithm so if
you if you hold that information
in another context
you can run it through the same one-way
hash and then you can resolve the same
number and then you can verify that your
logs are
emitting the pieces of information
connecting to the things that they're
supposed to be doing so there's a lot of
work that can happen just by
making a developer think in a different
mindset about what to log how to log it
why to log it who's going to have access
to it
and
how long is it going to live
very well thought out the other the
other thing is the on the whole
transport of logs
the thing that i would worry about i
guess from the wrestling side is that i
tend to use opportunities like where
lots go or how logs are transmitted it's
either ways to expo data or even as an
attack service
so if that
making the transformation logs used and
just for me it's a way to get in
so i think there's also gonna be some
kind of a meaningful way to talk to both
the set team the logging team and the
dev team about how to be transformed
logs in a secure way and how do we
ensure that it's a one-way ingress
you know this is the kind of thing that
i like hearing because this is the thing
that people don't often know but the
logs are all often the key that opens
the door
to the red team
now
based upon me talking a little bit last
question that i have i'm going to ask
you guys to zero trust or not to zero
trust
i think that's a hard question for me to
consider when there are so many
in your and i guess in the this case
edge devices kind of moving around
and
i don't feel it's the device itself they
even have them locked down it's the
communication between device and the
whatever the
data devices so i guess in most
instances there will be a bluetooth
connection so what can we do to optimize
security around bluetooth we're making
this assumption and accept from the
console matching bluetooth that is about
the screen built in
but simultaneously there's a bunch of
problems around the authentication
scheme around as well
so for me
i don't think it's so much as a question
around to zero for the nozzle trust
because of the fundamental connections
the bluetooth connectivity between
is the biggest attack surface then i
would worry about securing that burst
so i might have a little bit of an
interesting um thought process on this
being in the mobile space
i don't only just think about you know
is is the iphone platform as a whole
secure or is google
secure
but i also think about
is that third-party library that saves
me a little bit of time
should i be using that
uh should i just learn what it's doing
and write it myself and control it
myself
or should i research you know an
algorithm
that does whatever it needs to do should
i research it and write it by hand what
what is the trade-off to accept some
library do you just trust it blindly or
do you do you use it with
caution and i i always tend to
write things by hand if if i can
write something that we control
internally and share it across the teams
and have revisions on it you know open
source is a wonderful place
you you see open source
and you then have that source too in
public visibility which you might get
some benefits of hey people reporting
bugs and then you can go inherit and fix
those things through the the updates
that are made to the repositories but uh
my my natural tendency is to not trust
anything
um and to build mitigations
many times over as often as we can
to make sure that you know doing a risk
analysis well what if what if the the
flash memory is compromised well then
you encrypt your data to make sure that
it's not encrypted well what if what if
they can get the keys well then the key
is different place than where the data
is so you know building in several
layers and walls
around it
at some point you're going to have to
trust
something
but when you have mitigations put in
place you're burning down that risk as
much as you can
i love that uh that's something i worry
about constantly that's the software
supply chain right
and uh
for me i
tend to go towards the open source rat
more and more and trust certain
libraries but check and verify for
myself before blind using so i tend to
corral how
my developers can get to certain
libraries pull down like i tend to
control my dev network so that folks
can't just go windowing out and grab
what they want there's a verification
process of what is trusted and how we
can maintain it i try not to fork
existing resource projects because for
me it's hard to maintain things so
there's now a separate domain knowledge
necessary to be in a certain team which
i try personally to avoid granted i am
not creating that device like yourself
so i don't have that high lit mr cross
but for me i also think about
sustainability
so there's there's definitely a
need sometimes to use a well-established
library that specializes in one thing
you know they are the experts in this
case not
not me as an individual developer like
me as a team
with my colleagues so there there is
trade-offs and and
making sure that updates are made timely
uh to the field where vulnerabilities if
they're identified they get patched or
you know new features or whatever it is
that's benefit benefiting the patient
um
that there that all comes into play when
making those kind of decisions
so to end our time off i would like to
end it off on a positive note what is
the one piece of advice you can give to
manufacturers
engineers or someone generally in this
space
um or what is the one thing you want to
highlight that they've done well you
know something positive to end it with
because the world's in turn more school
with over two years on um so let's end
it off with a positive note can you
europe first
thanks well first of all let's say
thanks to inviting here has been great
uh hearing folks like yourself and eric
talk just made it warm and fuzzy that
things have obviously done very very
well in mechatronics
uh so kudos to metronic in your teams
as for advice uh
stay curious
uh it's how i survived and secure the
game this long for me to always wonder
not always be
scared
you know security is a weird frontier to
be in and at times that can't be scary
but fear should not be
the motivator or the demotivator it
should be the end goal of how can we all
get to the same applicable share of data
and everything else
yeah i'm i'm really excited for the
future i i think you hit one of the big
things that i had in mind about being
curious
as as a mobile developer that likes to
partake in the annual developer
conferences each summer
eagerly anticipating the fall release
and all the new things you always have
to be on top of things to
learn the new technologies
like let's say you're not building
application support for the fall updates
at a compile time perspective but your
users are going to go and install the
latest operating system because that's
what they're told for marketing
from the big apple and and google
campaigns that they see all over the
internet and on tv so my one of the
piece of advice i would have
would would also be to
stay curious go research new things
technology is ever-changing landscape
especially in mobile it changes several
times a year and these big companies
have reacted quite well to the global
circumstances by providing new
capabilities and technologies in their
sdks like health kit adding symptom
tracking that you can do
for if you're making a covet application
for a state or a country like these are
these are awesome things that are
happening and it's super exciting i
can't wait to see
what
big companies and small companies like
make with what's what's coming
thank you very much james from my side i
just want to say to the community if you
are curious about medical devices and
you want to research them and you want
to break them you want to figure out how
to work do it uh take the chance if you
find something dispose it responsibly
if you're a developer and you're curious
often developers make the best pen
testers because they understand how the
applications and devices are full so
just be curious be
excited it's a whole full circle you
don't have to subscribe to a single
color and say i'm only green i'm only
vermont red in the fact that all we're
actually all working together towards a
common goal
so from my perspective as a patient also
thank you very much for building these
devices because otherwise i wouldn't be
here um and it's now since 19 and i just
celebrated my 34th birthday
um so i'm very happy with my device um
and thank you very much for joining me
and that is all we have for you guys
today
thank you