Comment: Comment-1-
Comment: Comment-2-
Comment: Comment-3-
Comment: Comment-4-
Comment: Comment-5-
Comment: Comment-6-

PP-Module for Software Defined Networking Controllers

NIAP Logo
Version: 1.0
2024-10-31
National Information Assurance Partnership

Revision History

VersionDateComment
1.02024-10-31First draft of version 1.0 for comment

Contents

1Introduction1.1Overview1.2Terms1.2.1Common Criteria Terms1.2.2Technical Terms1.3Compliant Targets of Evaluation1.3.1TOE Boundary1.4Use Cases2Conformance Claims3Security Problem Definition3.1Threats3.2Assumptions3.3Organizational Security Policies4Security Objectives4.1Security Objectives for the Operational Environment5Security Requirements5.1Collaborative Protection Profile for Network Devices Security Functional Requirements Direction 5.1.1 Modified SFRs 5.1.1.1Trusted Path/Channels (FTP)5.2TOE Security Functional Requirements5.2.1Security Audit (FAU)5.2.2User Data Protection (FDP)5.2.3Security Management (FMT)5.3TOE Security Functional Requirements Rationale6Consistency Rationale6.1Collaborative Protection Profile for Network Devices6.1.1 Consistency of TOE Type 6.1.2 Consistency of Security Problem Definition 6.1.3 Consistency of OE Objectives 6.1.4 Consistency of Requirements Appendix A - Optional SFRsA.1Strictly Optional Requirements A.2Objective Requirements A.3Implementation-dependent Requirements Appendix B - Selection-based Requirements Appendix C - Entropy Documentation and AssessmentC.1Design DescriptionC.2Entropy JustificationC.3Operating ConditionsC.4Health TestingAppendix D - AcronymsAppendix E - Bibliography

1 Introduction

1.1 Overview

The scope of this Protection Profile Module (PP-Module) is to describe the security functionality of a software defined network (SDN) controller in terms of [CC] and to define functional and assurance requirements for such products. An SDN Controller is a central component of an SDN system and is available as a logical or a physical device. An SDN Controller manages and distributes network policies, collects network routing and payload information from the control and data planes, and interfaces with user applications in the management plane for functions such as configuration and logging. Each of the planes in an SDN system is composed of multiple logical or physical components. The SDN Controller logically separates the data plane from the control plane and centralizes control which enhances network flexibility and scalability through more efficient network management. This PP-Module is intended for use with the following Base-PP: This Base-PP is valid because an SDN controller is a specific implementation of a network device. Specifically, an SDN controller is one of many components of an SDN networking architecture. Specifically, an SDN controller manages and distributes network policies, collects routing and payload information from the data plane, and interfaces with user applications in the management plane. Each of the planes in an SDN system is composed of multiple logical or physical components. SDN controllers logically centralize the network intelligence and state in the control plane.

1.2 Terms

The following sections list Common Criteria and technology terms used in this document.

1.2.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.
Direct Rationale
 A type of Protection Profile, PP-Module, or Security Target in which the security problem definition (SPD) elements are mapped directly to the SFRs and possibly to the security objectives for the operational environment. There are no security objectives for the TOE.
Distributed TOE
A TOE composed of multiple components operating as a logical whole.
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.
Protection Profile Configuration (PP-Configuration)
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.2.2 Technical Terms

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
 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.
Control Plane
 A logical entity that receives instructions or requirements from the SDN application layer through its northbound interface and relays them to the data plane through its southbound interface. The controller extracts information about the network from the data plane and communicates back to the SDN application layer with an abstract view of the network, including statistics and events about what is happening.
Credential
 Data that establishes the identity of a user (e.g., a cryptographic key or password).
Data Plane
 Controls the forwarding and data processing capabilities for the network. This includes forwarding and processing of the data path.
Management Plane
 Composed of programs that communicate behaviors and needed resources with the SDN controller via application programming interfaces (APIs). In addition, the applications can build an abstracted view of the network by collecting information from the controller for decision-making purposes. These applications could include networking management, analytics, or business applications used to run large data centers. For example, an analytics application might be built to recognize suspicious network activity for security purposes. This is sometimes also referred to as the Orchestration Layer.
Northbound
Communications between an SDN and applications in the management plane.
Southbound
Communications between an SDN and network devices in the data plane.

1.3 Compliant Targets of Evaluation

A conformant TOE decouples its data and control planes such that data traffic and control traffic are restricted to their respective planes. It also enforces centralization of control so that all components of the SDN environment are under its control. This can expand across multiple distributed controllers for large, complex, or geographically dispersed networks. Compliant TOEs will implement the following functionality:

1.3.1 TOE Boundary

The TOE boundary for an SDN controller is one or more physical or virtual devices. An SDN controller may be a distributed TOE, as defined by the Base-PP.

The following figure shows the logical position of the SDN Controller between the management and data planes within the SDN infrastructure. This is a simplified diagram of the TOE's position in an SDN deployment. Other dependencies that are necessary to meet security requirements, such as an audit server, remote management interface, or source of certificate revocation information are not shown.


Figure 1: High-Level SDN Representation

The following elements of an SDN controller are outside the scope of this PP-Module and are therefore considered to be non-interfering with respect to security, even if they are included as part of a compliant product:

1.4 Use Cases

Requirements in this PP-Module are designed to address the security problems in at least the following use cases. These use cases are intentionally very broad, as many specific use cases exist for an SDN controller These use cases may also overlap with one another. An SDN controller's functionality may even be effectively extended by privileged applications installed on it. However, these are out of scope of this PP.
[USE CASE 1] Standalone Physical Device
The TOE is a single physical appliance that provides SDN controller functionality.
[USE CASE 2] Virtual Device
The TOE is a virtual machine that provides SDN controller functionality. The TOE boundary is either limited to the virtual machine or includes the hypervisor and underlying physical hardware, depending on whether or not the hypervisor may include virtual machines that are not part of the SDN controller.
[USE CASE 3] Cluster (stand-alone or virtual)
Regardless of whether the TOE is physical, virtual, or both, it includes multiple distinct instances that are combined into a distributed cluster.
[USE CASE 4] Hyper-Converge
The TOE amalgamates various computing resources into a single unit for storage-centric, server-centric, or hybrid (storage-server) workloads.

2 Conformance Claims

Conformance Statement

An ST must claim exact conformance to this PP-Module.

The evaluation methods used for evaluating the TOE are a combination of the workunits defined in [CEM] as well as the Evaluation Activities for ensuring that individual SFRs and SARs have a sufficient level of supporting evidence in the Security Target and guidance documentation and have been sufficiently tested by the laboratory as part of completing ATE_IND.1. Any functional packages this PP claims similarly contain their own Evaluation Activities that are used in this same manner.
CC Conformance Claims

This PP-Module is conformant to Part 2 (extended) and Part 3 (conformant) of Common Criteria CC:2022, Revision 1.
PP Claim

This PP claims conformance to the following Protection Profiles:

The following PPs and PP-Modules are allowed to be specified in a PP-Configuration with this PP-Module:
Package Claim

This PP-Module is not conformant to any Functional or Assurance Packages.

3 Security Problem Definition

The security problem is described in terms of the threats that the TOE is expected to address, assumptions about the operational environment, and any organizational security policies that the OS is expected to enforce.

3.1 Threats

T.INSECURE_NORTHBOUND_API
A malicious user or process may invoke insecure application programming interfaces (APIs) to inject malicious code to the TOE on a northbound interface or to retrieve sensitive information from it. Executing improper or unauthorized API functions or providing malicious input to achieve unintended or improper results from proper or authorized API functions can compromise network services. This can also result in sensitive data leakage.

3.2 Assumptions

All assumptions from the Base-PP also apply to the TOE’s environment when it includes this PP‐Module in its conformance claims. This document does not define any additional assumptions.

3.3 Organizational Security Policies

An organization deploying the TOE is expected to satisfy the organizational security policy listed below in addition to all organizational security policies defined by the claimed Base-PP.

This document does not define any additional OSPs.

4 Security Objectives

4.1 Security Objectives for the Operational Environment

All environmental security objectives from the Base-PP also apply to the TOE’s environment when it includes this PP‐Module in its conformance claims.

5 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:

5.1 Collaborative Protection Profile for Network Devices Security Functional Requirements Direction

In a PP-Configuration that includes the NDcPP, the TOE is expected to rely on some of the security functions implemented by the Network Device as a whole and evaluated against the NDcPP. The following sections describe any modifications that the ST author must make to the SFRs defined in the NDcPP in addition to what is mandated by Section 5.2 TOE Security Functional Requirements.

5.1.1 Modified SFRs

The SFRs listed in this section are defined in the NDcPP and relevant to the secure operation of the TOE.

5.1.1.1 Trusted Path/Channels (FTP)

FTP_ITC.1: Inter-TSF Trusted Channel

This SFR has been modified from its definition in the NDcPP to define external interfaces to environmental entities that are particular to this specific technology type.

The text of the requirement is replaced with:

FTP_ITC.1.1 The TSF shall be capable of using [selection:IPsec, SSH as defined in the Functional Package for SSH, TLS as defined in the Functional Package for TLS, DTLS as defined in the Functional Package for TLS, HTTPS] to provide a trusted communication channel between itself and authorized IT entities supporting the following capabilities: audit server, northbound components, southbound components, [selection: authentication server, external east/west components [assignment: other capabilities], no other capabilities] that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from disclosure and detection of modification of the channel data.

FTP_ITC.1.2 The TSF shall permit [selection: the TSF, the authorized IT entities] to initiate communication via the trusted channel.

FTP_ITC.1.3 The TSF shall initiate communication via the trusted channel for [assignment: list of services for which the TSF is able to initiate communications].

Application Note: This PP-Module modifies this SFR to allow for the specification of any northbound, southbound, or east/west environmental components with which the TSF may implement protected communications. A conformant TOE may implement a distributed east/west configuration rather than the east/west entities being in the OE; in this case, the ST would define the TOE boundary as a distributed TOE in accordance with the NDcPP and use FPT_ITT.1 to define the interface between east/west distributed TOE components.

5.2 TOE Security Functional Requirements

The following section describes the SFRs that must be satisfied by any TOE that claims conformance to this PP-Module. These SFRs must be claimed regardless of which PP-Configuration is used to define the TOE.

5.2.1 Security Audit (FAU)

FAU_GEN.1/SDN Audit Data Generation (SDN)

The SDN controller must have maximum auditing and logging of all unauthorized API usage, especially API usage attempts from users that are not in the API roles.

This will be populated as needed by the audit events for other SFRs

 The TSF shall implement functionality to generate audit data of the following SDN auditable events:
  1. Startup and shutdown of the audit functions;
  2. All auditable events for [not specified] level of audit;
  3. All unauthorized usage of all API endpoints, including create, read, update, and delete.
  4. All authorized usage of all API endpoints, including create, read, update, and delete.
  5. Full HTTP REST request parameters and values of any API requests sent to the SDNC controller API.
  6. All HTTP Response Codes returned from any HTTP API requests sent to the SDNC controller API.
  7. All error codes and error messages from usage of the API.
  8. [all auditable events for mandatory SFRs specified in Table t-audit-mandatory, selected SFRs in Table t-audit-sel-based].
The TSF shall record within the SDN audit data at least the following information:
  1. Date and time of the event, type of event, subject identity, (if relevant) the outcome (success or failure) of the event; and
  2. For each audit event type, based on the auditable event definitions of the functional components included in the PP-Module/ST, [Additional Audit Record Contents as specified in Table t-audit-mandatory, Table t-audit-sel-based].
Application Note:

This SFR mandates that audit data be generated for startup and shutdown of the audit functions, which is a duplicate of FAU_GEN.1.1 in the Base-PP. If the TOE has one single audit mechanism, then the events used to conform to the Base-PP requirement also suffice here. Startup and shutdown of the audit functions in the context of the SDN controller portion of the TOE only need to be logged separately if the SDN controller has a different logging mechanism from what the Base-PP uses. Note also that in many cases the startup and shutdown of the audit functions cannot be forced on its own because the audit functions may be operational by default. In this case, logging for startup and shutdown of the TOE itself is sufficient. The purpose of this part of the requirement is to ensure that a malicious user cannot disable auditing to evade detection of other malicious use of the TOE.

The auditable events for the 'not specified' level of audit is intended to communicate that this PP-Module does not claim one of the pre-defined audit levels specified in CC Part 2; this is inherently satisfied by demonstrating that the TSF generates appropriate audit data for all events that are explicitly required by the PP-Module.

5.2.2 User Data Protection (FDP)

FDP_ACC.1 Subset Access Control

The TSF shall enforce the [API access control policy] on [all APIs used to access the TSF].

FDP_ACF.1 Security Attribute-Based Access Control

  1. API Validation: The SDN controller must perform validation of API calls against the API templates.
  2. API Validation: The SDN controller must block API calls that fail validation.
  3. API Validation: The SDN controller must ensure that API calls conform to the API templates, and block any API calls that do not conform.


 The TSF shall enforce the [API access control policy] to objects based on the following: [supported operations that can be performed on or by API objects, the validity of the API call being issued, whether the API call is authorized based on the subject's role].
The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: [an API call that is valid with respect to an allowlisted API template can manipulate an object if allowing this manipulation has been configured].
The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: [an allowlist explicitly authorizes the API request].
Application Note: This does not explicitly assert that the request is valid with respect to the template, nor does it explicitly assert that the object being accessed can have the desired action performed on it.
The TSF shall explicitly deny access of subjects to objects based on the following additional rules: [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects].
Application Note: The intent of this requirement is to give the ST author the ability to define a denylist that takes priority over the rules defined in FDP_ACF.1.2 and FDP_ACF.1.3. It may be the case that no explicit denylist is supported and the defined rules are followed in order with access being denied as a default condition if not otherwise specified by a rule. If this is the case, the ST author may complete the assignment with "no additional rules."

5.2.3 Security Management (FMT)

FMT_API_EXT.1 Management of API Behavior

•API Call Templates: The SDN controller must have API templates that define how API calls must be performed to access API objects.

The TSF shall provide the ability to define the following API templates [assignment: list of API templates] against the following API objects [assignment: list of API objects].
The TSF shall permit API templates to be defined if they meet the following specified rules: [assignment: rules determining allowable templates].

FMT_MOF.1/SDN Management of Functions Behavior (SDN)

Manipulation Control: The SDN controller must let the administrator specify how the allowed API objects can be manipulated.

The TSF shall restrict the ability to [modify the behaviour of] the functions [API access function as defined by FDP_ACC.1, API validity function as defined by FMT_API_EXT.1] to [API Administrator].
Application Note: The restriction of modifying API access and validity functions to the API Administrator is intended to imply that the API User does not have the ability to modify API functions. The API User role having read-only access to these functions is not precluded by this requirement, as this requirement only relates to the ability to modify the behavior of the API.

FMT_SMF.1/SDN Specification of Management Functions (SDN)

Allowlisting: The SDN controller must let the administrator be able to allowlist API templates so that configuration attempts from all other APIs not in the allowlist is blocked.

The TSF shall be capable of performing the following management functions: [API access control as defined by FDP_ACF.1, API validity as defined by FMT_API_EXT.1].
Application Note: API access control refers to configuring the allowlist for the permitted API templates. API validity refers to the ability to defining the templates for how API calls must be performed to access API objects. The intent of this requirement is for the TSF to have the ability to define both when and how a given API can be invoked.

FMT_SMR.2/SDN Restrictions on Security Roles (SDN)

This could also just be done as a Modified SFR to FMT_SMR.2 in the NDcPP but it may be cleaner just to do it as its own iteration here.

  1. RBAC: The SDN controller must provide an API user role and API administrator role for role-based access control
  2. RBAC: The SDN controller must require that only administrators in the API administrator role can perform API calls.


 The TSF shall maintain the roles: [API User, API Administrator].
The TSF shall be able to associate users with roles.
The TSF shall ensure that the conditions [API User and API Administrator roles cannot be held simultaneously] are satisfied.

5.3 TOE Security Functional Requirements Rationale

The following rationale provides justification for each SFR for the TOE, showing that the SFRs are suitable to address the specified threats:

Table 1: SFR Rationale
ThreatAddressed byRationale
T.INSECURE_​NORTHBOUND_​API

6 Consistency Rationale

6.1 Collaborative Protection Profile for Network Devices

6.1.1 Consistency of TOE Type

When this PP-Module is used to extend the NDcPP, the TOE type for the overall TOE is still a network device. The TOE boundary is simply extended to include SDN controller functionality that is provided by the network device.

6.1.2 Consistency of Security Problem Definition

The threats defined by this PP-Module (see section 3.1) supplement those defined in the NDcPP as follows:
Table 2: Consistency of Security Problem Definition (NDcPP base)
PP-Module Threat, Assumption, OSPConsistency Rationale
T.INSECURE_NORTHBOUND_API

6.1.3 Consistency of OE Objectives

TBD

6.1.4 Consistency of Requirements

This PP-Module identifies several SFRs from the NDcPP that are needed to support Software Defined Networking Controller functionality. This is considered to be consistent because the functionality provided by the NDcPP is being used for its intended purpose. The rationale for why this does not conflict with the claims defined by the NDcPP are as follows:
Table 3: Consistency of Requirements (NDcPP base)
PP-Module RequirementConsistency Rationale
Modified SFRs
FTP_ITC.1This PP-Module expands the Base-PP SFR to define additional entities for trusted channels.
Additional SFRs
This PP-Module does not add any requirements when the NDcPP is the base.
Mandatory SFRs
FAU_GEN.1/SDN
FDP_ACC.1
FDP_ACF.1
FMT_API_EXT.1
FMT_MOF.1/SDN
FMT_SMF.1/SDN
FMT_SMR.2/SDN
Optional SFRs
This PP-Module does not define any Optional requirements.
Objective SFRs
This PP-Module does not define any Objective requirements.
Implementation-dependent SFRs
This PP-Module does not define any Implementation-dependent requirements.
Selection-based SFRs
This PP-Module does not define any Selection-based requirements.

Appendix A - Optional SFRs

A.1 Strictly Optional Requirements

This PP-Module does not define any Strictly Optional SFRs or SARs.

A.2 Objective Requirements

This PP-Module does not define any Objective SFRs.

A.3 Implementation-dependent Requirements

This PP-Module does not define any Implementation-dependent SFRs.

Appendix B - Selection-based Requirements

This PP-Module does not define any Selection-based SFRs.

Appendix C - Entropy Documentation and Assessment

This appendix describes the required supplementary information for the entropy source used by the OS.
The documentation of the entropy source 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. This documentation is not required to be part of the TSS.

C.1 Design Description

Documentation will include the design of the entropy source as a whole, including the interaction of all entropy source components. Any information that can be shared regarding the design should also be included for any third-party entropy sources that are included in the product.
The documentation will describe the operation of the entropy source to include, how entropy is produced, and how unprocessed (raw) data can be obtained from within the entropy source for testing purposes. The documentation should walk through the entropy source design indicating where the entropy comes from, where the entropy output is passed next, any post-processing of the raw outputs (hash, XOR, etc.), if and where it is stored, and finally, how it is output from the entropy source. Any conditions placed on the process (e.g., blocking) should also be described in the entropy source design. Diagrams and examples are encouraged.
This design must also include a description of the content of the security boundary of the entropy source and a description of how the security boundary ensures that an adversary outside the boundary cannot affect the entropy rate.
If implemented, the design description shall include a description of how third-party applications can add entropy to the RBG. A description of any RBG state saving between power-off and power-on shall be included.

C.2 Entropy Justification

There should be a technical argument for where the unpredictability in the source comes from and why there is confidence in the entropy source delivering sufficient entropy for the uses made of the RBG output (by this particular OS). This argument will include a description of the expected min-entropy rate (i.e. the minimum entropy (in bits) per bit or byte of source data) and explain that sufficient entropy is going into the OS randomizer seeding process. This discussion will be part of a justification for why the entropy source can be relied upon to produce bits with entropy.
The amount of information necessary to justify the expected min-entropy rate depends on the type of entropy source included in the product.
For developer-provided entropy sources, in order to justify the min-entropy rate, it is expected that a large number of raw source bits will be collected, statistical tests will be performed, and the min-entropy rate determined from the statistical tests. While no particular statistical tests are required at this time, it is expected that some testing is necessary in order to determine the amount of min-entropy in each output.
For third-party-provided entropy sources, in which the OS vendor has limited access to the design and raw entropy data of the source, the documentation will indicate an estimate of the amount of min-entropy obtained from this third-party source. It is acceptable for the vendor to 'assume' an amount of min-entropy, however, this assumption must be clearly stated in the documentation provided. In particular, the min-entropy estimate must be specified and the assumption included in the ST.
Regardless of type of entropy source, the justification will also include how the DRBG is initialized with the entropy stated in the ST, for example by verifying that the min-entropy rate is multiplied by the amount of source data used to seed the DRBG or that the rate of entropy expected based on the amount of source data is explicitly stated and compared to the statistical rate. If the amount of source data used to seed the DRBG is not clear or the calculated rate is not explicitly related to the seed, the documentation will not be considered complete.
The entropy justification shall not include any data added from any third-party application or from any state saving between restarts.

C.3 Operating Conditions

The entropy rate may be affected by conditions outside the control of the entropy source itself. For example, voltage, frequency, temperature, and elapsed time after power-on are just a few of the factors that may affect the operation of the entropy source. As such, documentation will also include the range of operating conditions under which the entropy source is expected to generate random data. It will clearly describe the measures that have been taken in the system design to ensure the entropy source continues to operate under those conditions. Similarly, documentation shall describe the conditions under which the entropy source is known to malfunction or become inconsistent. Methods used to detect failure or degradation of the source shall be included.

C.4 Health Testing

More specifically, all entropy source health tests and their rationale will be documented. This includes a description of the health tests, the rate and conditions under which each health test is performed (e.g., at start, continuously, or on-demand), the expected results for each health test, and rationale indicating why each test is believed to be appropriate for detecting one or more failures in the entropy source.

Appendix D - Acronyms

Table 4: Acronyms
AcronymMeaning
APIApplication Programming Interface
Base-PPBase Protection Profile
CCCommon Criteria
CEMCommon Evaluation Methodology
cPPCollaborative Protection Profile
DRBGDeterministic Random Bit Generator
HTTPHypertext Transfer Protocol
HTTPSHypertext Transfer Protocol Secure
IPInternet Protocol
ITInformation Technology
OEOperational Environment
OMBOffice of Management and Budget
OSOperating System
PPProtection Profile
PP-ConfigurationProtection Profile Configuration
PP-ModuleProtection Profile Module
RBACRole-Based Access Control
RBGRandom Bit Generator
RESTRepresentational State Transfer
RFCRequest for Comment
SARSecurity Assurance Requirement
SDNSoftware Defined Networking
SFRSecurity Functional Requirement
STSecurity Target
TLSTransport Layer Security
TOETarget of Evaluation
TSFTOE Security Functionality
TSFITSF Interface
TSSTOE Summary Specification
USBUniversal Serial Bus
VMVirtual Machine
VPNVirtual Private Network
XORExclusive Or

Appendix E - Bibliography

Table 5: Bibliography
IdentifierTitle
[CC]Common Criteria for Information Technology Security Evaluation -
[CEM]Common Methodology for Information Technology Security Evaluation -
[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.