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

3.2Organizational Security Policies

An organizational security policy is a set of rules or procedures imposed by an organization upon its operations to protect its sensitive data and IT assets. Table describes organizational security policies which are necessary for conformance to the protection profile.

Table Organizational Security Policies

Security Policy	Description
[None]	There are no Organizational Security Policies for the protection profile.

3.3Secure Usage Assumptions

Table describes the core security aspects of the environment in which Windows is intended to be used. It includes information about the physical, personnel, procedural, and connectivity aspects of the environment.

The following specific conditions are assumed to exist in an environment where the TOE is employed in order to conform to the protection profile:

Table Secure Usage Assumptions

Assumption	Description
A.PLATFORM	The OS relies upon a trustworthy computing platform for its execution. This underlying platform is out of scope of this PP.
A.PROPER_USER	The user of the OS is not willfully negligent or hostile, and uses the software in compliance with the applied enterprise security policy. At the same time, malicious software could act as the user, so requirements which confine malicious subjects are still in scope.
A.PROPER_ADMIN	The administrator of the OS is not careless, willfully negligent or hostile, and administers the OS within compliance of the applied enterprise security policy.

4.Security Objectives

This section defines the security objectives of Windows 10, Server 2016 and its supporting environment. Security objectives, categorized as either TOE security objectives or objectives by the supporting environment, reflect the stated intent to counter identified threats, comply with any organizational security policies identified, or address identified assumptions. All of the identified threats, organizational policies, and assumptions are addressed under one of the categories below.

4.1TOE Security Objectives

Table describes the security objectives for Windows which are needed to comply with the GP OS PP.

Table Security Objectives for the TOE

Security Objective	Source
O.ACCOUNTABILITY	Conformant OSs ensure that information exists that allows administrators to discover unintentional issues with the configuration and operation of the operating system and discover its cause. Gathering event information and immediately transmitting it to another system can also enable incident response in the event of system compromise.
O.INTEGRITY	Conformant OSs ensure the integrity of their update packages. OSs are seldom if ever shipped without errors, and the ability to deploy patches and updates with integrity is critical to enterprise network security. Conformant OSs provide execution environment based mitigations that increase the cost to attackers by adding complexity to the task of compromising systems.
O.MANAGEMENT	To facilitate management by users and the enterprise, conformant OSes provide consistent and supported interfaces for their security relevant configuration and maintenance. This includes the deployment of applications and application updates through the use of platform supported deployment mechanisms and formats, as well as providing mechanisms for configuration and application execution control.
O.PROTECTED_STORAGE	To address the issue of loss of confidentiality of credentials in the event of loss of physical control of the storage medium, conformant OSs provide data­at­rest protection for credentials. Conformant OSes also provide access controls which allow users to keep their files private from other users of the same system.
O.PROTECTED_COMMS	To address both passive (eavesdropping) and active (packet modification) network attack threats, conformant OSs provide mechanisms to create trusted channels for CSP and sensitive data. Both CSP and sensitive data should not be exposed outside of the platform.

4.2Security Objectives for the Operational Environment

The TOE is assumed to be complete and self-contained and, as such, is not dependent upon any other products to perform properly. However, certain objectives with respect to the general operating environment must be met. Table describes the security objectives for the operational environment as specified in the protection profile.

Table Security Objectives for the Operational Environment

Environment Objective	Description
OE.PLATFORM	The OS relies on being installed on trusted hardware.
OE.PROPER_USER	The user of the OS is not willfully negligent or hostile, and uses the software within compliance of the applied enterprise security policy. Standard user accounts are provisioned in accordance with the least privilege model. Users requiring higher levels of access should have a separate account dedicated for that use.
OE.PROPER_ADMIN	The administrator of the OS is not careless, willfully negligent or hostile, and administers the OS within compliance of the applied enterprise policy.

5.Security Requirements

The section defines the Security Functional Requirements (SFRs) and Security Assurance Requirements (SARs) for the TOE. The requirements in this section have been drawn from the General Purpose Operating Systems Protection Profile, Version 4.1, March 9, 2016 (GP OS PP), the Common Criteria, or are defined in the following section.

Conventions:

Where requirements are drawn from the protection profile, the requirements are copied verbatim, except for some changes to required identifiers to match the iteration convention of this document, from that protection profile and only operations performed in this security target are identified.

The extended requirements, extended component definitions and extended requirement conventions in this security target are drawn from the protection profile; the security target reuses the conventions from the protection profile which include the use of the word “Extended” and the “_EXT” identifier to denote extended functional requirements. The security target assumes that the protection profile correctly defines the extended components and so they are not reproduced in the security target.

Where applicable the following conventions are used to identify operations:

• 
  Iteration: Iterated requirements (components and elements) are identified with letter following the base component identifier. For example, iterations of FMT_MOF.1 are identified in a manner similar to FMT_MOF.1(Audit) (for the component) and FCS_COP.1.1(Audit) (for the elements).
  
• 
  Assignment: Assignments are identified in brackets and bold (e.g., [assigned value]).
  
• 
  Selection: Selections are identified in brackets, bold, and italics (e.g., [selected value]).
  
  • 
    Assignments within selections are identified using the previous conventions, except that the assigned value would also be italicized and extra brackets would occur (e.g., [selected value [assigned value]]).
    

• 
  Refinement: Refinements are identified using bold text (e.g., added text) for additions and strike-through text (e.g., deleted text) for deletions.
  

5.1TOE Security Functional Requirements

This section specifies the SFRs for the TOE.

Table TOE Security Functional Requirements

Requirement Class	Requirement Component
Security Audit (FAU)	Audit Data Generation (FAU_GEN.1)
Cryptographic Support (FCS)	Cryptographic Key Generation for (FCS_CKM.1(1))
	Cryptographic Key Establishment (FCS_CKM.2(1)
	Cryptographic Key Destruction (FCS_CKM_EXT.3)
	Cryptographic Operation for Data Encryption/Decryption (FCS_COP.1(SYM))
	Cryptographic Operation for Hashing (FCS_COP.1(HASH))
	Cryptographic Operation for Signing (FCS_COP.1(SIGN))
	Cryptographic Operation for Keyed Hash Algorithms (FCS_COP.1(HMAC))
	Random Bit Generation (FCS_RBG_EXT.1)
	Storage of Sensitive Data (FCS_STO_EXT.1)
	TLS Client Protocol (FCS_TLSC_EXT.1)
	TLS Client Protocol (FCS_TLSC_EXT.2)
	TLS Client Protocol (FCS_TLSC_EXT.3)
	TLS Client Protocol (FCS_TLSC_EXT.4)
	DTLS Implementation (FCS_DTLS_EXT.1)
User Data Protection (FDP)	Access Controls for Protecting User Data (FDP_ACF_EXT.1)
	Information Flow Control (FDP_IFC_EXT.1)
Identification & Authentication (FIA)	Authorization Failure Handling (FIA_AFL.1)
	Multiple Authentication Mechanisms (FIA_UAU.5)
	X.509 Certification Validation (FIA_X509_EXT.1)
	X.509 Certificate Authentication (FIA_X509_EXT.2)
Security Management (FMT)	Management of Security Functions Behavior (FMT_MOF_EXT.1)
Protection of the TSF (FPT)	Access Controls (FPT_ACF_EXT.1)
	Address Space Layout Randomization (FPT_ASLR_EXT.1)
	Stack Buffer Overflow Protection (FPT_SBOP_EXT.1)
	Software Restriction Policies (FPT_SRP_EXT.1)
	Boot Integrity (FPT_TST_EXT.1)
	Trusted Update (FPT_TUD_EXT.1)
	Trusted Update for Application Software (FPT_TUD_EXT.2)
TOE Access (FTA)	Default TOE Access Banners (FTA_TAB.1)
Trusted Path/Channels (FTP)	Trusted Path (FTP_TRP.1)
	Trusted Channel Communication (FTP_ITC_EXT.1(TLS))
	Trusted Channel Communication (FTP_ITC_EXT.1(DTLS))

5.1.1Security Audit (FAU)

5.1.1.1Audit Data Generation (FAU_GEN.1)

FAU_GEN.1.1

The OS shall be able to generate an audit record of the following auditable events: Start-up and shutdown of the audit functions; All auditable events for the not specified level of audit; and Authentication events (Success/Failure); Use of privileged/special rights events (Successful and unsuccessful security, audit, and configuration changes); Privilege or role escalation events (Success/Failure); [ File and object events (Successful and unsuccessful attempts to create, access, delete, modify, modify permissions), User and Group management events (Successful and unsuccessful add, delete, modify, disable), Audit and log data access events (Success/Failure), Cryptographic verification of software (Success/Failure), Program initiations (Success/Failure e.g. due to software restriction policy), System reboot, restart, and shutdown events (Success/Failure), Kernel module loading and unloading events (Success/Failure), Administrator or root­level access events (Success/Failure), [Lock and Unlock a user account]. ]

FAU_GEN.1.2

The OS shall record within each audit record at least the following information: Date and time of the event, type of event, subject identity (if applicable), and outcome (success or failure) of the event; and For each audit event type, based on the auditable event definitions of the functional components included in the PP/ST [none].

5.1.2Cryptographic Support (FCS)

5.1.2.1Cryptographic Key Generation (FCS_CKM.1(1))

Application Note: FCS_CKM.1.1 corresponds to FCS_CKM.1.1(1) in the GP OS protection profile.

FCS_CKM.1.1

The OS shall generate asymmetric cryptographic keys in accordance with a specified cryptographic key generation algorithm [ RSA schemes using cryptographic key sizes of 2048­bit or greater that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.3] ECC schemes using “NIST curves” P-256, P-384 and [P-521] that meet the following: FIPS PUB 186-4, “Digital Signature Standard (DSS), Appendix B.4 ].

5.1.2.2Cryptographic Key Establishment (FCS_CKM.2(1))

Application Note: FCS_CKM.2.1 corresponds to FCS_CKM.2.1(1) in the GP OS protection profile.

FCS_CKM.2.1

The OS shall implement functionality to perform cryptographic key establishment in accordance with a specified cryptographic key establishment method: RSA-based key establishment schemes that meets the following: NIST Special Publication 800-56B, “Recommendation for Pair-Wise Key Establishment Schemes Using Integer Factorization Cryptography” and [Elliptic curve-based key establishment schemes that meets the following: NIST Special Publication 800-56A, “Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography” ].

5.1.2.3Cryptographic Key Destruction (FCS_CKM_EXT.3)

FCS_CKM_EXT.3.1

The OS shall destroy cryptographic keys in accordance with the specified cryptographic key destruction methods [ For volatile memory, the destruction shall be executed by a single direct overwrite [consisting of zeroes] followed by a read­verify. If the read­verification of the overwritten data fails, the process shall be repeated again. ].

5.1.2.4Cryptographic Operation for Encryption / Decryption (FCS_COP.1(SYM))

Application Note: FCS_COP.1(SYM) corresponds to FCS_COP.1(1) in the GP OS protection profile.

FCS_COP.1.1(SYM)

The OS shall perform encryption/decryption services for data in accordance with a specified cryptographic algorithm:[ AES-XTS (as defined in NIST SP 800-38E),^5 AES-CBC (as defined in NIST SP 800-38A)] and [ AES Key Wrap (KW) (as defined in NIST SP 800-38F), AES-GCM (as defined in NIST SP 800-38D), AES-CCM (as defined in NIST SP 800-38C) ] and cryptographic key sizes [128-bit 256-bit].

5.1.2.5Cryptographic Operation for Hashing (FCS_COP.1(HASH))

Application Note: FCS_COP.1(HASH) corresponds to FCS_COP.1(2) in the GP OS protection profile.

FCS_COP.1.1(HASH)

The OS shall perform cryptographic hashing services in accordance with a specified cryptographic algorithm SHA-1 and [SHA-256, SHA-384, SHA-512] and message digest sizes 160 bits and [256 bits, 384 bits, 512 bits] that meet the following: FIPS Pub 180-4.

5.1.2.6Cryptographic Operation for Signing (FCS_COP.1(SIGN))

Application Note: FCS_COP.1(SIGN) corresponds to FCS_COP.1(3) in the GP OS protection profile.

FCS_COP.1.1(SIGN)

The OS shall perform cryptographic signature services (generation and verification) in accordance with a specified cryptographic algorithm [ RSA schemes using cryptographic key sizes of 2048-bit or greater that meet the following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 4, ECDSA schemes using “NIST curves” P-256, P-384 and [P-521] that meet the following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 5 ].

5.1.2.7Cryptographic Operation for Keyed Hash Algorithms (FCS_COP.1(HMAC))

Application Note: FCS_COP.1(HMAC) corresponds to FCS_COP.1(4) in the GP OS protection profile.

FCS_COP.1.1(HMAC)

The OS shall perform keyed-hash message authentication services in accordance with a specified cryptographic algorithm [ SHA-1, SHA-256, SHA-384, SHA-512 ] with key sizes [128 and 256 bits] and message digest sizes [160 bits, 256 bits, 384 bits, 512 bits] that meet the following: FIPS Pub 198-1 The Keyed-Hash Message Authentication Code and FIPS Pub 180-4 Secure Hash Standard.

5.1.2.8Random Bit Generation (FCS_RBG_EXT.1)

FCS_RBG_EXT.1.1	The OS shall perform all deterministic random bit generation (DRBG) services in accordance with NIST Special Publication 800-90A using [CTR_DRBG (AES)].
FCS_RBG_EXT.1.2	The deterministic RBG used by the OS shall be seeded by an entropy source that accumulates entropy from a [software-based noise source, platform-based noise source] with a minimum of [256 bits] of entropy at least equal to the greatest security strength (according to NIST SP 800-57) of the keys and hashes that it will generate.

5.1.2.9Storage of Sensitive Data (FCS_STO_EXT.1)

FCS_STO_EXT.1.1

The OS shall implement functionality to encrypt sensitive data stored in non-volatile storage and provide interfaces to applications to invoke this functionality.

5.1.2.10TLS Client Protocol (FCS_TLSC_EXT.1)

FCS_TLSC_EXT.1.1	The OS shall implement TLS 1.2 (RFC 5246) supporting the following ciphersuites: Mandatory ciphersuites: TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 5246 Optional ciphersuites: [ TLS_RSA_WITH_AES_256_CBC_SHA as defined in RFC 5246 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA as defined in RFC 4492 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA as defined in RFC 4492 TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246 TLS_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289 ].
FCS_TLSC_EXT.1.2	The OS shall verify that the presented identifier matches the reference identifier according to RFC 6125.
FCS_TLSC_EXT.1.3	The OS shall only establish a trusted channel if the peer certificate is valid.

5.1.2.11TLS Client Protocol (FCS_TLSC_EXT.2)

FCS_TLSC_EXT.2.1

The OS shall present the Supported Elliptic Curves Extension in the Client Hello with the following NIST curves: [secp256r1, secp384r1, secp512r1] and no other curves.

5.1.2.12TLS Client Protocol (FCS_TLSC_EXT.3)

FCS_TLSC_EXT.3.1

The OS shall present the signature_algorithms extension in the Client Hello with the supported_signature_algorithms value containing the following hash algorithms [SHA256, SHA384, SHA512] and no other hash algorithms.

5.1.2.13TLS Client Protocol (FCS_TLSC_EXT.4)

FCS_TLSC_EXT.4.1

The OS shall support mutual authentication using X.509v3 certificates.

5.1.2.14DTLS Implementation (FCS_DTLS_EXT.1)

FCS_DTLS_EXT.1.1	The OS shall implement the DTLS protocol in accordance with [DTLS 1.0 (RFC 4347), DTLS 1.2 (RFC 6347)].
FCS_DTLS_EXT.1.2	The OS shall implement the requirements in TLS (FCS_TLSC_EXT.1) for the DTLS implementation, except where variations are allowed according to DTLS 1.2 (RFC 6347).

5.1.3User Data Protection (FDP)

5.1.3.1Access Controls for Protecting User Data (FDP_ACF_EXT.1)

FDP_ACF_EXT.1.1

The OS shall implement access controls which can prohibit unprivileged users from accessing files and directories owned by other users.

5.1.3.2Information Flow Control (FDP_IFC_EXT.1)

FDP_IFC_EXT.1.1

The OS shall [ Provide an interface which allows a VPN client to protect all IP traffic using IPsec ] with the exception of IP traffic required to establish the VPN connection.

5.1.4Identification and Authentication (FIA)

5.1.4.1Authentication Failure Handling (FIA_AFL.1)

FIA_AFL.1.1	The OS shall detect when [an administrator configurable positive integer within a [range of 1 - 999] ] unsuccessful authentication attempts for [ Authentication based on user name and password, ] occur related to [the last successful authentication by that user].
FIA_AFL.1.2	When the defined number of unsuccessful authentication attempts for an account has been met, the OS shall: [Account Lockout].

5.1.4.2Multiple Authentication Mechanisms (FIA_UAU.5)

FIA_UAU.5.1	The OS shall provide the following authentication mechanisms: [ Authentication based on user name and password, ] to support user authentication.
FIA_UAU.5.2	The OS shall authenticate any user’s claimed identity according to the [authentication based on username and password is performed for TOE-originated requests and with credentials stored by the OS].

5.1.4.3X.509 Certification Validation (FIA_X509_EXT.1)

FIA_X509_EXT.1.1

The OS shall implement functionality to validate certificates in accordance with the following rules: RFC 5280 certificate validation and certificate path validation. The certificate path must terminate with a trusted CA certificate. The OS shall validate a certificate path by ensuring the presence of the basicConstraints extension and that the CA flag is set to TRUE for all CA certificates. The OS shall validate the revocation status of the certificate using [the Online Certificate Status Protocol (OCSP) as specified in RFC 2560, a Certificate Revocation List (CRL) as specified in RFC 5759, an OCSP TLS Status Request Extension (i.e., OCSP stapling) as specified in RFC 6066]. The OS shall validate the extendedKeyUsage field according to the following rules: Certificates used for trusted updates and executable code integrity verification shall have the Code Signing purpose (id-kp 3 with OID 1.3.6.1.5.5.7.3.3) in the extendedKeyUsage field. Server certificates presented for TLS shall have the Server Authentication purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1) in the extendedKeyUsage field. Client certificates presented for TLS shall have the Client Authentication purpose (id-kp 2 with OID 1.3.6.1.5.5.7.3.2) in the extendedKeyUsage field. S/MIME certificates presented for email encryption and signature shall have the Email Protection purpose (id-kp 4 with OID 1.3.6.1.5.5.7.3.4) in the extendedKeyUsage field. OCSP certificates presented for OCSP responses shall have the OCSP Signing purpose (id-kp 9 with OID 1.3.6.1.5.5.7.3.9) in the extendedKeyUsage field.

FIA_X509_EXT.1.2

The OS shall only treat a certificate as a CA certificate if the basicConstraints extension is present and the CA flag is set to TRUE.

5.1.4.4X.509 Certificate Authentication (FIA_X509_EXT.2)

FIA_X509_EXT.2.1

The OS shall use X.509v3 certificates as defined by RFC 5280 to support authentication for TLS and [HTTPS] connections.

5.1.5Security Management (FMT)

5.1.5.1Management of Security Functions Behavior (FMT_MOF_EXT.1)

FMT_MOF_EXT.1.1

The OS shall be capable of performing the following management functions, controlled by the user and overridden by the administrator as shown: X: Mandatory O: Optional Management Function Administrator User Configure minimum password length O O Configure minimum number of special characters in password O O Configure minimum number of numeric characters in password O O Configure minimum number of uppercase characters in password O O Configure minimum number of lowercase characters in password O O Enable/disable screen lock O O Configure screen lock inactivity timeout O O Configure remove connection inactivity timeout O O Enable/disable unauthenticated logon X X Configure lockout policy for unsuccessful authentication attempts through [timeouts between attempts, limiting the number of attempts during a time period] O O Configure host-based firewall O O Configure name/address of directory server to bind with O O Configure name/address of remote management server from which to receive management settings O O Configure name/address of audit/logging server to which to send audit/logging records O O Configure local audit storage capacity O O Configure audit rules O O Configure name/address of network time server O O Enable/disable automatic software update O O Configure Wi-Fi interface O O Enable/disable Bluetooth interface O O Configure USB interfaces O O Enable/disable [local area network interface] O O [none] O O

Application Note: The intent of this requirement is to ensure that the security target is populated with the management functions which are provided by Windows. This enables developers of compliance checklists, including those provided as operational user guidance, to leverage this table by providing enterprise specific values for each evaluated item.

5.1.6Protection of the TSF (FPT)

5.1.6.1Access Controls (FPT_ACF_EXT.1)

FPT_ACF_EXT.1.1	The OS shall implement access controls which prohibit unprivileged users from modifying: Kernel and its drivers/modules Security audit logs Shared libraries System executables System configuration files [none]
FPT_ACF_EXT.1.2	The OS shall implement access controls which prohibit unprivileged users from reading: Security audit logs System-wide credential repositories [none]

5.1.6.2Address Space Layout Randomization (FPT_ASLR_EXT.1)

FPT_ASLR_EXT.1.1

The OS shall always randomize process address space memory locations except for [none].

5.1.6.3Stack Buffer Overflow Protection (FPT_SBOP_EXT.1)

FPT_SBOP_EXT.1.1

The OS shall be compiled with stack-based buffer overflow protections enabled.

5.1.6.4Software Restriction Policies (FPT_SRP_EXT.1)

FPT_SRP_EXT.1.1

The OS shall restrict execution to only programs which match an administrator-specified [ File path File digital signature Version^6 Hash ].

5.1.6.5Boot Integrity (FPT_TST_EXT.1)

FPT_TST_EXT.1.1

The OS shall verify the integrity of the bootchain up through the OS kernel and [operating system executable code and application executable code] prior to its execution through the use of [a digital signature using a hardware-protected asymmetric key, a hardware-protected hash].^7

5.1.6.6Trusted Update (FPT_TUD_EXT.1)

FPT_TUD_EXT.1.1	The OS shall provide the ability to check for updates to the OS software itself.
FPT_TUD_EXT.1.2	The OS shall cryptographically verify updates to itself using a digital signature prior to installation using schemes specified in FCS_COP.1(SIGN).

5.1.6.7Trusted Update for Application Software (FPT_TUD_EXT.2)

FPT_TUD_EXT.2.1	The OS shall provide the ability to check for updates to application software.
FPT_TUD_EXT.2.2	The OS shall cryptographically verify the integrity of updates to applications using a digital signature specified by FCS_COP.1(SIGN) prior to installation.

5.1.7TOE Access (FTA)

5.1.7.1Default TOE Access Banners (FTA_TAB.1)

FTA_TAB.1.1

Before establishing a user session, the OS shall display an advisory warning message regarding unauthorized use of the OS.

5.1.8Trusted Path / Channels (FTP)

5.1.8.1Trusted Path (FTP_TRP.1)

FTP_TRP.1.1	The OS shall provide a communications path between itself and remote users that is logically distinct from other communications paths and provides assured identification of its endpoints and protection of the communicated data from modification and disclosure.
FTP_TRP.1.2	The OS shall permit [the TSF, local users, remote users] to initiate communication via the trusted path.
FTP_TRP.1.3	The OS shall require use of the trusted path for all remote administrative actions.

5.1.8.2Trusted Channel Communication (FTP_ITC_EXT.1(TLS))

FTP_ITC_EXT.1.1(TLS)

The OS shall use [ TLS as conforming to FCS_TLSC_EXT.1 ] to provide a trusted communications channel between itself and authorized IT entities supporting the following capabilities: [authentication server, [CRL checking, web traffic]] that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from disclosure and detection of modification of the channel data.

5.1.8.3Trusted Channel Communication (FTP_ITC_EXT.1(DTLS))

FTP_ITC_EXT.1.1(DTLS)

The OS shall use [ DTLS as conforming to FCS_DTLS_EXT.1, ] to provide a trusted communications channel between itself and authorized IT entities supporting the following capabilities: [web traffic, datagram-based application protocols] that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from disclosure and detection of modification of the channel data.

5.2TOE Security Assurance Requirements

5.2.1CC Part 3 Assurance Requirements

The following table is the collection of CC Part 3 assurance requirements from the General Purpose Operating Systems Protection Profile.

Requirement Class	Requirement Component
Security Target (ASE)	ST Introduction (ASE_INT.1)
	Conformance Claims (ASE_CCL.1)
	Security Objectives (ASE_OBJ.1)
	Extended Components Definition (ASE_ECD.1)
	Stated Security Requirements (ASE_REQ.1)
	Security Problem Definition (ASE_SPD.1)
	TOE Summary Specification (ASE_TSS.1)
Design (ADV)	Basic Functional Specification (ADV_FSP.1)
Guidance (AGD)	Operational User Guidance (AGD_OPE.1)
	Preparative Procedures (AGD_PRE.1)
Lifecycle (ALC)	Labeling of the TOE (ALC_CMC.1)
	TOE CM Coverage (ALC_CMS.1)
	Timely Security Updates (ALC_TSU_EXT.1)
Testing (ATE)	Independent Testing – Conformance (ATE_IND.1)
Vulnerability Assessment (AVA	Vulnerability Survey (AVA_VAN.1)

Table TOE Security Assurance Requirements

5.2.1.1Timely Security Updates (ALC_TSU_EXT.1)

Developer action elements:

ALC_TSU_EXT.1.1D The developer shall provide a description in the TSS of how timely security updates are made to the TOE.

ALC_TSU_EXT.1.2D The developer shall provide a description in the TSS of how users are notified when updates change security properties or the configuration of the product.

Content and presentation elements:

ALC_TSU_EXT.1.1C The description shall include the process for creating and deploying security updates for the TOE software.

ALC_TSU_EXT.1.2C The description shall include the mechanisms publicly available for reporting security issues pertaining to the TOE. The reporting mechanism could include web sites, email addresses, as well as a means to protect the sensitive nature of the report (e.g., public keys that could be used to encrypt the details of a proof-of-concept exploit).

Evaluator action elements:

ALC_TSU_EXT.1.1E The evaluator shall confirm that the information provided meets all the requirements for content and presentation of evidence.

Assurance Activity: The evaluator will verify that the TSS contains a description of the timely security update process used by the developer to create and deploy security updates. The evaluator will verify that this description addresses the entire application. The evaluator will also verify that, in addition to the OS developer’s process, any third-party processes are also addressed in the description. The evaluator will also verify that each mechanism for deployment of security updates is described.

The evaluator will verify that, for each deployment mechanism described for the update process, the TSS lists a time between public disclosure of a vulnerability and public availability of the security update to the OS patching this vulnerability, to include any third-party or carrier delays in deployment. The evaluator will verify that this time is expressed in a number or range of days.

The evaluator will verify that this description includes the publicly available mechanisms (including either an email address or website) for reporting security issues related to the OS. The evaluator shall verify that the description of this mechanism includes a method for protecting the report either using a public key for encrypting email or a trusted channel for a website.

5.2.2General Purpose OS PP Assurance Activities

This section copies the assurance activities from the protection profile in order to ease reading and comparisons between the protection profile and the security target.

5.2.2.1Security Audit (FAU)