Coming from a similar type of University setting the powers that were decided to keep all of the various domains separate but under the same *.university.edu address space. They appeared to be part of the same forest but were in fact multiple forests. There were trusts setup as the main campus domain had all the Exchange/email severs so they controlled the email but the individual domains controlled who was allowed to access email and hours they could login. At the time the main campus was Win 2003 ffl. Many sub domains were running 2008 but not all. I understand they are still doing it the same way now. It just allowed for more flexibility within the University but it also keep the intra university fighting down. The main campus could demand that some things were to be done a certain way but enforcement was really difficult for them. The various sub domains that I had seen were actually far better at keeping up with security than the main campus was. Besides the medical colleges this university had a number of semi-independent research institutes. Those had special needs like NDA's and control of IP that was contracted to them. One of the things the main campus tried to push was McAfee AV on all machines controlled from a server they controlled. That did not happen most of the individual forests just laughed and ask what drug they were using. They also tried pushing a broken disk encryption program that only they would control that also saw a lot of laughter. Jon From: [email protected] To: [email protected] Subject: RE: [NTSysADM] PCI compliance and account lockout policies Date: Wed, 25 Sep 2013 00:26:46 +0000
Leaving PCI aside for a moment… We are a university and are looking at pulling our medical center users into the greater campus. On the medical center side they have implemented lockout (we do not use lockout here) and we had a long discussion about the effectiveness of lockouts in general. At the end of the day, the purpose of lockout is to provide a mechanism to prevent passwords from being guessed. To be more specific, what we really want is to manage the percentage of all possible passwords that can be guessed. If your password policy requires and allows only a single-character, lowercase, English character for a password you have 26 possible passwords. Allowing 25 failures over the life of the password would mean that only a hacker with my luck will not pwn the password. If, however, your password policy requires complex passwords that are at least 10 characters long, are checked against a dictionary and have a mixture of characters/numbers/etc., 25 attempts would be trivial. That being said, all things being equal, the fewer guesses you allow, the better assurance you have that the password is not compromised. It will never be perfect, of course, because there is always a chance that someone will guess it right the first time. Example: Let’s say that I have a password policy that requires users to change their password every 90 days. Users being users, they all wait until day 90 to change. Then I create a lockout policy that locks the account after 6 failed attempts with a 30 minute reset window. Given those parameters, a bad guy could make 10 guesses per hour = 240 per day = 21,600 over the life of the password. That may or may not be acceptable in any particular environment based on use requirements and password entropy, but on the face of it that looks like a big number. I would also assert that most organizations would NOT CATCH (or at least not catch for a long time) a well-crafted guessing scheme that used these parameters, especially if it was able to get in the door. What if I wanted more assurance than the 21,600 maximum guesses would give me? Using the same lockout parameters I could shorten the password age or increase the entropy I required in the password. But if I am willing to rethink the notion of lockout and the associated parameters, I can significantly increase the assurance AND potentially decrease the number of calls a user makes to the helpdesk. I might also be able to catch systematic compromise attempts more readily. Here is what I would do. I would start by defining the maximum number of guesses I was willing to accept over the entire life of the password (which is really what I want to control for anyways). That decision can be made based on password composition requirements and what the password is used for. Next, I would keep track of every bad password attempt from all sources over the life of the password. I would also eliminate the notion of lockout after a few failed attempts over a short windows of time. (A guess is a guess… there is no difference between 1,000 guesses made in one second vs. making 1,000 guesses over a few days. The only thing guess reset windows do for us is create helpdesk calls.) Instead I would monitor the percentage of guesses that had been consumed for each password over the entire life of the password. So in the example above, I want to reduce the total possible number of guesses for each password to 1,000 over the life of the password. I pulled 1,000 out of thin air for this example… my thinking here is that a normal user will not make 1,000 wrong guesses in three months. That number should also be able to handle someone fat-fingering their password in a smart-phone and not catching if for a day. 1,000 guesses is just 5 percent of the possible number above (much higher assurance) and I don’t have to use aggressive lockout to implement it. In terms of monitoring, all I do is watch the percentage of guessed passwords consumed and guess consumption rate for each user. Outliers will quickly stand out and could be monitored, trigger action from the security office and/or trigger a proactive help desk call to the user. Once the maximum number of guesses has been consumed OR the maximum age has been exceeded (to account for shoulder surfing and other compromise modes), the password would be treated as expired and must be changed. As of today, this scheme is not possible using AD or most other authentication providers so this is all theoretical. But as password assurance becomes more critical, Microsoft and other vendors need to look at options like this to replace traditional, older methods in places where high-assurance, single-factor password authentication is required. James Rupprecht Enterprise IT Architect, Microsoft Technologies University of Kansas Information Technology From: [email protected] [mailto:[email protected]] On Behalf Of Maglinger, Paul Sent: Tuesday, September 24, 2013 5:13 PM To: '[email protected]' Subject: RE: [NTSysADM] PCI compliance and account lockout policies But it’s what PCI requires that counts… From: [email protected] [mailto:[email protected]] On Behalf Of Michael B. Smith Sent: Tuesday, September 24, 2013 4:00 PM To: [email protected] Subject: RE: [NTSysADM] PCI compliance and account lockout policies Microsoft no longer recommends using account lockout policies, instead requiring complex passwords. From: [email protected] [mailto:[email protected]] On Behalf Of Ziots, Edward Sent: Tuesday, September 24, 2013 2:43 PM To: [email protected] Subject: RE: [NTSysADM] PCI compliance and account lockout policies Actually answered my own question: PCI DSS 2.0 documents. 8.5.13 Limit repeated access attempts by locking out the user ID after not more than six attempts. (So asking for 3 attempts and 30 mins, abeit a little stringent is more than what the specification is asking which is no-more than six attempts). But also note the following: 8.2 In addition to assigning a unique ID, employ at least one of the following methods to authenticate all users: § Something you know, such as a password or passphrase § Something you have, such as a token device or smart card § Something you are, such as a biometric So without assuming anything are those whom would have access to the PCI environment have the following: 1) Unique ID’s 2) Two factor Authentication. Note this does not take in effect any service accounts that might be used. HTH Z Edward E. Ziots, CISSP, CISA, Security +, Network + Security Engineer Lifespan Organization [email protected] Work:401-255-2497 This electronic message and any attachments may be privileged and confidential and protected from disclosure. If you are reading this message, but are not the intended recipient, nor an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that you are strictly prohibited from copying, printing, forwarding or otherwise disseminating this communication. If you have received this communication in error, please immediately notify the sender by replying to the message. Then, delete the message from your computer. Thank you. From: [email protected] [mailto:[email protected]] On Behalf Of Ziots, Edward Sent: Tuesday, September 24, 2013 1:52 PM To: [email protected] Subject: RE: [NTSysADM] PCI compliance and account lockout policies MY question is which section in PCI explicitly states you need to use account lockout for compliance aspect. You are right there is a legitimate risk of having your accounts locked out, causing a DOS, but also the DOS itself would be pretty noisy and you should be able to detect that in your incident response measures. Also if you are using long and complex passwords, its going to be pretty hard to bruteforce guess the password. (Now if they get the hash to the account then that is another story) Z Edward E. Ziots, CISSP, CISA, Security +, Network + Security Engineer Lifespan Organization [email protected] Work:401-255-2497 This electronic message and any attachments may be privileged and confidential and protected from disclosure. If you are reading this message, but are not the intended recipient, nor an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that you are strictly prohibited from copying, printing, forwarding or otherwise disseminating this communication. If you have received this communication in error, please immediately notify the sender by replying to the message. Then, delete the message from your computer. Thank you. From: [email protected] [mailto:[email protected]] On Behalf Of Eric Wittersheim Sent: Tuesday, September 24, 2013 1:20 PM To: [email protected] Subject: [NTSysADM] PCI compliance and account lockout policies I'm wondering what you all are using for your account lockout policy if you are PCI compliant or something similar. Our auditors are requesting account lock out after 3 attempts for a minimum duration of 30 minutes. Our concern is what happens if we are brute forced and all of our users are locked out. We already have very strict firewall policies in place and our network is segmented as well but you never know. Do any of you use any tools that might help mitigate damage that can occur with a lockout policy in place? Thank you, Eric
<<inline: image001.jpg>>
