I had the ''opportunity'' to really celebrate this past Labor Day -- by laboring at a client's city offices.

My family tells me a couple of days were pretty nice. I couldn't corroborate that. I was getting a deep fluorescent tan helping assess the security of a network.

Through it all, I was struck by the events, the environment, the systems' misconfigurations, and some of the unaddressed risks I found. More to the point, I was working to assist a team of knowledgeable professionals with plenty of IT background. So why was this network in the state it was? Haven't we all been talking about security, best practices, password management, patch management, and reducing open shares for years?

OK, so before anybody starts a flame war about the number of hours needed to download, test and install patches (hp), the time in hours between exploits that generate critical patches (he), and the fact that he !\ hp and you can never catch up -- I know all that. That's why we talk of defense in depth. It's why training and certification groups, like the SANS Institute, look at fixing the top 20 problems and making sure as much automation is in place as is practical in a given network.

Things like configuration management or commonality of installations, Microsoft's Baseline Security Analyzer, and other vendors' network management and monitoring tools will help get a network set-up right in the first place. And then you need to keep it healthy with continued self-assessments. Add the essential pieces of an auditing program -- like logging events and then reviewing the logs. Better yet, after some homework doing a baseline, you can sort for differences and make that a much smaller list to read. And you can script that effort -- command line or wscripting or PERL -- so it happens at 3 a.m. and then leaves you a note on your desktop in the morning. The larger Systems Security Management products from several vendors do that, too, with great details and built-in presentation graphics.

I'll bet right about know you're saying something like, ''Right. So tell us something we don't know already.''

I!/d also bet that on this subject that would be hard to do.

I think we really do already know the baseline is out of date, that we don't really have a network map and need nmap to generate an IP list because IT just isn't sure. Or they are sure, but they're wrong. You probably have a great password policy -- written from the notes you took at a SANS class. And I'll bet you know of at least one user who used a pet's name -- or a reflexive password (login: username; password: username).

Well... We know what we should be doing. We know why -- and if you're not sure, start thinking about lawsuits, due diligence, negligence, and so on when client or personal information is leaked from your organization.

With all of that in mind, why don't we do what we need to do?

Because it's hard.

Networks and the organizations they serve are very complex organisms. I've often used the phrase, ''There are a lot of moving parts...'' My wife turned it around the other day, saying, ''True. And there are a lot of parts moving.''

You know that look a dog gives you when you talk to it and all it hears is blah-blah-blah? A raised-eyebrow-head-tilt-to-one-side-one-ear-up kind of canine ''hunh?'' That was me.

She took the cue and went on... The parts move new people, new software, new threats, new patches, and new regulations. And it never stops. She likened it to inventory control. Soon after the first item leaves a warehouse headed for the first customer, it gets reordered. But nobody really knows what's on the shelves. You may be close. The software says there are six items now, but you find eight. Or none. And you never get to actually stop to check. There are more orders going out and a truck just rolled up with that reorder of three items. But how many items does the truck actually have on board? Who knows!

Running a network is like that.

We write policy, and then legislation or corporate suits tell us we can't (or shouldn't) say it that way. A large enterprise needs to migrate from Version X to Version Y, service release 1a. Will it work with all of the installed applications? Do we know what all of the installed applications are? Can we get the testing and rollout done before SR2 comes out?

That!/s the environment. Real but not ideal.

Within that space, we generally have understaffed IT departments, users whose jobs are to make the company run and make money (not just use computers); software developers with access to the production networks (scary thought, eh?), and security departments (physical) separate from security (IT) separate from IT. Management also has too much to do and too little time -- big decisions often need to be boiled down to one-page briefs or point papers relying on other levels to do the ground work and make a solid recommendation.

And then there are vendors with ideas and products that will fix things. Just write a check and we'll be OK. (Does that include training, or tech support or patches? What about the next version?) In the end, however, those products are just tools. They will not fix a network if they are not used or are not used well. They also are only the technical end of a complex solution that has to include business process and people.

Properly trained IT management and security staffing, with the right tools, and with time to do the work is a challenging requirement to meet. The people I worked with this weekend had already made many of the recommendations that came out of the assessment -- but nothing had been done.

It really doesn't matter why: the risk was the same. Some of the pieces were in place but so were practices that negated some of the attempts to secure the environment. Password policies were not enforced because it was hard to get people to comply. There were open administrative shares on servers because coming up with a common configuration was hard. One user had a personal installation of software that duplicated a function served by a corporate version from a different vendor -- because they liked it better. And there was an anonymous ftp server on the network because alternatives were deemed too difficult.

To borrow from the British author, G.K. Chesterton, (he was speaking of religion, but this is useful in thinking about security) he once remarked, ''It's not that [security] has been tried and found wanting. It's been found difficult and left untried.''

Tool are important, some cost a lot and some are free, but whatever we do, we must remember that we need to put in the effort to secure our networks. They're complex, so it is going to be hard.

No more checks. No more talk. No more policies that are on paper only.

So, take a deep breath and roll up your sleeves and start implementing all this stuff because there's not enough evidence of real change out there.

Now, if you'll excuse me, I have to go find my copy of MBSA and see what this box looks like. I know I just saw it -- maybe this past March, I think. It's around here somewhere...

Bob Hillery, a former computer and security manager for the U.S. Navy, is a founder of Intelguardians, LLC, a security consultancy. With experience in the corporate, military and academic worlds, he now also is an instructor with the SANS Institute.