I’ve been looking at some security code in preparation for a few talks I plan on doing next year and there’s one thing I don’t see in many of the samples: backups.
When you get ready to encrypt data in a table, or you enable Transparent Data Encryption (TDE), you will end up creating a key of some sort, or a certificate. Some of these keys, especially the database master key, needs to be backed up. Otherwise you won’t be able to decrypt your database or data later on if you recover this database on another server.
As soon as you create a key for security, make sure you back it up right then. You might forget later, and then it might be too late. A little preparation will go a long way here.
This editorial was originally published on Jan 10, 2007. Steve is at DevConnections, so it is being republished.
So class, for today’s protection mechanism you’ll need: a mouse, a loop of wire, a lock, a key, and a link. Sounds like MaGyver, huh? This article on hot spot security gives you some software hints and covers most of the items I listed above. The exception is the loop of wire.
If you’re working for some time at a place, especially a place that’s traffic’d well, you might want to lock your computer to the desk or table. It will discourage iJacking or the chance that someone will walk by, grab your laptop and run. This is more likely in a cafe or Starbucks than an airport, but you never know.
The advice is good and it makes sense that most of the discovery and openness of Windows is rapidly becoming a liability. Even out here in the country, where I live and my nearest neighbor is nearly 1/4 mile away, I have keys on our wireless routers. I know it’s not the best security, and I did get some complaints about making everyone have a key until a neighbor’s router showed up on our computers. Makes you realize just how far away someone could be and reach your system.
As handy as all the capabilities are in wireless networking, as with anything else, they need to be secured and they should be turned off by default. Use them when you need them, but the rest of the time, try to be a bit more secure and limit access to your system.
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.
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.
