Healthcare security teams are under intense pressure to secure their environments from a growing number of threats.

Teams are often understaffed, constantly catching up with an onslaught of threats and vulnerabilities, and asked to secure legacy devices from the 1990’s – all while supporting other innovative health system teams who are raising the bar when it comes to architecting data analytics solutions and developing patient facing applications to provide a customer friendly healthcare experience.

There just aren’t enough hours in a day or even a year to do it all. This is where incorporating bug bounty programs may pay off in dividends to reduce the burden and maximize the output in security surveillance.

When implemented correctly, a bug bounty program can effectively crowdsource security research and testing services to help uncover real world exploitable vulnerabilities. In short, the program is a focused and scoped opportunity that is established for researchers to attempt to find exploitable security vulnerabilities.

Some of these opportunities come with a reward system that incentivizes the researchers with a reward in the form of rankings, swag, or a payment often in the range of several hundred to several thousand dollars. Though rare, some bounties even pay upwards of 1 million dollars.

Bug bounty programs are not…

A bug bounty program is not a vulnerability program, which typically focuses on known vulnerabilities that can be patched or remediated. While these kinds of known vulnerabilities could be in scope of a bug bounty, a security program should already include the scanning capabilities to detect and implement a patching process to remediate these kinds of issues.

That said, there is a value to leverage the bug bounty community to find these difficult to find vulnerabilities such as log4j, which tend to be beyond the ability of your typical vulnerability scanner.

A bug bounty program is also not a penetration test, which is typically scoped by both a time constraint and goal for system compromise. While a penetration test can overlap in many areas, the key differentiator is that a ‘bounty hunter’ or researcher, is typically only paid when a bug is found, validated and reported according to the guidelines of the bug bounty program whereas a pentester generally gets paid regardless of findings.

Bug bounty program risks

There are many challenges associated with running a bug bounty Program, most of which tend to be a scoping issue. Here are some of the top gotchas.

• Improper target scoping. Failure to scope the bug bounty parameters will result in researchers testing everything, and that can have operational impacts and potentially impact patient care. An example of this would be a researcher testing a live patient portal, taking down an interface that is critical to patient care, or targeting a third-party product. When setting up a bug bounty program, it is best practice to stand up an isolated network or test environment.

• Improper vulnerability scoping. Failure to scope the types of reportable vulnerabilities will result in low quality reporting, which will quickly overwhelm the security team and be counterproductive. It is best practice to list out all vulnerabilities that are out of scope (there are numerous lists out there) and only accept those bugs that are exploitable with working examples.

• Improper scaling of researcher access. The concept of crawl, walk, run applies to starting a bug bounty program. If the doors are opened too wide, too fast, there will be numerous redundant reports and this will impact the reputation of the program. This is one main reason why it helps to outsource the program initially, and then after some time, bring the program in house.

Bug bounty program use cases

While there are risks, if scoped properly there are some great ways that bug bounty programs can help provide value to healthcare solution providers:

• Patient facing mobile apps. Whether an app provider, or a healthcare organization with a development team, patient facing apps are excellent opportunities for bug bounty testing. API’s are a huge area of weakness for many mobile apps, so setting up a test environment with a test application and opening the doors to researchers will help ensure these mobile apps remain secure.

• Web applications. Most bug bounty programs are focused around a web application. Many of these are for profit web applications that are sold to customers, but the same vulnerabilities exist in custom programmed applications developed by marketing and research teams.

• Third party vendor selection. Bug bounty programs don’t have to just be used internally to be valuable, but they can also be considered as part of a security assessment process. If a solution provider has a bug bounty program, it demonstrates their confidence in their program and also indicates that the product has an established continuous crowdsourced vulnerable discovery and remediation program. In addition, if your security team has the skills, it also gives them a target to do their own security testing.

Bug bounty examples

At this point, I hope you are thinking about how a bug bounty program could benefit your security program. However, you are probably wondering if it is worth the time and effort. To illustrate the value, here are a few vulnerabilities that I have personally discovered in healthcare industry related applications.

• Persistent XSS Injection to Admin Portal on Telemedicine Application. P2 level bug that would have allowed a malicious actor to gain full administrator access to a target’s telemedicine application.

• Unauthorized Patient/Provider Create/Update/Delete Access in Web Based EMR. P2 level bug that could be exploited to access patient data from other organizations hosted on the EMR system.

• Unauthorized Prescription Creation/Viewing in web-based pharmacy. P2 level bug that could be exploited to insert prescriptions into other users of the online pharmacy.

• Root Access Call Center Server. P1 level bug that could be exploited to gain root level access to the target server, granting full control over the entire application.

• SAML Injection Takeover of Encrypted Email Solution. P1 level bug that inserts SAML configurations that would allow a malicious actor to take over the authentication mechanism and full site control of an encrypted email solution.

While a bug bounty program does need to be built with some planning and management, there is no doubt that leveraging the thousands of researchers who actively participate in these programs will mature the state of your security program.

Even if your organization isn’t ready for crowdsourced security scrutiny, chances are some of your solution providers are and it might just take a little pressure to get them to leverage one to enhance security across the healthcare industry one bug at a time. 

Seth Fogie is the Information Security Director at Penn Medicine.