Security Risk Hiding in Plain Sight

Security risks can lurk behind every corner, but some places can feel more hidden than others, even if that is not the case. One area perceived as hidden is the source code underpinning various digital health or other software based tools. Risks found in code can be troublesome because development of that code is often outsourced, which is actually part of the problem.

A recent white paper from databreaches.net and security researcher Jelle Ursem exposes the numerous problems that may arise through code stored on GitHub. The issues can be relatively basic and straightforward, meaning that even individuals not sophisticated with hacking or cybersecurity can get through what amount to non-existent defenses.

As outlined in the white paper, the most common issues found were:

  1. Login credentials being hard-coded instead of setting up as a configuration option on the server where the code is running;
  2. Using public as opposed to private repositories;
  3. Failing to use advanced authentication for email accounts such as two factor or multi-factor; and
  4. Merely abandoning a repository when finished, instead of deleting it.

Why are issues with code found on GitHub concerning? The ease of finding credentials and other weaknesses for sites and applications is well known to cyber attackers. In fact, reports suggest that attackers will often check stolen credentials against data available through GitHub, which can very quickly identify open systems and provide easy returns on the stolen information.

Emphasizing how the common issues impact organizations, the white paper provided nine examples of organizations with data exposed on GitHub as a result of the one or more of the issues. In most of the instances, data had been exposed for years at a time. The lengths involved are worrisome because the data was freely accessible and could be copied. If copied, then getting the specific issue corrected would not necessarily be helpful. The potential for an ongoing compromise should make organizations that much more concerned.

Beyond the very real likelihood of compromise, the other issue is that vast amounts of protected health information will be left exposed through the bad practices. It should be well known and recognized that exposed protected health information translates to data breach notice requirements, if the impacted covered entity actually learns about the exposure. Learning about (or accepting) the exposure is not always easy, especially if an organization does not want to listen to information from researchers or others in white hat roles.

Given the risks that can arise in the source code that remains available on GitHub, what should be done? Seek to have the items listed as the biggest problems addressed, which probably means a combination of removal and implementation of good security measures. From a technical standpoint, the fixes can be quite easy.

The more important issue raised by the exposures created by outsourced vendors is the need to vet and evaluate vendors and others providing services to healthcare organizations. Vendor assessment is a foundational means of managing risk and verifying claims made by the vendor. Put more basically, the process is conducting due diligence on the vendor. A good place to start can be some variation on the following questions:

  1. Do you comply with HIPAA?
  2. Have you implemented policies and procedures required by HIPAA?
  3. Have you conducted a risk analysis?
  4. Do you train your employees on HIPAA requirements?
  5. Do you have backup and contingency plans?
  6. Are your compliance operations vetted by a third party?

While those basic questions are not intended to guarantee full compliance, negative answers can create areas of concern or notes of caution before entering into an agreement with a particular vendor. The responses can also inform how to proceed with additional questioning and areas for more attention when it comes to conducting more vetting.

Ensuring awareness of how vendors operate is underscored by the growing number of exposures caused on the vendor (or business associate) level. An exposure on that level can very quickly lead to large numbers of patients being impacted since the vendor will have information about multiple covered entities as opposed to being confined to only one organization.

All of these issues may seem to be a cautionary note against using outside vendors. That is not the intent or purpose. Instead, the purpose is to understand that at times the results may be exactly what is paid for and that appropriate measures should be implemented. That means trying to cut a corner in hiring a vendor or seeking the cheapest vendor will not always produce the best results. Additionally, document relationships with good contracts that clearly set out the responsibilities and obligations of each side. If a relationship will be ongoing, consider periodic check-ins between the parties to check on current security efforts as well as discussing potential issues that could have arisen. Even if the check-ins do not find an issue, the reviews can spur action and help detect a vulnerability before it becomes a major issue.

Another suggestion from the white paper is for organizations to provide a point of contact for security researchers or others who identify data breaches or other compromises. Instead of forcing people who are trying to provide unsolicited assistance jump through any number of hurdles or never receive a response, organizations should welcome the information. While taking time to vet a report and not just jumping feet first into the notification, the reports also should not be pushed to the side as fake or sophisticated attacks. The means to make a reasonable determination should exist. In the end, being able to intake the notifications and follow up will only benefit the organization.

The white paper about risks in GitHub will hopefully be en eye opener. It is impossible and potentially very negligent to just assume that everything is fine and no issue exist. Even if a concern is outside of an organization’s normal scope of knowledge, poke around or ask questions. One never knows what can be found and it is much better to get a bad surprise out of the way quickly.

About Matt Fisher

Matt is the chair of Mirick O'Connell's Health Law Group and a partner in the firm's Business Group. Matt focuses his practice on health law and all areas of corporate transactions. Matt's health law practice includes advising clients with regulatory, fraud, abuse, and compliance issues. With regard to regulatory matters, Matt advises clients to ensure that contracts, agreements and other business arrangements meet both federal and state statutory and regulatory requirements. Matt's regulatory advice focuses on complying with requirements of the Stark Law, Anti-Kickback Statute, fraud and abuse regulations, licensing requirements and HIPAA. Matt also advises clients on compliance policies to develop appropriate monitoring and oversight of operations.
This entry was posted in Business, Compliance, Health IT, HIPAA, HITECH and tagged , , , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s