Tools for Auditing and Security

Steps to an Easy Audit: Standardizing Patch Management

Many of my clients ask me what is the best way to deal with applications and operating systems that need to be patched frequently (like Microsoft’s monthly “Patch Tuesday”). Industry best practices have emerged in some simple steps that can work in almost any size organization:

1. Create a Patch Management Policy
Policies come from the top down and demonstrate that the executive level is invested in managing and securing the enterprise. Policies dictate the scope of standards (“Once a month, we will review patches and document risk, etc, etc”) and procedures (“the patches will be tested on server A, deployed on production servers C,D,E…”) to deploy the patches. This Policy should be part of your overall Vulnerability Management. It’s part of managing risk.

2. Identify What Needs to Be Patched
Don’t just think Microsoft, or even just think servers. Every device on your network, at some point or another will need to be updated. Some devices may require multiple types of updates, such as a server that holds a database; both need to be patched. You need to know your entire inventory, and categorize those devices in terms of risk, so that you can prioritize patching. Some devices, such as your workstations, will need to have software patched, such as Microsoft Office. It will be worth your while to have a complete software and hardware inventory. Think of the SQL slammer worm: it paralyzed networks not only because of SQL Server, but because of all the default installations of MSDE (Microsoft Desktop Database Edition) on workstations.

3. Classify and Rank
Different devices on your network may have different levels of risk, so that patching them takes higher priority than say, patching a printer (yes, these must be updated, too!). Take the time to assess the devices according to their risk levels so that you know what must be patched first.

Different patches have different levels of risk. Those that Microsoft, for example, identifies as “critical,” should always be assessed and tested for deployment first. All patches should be reviewed for criticality and ranked. That allows testing and deployment to proceed efficiently. Lower priority patches can be deployed on a more moderate timeline.

4. Test, Test, Test
It certainly is true that Microsoft, in particular, has vastly improved its process for creating solid software updates that don’t, generally, break things. However, good process requires that you not make changes on a production system without ensuring that the patch will not break some critical procedure. Use your development environment as a test bed, or even your less critical production servers to rollout the patches to. You’ll be glad you did.

5. Document, Document, Document
What got patched when? How will you remember the reason you didn’t patch a particular server in six months? Develop a documentation system, or better yet, use your Help Desk system to document who, what, when and why. You can track compliance very effectively with those reports and not an extra cent.

6. Trust, but Verify
On more than one audit, I have discovered that the great piece of software the client set up to patch everything stopped working, or didn’t patch certain other systems. Once a quarter, run a check using MBSA (Microsoft Baseline Security Analyzer, a FREE tool from Microsoft) for Microsoft products, at the very least. It will also give you a good baseline on the security of those servers, and a better night’s sleep!

A YUMMY New (FREE) Tool for Looking at Packet Captures

I don’t know about you, but looking at packet captures is right up there with looking at Cisco PIX firewall configuration files. Nonetheless, it’s part of my job, on occasion, and although I enjoy the “capturing” part, the “looking through it” part tends to make my eyes cross.

So, a nifty new FREE tool “rumint.” (Short for rumored intelligence - why the name - who knows) Anyway, when you load a capture file (it will run a number of formats, including tcpdump) and select “Text Rainfall” from the View pulldown, and Voila! A screen that pulls ASCII text from each packet in the capture. Oh my. What a thing of beauty. I had an epiphany, it was so easy to read. You can set it for looping, as well.

This tool is part of an emerging field of “Security Data Visualization.” When I first heard of this topic, I thought of dashboards and graphs, but that’s not what this seems to be about, except in a peripheral way. I’ve just bought the first book out on the subject, Security Data Visualization And so far it’s gotten some very good reviews from at least one big name in the field. It’s also written by the author of rumint.

I think what they are shooting for is a new way of looking at data flow that uses the best part of the human brain. Computers can do a lot of things around computation and correlation, but they are basically only as good at it as we tell them to be.

You and I can look at a dataset in a certain way, and it comes together in a gestalt. Computers are not yet able to do this. Like looking at enough pieces of a puzzle, suddenly we will see the picture. I had that exact experience with rumint, which, by the way, can also run with real time packet captures.

And in any case, if it makes your life easier reading packet captures, enjoy! Kudos and thanks to the author.

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.

Time for an “Auditor” Admin-level ID or the End of Auditor Shoulder-Surfing

One of the biggest time wasters I experience during an IT audit is have to ask an administrator to:

a. Run tools/scripts for me in order to access information
b. “Shoulder-surfing” with an admin in order to collect information/screen shots.

It’s a waste of my time, since I know where to go on a network to get what I need, and an even bigger waste of an admin’s time to collect all the stuff for me.

If, of course, they already had it on hand, as a good admin should…..but, I digress.

So, OK, Microsoft, SUN, HP, Red Hat, IBM, etc.: isn’t it about time you created an auditor function/ID? How about an ID that would have administrative READ ONLY access? Look everywhere, touch nothing? And, make the ID uniquely trackable? Like the admin ID should be, but again…..

This would have incredible value in the business world, for in-house auditors, as well as us external folks. How about it?

Compliance is Only a “Gentleman’s C”

A comment from Dr Chuvakin reminded me of how long I’ve been thinking about “checkbox security.” As an auditor, I am certainly familiar with checkboxes, in fact, for my firm, I’ve written a number of them.

When I am going over doing an IT Audit with a new auditor, having a method for examining the environment is vital. Heck, having a method for pen-testing is vital. But it seems that so many people get caught up in thinking that the method IS the solution. If everything is checked off in the methodology, the environment is secure, right?

No. A thousand times. No. I’m sure TJMaxx had a bunch of checkboxes filled in for somebody. Didn’t do them a darn bit of good.

A few years ago I did an internal pen test for a company, and discovered that their use of a web proxy required that the user log in via HTML each time they went to the Internet. Long story short, Cain and Abel easily decrypted their casual hash for me and I was very shortly inside the network, up to admin level AND the CFO’s password. (Geez that was fun; but I digress…)

I asked my engagement manager, who was also doing a SOX 404 audit for them, if their SOX audit would have found this issue. No, of course not! Auditors don’t run Cain and Abel! (Maybe they should, eh?)

So where would that have left that company? SOX “compliant,” but still easily broken into by anyone with a simple tool. Not good. So much for checklists, checkboxes, and methodologies. The difference was, the company cared enough to pay for a quality pen test, not just someone coming in to run a scan. They changed their proxy, and now this issue no longer exists. They’re proud of their security, and they should be.

But if we are not thorough and specific, we can miss the obvious “low-hanging fruit.” In my mind, that’s all an auditor can really hope to do. And even that seems to be a full time job.

So, for those folks who say, “we’re compliant!!!” it doesn’t mean you are supporting a secure environment. It means you’ve gotten all the little boxes checked in someone’s methodology. It’s a “Gentleman’s C.”

What would an “A” look like? More on that later.