Guest Blogger
Shahid N. Shah, Chief Architect, Netspective
There is a general misconception in the health IT community that their database servers are somehow their most secure systems and that because they are secure their patients’ healthcare data and their own financial information is safe. While this is a dirty little secret, many databases are neither secure nor safe from data tampering or theft. Although lots of data may be stolen by hackers for identity theft, a great deal of other data theft occurs from insiders who could benefit from sale of such data. And, when insiders do it there’s almost no way to trace their movements if they’re smart.
In most organizations database administrators are trusted with enormous amounts of responsibility, only one of which happens to be data protection. In many organizations software engineers and other IT consultants have direct access to databases as well. In a complex environment there could be literally dozens or hundreds of technical people that have direct access to healthcare, financial, and other private information with little or supervision.
Shared (application) accounts on databases are painfully (and sometimes negligently) common. Shared (application) passwords are very common in thin-client or web based applications because it’s a design pattern followed over and over again: many web users connect to a single web application and all those web users connect through a single, pooled, database connection. Is this a bad thing? Not if you follow some common sense rules and practices. If someone did access the database with a shared/application account and made changes, performed queries, etc. there would be no way to know who it was or how it was done.
If that weren’t bad enough, production databases are often copied and used for debugging, performance testing, integration testing, or other QA activities. This means there are tapes, ZIP/TAR files, and other files with lots of private, privileged, patient data sitting around in people’s drawers or cabinets. Backup copies of production databases are necessary for debugging and QA. None of the uses seems out of line or improper – but, we need to be careful.
Here are some questions that you should ask your engineers and database administrators. I won’t be supplying any answers just yet (this is a teaser article). So, start by asking:
- Does your database use shared accounts that allow multiple individuals to connect to the database using a single account?
- Does your database use a single account to allow unfettered access by a single application or do various functions (read/write/admin) of the apps have their own accounts?
- How are you protecting the data that is duplicated for use in QA or by engineers? How about for debugging?
- When you copy data for use internally is it being deidentified and cleaned first?
- Are backup tapes logged in and logged out of secure compartments or can just anyone get access to them?
- Does your database have all information (passwords, SSNs, test results, salary records, etc) in plain text or is it encrypted?
- Are you using one-way or two-way encryption in those cases where it is encrypted? How do you manage public/private keys?
- Is your database server on virtual (private, non-routed) LAN segment with limited access from all other systems?
- Who can ping your database servers? Anyone or just particular servers?
These are stimulation questions, not to be seen as a comprehensive checklist. Check back here next week for the next article in this series that will guide you in how to take those answers and create a stronger data fortress. In the next article I will present some solutions (some easy, some hard) for how to better protect data, especially from insiders.
The multiple/generic login is a problem I've encountered so many times I've stopped being amazed. The biggest culprit is usually with the rotating, temporary or travelling nurses. Whenever I begin working with a new system I always try and query the user tables for names like "nurse"...
ID NAME
NRS1 - Nurse, Floating Peds
NRS2 - Nurse, Temp ID
and so on. I think that the worst part is when I hear stories of nurses who worked here years ago, have since left and, on occasion, become patients, only to return to work and still remember where the sticky note with the current NRS1 password is kept. Makes audit trails somewhat pointless. I'd get upset if it weren't for the fact that for every 10 "nurse" logins there is 1 "Testing, IS" login...
Posted by: Peter | January 09, 2006 at 06:38 PM