March 4, 2025 • 26 mins
"Putting this effort into the bug bounty helps us identify any sort of gaps that we might be missing, plug holes as fast as we can, and reward the researchers for all the efforts that they spend with us."
Being asked to embrace hackers may sound counterintuitive. However, in today's fast-paced world of healthcare security it's a strategy worth exploring. Brent Ufkes is a staff security engineer at Redox, joins for a conversation about bug bounty programs. He shares how these programs can become a game-changer for organizations like ours.
This episode explores:
- Understanding Bug Bounty Programs: Brent breaks down the essentials of a bug bounty program, how it contrasts with traditional penetration testing, and the ongoing collaboration it fosters between organizations and ethical hackers.
- Benefits Beyond Security Companies: There are a number of people that can benefit from bug bounty programs. Brent shares insights that it’s not just for security companies; any organization that offers a solution can find value in welcoming ethical hackers.
- Healthcare’s Unique Security Challenges: With considerations to compliance and patient safety, the conversation delves into why healthcare organizations, in particular, should consider bug bounty programs to safeguard against an evolving threat landscape.
Embracing bug bounty programs is a way to preemptively uncover vulnerabilities and enhance security postures, especially in the healthcare sector. Are you curious about how a bug bounty program could be implemented in your organization? Tune in to "Shut the Back Door" to better understand how this proactive approach to security can transform your stance in the digital realm.
Resources
https://redoxengine.com/
Have feedback or a topic suggestion? Submit it using this linked form.
Matt Mock mmock@redoxengine.com
Meghan McLeod mmcleod@redoxengine.com
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:03):
Welcome to Shut the Back Door brought to you by Redux.
Shut the Back Door is a health care security podcast
dedicated to keeping health data safe one episode at a
time. I'm your host, Jody Mayberry, and joining
me this episode are two guests.
Well, I say guest, but by now you're used to Megan McCloud.
(00:26):
Megan is the senior security engineer at Redox. Hello, Megan.
Hi, Jody. Nice being here again. It's great to have you. And our
special guest this time is Brent Uffkis, a staff
security engineer at Redux. Hello, Brent.
Hey, folks. Thanks for having me. Well, Brent has joined
us this time because we're going to have an episode
(00:48):
about hackers. A hacker's welcome benefiting
from bug bounty. So this
this is a interesting topic because we hear about
bugs all the time. But, Brent, what is a bug bounty
program? Hey. Yeah. A bug bounty program
is a form of crowdsource security testing
(01:12):
where ethical hackers actually look for vulnerabilities in our platform.
It differs from a traditional penetration test
in the sense that it's always ongoing.
Anybody can view our program, attempt to
hack our products, our platform, and we will be
(01:32):
as responsive as we can in terms of any any sorts of findings or any
questions that the researchers have. A traditional pen test
is usually given, like, a designated scope. So they
get like some form of hours that they they are allotted for
testing. Maybe it's forty, eighty, a hundred sixty hours
where they can spend time testing for us. Whereas in a bug
(01:54):
bounty program, it's consistently ongoing. So researchers at any
time, at any place in the world can log in, try to find issues
for us, start that conversation with us, report
any sort of findings. It's truly a
fascinating collaboration between the researchers and us.
When we're talking about ethical hackers, Brent, I'm I'm curious
(02:17):
your opinion on, like, what is an ethical hacker, and
then how are we finding these ethical hackers to actually
do this? Or or, like, we're not just, you know, posting an ad in Craigslist
or something like that. That's a good
point. A lot of times we work in conjunction with some sort of
tool out there. So there's a couple of different platforms between,
(02:39):
Bugcrowd, HackerOne. Those are some of the big
names, but there's also other ones and they all have their own benefits.
But typically, users have to sign up for
accounts on those sort of platforms to do some of the initial vetting to make
sure that they're authorized to do this kind of this
research. From there, the tools will
(03:02):
maintain some sort of, like, reputation with the researchers to make
sure that they're actually ethical. They're looking for
problems that the companies are interested in. They're reporting and
being responsive in a way that works well with
the team that is actually putting on the bug bounty program.
And there is different ways for us to kind of manage who we
(03:24):
want to be a part of our program between public,
private visibility of programs. There's all sorts
of ways that we can kind of look into and vet them. We
can ban folks that are giving us not
super helpful reports or doing sort of malicious activity that we
see in our application. We can invite researchers
(03:46):
that are particularly skilled in the area that we're looking for testing
on. Most of these tools have ways for us to
interact with the community of researchers and help boost our
engagement. Nice. Yeah. So basically, this gives us a
way to reach out to the community of ethical hackers, but we still
get to set the ground rules. And and there are still regulations
(04:08):
around it, not just a a free for all for anyone to to mess with
our systems. Yeah. Yeah. And and a lot of times, it does focus on,
like, public assets. So things that you would typically be
able to access if you were any person on the Internet. So, you know, we
all have our or not we all, but many
organizations have public assets that they like to test because
(04:30):
those are the things that are wide open. It's like your house. If you're
looking at a house, there's all sorts of entryways. And
somebody that has skilled assets might know how to get into that house
a different way. And so being able to focus on that public surface
area, a lot of times is one way that we can, you know,
boost our engagement, get eyes into some things that we might typically
(04:52):
overlook, etcetera. When it comes to these bug
bounty programs, I I can see why it's a
benefit for a company like Redux being a security
company. Who else should look at using bug bounty
programs? Is it just for security companies like yours?
No. I don't believe that it is for companies just like us. I
(05:15):
think that any sort of company that's actually, like, offering a
solution could benefit from it. Most most
security researchers are in it for a number
of things, whether it be, like, personal gain, financial
gain, education. But there's issues to be found in all
sorts of products. It might be some sort of hardware
(05:37):
product that might have some defect. It could be software. That's
the the common one typically seen with the bug bounty programs. People are
wanting to hack websites or APIs,
but some might offer an operating system
as a solution that would have issues. Some might
have just hardware or maybe like mobile applications.
(06:01):
And any company that ships something sell some sort
of tool could benefit from it. Well, with you talking about
who can benefit from it, let's just follow that path a
little further. Talk about more of the benefits of
having a bug bounty program. Yeah. I think some of the
main benefits here are that you get testing that's
(06:24):
external to your company. You're not diverting resources within
your own company to or own team into
testing these things. You get a fresh set of eyes
that might be more skilled in certain areas than your team is or just
has a different perspective on it. When you work at one
company for a long time, you kind of have a general understanding of how
(06:46):
things work. And having that fresh set of eyes come in and say, hey.
Let's just spend this time to look at this. Oftentimes, we'll look at it in
a different lens than we will. Access to testing
around the clock is an obvious benefit here, whereas
in, like, a typical pen test, we are reduced in time. And
when we have internal resources, you have to focus on
(07:09):
whatever you we perceive is the most important or that we might get the
most bang for our buck. But having these other folks that have
different timelines and different interest in areas allows
them to get deeper into your system in ways that you typically wouldn't. And,
generally, it's pretty cost efficient for
finding these vulnerabilities rather than actually waiting for
(07:31):
something to come up that's bigger and larger. When using
researchers to do this sort of security testing, we're able to
do it in a manner that they test in a what we put up is
is like a staging environment. So that the researchers, as they're testing
our health care application, they're not actually testing it against
real production data. They're testing it in a
(07:53):
isolated sandbox of an area, which reduces impact if
they do find any sort of security vulnerabilities. And helping us
catch it in that staging deployment helps us prevent
the leaking of true health information or true
other sort of vulnerability information, which does help us fix
those things before they get to production. Yeah. So, basically,
(08:16):
we're seeing cost effectiveness on the front side
by being able to just pay for the bugs that
they find as they find them versus a full time employee, but then we're
also, it sounds like, seeing a cost benefit
from preventing potential issues in the future. This
is a health care security podcast, so, of course, that leads me
(08:39):
to ask directly about health care
organization. Why should a health care organization consider running
a bug bounty program? It's a great question. We
face some unique security challenges in health care between
protecting health information, people,
medical device security. So it's especially
(09:01):
important for us to actually protect those patients in
the end here by protecting our products, protecting our information,
ensuring uptime. And there's a growing threat
landscape generally between ransomware running
rampant, APIs being abused, supply chain
attacks. And really, this oftentimes is boiled down to
(09:24):
us having or to potential compliance considerations.
Any sort of vulnerabilities or issues called out by researchers could have
potential impact for compliance, which is essential to
staying up in business and in in this industry. So us
really putting this effort into the bug bounty helps us identify any
sort of gaps that we might be missing, plug holes as fast as we
(09:47):
can, and reward the researchers for all the
efforts that they spend with us. We're very
thankful that we have the researchers that we do and that we are able to
maintain a program that these folks wanna come back and keep packing
for. And when I think about health care, you know, it it is
a twenty four seven situation as well. So like you were
(10:07):
talking about before, Brent, having people to be able to test
continuously, not just on a nine to five kind
of timeline, especially when health care is not
dictated by a traditional nine to five, that seems very
important as well. This may be a whole new concept
to us when we hear about a bug bounty program and
(10:29):
the idea of hackers being welcome.
I've always thought of hackers or something you you have to watch out for, and
and here you're telling us we should welcome them because they can help us
out. How do you determine if your organization is ready for
a bug bounty program? Yeah. Typically, there's
challenges when it comes to actually supporting a bug bounty program.
(10:52):
So one of the biggest issues that comes up is funding
and how can we afford to pay out these
researchers for these findings. And the way that I like to typically think about
that is these findings would cost us significantly
more if we didn't find them or if they are found in some other unsafe
way. So when it comes to cost and cost justification, in the
(11:14):
end, you will save money by paying researchers to
find these issues for you. Another thing to help determine if we're
ready is generally, do we have staffing to support these
programs? It is an ongoing conversation with the researchers
to make sure that they stay content, stay active in the program.
So whomever is working and actually hosting the bug bounty
(11:37):
program has to be willing to be engaged with those researchers,
help throw them a bone, answer the questions, and help educate them on
how your tool works. They're testing all sorts of different tools. They're not just
focused on one. So however, the more engaged
you stay with the researchers, the more they're excited to come
back and do more for you. This a lot of times is their full time
(11:59):
job or just a side project, but they stay motivated
when they're getting consistent conversations with us
and they're getting paid for the findings and getting paid
well and competitively for their findings. And this one big topic
when it comes to bug bounty is we we have
to reward people competitively. There's all sorts of benchmarks
(12:22):
around how companies how much companies are willing to pay for
security issues. And so in some industries like
like the crypto industry, many of those companies are willing to
pay significant dollars for findings
because of the financial impact. And health care is similar in the way
that we need to protect this health care information. So payments are
(12:44):
oftentimes higher than what you might see in some
random tooling industry, like just like iOS apps and
whatnot. When you're talking about needing staffing on
the organization side, We've touched on a little bit how
they need to be able to keep the researchers engaged and all that. But then
what is the other side of staffing? So, obviously, when we get a
(13:06):
bug that comes in, what what goes into that then from the organization's
side? Fantastic question. So outside of just
receiving the bug, a lot of times we'll need to actually
dig into the bug. Is this a real bug? So for
our organization, it typically looks like somebody on our
security team is playing that middleman. We're reading through
(13:29):
the reports, potentially retesting them ourselves. But we
also sometimes get people roped in from engineering to validate
the bug of, is this expected activity? How difficult
is it to fix this thing? Sometimes we end up working with the
documentation team to say, like, oh, this is expected activity
or maybe not expected activity. Let's clarify in our public facing
(13:51):
documentation how we want this to be interacted with.
Takes partnership from all teams when we do receive those. We're
not really on an island here in InfoSec solely handling all the
requests, but we do our best that we can to to filter it down
and make it actually important for the other teams, help other teams
prioritize this work and articulate how important these security issues are.
(14:14):
Yeah. My perspective might be a little biased because I I do a lot with
the vulnerability management side, but that's where I see these come in is
is through the vulnerable vulnerability management process. And
like you said, that's where we have to make sure that we're interacting with everyone
to get the proper prioritization. So as long as we're able to
triage these as they come in and ensure that they are real bugs
(14:36):
and that we they are something that we need to act on,
that then kind of folds in my mind into the the rest of our
vulnerability management. Yeah. And to note on that,
it's often a question of, is our organization ready for a bug
bounty program? And many of these platforms do take steps
to making sure that you're actually ready to become of, like, a full
(14:58):
fledged public bug bounty program. And that can look a a
couple different ways, but how we typically have seen
it done is you start with a private bug bounty
program where you and you invite select researchers.
So these platforms might hand out invitations to newer users or
more experienced users depending on what you're looking for. And they come
(15:21):
in and they do some base testing for you to see, like, can we uncover
the easier to find issues? And once your report
volume, so the number of reports that are getting sent into
you starts to dwindle or hit a steady rate,
typically will increase the number of private researchers that can
come into the program up until the point in which your organization's
(15:43):
comfortable with the report volume that you are actually willing to go
public. When you go public, you experience
a bit of influx with reports between automated reports
being sent to real low hanging fruit
security scanner like reports, and your organization
just has to be prepared to see those. So sometimes it does benefit
(16:06):
you to run a pen test before you actually
launch this on your product or your feature just so you can have an idea
of what kind of reports you're gonna see for the first time. And some some
organizations stay hybrid forever. They'll continually run a
private bug bounty program while letting some of their
features be public. Some companies might have, like, a couple of public
(16:27):
websites, but some private products that they can grant access to those
researchers too. It really just depends on how much time you
wanna spend supporting the platform and how much
you're willing to give in. So, basically, you don't have to be all
or nothing with Bug Bounty. You can kinda control
the volume that you wanna see. So if someone is on the fence about whether
(16:50):
they should have Bug Bounty, there are intermediary steps that they can take
rather than just being everything public all at once and getting this flood of
reports. They're able to go ahead and tamper
that down a little bit. Absolutely. Yeah. And it does
help with figuring out, like, how are we gonna how are we as an organization
going to work best with this new tool in our
(17:14):
software development life cycle. Typically, gets added
on top of all sorts of other security testing or requirements that you have
to do as a company or an organization. So it
has the flexibility to be what you need out of a tool.
What are legal requirements with a bug bounty program? Because I know that that
is also another consideration to have when we're thinking about staffing
(17:36):
and supporting bug bounties. So are there anything are there
any legal areas that people should be considering when
thinking about bug bounty? So I'm not in legal, so I cannot give
legal advice. But, typically,
all the researchers that are interacting with the program
sign terms and conditions of how they're going to interact with these
(17:58):
programs and how they're going to interact with these companies.
And we, as a program, also sign similar
terms to how we're going to respond to the
researchers when it comes to the identification of security
vulnerabilities in our platform. It's typically
a mutual respect thing of when researchers
(18:21):
give you valuable information, we give valuable responses
and issue payment in a way that respects their time.
There's obligations that have to be followed,
but I don't think I can really talk to those.
We've talked about being ready for a bug bounty
program, and you don't have to go all in. But what if you're you're
(18:44):
just not quite there yet? Are there alternatives
to having a bug bounty program? There are.
There are also vulnerability disclosure programs,
which is essentially the same thing as a bug bounty program, but
you're not rewarding payment for the findings.
So these vulnerability disclosure programs are a way
(19:07):
for the community to report issues to
you and for you to give them credit for their issues.
There's oftentimes rankings for these
researchers to say, like, how efficient of a researcher are
they? What kinds of findings are they good at finding? How
do they compare to other researchers? And these
(19:29):
vulnerability disclosure programs are really good ways for
intro hackers or veteran hackers that wanna spend time on some newer
products to dip their toes in, see
what they can find, and also just to give the company an idea of
what do I have out there. Also, some companies, if
they felt like they've gotten their use out of their bug bounty program, their scope
(19:51):
isn't gonna change too much on their product ever, sometimes they do see
themselves drop down to from a bug bounty program to a vulnerability
disclosure program to still allow folks to interact with
them, but just not in the same payment structure as before.
And then we've also already talked a little bit about penetration
testing and how that, of course, is a potential alternative
(20:15):
thinking about either doing internal penetration tests
with our own employees or hiring an external
company. I don't know, Brent, if you want to go into
those differences a little bit more. I know you touched on kind of a timeline,
a schedule for that, but if there are some other considerations that
someone might think about when weighing penetration
(20:36):
testing versus bug bounty or also
combining the two, like, we've talked about a bit. Yeah. In
my experience, most companies that follow any sort of
framework require penetration testing on some cadence.
Oftentimes, it's that they have to show that for each of their products that they
offer, they have at least one pen test
(20:58):
scheduled a year. I personally think that we benefit from as many pen
tests as we could possibly execute a year, but that's not always
feasible for the business. So Bug Bounty is a great supplementation
for us of we get that continued testing, whereas the
penetration tests are typically a little bit more costly to run.
You get the guaranteed trained resources for what you're paying
(21:21):
for. You know, you've got the company that's doing the pen test.
They're trained professionals. Whereas in the bug
bounty scope, we don't really know who the researchers
are per se outside of their perceived
reputation on the platform. So there is some benefit in
having an actual pen test and you know that you're getting the
(21:43):
qualified individuals to perform the pen tests. But,
typically, running a bug bounty program doesn't really benefit you from a
compliance standpoint. It's it's a supplementation to your
existing security testing. That's something I think we see a lot
in security as a whole is check the box versus then what's
going to push you to the next level of effectiveness as far
(22:05):
as security goes. So I think that's a a common thread
across all security elements. It sure is.
We we really due to this bug bounty program, we really
do see our organization leveled up in terms of what we handle as a
security team, the the quality of the findings that we have.
We actually because of our bug bounty program and because of our continued
(22:27):
penetration testing, we typically see less and less
results on each year's pen test because we're continuously improving our
security stands. And it allows us to move a little bit faster, set guidelines
for how we should operate in the future, and, also, just becomes an
integrated portion of our of our work where we're always ready
to support and announce new features to our bug
(22:50):
bounty program, get our researchers as as active as we possibly
can. It's done us great as a company. I think it's a good
point when you talk about how our volume continues
to decrease the more often that we have these spun up. So it might seem
a little overwhelming at first when someone feels like they're just
opening the floodgates and you get multiple reports or, like,
(23:12):
anytime you're looking at a new way to identify vulnerabilities
and different bugs. But if you can get through
that first chunk of issues, then
it does become a lot more manageable throughout the life cycle of your
programs because you're not you might see, say, a few dozen come
in at the beginning, but then maybe there's only one a week or a
(23:35):
few a week that are actually important bugs that were
discovered. Very true. I I feel like any tool that you get into
is gonna have that initial learning curve or hump to get past,
and you just have to push through it. And there's we're
thankful that the the tool that we do use has
configuration to help us do some automation in those areas where we're
(23:57):
seeing consistent reports of the same things or
duplicates of things that we've seen in the past. But
once we've established those rules, we save a lot of time, and we we
get to really focus on what's critical. We can narrow in on the
reports that we want to focus on, and we can help guide the researchers
away from things that might seem like problems and aren't
(24:20):
anymore. And I know we've mostly focused on who should do
bug bounty and the benefits of a bug bounty program. We do hope
in the a future episode to go ahead and touch on some of those
ways to make a bug bounty program actually work for you and
make it the most effective bug bounty program that you can. So we
were broader today, but there will be a future episode where you will
(24:43):
get to see Brent talk a little bit more about those
other intricacies as far as bug bounty goes. Yeah. This
was such a great introduction to a bug bounty
program. If you've never heard of one before or wondered if
something like that could work in your organization, this
discussion probably helped get you there. So when Brent does come back,
(25:04):
you'll be ready for him to talk more in-depth about how to
make it work. Well, join us next episode as we discuss more
security challenges impacting health care and as we did in
this episode, discuss practical ways to address them.
Well, Brent and Megan, is there anything else you would like to
add as we wrap up this episode? As I like to say with all my
(25:27):
notifications to our researchers, happy hunting. We hope you
come check out our program. Maybe we can post something in the show
notes for it. Yes. And also in our show notes, we do
have a link so that you can share any ideas for
topics that you would like to see in the future. You can also give us
comments and feedback, and don't forget to lock the back door.
Welcome to Shut the Back Door brought to you by Redux.
Shut the Back Door is a health care security podcast
dedicated to keeping health data safe one episode at a
time. I'm your host, Jody Mayberry, and joining
me this episode are two guests.
Well, I say guest, but by now you're used to Megan McCloud.
(00:26):
Megan is the senior security engineer at Redox. Hello, Megan.
Hi, Jody. Nice being here again. It's great to have you. And our
special guest this time is Brent Uffkis, a staff
security engineer at Redux. Hello, Brent.
Hey, folks. Thanks for having me. Well, Brent has joined
us this time because we're going to have an episode
(00:48):
about hackers. A hacker's welcome benefiting
from bug bounty. So this
this is a interesting topic because we hear about
bugs all the time. But, Brent, what is a bug bounty
program? Hey. Yeah. A bug bounty program
is a form of crowdsource security testing
(01:12):
where ethical hackers actually look for vulnerabilities in our platform.
It differs from a traditional penetration test
in the sense that it's always ongoing.
Anybody can view our program, attempt to
hack our products, our platform, and we will be
(01:32):
as responsive as we can in terms of any any sorts of findings or any
questions that the researchers have. A traditional pen test
is usually given, like, a designated scope. So they
get like some form of hours that they they are allotted for
testing. Maybe it's forty, eighty, a hundred sixty hours
where they can spend time testing for us. Whereas in a bug
(01:54):
bounty program, it's consistently ongoing. So researchers at any
time, at any place in the world can log in, try to find issues
for us, start that conversation with us, report
any sort of findings. It's truly a
fascinating collaboration between the researchers and us.
When we're talking about ethical hackers, Brent, I'm I'm curious
(02:17):
your opinion on, like, what is an ethical hacker, and
then how are we finding these ethical hackers to actually
do this? Or or, like, we're not just, you know, posting an ad in Craigslist
or something like that. That's a good
point. A lot of times we work in conjunction with some sort of
tool out there. So there's a couple of different platforms between,
(02:39):
Bugcrowd, HackerOne. Those are some of the big
names, but there's also other ones and they all have their own benefits.
But typically, users have to sign up for
accounts on those sort of platforms to do some of the initial vetting to make
sure that they're authorized to do this kind of this
research. From there, the tools will
(03:02):
maintain some sort of, like, reputation with the researchers to make
sure that they're actually ethical. They're looking for
problems that the companies are interested in. They're reporting and
being responsive in a way that works well with
the team that is actually putting on the bug bounty program.
And there is different ways for us to kind of manage who we
(03:24):
want to be a part of our program between public,
private visibility of programs. There's all sorts
of ways that we can kind of look into and vet them. We
can ban folks that are giving us not
super helpful reports or doing sort of malicious activity that we
see in our application. We can invite researchers
(03:46):
that are particularly skilled in the area that we're looking for testing
on. Most of these tools have ways for us to
interact with the community of researchers and help boost our
engagement. Nice. Yeah. So basically, this gives us a
way to reach out to the community of ethical hackers, but we still
get to set the ground rules. And and there are still regulations
(04:08):
around it, not just a a free for all for anyone to to mess with
our systems. Yeah. Yeah. And and a lot of times, it does focus on,
like, public assets. So things that you would typically be
able to access if you were any person on the Internet. So, you know, we
all have our or not we all, but many
organizations have public assets that they like to test because
(04:30):
those are the things that are wide open. It's like your house. If you're
looking at a house, there's all sorts of entryways. And
somebody that has skilled assets might know how to get into that house
a different way. And so being able to focus on that public surface
area, a lot of times is one way that we can, you know,
boost our engagement, get eyes into some things that we might typically
(04:52):
overlook, etcetera. When it comes to these bug
bounty programs, I I can see why it's a
benefit for a company like Redux being a security
company. Who else should look at using bug bounty
programs? Is it just for security companies like yours?
No. I don't believe that it is for companies just like us. I
(05:15):
think that any sort of company that's actually, like, offering a
solution could benefit from it. Most most
security researchers are in it for a number
of things, whether it be, like, personal gain, financial
gain, education. But there's issues to be found in all
sorts of products. It might be some sort of hardware
(05:37):
product that might have some defect. It could be software. That's
the the common one typically seen with the bug bounty programs. People are
wanting to hack websites or APIs,
but some might offer an operating system
as a solution that would have issues. Some might
have just hardware or maybe like mobile applications.
(06:01):
And any company that ships something sell some sort
of tool could benefit from it. Well, with you talking about
who can benefit from it, let's just follow that path a
little further. Talk about more of the benefits of
having a bug bounty program. Yeah. I think some of the
main benefits here are that you get testing that's
(06:24):
external to your company. You're not diverting resources within
your own company to or own team into
testing these things. You get a fresh set of eyes
that might be more skilled in certain areas than your team is or just
has a different perspective on it. When you work at one
company for a long time, you kind of have a general understanding of how
(06:46):
things work. And having that fresh set of eyes come in and say, hey.
Let's just spend this time to look at this. Oftentimes, we'll look at it in
a different lens than we will. Access to testing
around the clock is an obvious benefit here, whereas
in, like, a typical pen test, we are reduced in time. And
when we have internal resources, you have to focus on
(07:09):
whatever you we perceive is the most important or that we might get the
most bang for our buck. But having these other folks that have
different timelines and different interest in areas allows
them to get deeper into your system in ways that you typically wouldn't. And,
generally, it's pretty cost efficient for
finding these vulnerabilities rather than actually waiting for
(07:31):
something to come up that's bigger and larger. When using
researchers to do this sort of security testing, we're able to
do it in a manner that they test in a what we put up is
is like a staging environment. So that the researchers, as they're testing
our health care application, they're not actually testing it against
real production data. They're testing it in a
(07:53):
isolated sandbox of an area, which reduces impact if
they do find any sort of security vulnerabilities. And helping us
catch it in that staging deployment helps us prevent
the leaking of true health information or true
other sort of vulnerability information, which does help us fix
those things before they get to production. Yeah. So, basically,
(08:16):
we're seeing cost effectiveness on the front side
by being able to just pay for the bugs that
they find as they find them versus a full time employee, but then we're
also, it sounds like, seeing a cost benefit
from preventing potential issues in the future. This
is a health care security podcast, so, of course, that leads me
(08:39):
to ask directly about health care
organization. Why should a health care organization consider running
a bug bounty program? It's a great question. We
face some unique security challenges in health care between
protecting health information, people,
medical device security. So it's especially
(09:01):
important for us to actually protect those patients in
the end here by protecting our products, protecting our information,
ensuring uptime. And there's a growing threat
landscape generally between ransomware running
rampant, APIs being abused, supply chain
attacks. And really, this oftentimes is boiled down to
(09:24):
us having or to potential compliance considerations.
Any sort of vulnerabilities or issues called out by researchers could have
potential impact for compliance, which is essential to
staying up in business and in in this industry. So us
really putting this effort into the bug bounty helps us identify any
sort of gaps that we might be missing, plug holes as fast as we
(09:47):
can, and reward the researchers for all the
efforts that they spend with us. We're very
thankful that we have the researchers that we do and that we are able to
maintain a program that these folks wanna come back and keep packing
for. And when I think about health care, you know, it it is
a twenty four seven situation as well. So like you were
(10:07):
talking about before, Brent, having people to be able to test
continuously, not just on a nine to five kind
of timeline, especially when health care is not
dictated by a traditional nine to five, that seems very
important as well. This may be a whole new concept
to us when we hear about a bug bounty program and
(10:29):
the idea of hackers being welcome.
I've always thought of hackers or something you you have to watch out for, and
and here you're telling us we should welcome them because they can help us
out. How do you determine if your organization is ready for
a bug bounty program? Yeah. Typically, there's
challenges when it comes to actually supporting a bug bounty program.
(10:52):
So one of the biggest issues that comes up is funding
and how can we afford to pay out these
researchers for these findings. And the way that I like to typically think about
that is these findings would cost us significantly
more if we didn't find them or if they are found in some other unsafe
way. So when it comes to cost and cost justification, in the
(11:14):
end, you will save money by paying researchers to
find these issues for you. Another thing to help determine if we're
ready is generally, do we have staffing to support these
programs? It is an ongoing conversation with the researchers
to make sure that they stay content, stay active in the program.
So whomever is working and actually hosting the bug bounty
(11:37):
program has to be willing to be engaged with those researchers,
help throw them a bone, answer the questions, and help educate them on
how your tool works. They're testing all sorts of different tools. They're not just
focused on one. So however, the more engaged
you stay with the researchers, the more they're excited to come
back and do more for you. This a lot of times is their full time
(11:59):
job or just a side project, but they stay motivated
when they're getting consistent conversations with us
and they're getting paid for the findings and getting paid
well and competitively for their findings. And this one big topic
when it comes to bug bounty is we we have
to reward people competitively. There's all sorts of benchmarks
(12:22):
around how companies how much companies are willing to pay for
security issues. And so in some industries like
like the crypto industry, many of those companies are willing to
pay significant dollars for findings
because of the financial impact. And health care is similar in the way
that we need to protect this health care information. So payments are
(12:44):
oftentimes higher than what you might see in some
random tooling industry, like just like iOS apps and
whatnot. When you're talking about needing staffing on
the organization side, We've touched on a little bit how
they need to be able to keep the researchers engaged and all that. But then
what is the other side of staffing? So, obviously, when we get a
(13:06):
bug that comes in, what what goes into that then from the organization's
side? Fantastic question. So outside of just
receiving the bug, a lot of times we'll need to actually
dig into the bug. Is this a real bug? So for
our organization, it typically looks like somebody on our
security team is playing that middleman. We're reading through
(13:29):
the reports, potentially retesting them ourselves. But we
also sometimes get people roped in from engineering to validate
the bug of, is this expected activity? How difficult
is it to fix this thing? Sometimes we end up working with the
documentation team to say, like, oh, this is expected activity
or maybe not expected activity. Let's clarify in our public facing
(13:51):
documentation how we want this to be interacted with.
Takes partnership from all teams when we do receive those. We're
not really on an island here in InfoSec solely handling all the
requests, but we do our best that we can to to filter it down
and make it actually important for the other teams, help other teams
prioritize this work and articulate how important these security issues are.
(14:14):
Yeah. My perspective might be a little biased because I I do a lot with
the vulnerability management side, but that's where I see these come in is
is through the vulnerable vulnerability management process. And
like you said, that's where we have to make sure that we're interacting with everyone
to get the proper prioritization. So as long as we're able to
triage these as they come in and ensure that they are real bugs
(14:36):
and that we they are something that we need to act on,
that then kind of folds in my mind into the the rest of our
vulnerability management. Yeah. And to note on that,
it's often a question of, is our organization ready for a bug
bounty program? And many of these platforms do take steps
to making sure that you're actually ready to become of, like, a full
(14:58):
fledged public bug bounty program. And that can look a a
couple different ways, but how we typically have seen
it done is you start with a private bug bounty
program where you and you invite select researchers.
So these platforms might hand out invitations to newer users or
more experienced users depending on what you're looking for. And they come
(15:21):
in and they do some base testing for you to see, like, can we uncover
the easier to find issues? And once your report
volume, so the number of reports that are getting sent into
you starts to dwindle or hit a steady rate,
typically will increase the number of private researchers that can
come into the program up until the point in which your organization's
(15:43):
comfortable with the report volume that you are actually willing to go
public. When you go public, you experience
a bit of influx with reports between automated reports
being sent to real low hanging fruit
security scanner like reports, and your organization
just has to be prepared to see those. So sometimes it does benefit
(16:06):
you to run a pen test before you actually
launch this on your product or your feature just so you can have an idea
of what kind of reports you're gonna see for the first time. And some some
organizations stay hybrid forever. They'll continually run a
private bug bounty program while letting some of their
features be public. Some companies might have, like, a couple of public
(16:27):
websites, but some private products that they can grant access to those
researchers too. It really just depends on how much time you
wanna spend supporting the platform and how much
you're willing to give in. So, basically, you don't have to be all
or nothing with Bug Bounty. You can kinda control
the volume that you wanna see. So if someone is on the fence about whether
(16:50):
they should have Bug Bounty, there are intermediary steps that they can take
rather than just being everything public all at once and getting this flood of
reports. They're able to go ahead and tamper
that down a little bit. Absolutely. Yeah. And it does
help with figuring out, like, how are we gonna how are we as an organization
going to work best with this new tool in our
(17:14):
software development life cycle. Typically, gets added
on top of all sorts of other security testing or requirements that you have
to do as a company or an organization. So it
has the flexibility to be what you need out of a tool.
What are legal requirements with a bug bounty program? Because I know that that
is also another consideration to have when we're thinking about staffing
(17:36):
and supporting bug bounties. So are there anything are there
any legal areas that people should be considering when
thinking about bug bounty? So I'm not in legal, so I cannot give
legal advice. But, typically,
all the researchers that are interacting with the program
sign terms and conditions of how they're going to interact with these
(17:58):
programs and how they're going to interact with these companies.
And we, as a program, also sign similar
terms to how we're going to respond to the
researchers when it comes to the identification of security
vulnerabilities in our platform. It's typically
a mutual respect thing of when researchers
(18:21):
give you valuable information, we give valuable responses
and issue payment in a way that respects their time.
There's obligations that have to be followed,
but I don't think I can really talk to those.
We've talked about being ready for a bug bounty
program, and you don't have to go all in. But what if you're you're
(18:44):
just not quite there yet? Are there alternatives
to having a bug bounty program? There are.
There are also vulnerability disclosure programs,
which is essentially the same thing as a bug bounty program, but
you're not rewarding payment for the findings.
So these vulnerability disclosure programs are a way
(19:07):
for the community to report issues to
you and for you to give them credit for their issues.
There's oftentimes rankings for these
researchers to say, like, how efficient of a researcher are
they? What kinds of findings are they good at finding? How
do they compare to other researchers? And these
(19:29):
vulnerability disclosure programs are really good ways for
intro hackers or veteran hackers that wanna spend time on some newer
products to dip their toes in, see
what they can find, and also just to give the company an idea of
what do I have out there. Also, some companies, if
they felt like they've gotten their use out of their bug bounty program, their scope
(19:51):
isn't gonna change too much on their product ever, sometimes they do see
themselves drop down to from a bug bounty program to a vulnerability
disclosure program to still allow folks to interact with
them, but just not in the same payment structure as before.
And then we've also already talked a little bit about penetration
testing and how that, of course, is a potential alternative
(20:15):
thinking about either doing internal penetration tests
with our own employees or hiring an external
company. I don't know, Brent, if you want to go into
those differences a little bit more. I know you touched on kind of a timeline,
a schedule for that, but if there are some other considerations that
someone might think about when weighing penetration
(20:36):
testing versus bug bounty or also
combining the two, like, we've talked about a bit. Yeah. In
my experience, most companies that follow any sort of
framework require penetration testing on some cadence.
Oftentimes, it's that they have to show that for each of their products that they
offer, they have at least one pen test
(20:58):
scheduled a year. I personally think that we benefit from as many pen
tests as we could possibly execute a year, but that's not always
feasible for the business. So Bug Bounty is a great supplementation
for us of we get that continued testing, whereas the
penetration tests are typically a little bit more costly to run.
You get the guaranteed trained resources for what you're paying
(21:21):
for. You know, you've got the company that's doing the pen test.
They're trained professionals. Whereas in the bug
bounty scope, we don't really know who the researchers
are per se outside of their perceived
reputation on the platform. So there is some benefit in
having an actual pen test and you know that you're getting the
(21:43):
qualified individuals to perform the pen tests. But,
typically, running a bug bounty program doesn't really benefit you from a
compliance standpoint. It's it's a supplementation to your
existing security testing. That's something I think we see a lot
in security as a whole is check the box versus then what's
going to push you to the next level of effectiveness as far
(22:05):
as security goes. So I think that's a a common thread
across all security elements. It sure is.
We we really due to this bug bounty program, we really
do see our organization leveled up in terms of what we handle as a
security team, the the quality of the findings that we have.
We actually because of our bug bounty program and because of our continued
(22:27):
penetration testing, we typically see less and less
results on each year's pen test because we're continuously improving our
security stands. And it allows us to move a little bit faster, set guidelines
for how we should operate in the future, and, also, just becomes an
integrated portion of our of our work where we're always ready
to support and announce new features to our bug
(22:50):
bounty program, get our researchers as as active as we possibly
can. It's done us great as a company. I think it's a good
point when you talk about how our volume continues
to decrease the more often that we have these spun up. So it might seem
a little overwhelming at first when someone feels like they're just
opening the floodgates and you get multiple reports or, like,
(23:12):
anytime you're looking at a new way to identify vulnerabilities
and different bugs. But if you can get through
that first chunk of issues, then
it does become a lot more manageable throughout the life cycle of your
programs because you're not you might see, say, a few dozen come
in at the beginning, but then maybe there's only one a week or a
(23:35):
few a week that are actually important bugs that were
discovered. Very true. I I feel like any tool that you get into
is gonna have that initial learning curve or hump to get past,
and you just have to push through it. And there's we're
thankful that the the tool that we do use has
configuration to help us do some automation in those areas where we're
(23:57):
seeing consistent reports of the same things or
duplicates of things that we've seen in the past. But
once we've established those rules, we save a lot of time, and we we
get to really focus on what's critical. We can narrow in on the
reports that we want to focus on, and we can help guide the researchers
away from things that might seem like problems and aren't
(24:20):
anymore. And I know we've mostly focused on who should do
bug bounty and the benefits of a bug bounty program. We do hope
in the a future episode to go ahead and touch on some of those
ways to make a bug bounty program actually work for you and
make it the most effective bug bounty program that you can. So we
were broader today, but there will be a future episode where you will
(24:43):
get to see Brent talk a little bit more about those
other intricacies as far as bug bounty goes. Yeah. This
was such a great introduction to a bug bounty
program. If you've never heard of one before or wondered if
something like that could work in your organization, this
discussion probably helped get you there. So when Brent does come back,
(25:04):
you'll be ready for him to talk more in-depth about how to
make it work. Well, join us next episode as we discuss more
security challenges impacting health care and as we did in
this episode, discuss practical ways to address them.
Well, Brent and Megan, is there anything else you would like to
add as we wrap up this episode? As I like to say with all my
(25:27):
notifications to our researchers, happy hunting. We hope you
come check out our program. Maybe we can post something in the show
notes for it. Yes. And also in our show notes, we do
have a link so that you can share any ideas for
topics that you would like to see in the future. You can also give us
comments and feedback, and don't forget to lock the back door.
Popular Podcasts
On Purpose with Jay Shetty
I’m Jay Shetty host of On Purpose the worlds #1 Mental Health podcast and I’m so grateful you found us. I started this podcast 5 years ago to invite you into conversations and workshops that are designed to help make you happier, healthier and more healed. I believe that when you (yes you) feel seen, heard and understood you’re able to deal with relationship struggles, work challenges and life’s ups and downs with more ease and grace. I interview experts, celebrities, thought leaders and athletes so that we can grow our mindset, build better habits and uncover a side of them we’ve never seen before. New episodes every Monday and Friday. Your support means the world to me and I don’t take it for granted — click the follow button and leave a review to help us spread the love with On Purpose. I can’t wait for you to listen to your first or 500th episode!
24/7 News: The Latest
The latest news in 4 minutes updated every hour, every day.
Crime Junkie
Does hearing about a true crime case always leave you scouring the internet for the truth behind the story? Dive into your next mystery with Crime Junkie. Every Monday, join your host Ashley Flowers as she unravels all the details of infamous and underreported true crime cases with her best friend Brit Prawat. From cold cases to missing persons and heroes in our community who seek justice, Crime Junkie is your destination for theories and stories you won’t hear anywhere else. Whether you're a seasoned true crime enthusiast or new to the genre, you'll find yourself on the edge of your seat awaiting a new episode every Monday. If you can never get enough true crime... Congratulations, you’ve found your people. Follow to join a community of Crime Junkies! Crime Junkie is presented by audiochuck Media Company.