Microsoft Windows Common Criteria Evaluation Microsoft Windows 10 (Anniversary Update) Microsoft Windows Server 2016

20.FPT_ACF_EXT.1.2

The evaluator will create an unprivileged user account. Using this account, the evaluator will ensure that the following tests result in a negative outcome (i.e., the action results in the OS denying the evaluator permission to complete the action):

• 
  Test 1: The evaluator will attempt to read security audit logs generated by the auditing subsystem
  
• 
  Test 2: The evaluator will attempt to read system­wide credential repositories
  
• 
  Test 3: The evaluator will attempt to read any other object specified in the assignment
  

20.1.1.1.1Address Space Layout Randomization (FPT_ASLR_EXT.1)

The evaluator will select 3 executables included with the TSF. These must include any web browser or mail client included with the TSF. For each of these apps, the evaluator will launch the same executables on two separate instances of the OS on identical hardware and compare all memory mapping locations. The evaluator will ensure that no memory mappings are placed in the same location. If the rare chance occurs that two mappings are the same for a single executable and not the same for the other two, the evaluator will repeat the test with that executable to verify that in the second test the mappings are different.

20.1.1.1.2Stack Buffer Overflow Protection (FPT_SBOP_EXT.1)

The evaluator will determine that the TSS contains a description of stack­based buffer overflow protections used by the OS. Example implementations may be activated through compiler options such as "­fstack­protector­all", "fstack­protector", and "/GS" flags. These are referred to by a variety of terms, such as stack cookie, stack guard, and stack canaries. The TSS must include a rationale for any binaries that are not protected in this manner.

• 
  Test 1: The evaluator will inventory the kernel, libraries, and application binaries to determine those that do not implement stack­based buffer overflow protections. This list should match up with the list provided in the TSS.
  

20.1.1.1.3Software Restriction Policies (FPT_SRP_EXT.1)

For each selection specified in the ST, the evaluator will ensure that the corresponding tests result in a negative outcome (i.e., the action results in the OS denying the evaluator permission to complete the action):

• 
  Test 1: The evaluator will configure the OS to only allow code execution from the core OS directories. The evaluator will then attempt to execute code from a directory that is in the allowed list. The evaluator will ensure that the code they attempted to execute has been executed.
  
• 
  Test 2: The evaluator will configure the OS to only allow code execution from the core OS directories. The evaluator will then attempt to execute code from a directory that is not in the allowed list. The evaluator will ensure that the code they attempted to execute has not been executed.
  
• 
  Test 3: The evaluator will configure the OS to only allow code that has been signed by the OS vendor to execute. The evaluator will then attempt to execute code signed by the OS vendor. The evaluator will ensure that the code they attempted to execute has been executed.
  
• 
  Test 4: The evaluator will configure the OS to only allow code that has been signed by the OS vendor to execute. The evaluator will then attempt to execute code signed by another digital authority. The evaluator will ensure that the code they attempted to execute has not been executed.
  
• 
  Test 5: The evaluator will configure the OS to allow execution of a specific application based on version. The evaluator will then attempt to execute the same version of the application. The evaluator will ensure that the code they attempted to execute has been executed.
  
• 
  Test 6: The evaluator will configure the OS to allow execution of a specific application based on version. The evaluator will then attempt to execute an older version of the application. The evaluator will ensure that the code they attempted to execute has not been executed.
  
• 
  Test 7: The evaluator will configure the OS to allow execution based on the hash of the application executable. The evaluator will then attempt to execute the application with the matching hash. The evaluator will ensure that the code they attempted to execute has been executed.
  
• 
  Test 8: The evaluator will configure the OS to allow execution based on the hash of the application executable. The evaluator will modify the application in such a way that the application hash is changed. The evaluator will then attempt to execute the application with the matching hash. The evaluator will ensure that the code they attempted to execute has not been executed.
  

20.1.1.1.4Boot Integrity (FPT_TST_EXT.1)

The evaluator will verify that the TSS section of the ST includes a comprehensive description of the boot procedures, including a description of the entire bootchain, for the TSF . The evaluator will ensure that the OS cryptographically verifies each piece of software it loads in the bootchain to include bootloaders and the kernel. Software loaded for execution directly by the platform (e.g. first­stage bootloaders) is out of scope. For each additional category of executable code verified before execution, the evaluator will verify that the description in the TSS describes how that software is cryptographically verified.

The evaluator will verify that the TSS contains a description of the protection afforded to the mechanism performing the cryptographic verification.

The evaluator will perform the following tests:

• 
  Test 1: The evaluator will perform actions to cause TSF software to load and observe that the integrity mechanism does not flag any executables as containing integrity errors and that the OS properly boots.
  
• 
  Test 2: The evaluator will modify a TSF executable that is part of the bootchain verified by the TSF (i.e. Not the first­stage bootloader) and attempt to boot. The evaluator will ensure that an integrity violation is triggered and the OS does not boot (Care must be taken so that the integrity violation is determined to be the cause of the failure to load the module, and not the fact that in such a way to invalidate the structure of the module.).
  
• 
  Test 3: If the ST author indicates that the integrity verification is performed using a public key, the evaluator will verify that the update mechanism includes a certificate validation according to FIA_X509_EXT.1. The evaluator will digitally sign the TSF executable with a certificate that does not have the Code Signing purpose in the extendedKeyUsage field and verify that an integrity violation is triggered. The evaluator shall repeat the test using a certificate that contains the Code Signing purpose and verify that the integrity verification succeeds. Ideally, the two certificates should be identical except for the extendedKeyUsage field.
  

20.1.1.1.5Trusted Update (FPT_TUD_EXT.1)