In-Depth

Best Practices: Audit Without Getting Overwhelmed

How to create and maintain an effective security program through auditing.

• By Mathew Schwartz
• 11/12/2003

To avoid that trap and discern automated auditing best practices, Security Strategies spoke with Fred Pinkett, Vice President of product management for auditing software vendor Pedestal Software (http://www.pedestalsoftware.com), about the best way to create and maintain an effective security program through auditing.

What’s Pedestal’s role in security policy automation?

What Pedestal is about is system security policy management. It's about looking at your systems, looking at a policy, then assessing how you're complying with that policy.

How do you define policy?

Specifically how you have your system set up—all of the settings on a Unix or Windows box, who’s in the administrator group in your directory, who the users are … It’s all about the cycle of audit, assess, and comply. We provide a tool—SecurityExpressions—that does that in an agentless way.

What does the software look for?

Well, it ships with a number of best practices that are industry best practices—groups that have come together and [made recommendations, such as] SANS, the National Security Agency (NSA), the Navy's lock-down guides, then the vendors' guidelines—Microsoft, IBM's white paper for securing your AIX. Those policies come pre-built and ship with the product. Then you can take those and shape them to your environment, or start from scratch and write your own rules.

What’s the draw for automating security policy auditing?

The point of it, and one return on investment [(ROI)] of it, is replacing a bunch of manual tasks with automation—a tool that automates that process for you. Typically, auditing tools start with 20 or 30 systems, then try to extrapolate it to the whole network. But if you can automate even that process, if you can just push a button, you don’t have to extrapolate to the network, you can actually audit the whole network.

Where do companies start if they want to automate that process?

First, you have to pick your policy—something really locked down like the NSA policy. Or with lots of custom applications, [maybe] you need a lot of exceptions. Which is going to work well for your organization? For example, one particular financial organization had a lot of problems with modems because they had a lot of telecommuters.

What’s next?

The next three phases are audit, assess, and comply. Audit servers, desktops, or just start with servers, or just a particular operating system of server—Windows 2000. Or maybe you’re going to start with your outfacing Web servers, because that’s where you have a lot of risk. Then you get the report you need [to make changes].

How frequently should companies audit?

We have companies that want to monitor machines in real time [which another Pedestal product, Intact, does] or every day, but typically major audits will come once per year. One company has a practice of dividing the company into 20 different blocks, then getting to each one on a day of the month.

Interesting. What drove them to that approach?

That’s a medium-technology manufacturing company in upstate New York. What drove them to do this in the first place was a failed audit, and the reason they were being audited was they were worried about the privacy of some of their customer data. So … they started with NT boxes, are in process of doing their [Windows] 2000 boxes, and will move to Unix boxes from there. They came up with the idea of dividing systems into blocks, so they can hit one each day.

So they’ve cut the problem into manageable pieces?

That’s right. Start with a policy, and maybe start with one type of application, and go from there. Or divide it up by machines. In their particular case, where they needed domain expertise, they brought people in on contract to help.

What happens when the software finds systems lacking a patch? How careful do companies need to be, using auto-patching technology?

Patch quality assurance has to be built into the process on the customer's side of things; unfortunately there's no substitute for that. So a product like SecurityExpressions can help find systems that need to be patched, then push out the patches. But … there’s no substitute for customers testing a custom application with that patch before. Same goes for custom applications. You have to have some idea of what's in your internal systems to know what the effect will be, because you can apply a setting that can break an application.

How do companies deal with that?

You learn those things over time, and that's why you really have to start with defining your policy, and once you're comfortable with that, there's much less risk in the auditing and compliance stages.

How often should companies revisit their audits?

Well, part of the process is how often you audit—as part of the continuous loop of audit, assess, and comply. For example, you may learn that a certain application requires more lockdown, or a certain server isn’t [in compliance with] your policy, so there’s a constant adjustment of policy as well. Also systems drift over time. So if you look two-to-three times per month, that's much easier than dealing with 20 or 30 new things at the end of the year.

How do companies prove compliance to their policy?

The assessment part is the recording part—the tool is putting the data into the database, and there can be no question [it’s accurate].

Have you generated ROI numbers for automated policy enforcement and patch management?

There’s lots of ROI, some of it's hard to quantify, but from a quality sense it's certainly there. Obviously if your systems were patched and up to date against Slammer and Blaster, you'd reduce threats or impact costs. The same goes for internal threats, and the same goes for failed audits—if you fail an audit, you have to go through and do it all again. Finally, if you're going to do these things, if you've bought into all this, then there’s the ROI of doing it … in an automatic way. You want it to be automated and agentless.

Expand on the agentless aspect; you don’t need to install software on every system to be monitored?

[Correct.] I can run it on a server, or my laptop, and scan our whole network. It's not a high-resource intensive program.

How does it accomplish that?

It uses Windows networking to reach out and touch those machines. Windows has a lot of [capabilities] to enable that. Then on Unix machines we use a protocol called SSH—we use an open version inside [our software], then we interoperate with whatever SSH your machines have. Most people are using some level of SSH to do remote administration of Unix systems, so you don't have to go and install something special to run this, that's the point of the agentless architecture.