Educause Security Discussion mailing list archives

Re: Pre Production System Accreditation


From: Jim Dillon <Jim.Dillon () CUSYS EDU>
Date: Wed, 5 Sep 2007 13:05:14 -0600

-----Original Message-----
From: Valdis Kletnieks [mailto:Valdis.Kletnieks () VT EDU] 
Sent: Wednesday, September 05, 2007 12:43 PM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] Pre Production System Accreditation

Erm. No.  We don't want a perfectly secure system.  We want an
*appropriately* secure system.  At some point, the costs of better
security outweigh the benefits.    <<JD - Absolutely correct.  Perfectly
secure has no value as value often derives itself from risk. >>

And the sysadmins actually realize it at a gut level, even if they can't
spell it out - that's why they tend to say "here comes the security geek
with a bunch of silly rules and dumb restrictions".  Because quite
often, they *know* that some of the requirements don't make much
difference in *real* security.     <<JD - Sometimes, but more often it
is the grunge and unexciting work that no one wants to do OR the stuff
they would do if they weren't measured along some other performance
line.  The art of evaluating logs (for ex.) has been a bane on security
personnel since the first log was spooled, and even with today's tools
it appears to be a painful, sometimes boring, mostly inexact science to
an outsider like myself.  That does not mean it has no value. I've seen
numerous stupid security requirements leveled by over-zelous security
folks and auditors that do not do the impact assessment and risk
analysis, but I've seen way, way more security tasks avoided simply
because they were too difficult and they stole resources from the
admin's favorite pet project.  Very few really want to do the grunge
work of "true security" as you called it. >>


Of course, deciding what a "sufficiently high" level of security should
be
for a given system is a whole *different* can of worms.. ;)    <<JD -
Double AMEN to that, it is why I have mentioned and asked for the
specific counter arguments, so we can see whether or not the testing
requirements are beyond the norm of reason or if the admins are just
interested in the fun part of their work.  (We auditors rename this
control environment, but I like to call it culture.)  Simple asset
evaluation and threat consideration can't be ignored without negligence
resulting. >>

JD

Current thread: