Meeting the InCommon Assurance profile criteria using Active Directory

["Capehart,Jeffrey D" <>]

While thinking of questions for Microsoft, I took a look at how they were able to have Windows validated for Common Criteria Evaluation.  Here’s my review for the Windows 7 and Server 2008 validations (there are also earlier reports for Vista, XP, and Server 2003.)

http://www.niap-ccevs.org/st/st_vid10390-st.pdf  (Full 190 page document)

 

The short version seems to be:  They used IPSec, required 16 char passwords, required an AD domain be available, turned on FIPS mode, and probably also BitLockered the machine, and required the AD server to also follow their security management policy.

 

Just because Windows supports a feature doesn’t mean that everyone is using it, but it seems like Microsoft can pass validation if they offer the feature. 

 

Here are some “features” relevant to the IAP, based on the Target of Evaluation (TOE) system configuration and the TOE Security Functions (TSF):

 

Credential Manager (Previously Approved)

This provides a secure store for usernames/passwords and also stores links to certificates and keys. This enables a consistent single sign-on experience for users, including roaming users. Single sign-on makes it possible for users to access resources over the network without having to repeatedly supply their credentials.

 

Secure Network Communications   (IPSec, Previously Approved)

Windows 7 and Windows Server 2008 R2 support end-to-end encrypted communications across network using the IPSec standard. It protects sensitive internal communications from intentional or accidental viewing. AD provides central policy control for its use to make it deployable.

 

Cryptographic Protection: Windows 7 and Windows Server 2008 R2 provide FIPS-140-2 validated cryptographic functions that support encryption/decryption, cryptographic signatures, cryptographic hashing, cryptographic key agreement, and random number generation. The TOE additionally provides support for public keys, credential management and certificate validation functions and provides support for the National Security Agency’s Suite B cryptographic algorithms. The TOE also provides extensive auditing support of cryptopgraphic operations, support for replaceable random number generators, and a key isolation service designed to limit the potential exposure of secret and private keys. In addition to supporting its own security functions with cryptographic support, the TOE offers access to the cryptographic support functions for user application programs.

 

Table 3-1 presents known or presumed threats to protected resources that are addressed by Windows 7 and Windows Server 2008 R2.

T.REPLAY

A user may gain inappropriate access to the TOE by replaying authentication information, or may cause the TOE to be inappropriately configured by replaying TSF data or security attributes.

 

5.2.5.3 Verification of Secrets (FIA_SOS.1)

FIA_SOS.1.1 The TSF shall provide a mechanism to verify that secrets meet the following:

a) Passwords are at least 16 characters in length, consisting of any combination of upper and lower case letters, numbers, and symbols, and

b) Passwords are not reused within the last administrator-settable number of passwords used by that user.

 

6.1.4.4 Active Directory

The Active Directory Domain Services role, also known as a Domain Controller (DC), instantiates AD services that define policies and accounts that are shared by Windows machines in the domain. In addition group policies (see Security Management (FMT)) can also be defined in the AD that apply to selected machines and accounts within the domain.

 

6.1.4.6 Logon Process

[A very long, but good discussion on Kerberos and NTLM with Active Directory] …two types of authentication protocols will be used, either Windows Challenge / Response (NTLM) or Kerberos. Kerberos is the default logon method and will be used if a Kerberos KDC is available. Each DC includes a KDC in addition to its AD. NTLM will be used if no KDC is available or if the client requests NTLM authentication instead of Kerberos authentication. In the evaluated configuration a KDC is available to each DC.

 

[…] Furthermore, the Windows Kerberos feature is designed to employ the applicable cryptographic protection mechanisms described earlier.

 

FPT_WPF_EX.5: TPM Full Volume Encryption Support provides the ability for the TOE to make use of the capabilities of a supporting TPM chip in order to store encryption keys and to make them available only when appropriate conditions (i.e., system integrity) have been satisfied.

 

6.1.6.1 BitLocker Drive Encryption

In addition to protecting the TSF during runtime, BitLocker Drive Encryption (BDE) is a data protection feature available in Windows. It is responsible for helping prevent unauthorized access to data on lost or stolen systems (i.e., where physical access to the disk drive is possible) and therefore is intended primarily to defend against offline and online attacks when the user no longer has physical possession of the machine. BitLocker accomplishes this by combining two major data-protection procedures:

·         Encrypting the entire Windows operating system volume on the hard disk.

·         Verifying the integrity of early boot components and boot configuration data.

 

By default BitLocker will encrypt the hard drive using AES128-CBC with Elephant Diffuser; in addition, it can be configured to use (regular) AES-CBC using both 128 and 256 bit disk encryption keys. In the AES-CBC scenario, BitLocker derives the IV for a block from the AES key and block offset.

 

---

Jeff Capehart, CISA
IT Audit Manager
University of Florida - Office of Internal Audit
(352) 273-1882

http://oia.ufl.edu