Users put data where they need it, and they don't think about who has to know what they're up to in order to protect the data. The problem for security staffs is identifying where all the data is and making sure the proper controls are in place to protect the information.
We recently discovered that agency personnel often create Microsoft Access databases to help them manipulate data and create reports. The users who originate such databases, or the heads of their departments, may be deemed the owners of the data, but IT remains its custodian. Unfortunately, many data owners don't understand the concept of security controls, or even the need for them. It becomes the responsibility of IT security to implement the necessary controls.
Ideally, IT security would understand how people work, what they need and what they are trying to accomplish. Then we could get in front of any effort to manipulate data to make sure that something like an Access database has the proper security controls in place. That's not usually how things go. Generally, data is saved in various formats and then e-mailed, transferred, shared and printed. Afterward, the original data has morphed and has numerous owners and locations.
The realization that users were putting data that could be considered sensitive in Access databases meant I had some homework to do. I have very little understanding of how to secure an Access database, but whenever data that is considered electronic protected health information under the federal Health Insurance Portability and Accountability Act is involved, I have to make sure it is well protected.
I asked the IT person who provides Access database support how such files are secured. At first I got a blank stare, but then he responded, "We rely on file system permissions, basically." That made sense. Access output is treated like output from any other Microsoft Office program, such as Word or Excel. But I needed to know more.
Microsoft's Web site didn't give me a lot of answers, so I ended up checking the help menu from my copy of Access. I learned that there are some strategies for securing Access, but none of them is very good. Here are the techniques I found out about:
Encryption/decryption: This is the simplest method, but it only prevents the database from being opened by a tool or utility it doesn't recognize, like a word processor. It doesn't prevent anyone from opening an unsecured database using Access.
Show or hide objects in the database window: This is just a smoke-and-mirrors tactic and can easily be circumvented.
Start-up options: The database creator can specify a start-up form that opens automatically when the database opens. Again, it's smoke and mirrors.
Passwords: You can set up a password to the database, but only one. You wouldn't be able to open the database without the password, but you would have to give everyone who needs to access the database the same password. That's not a good practice. And if you replicate databases, as users do in my agency, you can't configure it for a password-upon-open option.
User-level security: This is slightly more secure than the above methods. The database creator or administrator can specify how much access each user has to tables, queries, forms, reports and macros. Information on a user's access level is stored in a file called "workgroup information."
Preventing users from replicating the database, setting passwords or setting start-up options: User-level security must be in place for this to work, but it would mean that only administrators would have the necessary permissions to change settings. This might be one change we can make, but it isn't enough.
Securing Microsoft Visual Basic for Applications code: You can copy your code into an Access MDE file and then password-protect it.
Securing data-access pages: This applies to data that is accessed via a Web page. The Web pages are stored in the file system, so only file system security applies.
In my view, these security measures are inadequate for protecting personal health information. Our responsibilities under HIPAA are one reason we outsourced our major information systems. But, with data everywhere, the problem has come home to roost.
So, what is my strategy? Tell program staffers that they can't create Access databases? Not going there.
I have requested a list of all Access databases agencywide. I want to know who the owner of each database is, who the users are, what the purpose of each database is and whether it contains electronic protected health information. Once we know where all these little databases are, we are going to institute user-level security for all of them and apply network-and file-level permissions based on the sensitivity of each database. I also want to require that anyone extracting data from the primary information system into a local file system or database must get sign-off from IT security and his department head.
At the same time, we'll have to re-educate staffers so they understand why we are doing this. We have trained our employees on HIPAA privacy, but they don't really understand the security aspects. As I said, convenience trumps security needs in their eyes, and they are used to having information available to them on the network and having the ability to copy, change, move and e-mail it -- all the things that keep a security manager awake at night.
I can't think of any other way of doing this. I'd certainly like to hear your ideas.
What do you think?
This week's journal is written by a real security manager, "C.J. Kelly," whose name and employer have been disguised for obvious reasons. Contact her at mscjkelly@yahoo.com, or join the discussions in our security blogs: computerworld.com/blogs/security.
To find a complete archive of our Security Manager's Journals, go to computerworld.com/secjournal.