OK - I definitely see where you're coming from. However, I believe that my environment is a bit better locked down than what you have so frequently experienced.
And no, I don't want someone to come audit me on that! :) Kurt On Wed, Mar 4, 2009 at 14:23, Michael B. Smith <[email protected]> wrote: > Well, I can only speak to my own experience. > > In every SMORG that I've entered as a "new consultant", I've found that there > are a number (generally MANY) users who have membership in high-privilege > groups or have access to high-privilege accounts. Usually, this comes as a > surprise to their supervisors, and the IT person often does not know what > membership in those groups entails. They simply are aware that "hey, if I put > Josie into group A, she stops complaining." > > Am I suggesting that those IT people are idiots? No. I've learned that most > IT people are VERY well meaning, but it is simply impossible to know > everything. Once you learn about the "objective domain" (OD) for your company > (that is, the problems and priority of various issues within a given > organization) an IT person tends to focus on that OD. This is quite > reasonable. > > It often takes an outside party (such as myself, or any number of other > qualified individuals) to take an "objective look" at access and policies to > determine whether they make sense - especially within such guidelines as > NIST-800, SOX-70, HIPAA, PCI, etc. Or even within the audit guidelines of a > particular company. I've often found that access to high-privilege accounts > is political - for example, the CFO who controls IT wants to have access to > everything that IT does. Well, I can understand that - but from an audit > perspective, that's ridiculous. The CFO doesn't know how to use that > privilege and their account may represent an access path that is otherwise > "uncontrolled" and therefore unsecureable. The smart CFO will agree that she > doesn't want that as an audit "finding". > > When explained from a rational perspective, almost all (99%+) of folks are OK > with this. Those few left are typically dealt with by explaining the issue to > the CEO of the company. > > That's my introduction. :-) Given my experience, I prefer to implement a > weekly password change on all non-basic accounts (that is, anything that has > above-standard access). Am I paranoid? Perhaps. How many people, in a > properly controlled environment, is this likely to affect? Less than 5. > > -----Original Message----- > From: Kurt Buff [mailto:[email protected]] > Sent: Wednesday, March 04, 2009 4:10 PM > To: NT System Admin Issues > Subject: Re: Password Policy Change > > I was only thinking about the standard user base, but I think I agree. > > Elucidate your thoughts? *Every* employee termination, or only upon > termination where the employee/manager had access to privileged > accounts? > > I assume that you're thinking about rainbow tables and pass-the-hash attacks. > > > > On Wed, Mar 4, 2009 at 12:29, Michael B. Smith > <[email protected]> wrote: >> I think that's fine as long as you change the passwords on any >> higher-privilege accounts upon every employee termination, managerial >> change, or every two weeks and review the need-to-know of those passwords on >> a regular basis. >> >> I am one of a relatively small (but growing) contingent who believes that >> any higher-privilege account (including service account) should be changed >> far more frequently than a low-privilege/normal-user account. >> >> -----Original Message----- >> From: Kurt Buff [mailto:[email protected]] >> Sent: Wednesday, March 04, 2009 2:49 PM >> To: NT System Admin Issues >> Subject: Re: Password Policy Change >> >> If the account was created more than 60 days ago, setting this policy >> will force a password change at next logon. >> >> If the account was created less than 60 days ago, setting this policy >> will force a password change when the account reaches 60 days. >> >> FWIW, I don't like a 60 day period. If I had my druthers, I'd enforce >> a very long password (greater than 16 characters) and force the >> password change at 180 or 365 days. This is spite of rainbow tables >> and pass-the-hash attacks. >> >> Kurt >> >> On Wed, Mar 4, 2009 at 07:51, John Hornbuckle >> <[email protected]> wrote: >>> Right now, our users' passwords don't expire. We're looking at changing >>> that. >>> >>> My question is this... If I decide to enable password expiration, how is >>> the expiration date calculated for my users? >>> >>> Let's say that today I set passwords to expire every 60 days. Will all >>> current users' passwords expire 60 days from today? Or will all current >>> users' passwords expire today, if those passwords are 60 days or older? >>> >>> >>> >>> John Hornbuckle >>> MIS Department >>> Taylor County School District >>> 318 North Clark Street >>> Perry, FL 32347 >>> >>> www.taylor.k12.fl.us >>> >>> >>> >>> >>> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ >>> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ >>> >>> >> >> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ >> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ >> >> >> >> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ >> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ >> >> > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
