Software application security vulnerabilities can create major risks for developers and development managers who must comply with HIPAA. The responsibility for protecting sensitive data extends all the way into your code. There is the obvious issue of patient confidentiality, but it becomes even more acute when information about a patient’s mental health is involved. Not only could the patients be severely affected by having this knowledge fall into the wrong hands, but the institution using your application (and your company, by extension) could suffer serious financial and reputational blows. If your code exposes that data to an attacker, that would be very bad.

Most companies are sitting on a vulnerability time bomb; more than 50% of all software breaches involve web applications, and yet fewer than 10% of organizations review their critical applications for security.

The developers and their managers at those companies know that they are taking a risk by not addressing application security vulnerabilities, but find themselves hard-pressed to do something about it in a cost-effective, yet thorough way.

Network security versus application security

When people talk about security in the technical realm, they often think more about network security than application security. “Network application vulnerabilities” is a very popular search phrase. But if you think about it, letting someone use your application is inviting them into your network, and once they are there, it’s what they do with the data inside applications – or the application itself – that can wreak the most havoc.

In our cloud-centric world, many applications involve customers sharing some kind of information. In the medical industry, many customers and doctors are now posting information to patient portals. If the application associated with that portal has security vulnerabilities, the entire database can be accessed. Applications accessed by users, no matter how secure the server is, open up potential threats. Even simple login screens have been the target of SQL injection attacks, exposing data to hackers without them ever needing to even breach the network.

Points of access need to be analyzed, and the application code tested for vulnerabilities, to make sure that the HIPAA standards are met before launch. This testing of the code against HIPAA standards and regulations should happen as the application is being developed, and worked into the normal development process workflow. All of this is possible with a tool designed for the process.

Using tools designed for the purpose of assessing HIPAA application security vulnerabilities

Obviously, the sooner you discover compliance issues, the easier they are to fix. As code is being developed, it becomes more and more complex, with a variety of interdependencies and inter-application relationships that are difficult to unravel – and repair. Finding significant application security vulnerabilities closer to launch can result in a major rewrite of large sections of code – and a major launch date setback.

The tool you use should be able to find and highlight those particular vulnerabilities that relate to HIPAA regulations and that leave you open to noncompliance and hacking-related exposure. It should track specific lines of code and map those troublesome areas back to those particular violations. It should provide your QA managers, engineers, and project managers with the exact violations, their locations, and an explanation of how the code violates those HIPAA regulations. It’s never enough to know “this could be a problem”; what you want is clear direction on how that problem should be addressed.

The right application vulnerability management tool will take the manual labor and  associated checklists our of vulnerability management. Manual labor always introduces errors into the process. Instead, the testing is automated and is incorporated into the development process, introducing quality assurance and security testing at each stage.

The tool should also make it convenient to share that information with all those involved in the development workflow, so that the effort can be managed properly. The vulnerabilities should be found, prioritized, and the best course of resolution should be made clear.

Lastly, the tool you use should be able to check for other application security vulnerabilities beyond those associated with HIPAA compliance, including OWASP Top 10 and SANS 25.

HIPAA Violation Penalties are severe

If you even think that your application might be subject to HIPAA regulations, you’ll want to consult with a HIPAA-literate lawyer, as the penalties are severe.

  • Unknowing –The minimum penalty for a category 1 violation is $100 per violation, with an annual maximum of $25,000 for repeat violations.
  • Reasonable Cause — The minimum penalty for this type of violation is $1,000 per violation, with an annual maximum of $100,000 for repeat violations.
  • Willful neglect with correction — The minimum penalty for this type of violation is $10,000 per violation, with an annual maximum of $250,000 for repeat violations.
  • Willful neglect without correction — The minimum penalty for this type of violation is $50,000 per violation, with an annual maximum of $1.5 million.
    If you want to more about this critical topic, we have written a white paper and an article on this subject, which you may find useful.

Given the financial impact of non-compliance, it’s important to handle all software vulnerabilities with extreme caution. Using a quality tool to eliminate application software vulnerabilities is an essential part of developing software.

If you want to learn more about how Code Dx can help with HIPAA compliance testing, contact us today.