Tearing My Hair Out

Using Your IDS as a Boat Anchor

Setting up your Intrusion Detection System to send you email alerts designed by the consultants who put it in and thinking you are secure is the equivalent of wrapping a chain around the server and tossing it in when you go fishing. It will do just as much, if not more good in the lake as it will on your network.

Here are some rules to follow for using an Intrusion Detection System on your network:

1. “Set It and Forget It” makes an IDS useless.

Why? Activity is happening on the network all the time. Suspicious events happen that are based on low level alerts that can aggregate - setting your email to high alerts only means you are missing the boat. Plan to spend at least an hour a day looking at the primary console and logs after you’ve finished cruising your firewall logs. And no, using an ESM (Enterprise Security Managment) tool to alert you does not get you off the hook. Only the human mind is capable of correlating activities and events in a remotely effective manner. We don’t yet have sufficient heuristics to automate intrusion detection.

Intrusion Detection Systems have a back end database to hold all the signatures they can monitor for. Some IDSs install agents on servers and have remote sensor collectors (say for the other side of the continent). The signatures can be updated almost daily. Do you need to install all the new signatures? No, but you’d better make sure you install the newest and nastiest ones that apply to your network. And keep the servers and database patched.

2. “We get too many false positives!” means it has not been configured correctly.

Why? Intrusion Detection Systems must be tuned. That means using about a month to analyze the traffic your IDS sees and eliminate the normal flow of events from your alerts. IDSs have an enormous database of signatures and if you turn all alerts for those signatures ON, you’ll be watching for UNIX hacks on your all-Microsoft network. Remove unneeded signatures from monitoring, and little by little you will remove alerts that are really normal traffic on your network. Why a month? Some transmissions only occur once a month. And taking out those signatures gives your sensors more CPU to see the traffic.

3. “One Size Fits All” means you’re not wearing anything.

I usually ask for the individual policies for each IDS sensor. For each sensor placement on your network, you want your intrusion detection system to watch for different traffic. It’s the best way to deploy sensors sparingly (and effectively) on a network. One sensor on the core router will not be enough, unless it can hold multiple policies: one for your internal network, one for your DMZ, and one for your extranet.

Think about it. You want to be watching for web-based attacks on your DMZ, but they will mean very little on your corporate network. Those signatures can be minimized internally, unless your internal web servers are high risk. If your DMZ is accessed from the Internet, many more signatures will need to be enabled. If you have one generic policy, you’re drowning in false positives and missing the REAL nasty traffic in the flotsam. And yes, you will have to spend time tuning and updating them on a regular basis.

4. “We have an IDS!” doesn’t mean it’s working.

Have you tested your IDS to make sure it’s working? I’m ashamed to say that too many IT Auditors don’t take a good look at this, and incorporate a simple test into their audits. A well tuned IDS should report an internal user running a portscan. It damages nothing, and is one of the most frequent first steps taken by a hacker with ill intent. And make sure that management knows ahead of time, but not the engineers in charge of the IDS. See what happens, and how quickly they report it.

4. “Oh, we outsource THAT,” means your risk has gone UP when your costs went down.

Unfortunately, I have yet to see an outsourced policy configuration on an IDS that was truly effective. IDSs are time intensive, and no one knows your network like an admin ON your network. As a result, you may get some very well-formatted canned reports every month, and it is certainly better than no IDS at all, but the effectiveness of the system decreases with every step away from your network. It’s a business decision, I know.

The other risk has to do with intrusions - you can outsource the functions, but you cannot outsource the responsibility, for both fiduciary and reputation risk should a breach occur.

Just buy a real boat anchor.

Yes, We Have No Bananas

I’ve been reading a fascinating book by Andrew Jaquith, Security Metrics - Replacing Fear, Uncertainty and Doubt. This book takes lots of buzzwords, like “ROSI,” “Risk Management,” “key indicators,” “accountability,” and “compliance,” and turns them on their heads.

It has always bothered me that IT security and IT audit pundits and promoters propose all sorts of theories masquerading as fact for assessing risk. Everyone has a different unit of measurement, including some very large standards organizations. This is simply an attempt to justify the cost of securing data. It has always bugged me because I have yet to see a good explanation for measuring events that have not happened. If there is a solid security architecture, Bad Things don’t happen. Mostly. How to get this across in measurable terms is deplorably difficult to the non-IT parts of the business (usually management).

We’ve been reduced to using “compliance requirements” to justify the cost for “security initiatives” across an enterprise, and that limits their applicability to what the regulations require, rather than basing our efforts on solid evidence for security improvements. Measurements and quantification just do not exist. (Gasp! Heresy, I know.)

How do we differentiate between an organization that has no security incidents because of their solid security practices, and an organization that has no incidents due to blind, dumb luck? Or my personal favorite, no incidents because they don’t have any way to even know if such incidents occur? Yes, we’re fine because we have no idea.

Jaquith does a great job of picking apart the BS Bingo, especially flashy terms used by vendors, who must continually sell you something to stay in existence. (When did true improvement turn into the next release?) If you run a Google search on “compliance,” there are 133 million results. Try the same query minus “.com,” and the results fall to a measly 12 million or so. No wonder most of our security spending has gone to product, not process. Companies have turned to compliance as a metric for good security.

Yes, we have no real idea what constitutes good information security practices.

Dear Network Administrator - Please Change Your Password Like Everyone Else!

I have a nifty little .vbs script I wrote last year. I send it to the network administrators before I come on site, ask them to run it and send me the results. It tells me username, login ID, description, length of password, last login date, acct locked, etc. It also tells me when the last time the password was changed. I use it to check for terminated users still on the system and that password controls are indeed what they say they are.

In the last 9 out of 10 Windows Domain IT audits, what group of people hasn’t changed their password(s) in over a year (sometimes two)? You guessed it. The last network admin got a little huffy, when I inquired, and replied, “We do comply with corporate policy! We just change them manually.” She cc’d my boss and her boss. Ouch.

I guess she didn’t read the file she sent me: it’s right there in plain text - the exact date. I copied and pasted her team’s last change dates, simply replying to ALL, and referencing the attached file. I try to be polite when watching someone loudly and publicly announce how badly they want to eat their shoes. After a pregnant day of silence, she came back with a very polite response telling me they were designing a new group policy just for their group to ensure passwords were changed in compliance with corporate policy. I could tell the shoe leather wasn’t very tasty.

I’ve done it too, as an administrator; somehow we don’t think that the rules should apply to us. After all, we’re the good guys! How, a non-engineer might ask, do they circumvent the group policy? Simply go into the administrative interface and select the checkmark for “password never expires.” All done.

As an IT auditor, I represent my company’s standard for IT, and so does a network administrator. If I am not following the rules, why should anyone else? Network Administrators have the most powerful rights on the network - capturing their passwords would allow a thief into everything. And the longer you don’t change it, the more time people have to work on getting it.

Plus, it just makes us engineers look bad.

P.S., the next most common group of non-changers? CEOs.

It Makes Me Tear My Hair Out #1

Visa, in conjunction with the US Chamber of Commerce, has published an alert that identifies the leading causes of data breaches. Full details can be found at the Chamber’s website. The five leading causes of card-related breaches are:

1) Storage of mag stripe data
2) Missing or outdated security patches
3) Use of vendor supplied default settings and passwords
4) SQL injection
5) Unnecessary and vulnerable services on servers

Why tear my hair out? Numbers 2, 3, and 5 shouldn’t be on this list. We’ve had how many warnings and regulations and requirements about patches, default settings and unnecessary services? And business wonders why it needs regulatory requirements. Because these bad business practices happen routinely. Because too many business owners don’t want to spend the money to secure their systems.

Just four months ago I did an audit of two online MSSQL databases, only to discover their administrative SA IDs had been left in the default configuration of “no password.” Why do we keep dropping the ball? Crooks are dumb, but they’re not that dumb.

Last year I interviewed a VP development of an online marketing software for a clothing retailer. When I asked him what steps he was taking to address SQL Injection, he replied, “What’s SQL Injection?”

Well, I’ve used up my italics for the day. Sigh.

But the Chamber website has some really nice papers and templates for those looking to get started with security policies and procedures. Good for them!