Category: Editorial

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.

Today we have an editorial that was originally published on Nov 7, 2006 as Steve is at DevConnections. 

It’s not bad enough that people get tons of spam, some of it cleverly disguised and hidden in messages we might be expecting, but this idea is doubly wrong. Apparently someone setup a spam message that informed people they’d been laid off. When they followed a link, a keystroke logger was installed on their machine.

So not only did their emotions skyrocket with the news they might be let go, but they potentially could get let go anyway after someone discovers they’ve installed software on their machine that could compromise the company.

I’d like to think that administrators wouldn’t be fooled by this and get something installed that would grab their passwords, but it’s not that easy. As an administrator, you should be wary of users on your machine without supervision, even under their own accounts. It’s the same reason I don’t let me kids work my computer without me being their; I’m not sure they won’t get some trojan installed.

The other part of this is ensuring that your security paradigm is properly set up. Anyone could fall for one of these and if they had administrative or other “superuser” rights, who knows what would be compromised. It’s also a good reason to ensure that you don’t share passwords, especially high level ones, for some quick fix. If someone needs some extra rights for a day, grant them rights and then remove them as soon as possible.

And change your passwords. I’ve worked in places where passwords were in force for years and everyone knew what they were. Might as well have a blank password.

I think targeted SPAM will become and more common in the future. Writing scripts to change senders, customize messages, change logos, etc. and target specific groups of people is not difficult and as more filters become able to deal with the large blasts of identical email, those looking to trick you will evolve as well.

So spread the word and warn your users. A large part of security is education on everyone’s part.

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.