Version | Date | Comment |
---|---|---|
v .1 | 2014-01-08 | Initial draft commit |
v .6 | 2014-03-14 | Attractive presentation achieved |
v .7 | 2014-08-08 | First round of Technical Community feedback incorporated |
v .8 | 2014-08-21 | Second round of Technical Community feedback incorporated |
v .9 | 2014-09-12 | Third round of Technical Community feedback incorporated |
v .9 | 2014-10-20 | Fourth round of Technical Community feedback incorporated |
v 1.0 | 2014-10-20 | Initial release |
v 1.1 | 2014-11-05 | Addition to TLS cipher suite selections |
v 1.2 | 2016-04-22 | Added server-side TLS requirements (selection-based)
Multiple clarification based on NIAP TRRT inquiries Refactored FDP_DEC_EXT.1 into separate components |
v 1.3 | 2019-03-01 | Incorporated available TDs
Refactored FPT_TUD Added a selection to FTP_DIT Moved SWID Tags requirement Incorporated TLS Package Added equivalency section |
Common Criteria (CC) | Common Criteria for Information Technology Security Evaluation. |
Common Evaluation Methodology (CEM) | Common Evaluation Methodology for Information Technology Security Evaluation. |
Extended Package (EP) | An implementation-independent set of security requirements for a category of products, which extends those in a Protection Profile. |
Protection Profile (PP) | An implementation-independent set of security requirements for a category of products. |
Protection Profile Module (PP-Module) | An implementation-independent statement of security needs for a TOE type complementary to one or more Base Protection Profiles. |
Security Target (ST) | A set of implementation-dependent security requirements for a specific product. |
Target of Evaluation (TOE) | The product under evaluation. In this case, application software and its supporting documentation. |
TOE Security Functionality (TSF) | The security functionality of the product under evaluation. |
TOE Summary Specification (TSS) | A description of how a TOE satisfies the SFRs in a ST. |
Security Functional Requirement (SFR) | A requirement for security enforcement by the TOE. |
Security Assurance Requirement (SAR) | A requirement to assure the security of the TOE. |
Address Space Layout Randomization (ASLR) | An anti-exploitation feature which loads memory mappings into unpredictable locations. ASLR makes it more difficult for an attacker to redirect control to code that they have introduced into the address space of an application process. |
Application (app) | Software that runs on a platform and performs tasks on behalf of the user or owner of the platform, as well as its supporting documentation. The terms TOE and application are interchangeable in this document. |
Application Programming Interface (API) | A specification of routines, data structures, object classes, and variables that allows an application to make use of services provided by another software component, such as a library. APIs are often provided for a set of libraries included with the platform. |
Credential | Data that establishes the identity of a user, e.g. a cryptographic key or password. |
Data Execution Prevention (DEP) | An anti-exploitation feature of modern operating systems executing on modern computer hardware, which enforces a non-execute permission on pages of memory. DEP prevents pages of memory from containing both data and instructions, which makes it more difficult for an attacker to introduce and execute code. |
Developer | An entity that writes application software. For the purposes of this document, vendors and developers are the same. |
Mobile Code | Software transmitted from a remote system for execution within a limited execution environment on the local system. Typically, there is no persistent installation and execution begins without the user's consent or even notification. Examples of mobile code technologies include JavaScript, Java applets, Adobe Flash, and Microsoft Silverlight. |
Operating System (OS) | Software that manages hardware resources and provides services for applications. |
Personally Identifiable Information (PII) | Any information about an individual maintained by an agency, including, but not limited to, education, financial transactions, medical history, and criminal or employment history and information which can be used to distinguish or trace an individual's identity, such as their name, social security number, date and place of birth, mother’s maiden name, biometric records, etc., including any other personal information which is linked or linkable to an individual. [OMB] |
Platform | The environment in which application software runs. The platform can be an operating system, hardware environment, a software based execution environment, or some combination of these. These types platforms may also run atop other platforms. |
Sensitive Data | Sensitive data may include all user or enterprise data or may be specific application data such as emails, messaging, documents, calendar items, and contacts. Sensitive data must minimally include PII, credentials, and keys. Sensitive data shall be identified in the application’s TSS by the ST author. |
Stack Cookie | An anti-exploitation feature that places a value on the stack at the start of a function call, and checks that the value is the same at the end of the function call. This is also referred to as Stack Guard, or Stack Canaries. |
Vendor | An entity that sells application software. For purposes of this document, vendors and developers are the same. Vendors are responsible for maintaining and updating application software. |
The requirements in this document apply to application software which runs on any type of platform. Some application types are covered by more specific PPs, which may be expressed as PP-Modules of this PP. Such applications are subject to the requirements of both this PP and the PP-Module that addresses their special functionality. PPs for some particularly specialized applications may not be expressed as PP-Modules at this time, though the requirements in this document should be seen as objectives for those highly specialized applications.
Although the requirements in this document apply to a wide range of application software, consult guidance from the relevant national schemes to determine when formal Common Criteria evaluation is expected for a particular type of application. This may vary depending upon the nature of the security functionality of the application.
The application, which consists of the software provided by its vendor, is installed onto the platform(s) it operates on. It executes on the platform, which may be an operating system (Figure 1), hardware environment, a software based execution environment, or some combination of these (Figure 2). Those platforms may themselves run within other environments, such as virtual machines or operating systems, that completely abstract away the underlying hardware from the application. The TOE is not accountable for security functionality that is implemented by platform layers that are abstracted away. Some evaluation activities are specific to the particular platform on which the application runs, in order to provide precision and repeatability. The only platforms currently recognized by the AppPP are those specified in SFR Evaluation Activities. To test on a platform for which there are no EAs, a Vendor should contact NIAP with recommended EAs. NIAP will determine if the proposed platform is appropriate for the PP and accept, reject, or develop EAs as necessary in coordination with the technical community.
Applications include a diverse range of software such as office suites, thin clients, PDF readers, downloadable smartphone apps, and apps running in a cloud container. The TOE includes any software in the application installation package, even those pieces that may extend or modify the functionality of the underlying platform, such as kernel drivers. Many platforms come bundled with applications such as web browsers, email clients and media players and these too should be considered subject to the requirements defined in this document although the expectation of formal Common Criteria evaluation depends upon the national scheme. BIOS and other firmware, the operating system kernel, and other systems software (and drivers) provided as part of the platform are outside the scope of this document.
If encrypt all transmitted is selected and TLS is selected, then evaluation of elements from either FCS_TLSC_EXT.1 or FCS_TLSS_EXT.1 is required.
If encrypt all transmitted is selected and HTTPS is selected, FCS_HTTPS_EXT.1 is required.
If encrypt all transmitted is selected and DTLS is selected, FCS_DTLS_EXT.1 is required.
If encrypt all transmitted is selected and SSH is selected, the TSF shall be validated against the Extended Package for Secure Shell.
If encrypt all transmitted is selected the corresponding FCS_COP.1 requirements will be included.
Factor | Same/Different | Guidance |
PP-Specified Functionality | Same | If the differences between Models affect only non-PP-specified functionality, then the Models are equivalent. |
Different | If PP-specified security functionality is affected by the differences between Models, then the Models are not equivalent and must be tested separately. It is necessary only to test the functionality affected by the software differences. If only differences are tested, then the differences must be enumerated, and for each difference the Vendor must provide an explanation of why each difference does or does not affect PP-specified functionality. If the Product Models are separately tested fully, then there is no need to document the differences. |
Factor | Same/Different | Guidance |
Product Models | Different | Versions of different Product Models are not equivalent unless the Models are equivalent as defined in Section 3. |
PP-Specified Functionality | Same | If the differences affect only non-PP-specified functionality, then the Versions are equivalent. |
Different | If PP-specified security functionality is affected by the differences, then the Versions are not considered equivalent and must be tested separately. It is necessary only to test the functionality affected by the changes. If only the differences are tested, then for each difference the Vendor must provide an explanation of why the difference does or does not affect PP-specified functionality. If the Product Versions are separately tested fully, then there is no need to document the differences. |
Factor | Same/Different/None | Guidance |
Platform Architectures | Different | Platforms that present different processor architectures and instruction sets to the application are not equivalent. |
PP-Specified Functionality | Same | For platforms with the same processor architecture, the platforms are equivalent with respect to the application if execution of all PP-specified security functionality follows the same code path on both platforms. |
Factor | Same/Different/None | Guidance |
Platform Architectures | Different | Platforms that run on different processor architectures and instruction sets are not equivalent. |
Platform Vendors | Different | Platforms from different vendors are not equivalent. |
Platform Versions | Different | Platforms from the same vendor with different major version numbers are not equivalent. |
Platform Interfaces | Different | Platforms from the same vendor and major version are not equivalent if there are differences in device interfaces and OS APIs that are relevant to the way the platform provides PP-specified security functionality to the application. |
Platform Interfaces | Same | Platforms from the same vendor and major version are equivalent if there are no differences in device interfaces and OS APIs that are relevant to the way the platform provides PP-specified security functionality to the application, or if the Platform does not provide such functionality to the application. |
Factor | Same/Different/None | Guidance |
Platform Type/Vendor | Different | Software-based execution environments that are substantially different or come from different vendors are not equivalent. For example, a java virtual machine is not the same as a container. A Docker container is not the same as a CoreOS container. |
Platform Versions | Different | Execution environments that are otherwise equivalent are not equivalent if they have different major version numbers. |
PP-Specified Security Functionality | Same | All other things being equal, execution environments are equivalent if there is no significant difference in the interfaces through which the environments provide PP-specified security functionality to applications. |
Identifier | Title |
---|---|
[CC] | Common Criteria for Information Technology Security Evaluation -
|
[CC] | Common Criteria for Information Technology Security Evaluation -
|
[CEM] | Common Evaluation Methodology for Information Technology Security - Evaluation Methodology, CCMB-2017-04-004, Version 3.1, Revision 5, April 2017. |
[OMB] | Reporting Incidents Involving Personally Identifiable Information and Incorporating the Cost for Security in Agency Information Technology Investments, OMB M-06-19, July 12, 2006. |
Acronym | Meaning |
---|---|
ADB | Android Debug Bridge |
AES | Advanced Encryption Standard |
ANSI | American National Standards Institute |
API | Application Programming Interface |
APK | Android Application Package |
APPX | Windows Universal Application Package |
ASLR | Address Space Layout Randomization |
BIOS | Basic Input/Output System |
CMC | Certificate Management over CMS |
CMS | Cryptographic Message Syntax |
CN | Common Names |
CRL | Certificate Revocation List |
CSA | Computer Security Act |
DEP | Data Execution Prevention |
DES | Data Encryption Standard |
DHE | Diffie-Hellman Ephemeral |
DMG | Apple Disk Image |
DNS | Domain Name System |
DPAPI | Data Protection Application Programming Interface |
DRBG | Deterministic Random Bit Generator |
DSS | Digital Signature Standard |
DT | Date/Time Vector |
DTLS | Datagram Transport Layer Security |
EAP | Extensible Authentication Protocol |
ECDHE | Elliptic Curve Diffie-Hellman Ephemeral |
ECDSA | Elliptic Curve Digital Signature Algorithm |
EMET | Enhanced Mitigation Experience Toolkit |
EST | Enrollment over Secure Transport |
FIPS | Federal Information Processing Standards |
DSS | Digital Signature Standard |
ELF | Executable and Linkable Format |
GPS | Global Positioning System |
HMAC | Hash-based Message Authentication Code |
HTTP | Hypertext Transfer Protocol |
HTTPS | Hypertext Transfer Protocol Secure |
IANA | Internet Assigned Number Authority |
IEC | International Electrotechnical Commission |
IETF | Internet Engineering Task Force |
IP | Internet Protocol |
IPA | iOS Package archive |
IR | Intermediate Integer |
ISO | International Organization for Standardization |
IT | Information Technology |
ITSEF | Information Technology Security Evaluation Facility |
JNI | Java Native Interface |
LDAP | Lightweight Directory Access Protocol |
MIME | Multi-purpose Internet Mail Extensions |
MPKG | Meta Package |
MSI | Microsoft Installer |
NFC | Near Field Communication |
NIAP | National Information Assurance Partnership |
NIST | National Institute of Standards and Technology |
OCSP | Online Certificate Status Protocol |
OID | Object Identifier |
OMB | Office of Management and Budget |
OS | Operating System |
Portable Document Format | |
PE | Portable Executable |
PID | Process Identifier |
PII | Personally Identifiable Information |
PKG | Package file |
PKI | Public Key Infrastructure |
PP | Protection Profile |
IT | Information Technology |
RBG | Random Bit Generator |
RFC | Request for Comment |
RNG | Random Number Generator |
RNGVS | Random Number Generator Validation System |
SAN | Subject Alternative Name |
SAR | Security Assurance Requirement |
SE | Security Enhancements |
SFR | Security Functional Requirement |
SHA | Secure Hash Algorithm |
S/MIME | Secure/Multi-purpose Internet Mail Extensions |
SIP | Session Initiation Protocol |
SP | Special Publication |
SSH | Secure Shell |
SWID | Software Identification |
TLS | Transport Layer Security |
UI | User Interface |
URI | Uniform Resource Identifier |
URL | Uniform Resource Locator |
USB | Universal Serial Bus |
XCCDF | eXtensible Configuration Checklist Description Format |
XOR | Exclusive Or |