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

Teams are often understaffed, constantly catching up with the onslaught of threats and vulnerabilities, and being asked to protect legacy equipment from the 1990s – while supporting other innovative health system teams that are raising the bar in building data analytics solutions and developing patient-oriented applications Provide a customer-friendly healthcare experience.

A day or even a year is not enough time to do it all. This is where incorporating a bug bounty program can pay dividends to reduce the burden and maximize the output of security monitoring.

When implemented properly, bug bounty programs can effectively crowdsource security research and testing services to help uncover real-world exploitable vulnerabilities. In short, the program is a focused and wide-ranging opportunity for researchers to attempt to discover exploitable security holes.

Some of these opportunities are accompanied by a reward system that rewards researchers in the form of rankings, swag, or payments usually in the range of a few hundred to a few thousand dollars. While rare, some bounties have even paid out over $1 million.

A bug bounty program is not…

A bug bounty program is not a bug program, it usually focuses on known vulnerabilities that can be patched or fixed. While these known vulnerabilities may fall under the scope of bug bounties, security programs should already include scanning capabilities to detect and implement a patching process to fix these types of issues.

That said, there is value in leveraging the bug bounty community to uncover these hard-to-find vulnerabilities (e.g. log4j) that are often beyond the capabilities of typical vulnerability scanners.

A bug bounty program is also not a penetration test, it’s usually limited by time constraints and system compromise goals. While penetration testing can overlap in many areas, the key difference is that “bounty hunters” or researchers are typically paid only for discovering, validating, and reporting vulnerabilities according to bug bounty program guidelines, whereas penetration testers typically get paid regardless of the results How to pay.

Bug Bounty Program Risks

There are many challenges to running a bug bounty program, most of which tend to be scoping issues. Here are some of the most important questions.

• Improper target range. Failure to scope bug bounty parameters will lead researchers to test everything, which could impact operations and potentially impact patient care. An example of this is researchers testing real-time patient portals, shutting down interfaces critical to patient care, or targeting third-party products. When setting up a bug bounty program, the best practice is to set up an isolated network or test environment.

• Vulnerability scope is inappropriate. Failure to identify the types of reportable vulnerabilities will result in poor reporting, which will quickly overwhelm security teams and backfire. Best practice is to list all out-of-scope vulnerabilities (there are many lists out there), and only accept those that can be exploited with a working example.

• Inappropriate scale of researcher access. The concept of crawl, walk, run is suitable for starting a bug bounty program. If the door is opened too wide and too fast, there will be a lot of redundant reports, which will affect the reputation of the program. This is one of the main reasons for initially outsourcing a program and then bringing it in-house after a while.

Bug Bounty Program Use Cases

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

• Mobile application for patients. Whether it’s an application provider, or a healthcare organization with a development team, patient-facing applications are a great opportunity for bug bounty testing. APIs are a huge weakness for many mobile apps, so setting up a test environment with test apps and keeping the door open to researchers will help ensure those mobile apps stay secure.

• web application. Most bug bounty programs focus on web applications. Many of these are for-profit web apps sold to customers, but the same vulnerabilities exist in custom program apps developed by marketing and research teams.

• Third-party vendor selection. Bug bounty programs don’t have to be used internally to be valuable, but they can also be considered part of the security assessment process. If a solution provider has a bug bounty program, it shows that they have confidence in their program, and it also shows that the product has an established program to continuously crowdsource vulnerability discovery and remediation. Also, if your security team has the skills, it also gives them a goal to do security testing on their own.

Bug Bounty Example

At this point, I hope you’re thinking about how bug bounty programs can benefit your security program. However, you may be wondering if it’s worth the time and effort. To illustrate its value, here are some of the vulnerabilities I’ve personally found in healthcare-related applications.

• Persistent XSS injection into the admin portal of the telemedicine application. A P2 level bug that allows malicious actors to gain full administrator access to the targeted telemedicine application.

• Unauthorized patient/provider create/update/delete access in web-based EMR. A P2 level error that can be used to access patient data from other organizations hosted on the EMR system.

• Unauthorized prescription creation/viewing in a web-based pharmacy. A P2-level vulnerability that can be used to insert prescriptions into other users of an online pharmacy.

• Root access to the call center server. A P1-level vulnerability can be exploited to gain root-level access to a target server, thereby granting full control over the entire application.

• SAML injection takes over encrypted email solutions. Inserting a P1-level error in the SAML configuration, allowing malicious actors to take over the authentication mechanisms and full site control of encrypted email solutions.

While it does take some planning and management to build a bug bounty program, there is no doubt that leveraging the thousands of researchers actively involved in these programs will make the state of your security program more mature.

Even if your organization isn’t ready for a crowdsourced security review, some of your solution providers may be, and it may only take a little pressure to get them to exploit a vulnerability to enhance security across the healthcare industry .

Seth Fogie is Director of Information Security at Penn Medicine.