Meeting the InCommon Assurance profile criteria using Active Directory

["Capehart,Jeffrey D" <>]

Maybe if we have some folks throw out suggestions via the email list, they can be evaluated on a per-criteria basis to make less work of it?

 

For example, let’s start with 4.2.3.4, the stored passwords criteria.  If syskey will encrypt the “SAM”, does that cover everything for password storage?  Do we know if syskey uses an approved algorithm?

 

Some configurations would turn off LM Hash storage and force NTLM to be used, ensure no passwords stored in the clear, and make sure Kerberos authentications use only Approved Algorithms (does Kerberos store the keys derived from the NT Hash/password or are they always derived on-the-fly?):

·         Set the value for Store password using reversible encryption to Disabled.

·         Prevent storage of the LM Hash:  Network security: Do not store LAN Manager hash value on next password change

·         Network security: Configure encryption types allowed for Kerberos

 

Then you only need AM for the MD4 (salted, but not variable, hash).  That will be tough with claims of 348 billion hashes per second with 25 GPU’s.

 

If you used syskey, that is supposed to encrypt the whole password database, right?

 

If you used Bitlocker full disk encryption instead, that might cover encrypting the password database, but it might not meet the part about passwords being decrypted only when required for immediate authentication.

 

If you don’t encrypt, the server better be well protected to defend in an alternative means.

 

For those thinking that configuring to meet the spec isn’t an alternative means, my view on that is that there are probably ways to configure Active Directory as strongly as possible and still be stuck with something that doesn’t meet the criteria.  Therefore, the alternative means would still need to be applied, but to a more limited a set of problems.

 

For example, by exceeding standards elsewhere, it may be possible to assert that the security is good enough to meet the expected risk, along with the configurations mentioned.

 

So, to minimize risk of someone stealing the password database, a policy of not surfing the web from servers, not reading email on servers, having anti-virus running, firewalls, or limiting functionality might reduce the risk of getting hacked, but won’t be as strong as encrypting the password database.

 

If the domain servers require special admin logins with higher credentials or much stronger password requirements, or perhaps an administrative VPN to access them, or only from the server room which requires key card access with a pin (i.e. two factor) and security cameras, then that could “exceed” the minimum required from the lead-in and physical security criteria:

·          4.2.3.4 (lead in) Access to encrypted stored Secrets and to decrypted copies shall be protected by discretionary access controls that limit access to administrators and applications that require access. (Could be admin account password, member of domain administrator group, or service accounts.)

·         4.2.8.2 IdMS Operations shall employ physical access control mechanisms to restrict access to sensitive areas, including areas such as leased space in remote data centers, to authorized personnel. (Here, a locked door could meet this requirement.)

 

The following applies more to a client workstation than a server, but you get the idea of compensating controls (i.e. an alternative means).  This one is for if you allow storage of cached credentials, here is a way to protect them.

 

Microsoft states:

Passwords that are cached can be accessed by the user when logged on to the computer. Although this information may sound obvious, a problem can arise if the user unknowingly runs malicious software that reads the passwords and forwards them to another, unauthorized user.

 

The chances of success for this exploit and others that involve malicious software are reduced significantly for organizations that effectively implement and manage an enterprise antivirus solution combined with sensible software restriction policies. For more information see Software Restriction Policies.

 

 

Software Restriction Policies.

Applies To: Windows Server 2008 (Updated: January 21, 2009)

Software restriction policies provide a policy-driven system to specify which programs are allowed to run on the local computer and which are not. Two improvements have been made to software restriction policies for Windows Vista and Windows Server 2008. First, the default hash rule algorithm has been upgraded from Message Digest version 5 (MD5) to the Secure Hash Alogorithm-256(SHA256). SHA-256 is a 256-bit (32-byte) message digest hash and is meant to provide 128 bits of security against collision attacks and is considered much stronger than MD5, which has known vulnerabilities. MD5 is still supported for compatibility with Windows XP. Second, certificate rules can now be activated from within the Software Restriction Policies snap-in extension instead of from within the Local Security Policies snap-in.

--Jeff

 

From: [mailto:] On Behalf Of Michael W. Brogan
Sent: Thursday, March 21, 2013 4:10 PM
To:
Subject: [AD-Assurance] RE: Questions for Microsoft?

 

My thought is that our efforts to complete the third and fourth columns of the table at https://spaces.internet2.edu/x/BA8wAg would expose some knowledge gaps we would turn into questions for Microsoft. In addition there might be a set of statements for which we need verification.

 

Perhaps we could use footnotes within the table to link to a set of question tallied below the table?

 

I may not have the knowledge or time to complete columns 3 and 4, so I encourage others to contribute where they can.

 

--Michael