Re: Making the case for security policies and personnel

[James Conley <jconley () THINKSECURE ORG>]

Mark,

Any security control such as requiring password changes (or expiring
passwords) should be based on mitigating a specific risk.  If your
organization does not have that risk, then by all means, don't implement
the security control.

Changing passwords mitigates the risk of an internal attacker cracking user
passwords.  If the user password is obtained, the attacker can do  anything
the user can.  If the user is critical (such as a sysadmin) the damage
could be great, therefore the risk could be great.  Of course, great damage
is not enough, you also need to have a reasonable likelihood of occurrence
of the attack.

Since an internal attacker (or an external attacker who has 'rooted' a
system) has both the means and will to crack non-expiring passwords, there
is a reasonable likelihood that this attack will occur.  ---This is of
course a point that can be tested by polling organizations that DON'tT
expire their passwords and see what their attack rate is.

The 'will' to attack comes from the great gains from having a users password.

The 'means' to crack passwords comes via the abundant password cracking
tools.  L0phtcrack is probably the most popular.  It can sniff passwords
over a line and then crack them.  The key to cracking these passwords comes
down to time.  If a user has a 14 to 16 character password with
alphanumerics and special characters, !@#$%^&*(), then it will take OVER 45
days on average to crack the password.  If the user is required to change
the password every 45 days, then this risk is mitigated.  Not removed, but
mitigated.

Here are some rough L0phtcrack numbers, from personal experience.  I'm sure
L0pht has done studies.  If not, a study would be easy to set up and do.
   Password_complexity     Example        Time_to_Crack_On_Average
   dictionary word                golf                <1 min
   Alpha's                           myGirlSue      10 hours
   AlphaNumerics                1lovG0lf          2 days
   Special Characters          rG!ke#9w&me  50 days

So if a user has a password that is a dictionary word, they need to change
it every minute!  But if they use a long special character password, they
are good for a while.

Ultimately, the password policy is a decision that each organization must
make based on their perceived risk.

Jim


At 09:54 AM 2/14/2003 -0500, you wrote:
> Audit wants password aging (expiration).  Over the years, we haven't
> seen any real benefit to that, and favor requiring users to consistently
> pick a really good password instead.  We do know that password aging
> causes an additional burden on our support centers, esp. at semester
> start time, and after holiday breaks because students forget their
> passwords when they are away.  Some of us have discussed before whether
> there has been a study done related to password expiration, but no one
> recalls seeing one.
>
> Having said that, we do expire passwords on our mainframe, at 60 days.
> Once that system is gone -- we've had a 5-year plan to retire that for
> 10 years -- and we get our central authentication scheme broadly used,
> we will no longer have aging in any significant way.  But, I've asked
> our IU(Yale)CAS team to include that as an option in our scheme anyway,
> along with intruder lockout.  And, our scheme has fairly stringent
> password-forming rules.  Our standard/central password change page is at
> https://password.iu.edu/.
>
> M.
>
> --
> Mark S. Bruhn, CISSP
> Chief IT Security and Policy Officer
> Office of the Vice President for Information Technology and CIO
> Indiana University
> 812-855-0326
>
> Incidents involving IU IT resources: it-incident () iu edu
> Complaints/kudos about OVPIT/UITS services: itombuds () iu edu
>
>
>
>
> -----Original Message-----
> From: Ced Bennett [mailto:Ced.Bennett () Stanford edu]
> Sent: Friday, February 14, 2003 9:05 AM
> To: SECURITY () LISTSERV EDUCAUSE EDU
> Subject: Re: [SECURITY] Making the case for security policies and
> personnel
>
>
> Mark:
> I concur with all your comments about "keep it high level."  And in
> talking
> with people on campus who are more reluctant to understand or care, I
> use
> metaphor ("would you come to work in the morning and leave the front
> door of
> your house open?  Or closed, but unlocked?").
>
> I actually have a dotted-line relationship with the Director of Internal
> Audit and it has been invaluable.  Among other things, he often offers
> his
> help in talking with offices that need to be persuaded of the right way
> to
> do things.
>
> Cheers,
> Ced
>
> PS:  What are the two positions (between you and audit) on password
> aging (I
> missed the thread here).
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Cedric Bennett          Ph:   650/723-0728      Fax:  650/723-2011
> Director of Information Security Services
>   Information Technology Systems & Services
> Stanford University
> Polya Hall, Room 103
> 255 Panama Street
> Stanford, CA 94305-3055          Ced.Bennett () Stanford edu
>
>
>
> -----Original Message-----
> From: The EDUCAUSE Security Discussion Group Listserv
> [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Bruhn, Mark S.
> Sent: Thursday, February 13, 2003 12:12 PM
> To: SECURITY () LISTSERV EDUCAUSE EDU
> Subject: Re: [SECURITY] Making the case for security policies and
> personnel
>
>
> I just came across this, and recognized it was most likely addressed to
> me!  Sorry for the delay.
>
> I have several presentations that we've done for the IU Board of
> Trustees, but those were done in closed session and so I can't share
> them.  I do think there is good information in a presentation that our
> CIO did at EDUCAUSE 2001.  See that at
> http://www.indiana.edu/~ovpit/presentations/.
>
> The key, as I've said before, and this might be obvious, is to keep
> things high level.  Discuss institutional risks and not individual
> security vulnerabilities.  The Dean of SPEA doesn't care about inetd or
> NETBios vulnerabilities.  The Dean of SPEA cares that student grades
> might very well be exposed.  The Dean of SPEA cares that his email could
> very well be read by others.  The Dean of SPEA cares that he might have
> to answer pointed questions from the media about why a system was
> mismanaged -- reporters are getting much more wise and are asking
> questions like "well, if the vulnerability exploited was such-and-such,
> there was a patch issued last August.  Why wasn't that applied?"
>
> Anecdotally:  it happened here just like that.  In the media "event"
> related to one of our two publicized incidents in 2001, the Dean said
> "our technicians have informed me that the patch you cite wasn't
> applicable to our server."  I was at the table under the lights with
> him, and all I could do was sit there, knowing he was wrong, and waiting
> for someone to call him on it.  I just hoped they didn't ask me if I
> agreed.  They didn't at the time, but a reporter called me immediately
> after and asked me about it, and I said that he needed to call the Dean
> because I wasn't intimately familiar with their technology suite.  So
> glad I took those classes in handling the media.
>
> By the way, when we report to the Trustees in closed session, the
> Director of Internal Audit is also there, and so our relationship with
> him and his office is key.  They do look to him periodically for comment
> and input on what we are saying, and he has always absolutely concurred.
> He has said numerous times "yes, that is definitely consistent with what
> we saw in our last round of audits."  I also get copied on every audit
> report, and we're asked to comment on many of them where IT security and
> policy issues are at issue.  It is very frequent that our Security
> Office is mentioned in these as a source for information or security
> tools.   (They and we still disagree on password aging, as I've said
> here before...but agree on most everything else :)
>
> M.
>
> --
> Mark S. Bruhn, CISSP
> Chief IT Security and Policy Officer
> Office of the Vice President for Information Technology and CIO
> Indiana University
> 812-855-0326
>
> Incidents involving IU IT resources: it-incident () iu edu
> Complaints/kudos about OVPIT/UITS services: itombuds () iu edu
>
>
>
>
> -----Original Message-----
> From: Dorette Kerian [mailto:dorette_kerian () MAIL UND NODAK EDU]
> Sent: Friday, February 07, 2003 6:46 PM
> To: SECURITY () LISTSERV EDUCAUSE EDU
> Subject: [SECURITY] Making the case for security policies and personnel
>
>
> Mark,
> I heard you speak at Net@edu about making the case for security
> policies and personnel on your campus.  It was helpful information.  You
> talked about the importance of speaking in CEO or cabinet talk rather
> than technical talk.  You also mentioned that you may have a slide show
> you used on your campus.
> I'm having difficulty getting traction with the administration on this
> issue so I'm looking for other approaches.  I'd sure appreciate any
> examples, models you would be willing to share.
> Thanks, Mark.
> Best wishes,
> Dorette
>
> Dorette Kerian, Director, ITSS
> Information Technology Systems and Services
> University of North Dakota and Higher Education Computer Network
> dorette_kerian () mail und nodak edu
> 701.777-3880, fax 701.777-3978
>
> **********
> Participation and subscription information for this EDUCAUSE Discussion
> Group discussion list can be found at
> http://www.educause.edu/memdir/cg/.
>
> **********
> Participation and subscription information for this EDUCAUSE Discussion
> Group discussion list can be found at
> http://www.educause.edu/memdir/cg/.
>
> **********
> Participation and subscription information for this EDUCAUSE Discussion
> Group discussion list can be found at
> http://www.educause.edu/memdir/cg/.
>
> **********
> Participation and subscription information for this EDUCAUSE Discussion
> Group discussion list can be found at http://www.educause.edu/memdir/cg/.


------------------------------
James Conley
CISSP, Security+, CCNA, SPS, STA
703.593.7354
JConley () ThinkSecure org

**********
Participation and subscription information for this EDUCAUSE Discussion Group discussion list can be found at 
http://www.educause.edu/memdir/cg/.