Voice of the DBA

Tag: security

  • Employee Slurping

    This editorial was originally published on Oct 21, 2006. It is being re-run as Steve is out at SQL in the City today.

    I’m not talking about soup at the employee cafeteria or summer trips to 7-11, but rather the newest definition of slurping: siphoning off data with portable storage devices. It started to become a big concern with the wide deployment of iPods with their 20+GB storage capacity and easy connection to PCs. The advent of this scale of portable device, made more disturbing because of their benign appearance, has raised the concern of IT security folks. Now someone could appear to be listening to music while doing their work and siphon off an entire database!

    Now a number of companies are starting to build software to secure USB devices and help prevent data theft. And they’re taking an interesting approach, similar to that taken by networks: they control the access to USB devices at the PC level.

    This is a step in the right direction, but it still doesn’t limit what data can be downloaded to the device if USB access is enabled. It does report on access, which is probably as important as blocking the transfer. Being able to respond to security events and track them down is critical since someone will always find ways around the limits you impose.

    The is of particular concern for DBAs as the sizes of these devices grow close to that of our databases. Losing a record or two of data is one thing. Losing an entire database is something else.

  • Virtualization for Security

    Will we see VMs on phones for security?

    This editorial was originally published on Nov 7, 2006. It is being re-run as Steve is at SQL in the City today.

    I read a novel some time back about the CIA. Well, not exactly about the CIA, but it was a spy novel and the CIA was in it. One thing in there that caught me eye, and probably the only thing since I can’t remember which book it was, was the use of a secondary computers by one of the analysts.

    In this situation, the analyst had a computer that was connected to the internal network, but not anything outside. Instead there was a second machine that could connect to the Internet and allow research, checking on things outside the internal network, etc. There wasn’t an easy way to transfer information between the computer (other than typing it in), so it provided some aspect of security.

    That same type of architecture may be the answer to IT control of user’s browsing. Imagine if a virtual computer were installed on everyone’s machine. With the high power we have and free Virtual PC, this might make sense. Have it automatically installed and connect on a different IP network than the regular machine. This virtual machine could have outside access for Hotmail, browsing, etc., while the internal machine would only allow access to corporate information.

    I know there are some issues and the cut-and-paste problem could still exist. There also might be issues with trying to track browsing for regulatory and compliance purposes, but it would prevent some of the secruity issues.

    Have a virus hit? Clean out and reset the virtual machine.

    It would also help propgations by users who run as adminsitrator. I know you’re not supposed to do this, but sometimes it’s not practical. You’re doing a lot of administrative work and need to check something on TechNet. With cross site scripting issues, even this might not be safe anymore.

    Actually the more I think about it, this might be the solution out here at the ranch for letting the kids browse their music sites 🙂

  • Protecting Data

    Is it really true that we can’t anonymize data? If that’s true, then are we wasting time in looking at any type of obfuscation process or scripting for data that we restore to non-production environments? If that is true, then we then need secure development environments and treat them like production servers as far as security and access controls go.

    It’s somewhat amusing that the reason we can’t likely anonymize data anymore is because we have too much of it. All the different data sets that can be cross referenced, suing public data, make the success rate of anonymizing techniques low. I don’t know how practical it is for someone to actually combine data sets from public sources and using the information to determine the identities of people from other data sets. I do know, however, that there are lots of smart people out there with access to cheap computing resources and lots of spare time on their hands. This might be 21st century vandalism, and we, as data professionals, will be the people that have to deal with it.

    Does this mean that we should not bother to obfuscate or change production data that is copied to development systems? I don’t think that’s the case. In many environments there might not be enough information for someone to identify the original rows. Especially if you protect all of your data systems, ensuring that web logs and other potentially related source of information are not readily available. Even a rogue developer might not be able to unravel the anonymization if you keep separate data sets secure and limit the number of people that could combine them.

    Steve Jones

    The Voice of the DBA Podcasts

  • Password Help

    Ensure you keep shared passwords safe when people leave.

    Today we have an editorial that was originally published on Oct 9, 2006. 

    Yesterday I wrote about compliance tips and one of the things I mentioned was using encryption and passwords for your backups. It’s a good idea that you should use even with disk backups. You never know when someone might get socially-engineered and hand over one of your .bak files to the wrong folks.

    But using encryption isn’t enough; you need strong key management that changes the passwords on a regular basis to prevent data losses from the passwords getting released over time. I’ve worked in a dozen companies and there are many cases where a password has been used for some shared function, some application, some particular feature, whatever. If this password has remained the same for over a year, it’s been almost common knowledge throughout the company what the password is. I’ve seen business people, executives, even secretaries that knew the password to the point where it was useless.

    Shared passwords will be a fact of life in many cases. Administrative teams grow, help desk people may need access, consultants help out and learn them, and others overhear them. It’s going to happen, so you need to mitigate this risk.

    I used to manage a nightclub and we had similar risks with the alcohol. Since turnover was a fact of life, we had a simple policy. When a manager left, for any reason, all alarm codes were changed. On the third occurrence of a manager leaving, we had all locks re-keyed. It was a simple policy to reduce risk.

    The same thing needs to happen with your backups. Use one or even a few passwords to protect the various database backups. But then change those passwords every month or two and escrow or archive the old ones. You may not be able to prevent losses of the backup files, but by ensuring they are protected and the passwords changed regularly, you may just protect the data.

    And your job.