An ST must claim exact conformance to this PP,
as defined in the CC and CEM addenda for Exact Conformance, Selection-based SFRs, and
Optional SFRs (dated May 2017).
CC Conformance Claims
This PP is conformant to Parts 2 (extended) and 3 (conformant) of Common Criteria Version 3.1, Revision 5.
PP Claim
This PP does not claim conformance to any Protection Profile.
Package Claim
This PP does not claim conformance to any packages.
5 Introduction to Distributed TOEs
words
5.1 Supported Distributed TOE Use Cases
words
5.2 Unsupported Distributed TOE Use Cases
words
5.3 Registration of Components of a Distributed TOE
words
5.4 Allocation of Requirements in Distributed TOEs
words
6 Security Problem Description
A Network Device has a network infrastructure role that it is designed to provide. In doing so,
the Network Device communicates with other Network Devices and other network entities (i.e.
entities not defined as Network Devices because they do not have an infrastructure role) over
the network. At the same time, it must provide a minimal set of common security functionality
expected by all Network Devices. The security problem to be addressed by a compliant
Network Device is defined as this set of common security functionality that addresses the
threats that are common to Network Devices, as opposed to those that might be targeting the
specific functionality of a specific type of Network Device. The set of common security
functionality addresses communication with the Network Device, both authorized and
unauthorized, the ability to perform valid and secure updates, the ability to audit device activity,
the ability to securely store and utilize device and Administrator credentials and data, and the
ability to self-test critical device components for failures.
6.1 Threats
T.NETWORK_ATTACK
An attacker is positioned on a communications channel or elsewhere on the
network infrastructure. Attackers may engage in communications with applications and
services running on or part of the OS with the intent of compromise. Engagement may
consist of altering existing legitimate communications.
T.NETWORK_EAVESDROP
An attacker is positioned on a communications channel or elsewhere on the
network infrastructure. Attackers may monitor and gain access to data exchanged between
applications and services that are running on or part of the OS.
T.LOCAL_ATTACK
An attacker may compromise applications running on the OS. The
compromised application may provide maliciously formatted input to the OS through a
variety of channels including unprivileged system calls and messaging via the
file system.
T.LIMITED_PHYSICAL_ACCESS
An attacker may attempt to access data on the OS while having a limited
amount of time with the physical device.
6.2 Assumptions
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.
6.3 Organizational Security Policies
P.ENTERPRISE
If the OS is bound to a directory or management server, the configuration of
the OS software must be capable of adhering to the enterprise security policies
distributed by them.
7 Security Objectives
7.1 Security Objectives for the TOE
O.ACCOUNTABILITY
Conformant OSes 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 OSes ensure the integrity of their update
packages. OSes are seldom if ever shipped without errors, and the
ability to deploy patches and updates with integrity is critical to enterprise network
security. Conformant OSes 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 OSes
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 OSes provide mechanisms to create
trusted channels for CSP and sensitive data. Both CSP and sensitive data
should not be exposed outside of the platform.
7.2 Security Objectives for the Operational Environment
The following security objectives for the operational
environment assist the OS in correctly providing its security functionality.
These track with the assumptions about the environment.
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
security policy.
7.3 Security Objectives Rationale
This section describes how the assumptions, threats, and organizational
security policies map to the security objectives.
The threat T.NETWORK_ATTACK is countered by O.ACCOUNTABILITY as this
provides a mechanism for the OS to report behavior that may indicate a network
attack has occurred.
The threat T.NETWORK_EAVESDROP is countered by O.MANAGEMENT as this provides
for the ability to configure the OS to protect the confidentiality of its transmitted
data.
The objective O.ACCOUNTABILITY protects against local attacks by providing
a mechanism to report behavior that may indicate a local attack is occurring or
has occurred.
The organizational security policy P.ENTERPRISE is enforced through the
objective O.MANAGEMENT as this objective represents how the enterprise and user assert
management over the OS.
8 Security Requirements
This chapter describes the security requirements which have to be fulfilled by the product under evaluation.
Those requirements comprise functional components from Part 2 and assurance components from Part 3 of
[CC].
The following conventions are used for the completion of operations:
Refinement operation (denoted by bold text or strikethrough
text): is used to add details to a requirement (including replacing an assignment
with a more restrictive selection) or to remove part of the requirement that is made irrelevant
through the completion of another operation, and thus further restricts a requirement.
Selection (denoted by italicized text): is used to select one or more options
provided by the [CC] in stating a requirement.
Assignment operation (denoted by italicized text): is used to assign a
specific value to an unspecified parameter, such as the length of a password. Showing the
value in square brackets indicates assignment.
Iteration operation: is indicated by appending the SFR name with a slash and unique identifier
suggesting the purpose of the operation, e.g. "/EXAMPLE1."
The individual security functional requirements are specified in the sections below. SFRs in
this section are mandatory SFRs that any conformant TOE must meet. Based on selections
made in these SFRs it will also be necessary to include some of the selection-based SFRs in
Appendix B. Additional optional SFRs may also be adopted from those listed in Appendix A.
For a distributed TOE, the ST author should reference Table 1 for guidance on how each SFR
should be met. The table details whether SFRs should be met by all TOE components, by at
least one TOE component or whether they are dependent upon the feature being implemented
by the TOE component. The ST for a distributed TOE must include a mapping of SFRs to each
of the components of the TOE. (Note that this deliverable is examined as part of the
ASE_TSS.1 and AVA_VAN.1 Evaluation Activities as described in [SD, 5.1.2] and [SD,
5.6.1.1] respectively.
The Evaluation Activities defined in [SD] describe actions that the evaluator will take in order
to determine compliance of a particular TOE with the SFRs. The content of these Evaluation
Activities will therefore provide more insight into deliverables required from TOE Developers.
8.1 Conventions
The conventions used in descriptions of the SFRs are as follows:
8.3.8 TOE Security Functional Requirements Rationale
The following rationale provides justification for each security objective for the TOE,
showing that the SFRs are suitable to meet and achieve the security objectives:
The Security Objectives in
Section 7 Security Objectives were constructed to address threats identified in
Section 6.1 Threats. The Security Functional Requirements (SFRs)
in Section 8.3 Security Functional Requirements are a formal instantiation of the Security Objectives. The PP
identifies the Security Assurance Requirements (SARs) to frame the extent to
which the evaluator assesses the documentation applicable for the evaluation and performs
independent testing. This section lists the set of SARs from CC part 3
that are required in evaluations against this PP. Individual Assurance Activities
to be performed are specified both in Section 8.3 Security Functional Requirements
as well as in this section. The general model for evaluation of OSs against STs written to conform to this PP is as follows: After the
ST has been approved for evaluation, the ITSEF will obtain the
OS, supporting environmental IT, and the administrative/user guides for
the OS. The ITSEF is expected to perform actions mandated by the Common Evaluation
Methodology (CEM) for the ASE and ALC SARs. The ITSEF also performs the Assurance Activities
contained within Section 8.3 Security Functional Requirements, which are intended to be an interpretation of the
other CEM assurance requirements as they apply to the specific technology instantiated in the
OS. The Assurance Activities that are captured in Section 8.3 Security Functional Requirements also provide
clarification as to what the developer needs to provide to demonstrate the OS is compliant
with the PP.
The information about the OS is contained in the guidance documentation available to the end user as
well as the TSS portion of the ST. The OS developer must concur with the description of the product that is
contained in the TSS as it relates to the functional requirements. The Assurance Activities
contained in Section 8.3 Security Functional Requirements should provide the ST authors with
sufficient information to determine the appropriate content for the TSS section.
The
functional specification describes the TSFI. It is not
necessary to have a formal or complete specification of these interfaces. Additionally,
because OSs conforming to this PP will necessarily have interfaces to
the Operational Environment that are not directly invokable by OS
users, there is little point specifying that such interfaces be described in and of
themselves since only indirect testing of such interfaces may be possible. For this PP,
the activities for this family should focus on understanding the interfaces presented in
the TSS in response to the functional requirements and the interfaces
presented in the AGD documentation. No additional “functional specification” documentation
is necessary to satisfy the assurance activities specified. The interfaces that need to be
evaluated are characterized through the information needed to perform the assurance
activities listed, rather than as an independent, abstract list.
The developer shall provide a tracing from the functional specification to the
SFRs.
Application
Note:
As indicated in the introduction to this section, the
functional specification is comprised of the information contained in the AGD_OPE and
AGD_PRE documentation. The developer may reference a website accessible to application
developers and the evaluator. The assurance activities in the functional requirements
point to evidence that should exist in the documentation and TSS
section; since these are directly associated with the SFRs, the tracing in element
ADV_FSP.1.2D is implicitly already done and no additional documentation is
necessary.
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 8.3 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.
8.4.3 Class AGD: Guidance Documentation
The guidance documents will be
provided with the ST. Guidance must include a description of how the IT
personnel verifies that the Operational Environment can fulfill its role for the security
functionality. The documentation should be in an informal style and readable by the IT
personnel. Guidance must be provided for every operational environment that the product
supports as claimed in the ST. This guidance includes instructions to
successfully install the TSF in that environment; and Instructions to
manage the security of the TSF as a product and as a component of the
larger operational environment. Guidance pertaining to particular security functionality is
also provided; requirements on such guidance are contained in the assurance activities
specified with each requirement.
The developer shall provide operational user guidance.
Application
Note:
The operational user guidance does not have to be contained in a
single document. Guidance to users, administrators and application developers can be
spread among documents or web pages.
Rather than repeat information here, the developer should
review the assurance activities for this component to ascertain the specifics of the
guidance that the evaluator will be checking for. This will provide the necessary
information for the preparation of acceptable guidance.
The operational user guidance shall describe, for each user role, the
user-accessible functions and privileges that should be controlled in a secure
processing environment, including appropriate warnings.
Application
Note:
User and administrator are to be considered in the definition
of user role.
The operational user guidance shall describe, for each user role, the available
functions and interfaces, in particular all security parameters under the control of
the user, indicating secure values as appropriate.
Application
Note:
This portion of the operational user guidance should be presented
in the form of a checklist that can be quickly executed by IT personnel (or end-users,
when necessary) and suitable for use in compliance activities.
When possible, this guidance is to be expressed in the eXtensible Configuration
Checklist Description Format (XCCDF) to
support security automation.
Minimally, it should be presented in a structured
format which includes a title for each configuration item,
instructions for achieving the secure configuration, and any relevant rationale.
The operational user guidance shall, for each user role, clearly present each
type of security-relevant event relative to the user-accessible functions that need to
be performed, including changing the security characteristics of entities under the
control of the TSF.
The operational user guidance shall identify all possible modes of operation of
the OS (including operation following failure or operational
error), their consequences, and implications for maintaining secure operation.
The operational user guidance shall, for each user role, describe the security
measures to be followed in order to fulfill the security objectives for the
operational environment as described in the ST.
Some of the contents of the operational guidance are verified by the
assurance activities in Section 8.3 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.
The developer shall provide the OS, including its preparative
procedures.
Application
Note:
As with the operational guidance, the developer should look to
the assurance activities to determine the required content with respect to preparative
procedures.
The preparative procedures shall describe all the steps necessary for secure
acceptance of the delivered OS in accordance with the developer's
delivery procedures.
The preparative procedures shall describe all the steps necessary for secure
installation of the OS and for the secure preparation of the
operational environment in accordance with the security objectives for the operational
environment as described in the ST.
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.
8.4.4 Class ALC: Life-cycle Support
At the assurance level provided
for OSs conformant to this PP, life-cycle support is limited to end-user-visible aspects of
the life-cycle, rather than an examination of the OS vendor’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 is a
reflection on the information to be made available for evaluation at this assurance level.
ALC_CMC.1 Labeling of the TOE (ALC_CMC.1)
This component is
targeted at identifying the OS such that it can be distinguished from
other products or versions from the same vendor and can be easily specified when being
procured by an end user.
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)
Given the scope of the OS and its associated evaluation
evidence requirements, this component’s assurance activities are covered
by the assurance activities listed for ALC_CMC.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
This component requires the
OS developer, in conjunction with any other necessary parties, to provide information as
to how the end-user devices are updated to address security issues in a timely manner. The
documentation describes the process of providing updates to the public from the time a
security flaw is reported/discovered, to the time an update is released. This description
includes the parties involved (e.g., the developer, carriers(s)) and the steps that are
performed (e.g., developer testing, carrier testing), including worst case time periods,
before an update is made available to the public.
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.
The description shall include the mechanisms publicly available for reporting
security issues pertaining to the OS.
Note:
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).
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.
8.4.5 Class ATE: Tests
Testing is specified for functional aspects of
the system as well as aspects that take advantage of design or implementation weaknesses.
The former is done through the ATE_IND family, while the latter is through the AVA_VAN
family. At the assurance level specified in this PP, testing is based on advertised
functionality and interfaces with dependency on the availability of design information. One
of the primary outputs of the evaluation process is the test report as specified in the
following requirements.
Testing is performed to confirm the
functionality described in the TSS as well as the administrative
(including configuration and operational) documentation provided. The focus of the testing
is to confirm that the requirements specified in Section 8.3 Security Functional Requirements being met,
although some additional testing is specified for SARs in Section 8.4 Security Assurance Requirements.
The
Assurance Activities identify the additional testing activities associated with these
components. The evaluator produces a test report documenting the plan for and results of
testing, as well as coverage arguments focused on the platform/OS
combinations that are claiming conformance to this PP. Given the scope of the OS and its associated evaluation evidence requirements, this component’s
assurance activities are covered by the assurance activities listed for ALC_CMC.1.
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.
8.4.6 Class AVA: Vulnerability Assessment
For the first generation of
this protection profile, the evaluation lab is expected to survey open sources to discover
what vulnerabilities have been discovered in these types of products. In most cases, these
vulnerabilities will require sophistication beyond that of a basic attacker. Until
penetration tools are created and uniformly distributed to the evaluation labs, the
evaluator will not be expected to test for these vulnerabilities in the OS. The labs will be expected to comment on the likelihood of these vulnerabilities given
the documentation provided by the vendor. This information will be used in the development
of penetration testing tools and for the development of future protection profiles.
The evaluator shall perform a search of public domain sources to identify
potential vulnerabilities in the OS.
Application
Note:
Public domain sources include the Common Vulnerabilities
and Exposures (CVE) dictionary for publicly-known vulnerabilities. Public domain
sources also include sites which provide free checking of files for viruses.
The evaluator shall conduct penetration testing, based on the identified
potential vulnerabilities, to determine that the OS is resistant to
attacks performed by an attacker possessing Basic attack potential.
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.
Appendix A - Optional Requirements
As indicated in the introduction to this PP, the baseline requirements (those that must be
performed by the TOE) are contained in the body of this PP.
This appendix contains three other types of optional requirements that may be included in the ST, but are not required in order
to conform to this PP.
However, applied modules, packages and/or use cases may refine specific requirements as mandatory.
The first type (A.1 Strictly Optional Requirements) are strictly optional requirements that are independent of the
TOE implementing any function.
If the TOE fulfills any of these requirements or supports a certain functionality, the vendor is encouraged to include the SFRs
in the ST, but are not required in order to conform to this PP.
The second type (A.2 Objective Requirements) are objective requirements that describe security functionality not yet
widely available in commercial technology.
The requirements are not currently mandated in the body of this PP, but will be included in
the baseline requirements in future versions of this PP. Adoption by vendors is
encouraged and expected as soon as possible.
The third type (A.3 Implementation-dependent Requirements)
are dependent on the TOE implementing a particular function.
If the TOE fulfills any of these requirements, the vendor must either add the related SFR or disable the functionality for the
evaluated configuration.
This PP does not define any
Objective requirements.
A.3 Implementation-dependent Requirements
This PP does not define any
Implementation-dependent requirements.
Appendix B - Selection-based Requirements
As indicated in the introduction to this PP,
the baseline requirements
(those that must be performed by the TOE or its underlying platform)
are contained in the body of this PP.
There are additional requirements based on selections in the body of
the PP:
if certain selections are made, then additional requirements below must be included.
B.1 Security Audit (FAU)
FAU_GEN_EXT.1 Security Audit Generation
The inclusion of this selection-based component depends upon selection in
FAU_GEN.1.1.
The following sections list Common Criteria and technology terms used in this document.
D.1.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.
D.1.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.
