Collaborative Protection Profile for QQQQ
Version: 1.0 2015-08-14 National Information Assurance Partnership
Foreword
This is a Supporting Document (SD), intended to complement the Common Criteria version 3
and the associated Common Evaluation Methodology for
Information Technology Security Evaluation.
SDs may be “Guidance Documents”, that highlight specific approaches
and application of the standard to areas where no mutual recognition of
its application is required, and as such, are not of normative nature,
or “Mandatory Technical Documents”, whose application is mandatory for evaluations
whose scope is covered by that of the SD.
The usage of the latter class is not only mandatory, but certificates
issued as a result of their application are recognized under the CCRA.
Technical Editor:
National Information Assurance Partnership (NIAP)
Document history:
Version
Date
Comment
Round 1
2015-04-23
First draft of version 1.0 for comment
1.0
2015-08-14
Release - first version released
General Purpose:
The purpose of this SD is to define evaluation methods for the functional behavior of
products.
Acknowledgments:
This SD was developed with support from NIAP
Technical Community members, with representatives from industry, government
agencies, Common Criteria Test Laboratories, and members of academia.
1.1 Technology Area and Scope of Supporting Document
The scope of the Collaborative Protection Profile for QQQQ is
to describe the security functionality of
products in terms of
[CC] and to define functional and assurance requirements for them.
Although Evaluation Activities are defined mainly for the evaluators to follow, in general they also help developers to prepare for evaluation by identifying specific requirements for their TOE.
The specific requirements in Evaluation Activities may in some cases clarify the meaning of Security
Functional Requirements (SFR), and may identify particular requirements for the content of Security
Targets (ST) (especially the TOE Summary Specification), user guidance documentation, and possibly
supplementary information (e.g. for entropy analysis or cryptographic key management architecture).
1.2 Structure of the Document
Evaluation Activities can be defined for both SFRs and Security Assurance Requirements (SAR),
which are themselves defined in separate sections of the SD.
If any Evaluation Activity cannot be successfully completed in an evaluation, then
the overall verdict for the evaluation is a 'fail'.
In rare cases there may be acceptable reasons why an Evaluation Activity
may be modified or deemed not applicable for a particular TOE,
but this must be approved by the Certification Body for the evaluation.
In general, if all Evaluation Activities (for both SFRs and SARs) are successfully
completed in an evaluation then it would be expected that the overall verdict for
the evaluation is a ‘pass’.
To reach a ‘fail’ verdict when the Evaluation Activities have been successfully
completed would require a specific justification from the evaluator as to why the
Evaluation Activities were not sufficient for that TOE.
Similarly, at the more granular level of assurance components, if the Evaluation
Activities for an assurance component and all of its related SFR Evaluation
Activities are successfully completed in an evaluation then it would be expected
that the verdict for the assurance component is a ‘pass’.
To reach a ‘fail’ verdict for the assurance component when these Evaluation
Activities have been successfully completed would require a specific justification
from the evaluator as to why the Evaluation Activities were not sufficient for that TOE.
1.3 Terms
The following sections list Common Criteria and technology terms used in this document.
1.3.1 Common Criteria Terms
Assurance
Grounds for confidence that a TOE meets the SFRs [CC].
Base Protection Profile (Base-PP)
Protection Profile used as a basis to build a PP-Configuration.
Collaborative Protection Profile (cPP)
A Protection Profile developed by
international technical communities and approved by multiple schemes.
Common Criteria (CC)
Common Criteria for Information Technology Security Evaluation (International Standard ISO/IEC 15408).
Common Criteria Testing Laboratory
Within the context of the Common Criteria Evaluation and Validation Scheme (CCEVS), an IT security evaluation facility
accredited by the National Voluntary Laboratory Accreditation Program (NVLAP) and approved by the NIAP Validation Body to conduct Common Criteria-based evaluations.
Common Evaluation Methodology (CEM)
Common Evaluation Methodology for Information Technology Security Evaluation.
Distributed TOE
A TOE composed of multiple components operating as a logical whole.
Extended Package (EP)
A deprecated document form for collecting SFRs that implement a particular protocol, technology,
or functionality. See Functional Packages.
Functional Package (FP)
A document that collects SFRs for a particular protocol, technology,
or functionality.
Operational Environment (OE)
Hardware and software that are outside the TOE boundary that support the TOE functionality and security policy.
Protection Profile (PP)
An implementation-independent set of security requirements for a category of products.
A comprehensive set of security requirements for a product type that consists of at least one Base-PP and at least one PP-Module.
Protection Profile Module (PP-Module)
An implementation-independent statement of security needs for a TOE type complementary to one or more Base-PPs.
Security Assurance Requirement (SAR)
A requirement to assure the security of the TOE.
Security Functional Requirement (SFR)
A requirement for security enforcement by the TOE.
Security Target (ST)
A set of implementation-dependent security requirements for a specific product.
Target of Evaluation (TOE)
The product under evaluation.
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 an ST.
1.3.2 Technical Terms
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 a process.
Administrator
An administrator is responsible for management activities, including setting policies that are
applied by the enterprise on the operating system.
This administrator could be acting remotely through a management server, from which the system
receives configuration policies.
An administrator can enforce settings on the system which cannot be overridden by non-administrator users.
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.
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.
Critical Security Parameters (CSP)
Information that is either user or system defined and
is used to operate a cryptographic module in processing encryption functions including
cryptographic keys and authentication data, such as passwords, the disclosure or modification
of which can compromise the security of a cryptographic module or the security of the
information protected by the module.
DAR Protection
Countermeasures that prevent attackers, even those with physical access,
from extracting data from non-volatile storage.
Common techniques include data encryption and wiping.
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 OS software. For the purposes of this document,
vendors and developers are the same.
General Purpose Operating System
A class of OSes designed to support a wide-variety of workloads consisting of many concurrent applications or services.
Typical characteristics for OSes in this class include support for third-party applications,
support for multiple users, and security separation between users and their respective resources.
General Purpose Operating Systems also lack the real-time constraint that defines Real Time Operating Systems (RTOS).
RTOSes typically power routers, switches, and embedded devices.
Host-based Firewall
A software-based firewall implementation running on the OS for filtering inbound and
outbound network traffic to and from processes running on the OS.
Operating System (OS)
Software that manages physical and logical resources and provides services
for applications. The terms TOE and OS are interchangeable in this
document.
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]
Sensitive Data
Sensitive data may include all user or enterprise data or may be specific
application data such as PII, emails, messaging, documents, calendar items, and contacts.
Sensitive data must minimally include credentials and keys. Sensitive data shall
be identified in the OS's TSS by the ST author.
User
A user is subject to configuration policies applied
to the operating system by administrators. On some systems under certain
configurations, a normal user can temporarily elevate privileges to that of an administrator.
At that time, such a user should be considered an administrator.
Virtual Machine (VM)
Blah Blah Blah
2 Evaluation Activities for SFRs
The EAs presented in this section capture the actions the evaluator performs
to address technology specific aspects covering specific SARs (e.g. ASE_TSS.1,
ADV_FSP.1, AGD_OPE.1, and ATE_IND.1) – this is in addition to the CEM workunits
that are performed in Section 3 Evaluation Activities for SARs.
Regarding design descriptions (designated by the subsections labeled TSS, as
well as any required supplementary material that may be treated as proprietary),
the evaluator must ensure there is specific information that satisfies the EA.
For findings regarding the TSS section, the evaluator’s verdicts will be
associated with the CEM workunit ASE_TSS.1-1.
Evaluator verdicts associated with the supplementary evidence will also be
associated with ASE_TSS.1-1,
since the requirement to provide such evidence is specified in ASE in the PP.
For ensuring the guidance documentation provides sufficient information for
the administrators/users as it pertains to SFRs, the evaluator’s verdicts will
be associated with CEM workunits ADV_FSP.1-7, AGD_OPE.1-4, and AGD_OPE.1-5.
Finally, the subsection labeled Tests is where the authors have determined
that testing of the product in the context of the associated SFR is necessary.
While the evaluator is expected to develop tests, there may be instances where
it is more practical for the developer to construct tests, or where the
developer may have existing tests.
Therefore, it is acceptable for the evaluator to witness developer-generated
tests in lieu of executing the tests.
In this case, the evaluator must ensure the developer’s tests are executing both
in the manner declared by the developer and as mandated by the EA.
The CEM workunits that are associated with the EAs specified in this section
are: ATE_IND.1-3, ATE_IND.1-4, ATE_IND.1-5, ATE_IND.1-6, and ATE_IND.1-7.
2.1 TOE SFR Evaluation Activities
2.1.1 QQQQ
FOO_FOO.1 Foo Foo
FOO_FOO.1
The following content should be included if:
pizza
is selected from
FOO_FOO.1.1
Check for anchovies
Specific to the componenet
TSS
ABC
FOO_FOO.1.1
Specific to the element
TSS
ABC
FOO_BAR.1 Foo Bar
FOO_BAR.1
SomethingSomething
TSS
ABC
Guidance
Some guidance
2.1.2 QQQQ
FQQ_QQQ.1 QQQQQ
FQQ_QQQ.1
TSS
Activities assoiated with the TSS.
Guidance
Activities assoiated with guidance
Tests
Test 1:
Make shadow puppets.
Test 1.1This is the motivation behind the tests.
Evidence:A warm fuzzy feeling
Activities assoiated with the Tests.
The following content should be included if:
For
virtual TOEs
Great tests for something virtual.
The following content should be included if:
For
physical/imaginary TOEs
Great tests for something tangible or in my mind.
2.1.3 Security Management (FMT)
FMT_SMF.1/HOST Specification of Management Functions (EDR Management of Host Agent)
FMT_SMF.1/HOST
TSS
The evaluator shall verify the ST contains a list of roles and what functions they can perform.
The evaluator shall verify the list matches the chart in the requirement.
Guidance
The evaluator shall review the operational guidance to verify that the EDR has
documented capabilities to perform the management functions.
Tests
The evaluator shall perform the below tests:
Test 2:
The evaluator shall modify the time frame for sending Host Agent data to the EDR
and verify that an affected Host Agent is sending data at the intended interval.
Test 3:
The evaluator shall tag or categorize a group of individual endpoint systems and
verify that the tag or categorization persists within the EDR management dashboard for
other users.
Test 4:
The evaluator shall attempt each function with each role and verify access conforms with the chart in the requirement.
Test 5This is the motivation behind the tests.
Evidence:A check should appear.
2.1.4 Security Audit (FAU)
FAU_GEN.1 Audit Data Generation
FAU_GEN.1
TSS
The evaluator shall check the TSS and ensure that it lists all of the auditable events
and provides a format for audit records. Each audit record format type shall be covered, along with a
brief description of each field. The evaluator shall check to make sure that every audit event type
mandated by the PP is described in the TSS.
Guidance
The evaluator shall also make a determination of the administrative actions that are relevant in the
context of this PP. The evaluator shall examine the administrative guide and make a determination of which
administrative commands, including subcommands, scripts, and configuration files, are related to the
configuration (including enabling or disabling) of the mechanisms implemented in the TOE
that are necessary to enforce the requirements specified in the PP. The evaluator shall document the
methodology or approach taken while determining which actions in the administrative guide are
security-relevant with respect to this PP.
Tests
The evaluator shall test the TOE’s ability to correctly generate audit records by
having the TOE generate audit records for the events listed and administrative actions.
For administrative actions, the evaluator shall test that each action determined by the evaluator above to
be security relevant in the context of this PP is auditable. When verifying the test results, the
evaluator shall ensure the audit records generated during testing match the format specified in the
administrative guide, and that the fields in each audit record have the proper entries.
Note that the testing here can be accomplished in conjunction with the testing of the security mechanisms
directly.
See Table t-audit-mandatory for more information.
FAU_SAR.1 Audit Review
FAU_SAR.1
Guidance
The evaluator shall review the operational guidance for the procedure on how to review the audit
records.
Tests
The evaluator shall verify that the audit records provide all of the information specified in
FAU_GEN.1 and that this information is suitable for human interpretation. The assurance
activity for this requirement is performed in conjunction with the assurance activity for
FAU_GEN.1.
FAU_STG.1 Protected Audit Trail Storage
FAU_STG.1
The evaluator shall ensure that the TSS describes how the audit records are protected from unauthorized modification or deletion. The evaluator shall ensure that the TSS describes the conditions that must be met for authorized deletion of audit records. The evaluator shall perform the following tests:
Tests
Test 6:
The evaluator shall access the audit trail as an unauthorized Administrator and attempt
to modify and delete the audit records. The evaluator shall verify that these attempts
fail.
Test 7:
The evaluator shall access the audit trail as an authorized Administrator and attempt
to delete the audit records. The evaluator shall verify that these attempts succeed.
The evaluator shall verify that only the records authorized for deletion are deleted.
FAU_STG_EXT.1 Off-Loading of Audit Data
FAU_STG_EXT.1
Protocols used for implementing the trusted channel must be selected in FTP_ITC_EXT.1.
TSS
The evaluator shall examine the TSS to ensure it describes the means by which
the audit data are transferred to the external audit server, and how the trusted channel is
provided.
The evaluator shall examine the TSS to ensure it describes what happens when the
local audit data store is full.
Guidance
The evaluator shall examine the operational guidance to ensure it describes how to establish the trusted channel to the audit server, as well as describe any requirements
on the audit server (particular audit server protocol, version of the protocol required, etc.), as well
as configuration of the TOE needed to communicate with the audit server.
The evaluator shall also examine the operational guidance to
determine that it describes the relationship between the local audit data and the audit data that
are sent to the audit log server. For example, when an audit event is generated, is it simultaneously
sent to the external server and the local store, or is the local store used as a buffer and “cleared”
periodically by sending the data to the audit server.
Tests
Testing of the trusted channel mechanism is to be performed as specified in the assurance
activities for FTP_ITC_EXT.1.
The evaluator shall perform the following test for this requirement:
Test 8:
The evaluator shall establish a session between the TOE and the audit server according to the configuration guidance provided. The evaluator shall then examine the traffic that passes between the audit server and the TOE during several activities of the evaluator’s choice designed to generate audit data to be transferred to the audit server. The evaluator shall observe that these data are not able to be viewed in the clear during this transfer, and that they are successfully received by the audit server. The evaluator shall record the particular software (name, version) used on the audit server during testing.
The evaluator shall perform operations that generate audit data and verify that this data is
stored locally. The evaluator shall perform operations that generate audit data until the local
storage space is exceeded and verifies that the TOE complies with the behavior
defined in the ST for FAU_STG_EXT.1.2.
2.2 Evaluation Activities for Optional SFRs
2.2.1 QQQQ
FQQ_QQQ.2 TQQQQQ
FQQ_QQQ.2
TSS
Activities assoiated with the TSS.
2.2.2 Security Audit (FAU)
FAU_ARP.1 Security Audit Automatic Response
FAU_ARP.1
Tests
The evaluator shall generate a potential security violation as defined in FAU_SAA.1 and verify
that each action in the assignment in FAU_ARP.1.1 is performed by the TSF as a
result. The evaluator shall perform this action for each security violation that is defined in
FAU_SAA.1.
FAU_SAA.1 Security Audit Analysis
FAU_SAA.1
Tests
The evaluator shall cause each combination of auditable events defined in FAU_SAA.1.2 to occur,
and verify that a potential security violation is indicated by the TSF.
2.3 Evaluation Activities for Selection-Based SFRs
There are no specific assurance activities associated with these SARs, except
ensuring the information is provided. The functional specification documentation is
provided to support the evaluation activities described in Section 5.1 Security Functional Requirements, and
other activities described for AGD, ATE, and AVA SARs. The requirements on the content
of the functional specification information is implicitly assessed by virtue of the
other assurance activities being performed; if the evaluator is unable to perform an
activity because there is insufficient interface information, then an adequate
functional specification has not been provided.
3.2 Class AGD: Guidance Documentation
AGD_OPE.1 Operational User Guidance (AGD_OPE.1)
AGD_OPE.1
Some of the contents of the operational guidance are verified by the
assurance activities in Section 5.1 Security Functional Requirements and evaluation of the OS according to the [CEM]. The following additional
information is also required. If cryptographic functions are provided by the OS, the operational guidance shall contain instructions for configuring
the cryptographic engine associated with the evaluated configuration of the OS. It shall provide a warning to the administrator that use of other
cryptographic engines was not evaluated nor tested during the CC evaluation of the
OS. The documentation must describe the process for verifying
updates to the OS by verifying a digital signature – this may be
done by the OS or the underlying platform. The evaluator will
verify that this process includes the following steps: Instructions for obtaining the
update itself. This should include instructions for making the update accessible to
the OS (e.g., placement in a specific directory). Instructions for
initiating the update process, as well as discerning whether the process was
successful or unsuccessful. This includes generation of the hash/digital signature.
The OS will likely contain security functionality that does not
fall in the scope of evaluation under this PP. The operational guidance shall make it
clear to an administrator which security functionality is covered by the evaluation
activities.
AGD_PRE.1 Preparative Procedures (AGD_PRE.1)
AGD_PRE.1
As indicated in the introduction above, there are significant expectations
with respect to the documentation—especially when configuring the operational
environment to support OS functional requirements. The evaluator
shall check to ensure that the guidance provided for the OS
adequately addresses all platforms claimed for the OS in the ST.
3.3 Class ALC: Life-cycle Support
ALC_CMC.1 Labeling of the TOE (ALC_CMC.1)
ALC_CMC.1
The evaluator will check the ST to ensure that it contains
an identifier (such as a product name/version number) that specifically identifies the
version that meets the requirements of the ST. Further, the
evaluator will check the AGD guidance and OS samples received for
testing to ensure that the version number is consistent with that in the ST. If the vendor maintains a web site advertising the OS, the evaluator will examine the information on the web site to
ensure that the information in the ST is sufficient to distinguish
the product.
ALC_CMS.1 TOE CM Coverage (ALC_CMS.1)
ALC_CMS.1
The "evaluation evidence required by the SARs" in this PP is limited to the
information in the ST coupled with the guidance provided to
administrators and users under the AGD requirements. By ensuring that the OS is specifically identified and that this identification is
consistent in the ST and in the AGD guidance (as done in the
assurance activity for ALC_CMC.1), the evaluator implicitly confirms the information
required by this component. Life-cycle support is targeted aspects of the developer’s
life-cycle and instructions to providers of applications for the developer’s devices,
rather than an in-depth examination of the TSF manufacturer’s
development and configuration management process. This is not meant to diminish the
critical role that a developer’s practices play in contributing to the overall
trustworthiness of a product; rather, it’s a reflection on the information to be made
available for evaluation. The evaluator will ensure that the developer has
identified (in guidance documentation for application developers concerning the
targeted 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 and linker flags). The evaluator will ensure that this documentation
also includes an indication of whether such protections are on by default, or have to
be specifically enabled. The evaluator will ensure that the TSF is
uniquely identified (with respect to other products from the TSF
vendor), and that documentation provided by the developer in association with the
requirements in the ST is associated with the TSF
using this unique identification.
ALC_TSU_EXT.1 Timely Security Updates
ALC_TSU_EXT.1
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.
The evaluator will prepare a test plan and report documenting the testing
aspects of the system, including any application crashes during testing. The evaluator
shall determine the root cause of any application crashes and include that information
in the report. The test plan covers all of the testing actions contained in the
[CEM] and the body of this PP’s Assurance Activities. While it is
not necessary to have one test case per test listed in an Assurance Activity, the
evaluator must document in the test plan that each applicable testing requirement in
the ST is covered. The test plan identifies the platforms to be
tested, and for those platforms not included in the test plan but included in the
ST, the test plan provides a justification for not testing the
platforms. This justification must address the differences between the tested
platforms and the untested platforms, and make an argument that the differences do not
affect the testing to be performed. It is not sufficient to merely assert that the
differences have no affect; rationale must be provided. If all platforms claimed in
the ST are tested, then no rationale is necessary. The test plan
describes the composition of each platform to be tested, and any setup that is
necessary beyond what is contained in the AGD documentation. It should be noted that
the evaluator is expected to follow the AGD documentation for installation and setup
of each platform either as part of a test or as a standard pre-test condition. This
may include special test drivers or tools. For each driver or tool, an argument (not
just an assertion) should be provided that the driver or tool will not adversely
affect the performance of the functionality by the OS and its
platform. This also includes the configuration of the cryptographic engine to be
used. The cryptographic algorithms implemented by this engine are those specified by
this PP and used by the cryptographic protocols being evaluated (IPsec, TLS). The test
plan identifies high-level test objectives as well as the test procedures to be
followed to achieve those objectives. These procedures include expected results.
The test report (which could just be an annotated version of the test plan) details
the activities that took place when the test procedures were executed, and includes
the actual results of the tests. This shall be a cumulative account, so if there was a
test run that resulted in a failure; a fix installed; and then a successful re-run of
the test, the report would show a “fail” and “pass” result (and the supporting
details), and not just the “pass” result.
3.5 Class AVA: Vulnerability Assessment
AVA_VAN.1 Vulnerability Survey (AVA_VAN.1)
AVA_VAN.1
The evaluator will generate a report to document their
findings with respect to this requirement. This report could physically be part of the
overall test report mentioned in ATE_IND, or a separate document. The evaluator
performs a search of public information to find vulnerabilities that have been found
in similar applications with a particular focus on network protocols the application
uses and document formats it parses.
The evaluator documents the sources consulted and
the vulnerabilities found in the report.
For each vulnerability found, the evaluator
either provides a rationale with respect to its non-applicability, or the evaluator
formulates a test (using the guidelines provided in ATE_IND) to confirm the
vulnerability, if suitable. Suitability is determined by assessing the attack vector
needed to take advantage of the vulnerability. If exploiting the vulnerability
requires expert skills and an electron microscope, for instance, then a test would not
be suitable and an appropriate justification would be formulated.
4 Required Supplementary Information
This Supporting Document has no required supplementary information beyond the ST, operational
guidance, and testing.
