Protection Profile Summary

Transcription

1 NIAP Protection Profile for Mobile Device Management (PP_MDM_v2.0) PP link: Summary author: Date: 26 March 2015 Overview The NIAP Protection Profile for Mobile Device Management (PP_MDM_v2.0) specifies baseline security requirements for MDM systems products that allow enterprises to apply security policies to mobile devices, such as smartphones and tablets. In the figure below, the Target of Evaluation (TOE) is shown in blue the MDM Server component. MDM Agent requirements are addressed separately in the Extended Package for MDM Agents (available at PP_MDM_v2.0 also includes optional requirements for the Mobile Application Store (MAS) Server, which hosts applications for the enterprise. The MAS server is optional and may be separate or included in the MDM Server. MDM Server requirements cover the following objectives: Protected Communications. Encrypt communication between the server components and agents (DTLS, HTTPS or TLS) and between remote administrators and server components (IPsec, HTTPS, TLS or SSH). System Reporting. Support administrator alerts, granular auditing of administrator actions and specific events identified in the PP and report status of enrolled agents. Mobile Device Configuration. Define and push policies to enrolled agents the PP defines baseline commands a policies that must be supported (see shortcut below). Administration of Management Capability. Implement authentication and access control for administrators. MDM Integrity. Implement code signing for integrity verification at startup and during installation of updates. Shortcut! For a detailed list of MDM policies that must be supported refer to section (FMT_SMF.1) on page 20 of the PP document. Page 1 of 9

2 Noteworthy Platform / Evaluated Product Dependencies There are a few places in the MDM PP that assume the TOE is installed on an evaluated OS and interacts with evaluated Agents and/or Mobile Devices. Further, it is assumed that the Security Targets (ST) of these products are consistent with the MDM s ST. Specific instances: MDM Agent. Section 1.1 of the PP states: The MDM Agent is addressed in the Extended Package for MDM Agents. If the MDM Agent is installed on a mobile device as an application developed by the MDM developer, the EP extends this PP and is included in the TOE. In this case, the TOE security functionality specified in this PP must be addressed by the MDM Agent in addition to the MDM Server. Otherwise, the MDM Agent is provided by the mobile device vendor and is out of scope of this PP; however, MDMs are required to indicate the mobile platforms supported by the MDM Server and must be tested against the native MDM agent of those platforms. Mobile Device. FMT_SMT.1(1) application notes and assurance activities require that the ST only reference (that is the evaluated MDM can only claim to manage) Mobile Devices that conform with the Mobile Device Fundamentals PP v2.0. Operating System (Platform). The PP allows certain functions to be performed by the TOE or the Platform. Where this is the case, the related assurance activities instructs the evaluator to check consistency with the platform Security Target. Section 4.4 of the MDM PP states those requirements for which the platform has been selected shall comply with the scheme s policy for platform-dependent products. This get s a bit complicated o The Platform-Dependent Guidance basically states that if there is no evaluated platform, the evaluator can use other platform vendor documentation to verify that the claimed functionality is present. See guidance here: o Given the above policy is still published by NIAP, it is assumed to be in effect, however, this NIAP policy was introduced by LabGram 72, which sates [platform dependent] guidance is in effect until we publish a new OS PP, which is planned for early It is not clear if the current NIAP GPOS PP is the new OS PP or not. Reference: Ark Infosec recommends early engagement with the Scheme on these points to ensure the supported devices and platforms are eligible for inclusion in the MDM Security Target. New mandatory minimums for cryptography NIAP are introducing new mandatory minimums for the following: AES Key Size. Support for 256-bit key sizes will be required for products entering evaluation after Quarter 3, See FCS_COP.1.1(1) application notes. SHA Algorithms. Products entering into evaluation after Quarter 3, 2015 will be required to include SHA-2 algorithms. See FCS_COP.1.1(2) application notes. Digital Signatures (ECDSA). ECDSA schemes will be required for products entering evaluation after Quarter 3, See FCS_COP.1.1(3) application notes. RBG (ANSI X9.31). Use of the ANSI X9.31DRBG to be disallowed after 2015 per NIST SP A. See FCS_RBG_EXT.1 application notes. Page 2 of 9

3 New life-cycle requirement This is a bit of an Easter egg hidden in the assurance activity for ALC_CMS.1 (page 63). This might have been included unintentionally from the Mobile Device Fundamentals PP for which it seems more appropriate: The evaluator shall ensure that the developer has identified (in public-facing development documentation for their platform) one or more development environments appropriate for use in developing applications for the developer s platform. For each of these development environments, the developer shall provide information on how to configure the environment to ensure that buffer overflow protection mechanisms in the environment(s) are invoked (e.g., compiler flags). The evaluator shall ensure that this documentation also includes an indication of whether such protections are on by default, or have to be specifically enabled. Functional Requirements Summary TOE Requirements Defined in Section 4.3 of the PP, these requirements comprise the functions that must be present in a compliant product. FAU_ALT_EXT.1 Server Alerts Defines the events that must trigger administrator alerts changes in enrollment status and failure to apply policies to a device. FAU_GEN.1 FAU_NET_EXT.1 FIA_ENR_EXT.1 FMT_MOF.1(1) FMT_MOF.1(2) FMT_SMF.1(1) Audit Data Network Reachability Review Enrollment of Mobile Device into Management Management of Functions in MDM Server Management of Enrollment Function Specification of Management Functions (Server configuration of Agent) Standard audit requirement provides a list of specific events to be logged. Note: This is often an area that requires development to address. Report the network connectivity status of an enrolled agent (e.g. agents send periodic polls per MDM Agent EP). User authentication during device enrollment and limitations on device enrollment: specific devices, specific device models, a number of devices or specific time period. Lists the functions that must be restricted to administrators only. Enrollment of devices must be restricted to authorized administrators and mobile device users. Core requirement - specifies the required capability for MDM Agent configuration. This requirement is broken into two configurable areas: MDM Agent commands and MDM Agent policies. Includes mandatory and optional requirements that can be tailored. Note: Functionality must also be specified in supported Mobile Device Security Target(s). Page 3 of 9

4 FMT_SMF.1.1(2) FMT_SMR.1(1) Specification of Management Functions (Server Configuration of Security Management Roles List of management functions to be supported by the MDM Server. Specification of supported roles and association of users with roles. FPT_TUD_EXT.1 Trusted Updates Must be able to query the current version of the MDM Server software. Requirements that can be met by the TOE or Platform Defined in Section 4.4 of the PP, these requirements met by the MDM Server or the MDM Server s platform (OS). FAU_GEN.1.2(1) FAU_STG_EXT.1 FCS_CKM.1 FCS_CKM.2 FCS_CKM_EXT.4 Audit Data External Audit Trail Storage Establishment Destruction Information to be included in all audit records. Must support external audit storage and transmit using secure protocol: IPSec, SSH or TLS. Specify asymmetric key generation schemes in use (RSA, ECC or FCC). Note: If met by platform then equivalent schemes need to be included in the platform ST(s). If met by TOE, CAVP certificate required and detailed specification included in the ST. Specify key establishment methods in use (RSA, ECC or FCC). Note: If met by platform then equivalent methods need to be included in the platform ST(s). If met by TOE, CAVP certificate required and detailed specification included in the ST. Key destruction (overwrite) requirements for volatile memory, non-volatile EEPROM, non-volatile flash memory and any other memory. Note: The related assurance activity assumes the TOE is running on an evaluated OS and also requires all plaintext CSPs (secrets) to be described in the ST. The evaluator also has to cross-reference the platform ST to confirm the CSPs would be covered by that key destruction claims in that ST. This could be difficult to meet. Page 4 of 9

5 FCS_COP.1(*) FCS_RBG_EXT.1 FCS_STG_EXT.1 FIA_UAU.1 Cryptographic Operation Random Bit Storage Timing of Authentication Specify: Encryption algorithms in use (AES-CBC, AES- GCM, AES KW, AES KWP, AES-CCM) and key sizes must support 128-bit. 256-bit keys optional. Note: 256bit keys mandatory for products entering evaluation after Q Hashing algorithms in use (SHA-1, SHA-256, SHA-384, SHA-512). Note: SHA-2 mandatory for products entering evaluation after Q Digital signatures RSA or ECDSA. Note: ECDSA schemes will be required for products entering evaluation after Quarter 3, HMAC. SHA-1, SHA-256, SHA-384, SHA-512. Note: If met by platform then equivalent methods need to be included in the platform ST(s). If met by TOE, CAVP certificate required. Specify deterministic random bit generation (DRBG) standard in use - NIST SP A (additional details in PP) or FIPS Pub Annex C: X9.31 Appendix 2.4 using AES. Specify entropy source and strength. Note: Use of ANSI X9.31 to be disallowed after 2015 per NIST SP A. Note: If met by platform then equivalent methods need to be included in the platform ST(s). In all cases Entropy Documentation is required per PP Appendix E. Specify how persistent secrets and private keys are stored TOE or Platform. Note: In all cases the ST must identify all such persistent secrets and keys. If met by platform then evaluator must confirm that the platform ST describes protection of the keys (or could likely extrapolate such protection). If met by the TOE, the ST must describe secure key storage process. Specify where authentication is performed TOE or Platform. FIA_X509_EXT.1 X509 Validation Specify if TOE or Platform performs certificate validation. List of detailed certificate validation requirements. FIA_X509_EXT.2 X509 Authentication Specify if TOE or Platform performs certificate authentication services. Requires support for X.509v3 certificates. List of detailed requirements. FPT_TST_EXT.1 TSF Testing Specify if TOE or Platform runs self tests. Must verify the integrity of stored executable code. FPT_TUD_EXT.1 Trusted Update Specify if TOE or Platform facilitates software updates and verification of updates for the MDM server. FTP_ITC.1(1) Inter-TSF Trusted Channel (Authorized IT Entities) Specify if TOE or Platform provides secure communications with audit server / other servers. Allowed protocols: IPsec, SSH, TLS, TLS/HTTPS Page 5 of 9

6 FTP_TRP.1(2) Trusted Path for Enrollment Specify if TOE or Platform provides secure communications with mobile device users. TLS or TLS/HTTPS. Optional Requirements Defined in Appendix B of the PP, these requirements are optional and are not required for conformance. FAU_SEL.1 FPT_ITT.1(1) FTA_TAB.1 FTP_ITC.1(2) Security Audit Event Selection Basic Internal TSF Data Transfer Protection (MDM Default TOE Access Banners Inter-TSF Trusted Channel (MDM Agent) Configurable logging of audit events based on defined attributes. Protection of communication between the MDM Agent and MDM Server. Allowed protocols TLS, HTTPS, DTLS. Warning message at login. Protection of communication (and mutual authentication of endpoints) between MDM Agent and TOE (including MAS. Allowed protocols TLS, HTTPS, DTLS. FAU_SAR.1 Audit Review Capability to read audit data. Can be provided by TOE or Platform. FAU_STG_EXT.2 Audit Event Storage Protection of stored audit data. Can be provided by TOE or Platform. FCS_TLSC_EXT. 1 FAU_GEN.1.1(2) FAU_STG_EXT.1 (2) FMT_MOF.1(3) FMT_MOF.1(4) FMT_SMF.1(3) FMT_SMR.1(2) Cryptographic Support Audit (MAS External Audit Trail Storage (MAS Management of Functions in MAS Server Management of Download Function in MAS Server Specification of Management Functions (MAS Security Management Roles Detailed TSL requirements. Can be provided by TOE or Platform. TLS v1.0, 1.1 and 1.2 allowed. List of allowed ciphers provided. MAS Server audit requirements. MAS Server audit storage requirements secure transmission of audit data using IPsec, SSH, TLS or TLS/HTTPS. Restrict MAS Server management functions to admin. MAS Server ability to restrict download of apps according to configured policy. MAS Server capability to include: configure application access groups, download applications, other capabilities specified by ST author. MAS Server supports multiple roles and associate users with roles. Roles to include: administrator, MD user, enrolled mobile devices, application access groups. Page 6 of 9

7 FPT_ITT.1(2) FPT_ITT.1(3) FTP_ITC.1(3) Basic Internal TSF Data Transfer Protection (Distributed TOE) Basic Internal TSF Data Transfer Protection (MAS Inter-TSF Trusted Channel (Authorized IT Entities) Protection of data between separate parts of the TOE (if distributed). Allowed protocols: IPsec, TLS, HTTPS, DTLS. Protection of data between MDM Agent and MAS Server. Allowed protocols: TLS, HTTPS, DTLS. Protection of communication between MAS Server and audit server / other servers. Allowed protocols: IPsec, SSH, TLS, TLS/HTTPS. Can be provided by TOE or Platform. Selection-Based Requirements Defined in Appendix C of the PP, these requirements are to be included based on the options chosen in the baseline requirements. FCS_IV_EXT.1 FCS_STG_EXT.2 FCS_DTLS_EXT. 1 FCS_HTTPS_EX T.1 FCS_IPSEC_EXT.1 FCS_SSHS_EXT. 1 FCS_TLSC_EXT. 1.5 Initialization Vector Encrypted Storage DTLS Protocol HTTPS Protocol IPsec Protocol SSH Protocol TLS Client Protocol MDM Server shall generate IVs. Defines requirements for IVs. Include if FCS_STG_EXT.2 is in ST. MDM Server encrypt keys with AES. Provide options for modes to use. Include if selected in FCS_STG_EXT.1 TOE or Platform provides DTLS. Specifies DTLS requirements. Include if DTLS selected in baseline requirements. TOE or Platform provides HTTPS. Specifies HTTPS requirements. Include if HTTPS selected in baseline requirements. TOE or Platform provides IPsec. Specifies extensive IPsec requirements. Include if IPsec selected in baseline requirements. TOE or Platform provides SSH. Specifies extensive SSH requirements. Include if SSH selected in baseline requirements. TOE or Platform provides TLS as client. Specified TLS requirements. TLS v1.0, 1.1 and 1.2 allowed. List of allowed ciphers provided. Include if TLS selected in baseline requirements and TOE is the client side. Note: Include if TLS ciphers use ECDHE. Page 7 of 9

8 FCS_TLSS_EXT. 1 TLS Server Protocol TOE or Platform provides TLS as server. Specified TLS requirements. TLS v1.0, 1.1 and 1.2 allowed. List of allowed ciphers provided. Include if TLS selected in baseline requirements and TOE is the server side. Objective Requirements Defined in Appendix D of the PP, these requirements are to be included in the baseline of future versions of the PP and may be claimed now if desired. FAU_CRP_EXT.1 FMT_POL_EXT.1 FCS_TLSC_EXT FCS_TLSS_EXT Support for Compliance Reporting of Mobile Device Configuration Trusted Policy Update TLS Client Protocol TLS Server Protocol MDM Server supports secure (TLS/HTTPS, TLS, DTLS, IPsec, SSH) reporting of mobile device configuration. Includes a list of information to be included if present. MDM Server digitally signs policy updates pushed to Agents. Limits the hashing algorithms supported (SHA-2) for the purpose of digital signature verification by the client and limits the server to the supported hashes for the purpose of digital signature generation by the server. The signature_algorithm extension is only supported by TLS 1.2. Support for RFC an extension to TLS that binds renegotiation handshakes to the cryptography in the original handshake. This requirement limits the hashing algorithms supported for the purpose of digital signature verification by the server and limits the client to the supported hashes for the purpose of digital signature generation by the client. The supported_signature_algorithms is only supported by TLS 1.2. Support for RFC an extension to TLS that binds renegotiation handshakes to the cryptography in the original handshake. FIA_X509_EXT.3 X509 Enrollment Device enrollment using X509. Specific requirements included. FIA_X509_EXT.3 Alternate X509 Enrollment Support for Enrollment over Secure Transport (EST). Page 8 of 9

9 Evidence and Testing Requirements Security Target ASE Functional Specification ADV_FSP.1 Guidance Documentation AGD_OPE.1, AGD_PRE.1 Configuration Management ALC_CMC.1, ALC_CMS.1 Independent Testing ATE_IND.1 Vulnerability Analysis AVA_VAN.1 Entropy Documentation and Assessment Evaluation scoping document. Based on the Protection Profile template requirements are tailored to the application and detail added in a summary specification. Description of interfaces satisfied by the Security Target and administration guidance. User and administration guidance. The PP contains specific content requirements that generally require production of an addendum covering these items. Product needs to be able to display the running version. Provide a document listing all evaluation evidence. Note: Related assurance activity requires: that the developer has identified (in public-facing development documentation for their platform) one or more development environments appropriate for use in developing applications for the developer s platform. For each of these development environments, the developer shall provide information on how to configure the environment to ensure that buffer overflow protection mechanisms in the environment(s) are invoked (e.g., compiler flags). The evaluator shall ensure that this documentation also includes an indication of whether such protections are on by default, or have to be specifically enabled. Developer provides the application and required equipment for testing. Most labs will require the developer to provide a detailed supporting test plan to ensure efficient testing by the evaluators. Public domain search for vulnerabilities (e.g. CVE) and virus scan. Penetration testing of any identified vulnerabilities. Refer to PP Appendix E for detailed requirements. The documentation of the entropy source(s) should be detailed enough that, after reading, the evaluator will thoroughly understand the entropy source and why it can be relied upon to provide sufficient entropy. This documentation should include multiple detailed sections: design description, entropy justification, operating conditions, and health testing. Page 9 of 9