May, 2009

When a Control is NOT a Control or, “It’s Good Enough”

I run into an awful lot of engineers who hate paperwork (I feel the same way.) They are busy fixing problems, building new application support and dealing with upper managers who have no idea what they’re asking for, clueless users and now I come along to top it off asking for a bunch of documentation.

Been there, done that.

I gently explain, after I have corrected their misapprehension that auditors know nothing about IT, that if it’s not written down, it doesn’t exist. I know some engineers who believe in job security that way, but the fact is it just makes it harder for the next person to step into that role. That role will always exist. So why make it easier for the next person? Sooner or later, that next person will be you.

Why write down how a server should be built? Why write down how the servers get patched? Why bother changing the administrator password on all the servers and a different one on all the workstations? Why check to make sure that the anti virus server is actually updating all those machines? Why test to confirm that the group policy for downloading patches is actually working, and how to do that?

It’s part of being a professional engineer. It’s part of all the certifications we have signed off on; that pesky ethical paragraph that asks us to be responsible, dedicated and at the top of our game whether the job asks for that, or more commonly, does not.

It’s also a really great way of showing just how much work you do.

“Good Enough” is short for “Good Enough to Get Hacked.”

Bottom line? When you are sitting in front of a judge testifying as to what steps were taken to secure your organization, you WILL be asked what policies, standards and procedures you were following. If you have none to give the judge, you will be roasted by the jury, and your company will lose its case.

We can blame the company for not “making” us do it, but that’s not the real deal, is it?

A Free Tool for Testing Your Firewalls and Routers

I see a LOT of firewall configuration files and router configuration files. It’s the bane of my auditor’s existence to read through a PIX firewall config (up to 500 pages of a text file). After the 35th page of text, you could drive a truck through that firewall while I tried to wake up.

Plus, I can’t just log on to the firewall and look at it, oh no. I’m an auditor, and we aren’t trusted with such things (probably just as well). So, when I find a tool that will look at the configuration text file, analyze it and give me a nice HTML report, I want to throw a party.

Allow me to introduce Nipper. It takes a microsecond to turn out an absolutely superb report (and found things I missed!). AND it doesn’t just do Cisco, it also handles Nortel, Sonicwall, Juniper and Nokia. I’m in love. AND I gave the guy $50.00. I hope he had a party for himself. What an awesome piece of work.

It runs in Linux or Windows, and somebody else built a GUI front end, if command line makes your eyes cross. Grab your config files and see what you might have missed.

Looking for Some Good (and FREE!) IT Policy Templates?

Thanks to an email, I’ve come across a great website to offer you when it’s time to go looking for some good policy templates.

SANS, the be-all end-all of security training, has organized a website that offers us free policy and standards templates, as well as a course, if you need it.

You’ll need to scroll down a bit to get to all the templates. There are also some nifty security awareness posters and some explanations for the difference between policy, standards, and procedures.

I downloaded over two dozen document templates. There’s some really good stuff here for Admins and Auditors.

Turn it Off on the Road

I travel a lot - about 40% of the time. I plug in to the Net from all sorts of places as a part of doing business. So I have some rules based on experience:

1. Turn off the WiFi adapter if it’s not in use. Why broadcast the last hotel you stayed in, and allow bad people to try and attach to your machine? Check your settings, too, to make sure you connect only to infrastructure, NEVER Ad hoc. Never.

2. When you’re in the hotel at night, have you ever checked your Event Log? That’s how I found someone from a lobby computer trying to log into my machine using various passwords and the “Administrator” login. Of course, I had changed that ID name AND created another one with no rights. The motel manager got an earful. So - turn off your laptop, or pull the network plug at night.

And make sure you have Failure logging in your local security policy. For everything. Can’t hurt, since the log overwrites.

Don’t leave the machine on the network for someone to attack all night.

3. Disable ALL shares on your computer. During the day, I have a share running so that coworkers can exchange and update files. I turn it off every night.

4. If you have to leave your laptop somewhere, first of all: don’t. I take mine back with me to the hotel. But when I leave it in the office, I turn if off. Off, whoever steals it won’t get past the disk encryption. If I leave it on, the encryption is disabled, and the possibility of hacking my password or otherwise bypassing Windows controls exists.

Your laptop is disk-encrypted, right?

4. Tape a business card to the top of your computer. A lot of laptops look alike going through security at the airport. Make sure no one has walked off with yours.

5. If you walk away from your computer, lock the screen. Make it a habit, whether you are in the office or on the road.

I had a boss that would go around locking it for you with a nasty message scrolling across the desktop - AND you had to go to him to get the password, because he went in and changed it.

Take a moment to think about what files are on your laptop and what value they might have. Consider what steps you will need to go through should your laptop be stolen.

Security Maxims to Live By

I happened across the Vulnerability Assessment Team website of the Argonne National Laboratory. The Security Manager there has a great sense of humor, and has devised some security maxims much like my Rules of Thumb only BETTER.

Here’s a couple of my favorites:

Big Heads Maxim: The farther up the chain of command a (non-security) manager can be found, the more likely he or she thinks that (1) they understand security and (2) security is easy.

Plug into the Formula Maxim: Engineers don’t understand security. They tend to work in solution space, not problem space. They rely on conventional designs and focus on a good experience for the user and manufacturer, rather than a bad experience for the bad guy. They view nature as the adversary, not people, and instinctively think about systems failing stochastically, rather than due to deliberate, intelligent, malicious intent.
I would add “Software Programmers” to this one.

We’ll Worry About it Later Maxim: Effective security is difficult enough when you design it in from first principles. It almost never works to retrofit it in, or to slap security on at the last minute, especially onto inventory technology.

Head on over and check out the rest.

Watching Your Data Evaporate in the Cloud

“Cloud” computing continues to beat the drum of “cutting costs.” Although I must say that I am hard put to differentiate between “cloud computing” and data centers that host hardware, the emphasis seems to be on shared server resources and supposedly quick turnaround for new applications.

In my experience, “quick application development” is usually another way of saying “open everything up to make it work,” followed by “oops.” Or “ouch.”

The giants (Amazon, Google and IBM) are promising to customize security for their clients, but I have yet to see a price tag on that promise, or a standard for security in a cloud. I suspect that there isn’t one, and isn’t likely to be one.

Here’s some questions that keep me wondering:

How would they implement different levels of security on the same hardware/server OS?
How do I know who else is sharing my server?
How do I know that my confidential data is secure? (Think PCI and HIPAA)
How would I handle eDiscovery?
Who maintains logs - specifically audit trails?
How does handing off security to a third-party affect compliance?
Where is my backup data?
And, uh, what happens if the cloud vendor goes belly up?
Who is responsible for a data breach?

Faster, better, cheaper - pick TWO.