Application Risk Analysis, and the need for it

by Wally Moore

on January 12, 2016

in application risk analysis, blog

Application Risk Analysis

Application Risk Analysis and the need for it, is the topic for this eighth post in our “compliance - why and how” series with specific emphasis on the application infrastructure.

Risk Analysis

After a company completes a thorough Risk Analysis, they will have a LOT of information to analyze about their own unique way (their company way) of doing business. This includes oral communication, written communication and electronic communication. All of it falls under the umbrella of protected health information (PHI).

But that’s just the beginning, because once the Risk Analysis is complete, a company will have to actually implement what they’ve learned and that’s where the rubber meets the road, so to speak, with HIPAA compliance.

Application Risk Analysis has many things to talk about. This post includes private data encryption and user input validation.

These are big terms, I know, but they are very simple day-to-day activities, as you’ll read.

Effects of HIPAA

The actual implementation of HIPAA is having a profound impact on industries far beyond the Healthcare industry. Anyone, and any company, both private and public, that deals with any US citizen's health information in any form, computer based or paper, is affected by HIPAA.
The standards HIPAA mandates are not product-specific. They are designed to provide an industry "best practices." For example, security consists of more than just passwords and firewalls; organizations must ensure the confidentiality and integrity of their patient health records.

Big words

Also, when you’re talking about communication, the transmission of that data must be authenticated and have the property of non-repudiation. Whoa, big word! What the heck does that mean?

Typically, non-repudiation refers to the ability of ensuring that a party to a contract, or a communication, cannot deny the authenticity of their signature on a document, or the sending of a message that they originated.

Various HIPAA regulations, including but not limited to §164.308 and §164.312, require validation and protection of PHI through the use of software and/or hardware. When software is utilized to access such information, a thorough code review is in order. This type of analysis validates application security characteristics that ensure the various vulnerability-points like backdoors are not implemented in the code. It should be noted that a single security breakdown of such an application could lead to un-authorized access of PHI, thereby exposing your company to potential incidents and even sanctions.

When an assessment of this nature is performed, a review of the application infrastructure helps validate various components of risk including:

Private data encryption

All private data, such as user names, passwords, information that identifies a user, credit card information, and dates of birth should be encrypted by using industry supported, strong encryption such as the Advanced Encryption Standard (AES). AES is a specification for the encryption of electronic data established by the U.S. National Institute of Standards and Technology (NIST) in 2001.

Big terms

User input validation cannot be trusted to be valid. It is recommended that ALL user input be filtered and examined at the Web server before being acted upon by the application. Check for proper size and content type to prevent buffer overflows and code injections.
Client-side validations are not useful for security because they can be bypassed easily.User input validation compliance should be required at all times because the vulnerability severity is judged to be high. The technical term for this is “bad” really bad.

In other words

All companies should just assume that incoming data is invalid until proven otherwise, even if the application you’re using assumes that all requests are valid. The sooner the application recognizes an invalid request, the less chance there is for damage to your data caused by intentionally malicious code. Attackers count on the fact that it is easy to impede server performance in servicing legitimate requests when system recognition of illegitimate requests takes a long time. This is a prime example of a denial of service attack.

Lengthy operations and resource-intensive operations should always be handled securely. If you need to perform a lengthy SQL query, or if you have an operation that requires a great deal of processing power, you should first confirm that the request is legitimate.
Authenticating the request not only prevents malicious users from consuming resources on the application server, it also provides the ability to track misuse in audit logs, which means that administrators can trace illegitimate use back to a particular user.

In our next post will discuss passwords.

How do you this stuff?

Most small health care providers do not have the technical resources to understand all this geek stuff. And many health care providers are not HIPAA Compliant. If this describes you, DTS can help you Achieve compliance, Illustrate compliance to auditors and Maintain full compliancy.

Return to main HIPAA page

For more information:

Dedicated to your success,

Wally Moore
General Manager and Compliance Officer
dts|infotech . . . computer networks that work