Version: 1.0
2024-10-31
National Information Assurance Partnership
| Version | Date | Comment |
|---|---|---|
| 1.0 | 2024-10-31 | First draft of version 1.0 for comment |
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. |
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. |
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. |
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. |
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). |
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. |
Data Plane | Controls the forwarding and data processing capabilities for the network. This includes forwarding and processing of the data path. |
Developer | An entity that writes OS software. For the purposes of this document, vendors and developers are the same. |
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. |
Hybrid Authentication | A hybrid authentication factor is one where a user has to submit a combination of a cryptographic token and a PIN or password and both must pass. If either factor fails, the entire attempt fails. |
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. |
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. |
Personal Identification Number (PIN) | An authentication factor that is comprised of a set of numeric or alphabetic characters that may be used in addition to a cryptographic token to provide a hybrid authentication factor. At this time it is not considered as a stand-alone authentication mechanism. A PIN is distinct from a password in that the allowed character set and required length of a PIN is typically smaller than that of a password as it is designed to be input quickly. |
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. |
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. |
Southbound | Communications between an SDN and network devices in the data plane. |
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. |
The following figure shows the SDN controller sitting 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.
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:
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.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, TLS, DTLS, 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.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.
The following rationale provides justification for each SFR for the TOE,
showing that the SFRs are suitable to address the specified threats:
| Threat | Addressed by | Rationale |
|---|---|---|
| T.INSECURE_API | ||
| PP-Module Threat, Assumption, OSP | Consistency Rationale |
|---|---|
| T.INSECURE_API | |
| T.ATTACKER_ACCESS |
TBD
| PP-Module Requirement | Consistency Rationale |
|---|---|
| Modified SFRs | |
| FTP_ITC.1 | This 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. | |
This PP-Module does not define any Strictly Optional SFRs or SARs.
This PP-Module does not define any Objective SFRs.
This PP-Module does not define any Implementation-dependent SFRs.
This PP-Module does not define any Selection-based SFRs.
| Acronym | Meaning |
|---|---|
| ABAC | Attribute-Based Access Control |
| AES | Advanced Encryption Standard |
| ANSI | American National Standards Institute |
| API | Application Programming Interface |
| app | Application |
| APT | Advanced Persistent Threats |
| ASLR | Address Space Layout Randomization |
| Base-PP | Base Protection Profile |
| CC | Common Criteria |
| CEM | Common Evaluation Methodology |
| CESG | Communications-Electronics Security Group |
| CLI | Command-Line Interface |
| CMC | Certificate Management over CMS |
| CMS | Cryptographic Message Syntax |
| CN | Common Names |
| cPP | Collaborative Protection Profile |
| CRL | Certificate Revocation List |
| CRUD | Create, Read, Update, Delete |
| CSA | Computer Security Act |
| CSP | Critical Security Parameters |
| DAR | Data At Rest |
| DEP | Data Execution Prevention |
| DES | Data Encryption Standard |
| DHE | Diffie-Hellman Ephemeral |
| DNS | Domain Name System |
| DRBG | Deterministic Random Bit Generator |
| DSS | Digital Signature Standard |
| DT | Date/Time Vector |
| DTLS | Datagram Transport Layer Security |
| EAP | Extensible Authentication Protocol |
| ECDHE | Elliptic Curve Diffie-Hellman Ephemeral |
| ECDSA | Elliptic Curve Digital Signature Algorithm |
| EP | Extended Package |
| ESR | Equivalent Series Resistance |
| EST | Enrollment over Secure Transport |
| FIPS | Federal Information Processing Standards |
| FP | Functional Package |
| HMAC | Hash-based Message Authentication Code |
| HTTP | Hypertext Transfer Protocol |
| HTTPS | Hypertext Transfer Protocol Secure |
| IETF | Internet Engineering Task Force |
| IP | Internet Protocol |
| ISO | International Organization for Standardization |
| IT | Information Technology |
| ITSEF | Information Technology Security Evaluation Facility |
| MFA | Multi-Factor Authentication |
| MITM | Man-in-the-Middle |
| NAT | Network Address Translation |
| NFC | Near Field Communication |
| NIAP | National Information Assurance Partnership |
| NIST | National Institute of Standards and Technology |
| OCSP | Online Certificate Status Protocol |
| OE | Operational Environment |
| OID | Object Identifier |
| OMB | Office of Management and Budget |
| OS | Operating System |
| OWASP | Open Worldwide Application Security Project |
| PII | Personally Identifiable Information |
| PIN | Personal Identification Number |
| PKI | Public Key Infrastructure |
| PP | Protection Profile |
| PP | Protection Profile |
| PP-Configuration | Protection Profile Configuration |
| PP-Module | Protection Profile Module |
| RBAC | Role-Based Access Control |
| RBG | Random Bit Generator |
| REST | Representational State Transfer |
| RFC | Request for Comment |
| RNG | Random Number Generator |
| S/MIME | Secure/Multi-purpose Internet Mail Extensions |
| SAN | Subject Alternative Name |
| SAR | Security Assurance Requirements |
| SAR | Security Assurance Requirement |
| SDN | Software Defined Networking |
| SFR | Security Functional Requirements |
| SFR | Security Functional Requirement |
| SHA | Secure Hash Algorithm |
| SIP | Session Initiation Protocol |
| ST | Security Target |
| SWID | Software Identification |
| TLS | Transport Layer Security |
| TOE | Target of Evaluation |
| TSF | TOE Security Functionality |
| TSFI | TSF Interface |
| TSS | TOE Summary Specification |
| URI | Uniform Resource Identifier |
| URL | Uniform Resource Locator |
| USB | Universal Serial Bus |
| VM | Virtual Machine |
| VPN | Virtual Private Network |
| XCCDF | eXtensible Configuration Checklist Description Format |
| XOR | Exclusive Or |
| Identifier | Title |
|---|---|
| [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. |
