Buyer beware: encryption does not mean application security

It’s funny that most of my time during a review or evaluation of web based healthcare IT systems when I bring up the issue of security the salesperson almost always says “yes, we use SSL.”

There’s a great of deal of growth in EMRs, EHRs, and other healthcare applications that will be web hosted over a WAN like the Internet or via a VPN. One thing that all IT community members and architects should be very clear about in our world is that SSL (encryption) is not the same thing as application security. You can have the best encryption in the world and still have a healthcare application full of holes that allows sensitive medical data to be released without your knowledge.

SSL encryption is great for making sure that data transfer is safe and that passwords and other sensitive health information is not passed in clear text over the wire. However, application security is much more than encryption and when choosing and installing modern applications ask the vendors about the following major security threats:

• SQL Injection – how does the vendor ensure that the end users of applications can not send arbitrary SQL into the database? Don’t take simple answers and ask for specific techniques, QA mechanisms, etc. SQL injection is a very common problem in most web based applications and is difficult to catch without code inspections.
• Cross Site Scripting (CSS) – how does the vendor make sure that an end user can’t just inject JavaScript into forms and fields and take over the application? Like SQL injection, CSS is a terribly common and easy to overlook but it can allow non technical users to break into your healthcare data.
• Parameter Tampering – many vendors poorly manage URL parameter validation meaning end users can simply tinker with URLs and gain more privileges or circumvent security.
• Buffer Overflows – these are the standard attacks but can be overcome pretty easily using modern languages like C# and Java in many cases.
• Using excessive privileges – sometimes roles and permissions are overgranted. Ask the vendor for a security document that describes all permissions and roles in the system and risks associated with each one of them.
• Insecure coding practices – unless the vendor has a coding security practices/policy document in place it’s likely the software may be full of holes they may not even know about. Demand to see the QA and security plans associated with software development.

Your application vendor should be able to speak to the following major security issues. Ask them to elaborate on all of them and if anything sounds fishy, probe further.

• Identification – what identity management system is in use?
• Authentication – what governs how an application authenticates as user?
• Authorization – what governs the rules for authorizing valid users to specific tasks and keeping them away from others?
• Integrity – how does the application ensure that information will not be changed, altered, or lost in an unauthorized or accidental manner?
• Confidentiality – how can the application validate that no unauthorized party or process can access or disclose the information?
• Auditing – are all transactions recorded so that problems can be analyzed after the fact?
• Non-repudiation – does the system provide a way to ensure that parties are able to provide legal proof to a third party that the sender did send the information, and the receiver received the identical information?

Just remember, security is more than just “using SSL”.