dcsimg

Stop Talking and Start Implementing Real Change

SHARE
Share it on Twitter  
Share it on Facebook  
Share it on Google+
Share it on Linked in  
Email  
I had the ''opportunity'' to really celebrate this past Labor Day -- bylaboring at a client's city offices.

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

Through it all, I was struck by the events, the environment, thesystems' misconfigurations, and some of the unaddressed risks I found.More to the point, I was working to assist a team of knowledgeableprofessionals with plenty of IT background. So why was this network inthe state it was? Haven't we all been talking about security, bestpractices, password management, patch management, and reducing openshares for years?

OK, so before anybody starts a flame war about the number of hoursneeded to download, test and install patches (hp), the time in hoursbetween exploits that generate critical patches (he), and the fact thathe !\ hp and you can never catch up -- I know all that. That's why wetalk of defense in depth. It's why training and certification groups,like the SANS Institute, look at fixing the top 20 problems and makingsure 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' networkmanagement and monitoring tools will help get a network set-up right inthe first place. And then you need to keep it healthy with continuedself-assessments. Add the essential pieces of an auditing program --like logging events and then reviewing the logs. Better yet, after somehomework doing a baseline, you can sort for differences and make that amuch smaller list to read. And you can script that effort -- commandline or wscripting or PERL -- so it happens at 3 a.m. and then leavesyou a note on your desktop in the morning. The larger Systems SecurityManagement products from several vendors do that, too, with greatdetails and built-in presentation graphics.

I'll bet right about know you're saying something like, ''Right. Sotell 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 wedon't really have a network map and need nmap to generate an IP listbecause IT just isn't sure. Or they are sure, but they're wrong. Youprobably have a great password policy -- written from the notes you tookat a SANS class. And I'll bet you know of at least one user who used apet's name -- or a reflexive password (login: username; password:username).

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

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...'' Mywife turned it around the other day, saying, ''True. And there are a lotof parts moving.''

You know that look a dog gives you when you talk to it and all it hearsis blah-blah-blah? A raised-eyebrow-head-tilt-to-one-side-one-ear-upkind 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. Shelikened it to inventory control. Soon after the first item leaves awarehouse headed for the first customer, it gets reordered. But nobodyreally knows what's on the shelves. You may be close. The software saysthere are six items now, but you find eight. Or none. And you never getto actually stop to check. There are more orders going out and atruck just rolled up with that reorder of three items. But how manyitems 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 wecan't (or shouldn't) say it that way. A large enterprise needs tomigrate from Version X to Version Y, service release 1a. Will it workwith all of the installed applications? Do we know what all of theinstalled applications are? Can we get the testing and rollout donebefore SR2 comes out?

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

Within that space, we generally have understaffed IT departments, userswhose jobs are to make the company run and make money (not just usecomputers); software developers with access to the production networks(scary thought, eh?), and security departments (physical) separate fromsecurity (IT) separate from IT. Management also has too much to do andtoo little time -- big decisions often need to be boiled down toone-page briefs or point papers relying on other levels to do the groundwork 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 techsupport or patches? What about the next version?) In the end, however,those products are just tools. They will not fix a network if they arenot used or are not used well. They also are only the technical end of acomplex solution that has to include business process and people.

Properly trained IT management and security staffing, with the righttools, and with time to do the work is a challenging requirement tomeet. The people I worked with this weekend had already made many of therecommendations that came out of the assessment -- but nothing had beendone.

It really doesn't matter why: the risk was the same. Some of the pieceswere in place but so were practices that negated some of the attempts tosecure the environment. Password policies were not enforced because itwas hard to get people to comply. There were open administrative shareson servers because coming up with a common configuration was hard. Oneuser had a personal installation of software that duplicated a functionserved by a corporate version from a different vendor -- because theyliked it better. And there was an anonymous ftp server on the networkbecause alternatives were deemed too difficult.

To borrow from the British author, G.K. Chesterton, (he was speaking ofreligion, but this is useful in thinking about security) he onceremarked, ''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 wedo, we must remember that we need to put in the effort to secure ournetworks. 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 implementingall this stuff because there's not enough evidence of real change outthere.

Now, if you'll excuse me, I have to go find my copy of MBSA and seewhat 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. Withexperience in the corporate, military and academic worlds, he now alsois an instructor with the SANS Institute.

Submit a Comment

Loading Comments...