"How Do You Know?"

Things NOT to Do When You’ve Been Hacked, Part II

I finally asked that deadly question: “What do your Incident Response Procedures say?” Whoops, there goes all the buddy-buddy geekiness: I have morphed into The Auditor Who Asks Questions.

“Umm, well, they pretty much say to do what we just did.” I notice the vagueness of the reply, but decide to let it pass, for the moment. They don’t really know what their procedures say they should do. Probably the procedures are too generic.

“OK. But what if he has jumped to this box from another box he compromised first? How would you know?” More pained and irritated looks coming my way. “By now, you won’t really be able to tell what happened unless you go to a backup and start analyzing whatever you can find for connection information. But that won’t necessarily give you rootkit information. If you’re lucky, you might see a netcat connection, but only if he hasn’t erased the Event Logs.”

“Even so,” I continue, knowing I am now excluded from the Kool Kids Klub, “If he has gotten your SAM database off the server, wouldn’t he know the administrator password? Is that password the same on every server?”

Turns out the password IS the same, and the Event Logs overwrite according to defaults. Now they can’t trust the server OR the administrator password. But I’m leaving, and besides, this isn’t an audit anyway, just some consulting.

So they left the server alone, because “There are all those websites on it, the users would scream and we’ll watch it carefully.” And never mind about passwords because “It’s a really tough one they’ll never crack.”

I wonder what will happen next, don’t you?

Hard Disks Never Die - They go to Digital Forensics

I’m attending an absolutely fascinating course on Digital Forensics provided by SANS. One of the things we will be doing is collecting data from hard drives for various practice exercises.

Imagine my amusement when the handout and appendixes recommend where to get used hard drives to practice on: eBay or Craigslist. Didn’t Simson Garfinkel do this a few years ago? And come up with a whole bunch of juicy information?

How do you dispose of hard drives? There are overwriting programs and businesses that will pick them up and dispose of them securely, providing a certificate (and thus transferring your risk). But how do you know they are performing as agreed?

I’m looking forward to my eBay hard drives and what they will disclose. Hope they’re not yours!

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.

When a “Pentest” is not a Pentest

There are as many definitions of pentest and penetration testing as there are google search results. (Some 10,700,00 or so). The problem is, there doesn’t seem to be a standard definition of what constitutes penetration testing.

As a result, there are hundreds of companies promoting their version of a “pentest,” and a wide variety of prices given for the proposed “service.” If you’re looking for “a penetration test,” you can spend hours reading about it on various vendor sites. But what are you really getting? It can vary. A LOT.

A couple of years ago one of our banking clients proudly informed us that he had commissioned a “penetration test” quarterly from the same company that managed their firewall. (Yes, I smelled a rat.)
I took a look at the contract, which did, indeed, provide a “penetration test” quarterly, and examined one of their previous reports.

I recognized the format of the report - it was output from a Nessus scan (back when Nessus used to be free). So this company was testing itself with a free product and charging the bank. Nice.

It was a nice report, and the client was happy with it. He was convinced he was going the extra mile to protect his bank. (Hopefully, he’s not still doing this.) I tried to explain to him the difference between penetration testing and a vulnerability scan, but it was hard going. Especially when he had been sold on the scan being the test.

It’s embarrassing when I see my own genre out to so blatantly make a buck. Right up there with “SAS 70 certification.” Then there’s the folks that come in with a lowball bid just to build business in a market they don’t have any traction in. They make us all look bad, don’t they?

So, what is a “penetration test?” Some of it depends on who is asking. The organization that is looking to acquire one really needs to know what they need to learn from the test. There is no passing grade, unfortunately.

Next: Let’s talk terms

Securing the Security Devices

OK, so you’ve bought the glow-in-the-dark, meets all the compliance requirements and looks really shiny “security solution” from a vendor (one or many).

Or maybe your management has bought it and presented it to you as a fait accompli. (Hope I’m spelling that fancy French right!) And of course either you have to manage it (without training, “that’s too expensive, just watch the consultants put it in”), or it’s been “outsourced.”

Or as an auditor, you’ve been told to use it for all auditing functions, and not worry about doing any follow up or periodic testing because this product is such a “time-saver.”

So, how do you know (my favorite question) it’s working and doing a good job? Not what the fancy report it produces says, not what the consultant says, not what the manual says, not what the boss says. What you can actually see.

I’ve been following a discussion on the Security Focus “pen-test” mailing list about how security software has just as many issues as regular software. I don’t like thinking that the software protecting me and writing to a SQL database is using an unencrypted ODBC connection that can be captured by ARP poisoning.

So, although I am rarely asked to audit or test a firewall, IDS or host IDS, having run and learned on all of them, I have some suggestions for you to try out.

NEXT: How to Audit Your IDS/Firewall/ECM for free.