Common Criteria for Network Devices: What to expect from products certified with a protection profile

In the list of certified products on Common Criteria's website, the 'Network Devices’ category is the one with the largest and most diverse number of solutions. All of them have one characteristic in common: they are products that manage (process, filter and distribute) information flowing through a network’s architecture.

In this broad category, we can find an infinite number of Common Criteria-certified solutions with this label. These could be traditional network electronics such as routers, switches and access points, or cybersecurity solutions for networks such as firewalls, proxies, antivirus, virtual private networks (VPN) and other solutions for the detection of threats and protection of information. 

Although at first glance this may seem a very generalist group, it actually makes sense. Let us not lose sight of the purpose of a Common Criteria certification. We might presume that certifications are just aimed at validating the security functions offered by the solution. However, more often than not, the security of the solution itself is also evaluated.

In other words, the laboratory not only assures that the operation of the solution conforms to what is expected for a solution of its kind, but also, we check that the solution has been developed in a secure way so that the product does not pose a threat to itself and the environment where it is deployed. Moreover, the laboratory also reviews the associated guidance to make sure that any security-critical instructions are properly provided to the end user in the product documentation.

Let’s take an antivirus solution as an example: the laboratory would not assess whether an antivirus is capable of detecting a greater or lesser number of malware, or whether it does so faster or slower than other solutions on the market. We would assess that the process of detecting malicious content exists and that management processes are secure. We would make sure its software does not contain vulnerabilities (such as those derived from using old and vulnerable third party libraries), and that it doesn’t use weak authentication mechanisms. These are just some of many evaluation activities we would perform.

Here is the meeting point between all these different solutions and products. That is, in the requirements and security levels that must be demanded from a network device or a solution (in physical or software/virtualized format) that connects to a network and handles the information that circulates through it.

Certification against a Protection Profile

As we discussed in a previous article on the questions CISOs should ask themselves before choosing a cybersecurity solution or network device, there are different options for conducting a Common Criteria security assessment of a solution. In short, the developer can decide the objectives and scope of the evaluation (Target of Evaluation, commonly known as TOE) based on an EAL (Evaluation Assurance Level). Alternatively, they can use a Protection Profile that fits the taxonomy of the solution.

As we also mentioned in the aforementioned article, Protection Profiles are generated by international technical working groups, which may be composed of manufacturers, evaluation laboratories, public bodies, risk owners, consumers, and other parties. The Protection Profiles are then reviewed and certified by a recognized Common Criteria Certification Body and then published on this website.

Undoubtedly, the profile that fits better for security evaluations of network devices, and one of the most widely used protection profiles, is the NDcPP, "Collaborative Protection Profile for Network Devices", which is currently in version 2.2e, released on 23-03-2020.

Two products evaluated under NDcPP will offer at least the mandatory security functionalities evaluated in equivalent assurance levels. In contrast, the guarantees provided by a certificate of a product, evaluated without a protection profile will vary depending on what the developer decided to declare in the functionality descriptions for their evaluated solution. 

Features of the Collaborative Protection Profile for Network Devices (NDcPP)

The NDcPP provides a fundamental set of security requirements to be expected from a network solution, with the objective of mitigating a specific list of security threats. It does this regardless of the ultimate purpose of the solution or any specific security functionality (e.g. firewall) that the product may provide.

Primarily, this reference set includes requirements for:

• securing any remote control path for management, providing identification and authentication services for both local access and remote logins; 
• ensuring auditability of security-related events; 
• cryptographically validating the legitimate origin of any software updates; 
• validating that the cryptographic algorithms used by the TOE are robust and well implemented; 
• and ensuring the device does not present public vulnerabilities and behaves normally when presented with malformed network traffic (fuzzing technique). 

Ultimately, the aim is to ensure that the management capabilities of the product are secure, and that it does not pose a security threat in the network environment where it is deployed.

Main security threats covered by NDcPP

The threats that the NDcPP Protection Profile is intended to mitigate are grouped according to the functional areas of the product:

Communications with the network device

• Unauthorized administrative access: Attackers could attempt to gain administrative access either through network attacks or by attempting to exploit a user's session or credentials without such permissions.
• Weak cryptographic algorithms: A potential attacker could compromise the confidentiality, integrity and authenticity of a communication if weak protection mechanisms are used. This would apply both to communications and to the information that may be stored within the device itself.
• Untrusted communication channels: An attacker could attack the security of communication channels if they have not been designed and implemented robustly and do not correctly manage the exchange of sensitive information.
• Weak authentication between communication endpoints: An attacker could exploit a weak authentication mechanism within a secure communication protocol. For example, a shared or easily guessed password used within a secure channel. The channel may be very secure, but it will be useless if the password is easy to guess.

Valid updates

• Compromised update: An attacker could attempt to attack a device via a manipulated update. For example, spyware could be inserted into an update package if it is not properly protected.

Auditing

• Undetected activity: An attacker could modify some kind of critical system parameter without the knowledge of an administrator. For example, the system must keep a log of all events relevant to the security of the system.

Administrator and device credentials and information

• Compromise of security functionality: If an attacker does indeed have access to the device in question, critical system parameters (stored passwords, cryptographic keys) must be specially protected, disabling any interface that could expose this data in an unencrypted manner. 
• Crackable credentials: Attackers could take advantage of credentials that are easily crackable by software or directly by trying all possible combinations through a brute force attack in case they have access to the content of the device's memory or disks.

Device failure

• Failure of security functionality: Security mechanisms could fail at some point, due to a bug or the device being in an inconsistent state. However, the device should have the ability to detect this insecure state through the use of self-testing of the security functionality.

To mitigate such threats, the protection profile for Network Devices, NDcPP, contains the following Security Functional Requirements (SFR), grouped by the functional areas of the TOE (Target of Evaluation) listed below in the annex, which the developer must fulfil to pass the evaluation. 

A summary

In summary, when comparing different network devices or cybersecurity solutions for deployment in our corporate network infrastructure, certification based on the Protection Profile provides us with the minimum guarantees on the product’s management functionalities and robustness against possible security threats.

Annex: NDcPP Fundamental Security Requirements

Secure Communications Requirements 

• Channels: Specific protocols - Entities and services used - Protocols required by each channel
• Protocols: Specific protocols required for the channels 
• Cryptography / Key Management: Asymmetric Key Generation - Key Establishment - Key Erasure
• Cryptography / Cryptologic Management: Cryptologic configuration 
• Cryptography / Random Bit Generation
• Cryptography / x.509 Certificates: Certificate validation - Authentication - Requesting a certificate

 
Administrator Authentication Requirements

• Authentication Mechanisms: Available mechanisms - Pre-authentication services - Actions in case of failed login attempts
• Protecting Authentication Information: Password Restrictions - Password Entry Protection - Protecting Stored Credentials
• Banner message: Display a message to admins at login time (e.g. legal disclaimer)
• Session protection: Session termination - Automatic protection of local session - Automatic termination of remote session
• Management: Security Administrator Role Definition

Correct Operation:

• Self-test: Basic self-test
• Time Synchronization: NTP Protocol

Audit:

• Main audit: Generation of audit information - Events associated to users - Link to external audit server, time stamp - Generation of audit information for distributed TOEs
• Audit space policies: Protection of audit log - Loss of log information - Low space alerts - Protection of local and remote events storage
• Management: Functions

Reliable updates:

• Digital Signature: Requirement for the use of digital signature verification
• X.509 Certificates: Requirement to use certificates - Validation - Authentication - Request certificate
• Management: Manual and automatic update

Management

• Main Management: Definition of the role of Security Administrator - Definition of management functions - Management of information on TOE functionalities (TSF) by the security administrator - Control of behaviour in manual updates
• Audit Management: Audit Configuration
• General TOE configuration: Service configuration and TOE functionalities - Key management - Control over behaviour in automatic updates

Distributed TOE

• Registration: Definition of Security Administrator role - Definition of management functions - Management of information about TOE functionalities (TSF) by the security administrator - Behavioural control on manual updates
• Liaison channels: Alternative link channels - Validation of certificates - Audit: Generation of information on TOE functionalities by the security administrator - Control of manual update behaviour
• Auditing: Generation of audit information for distributed TOEs - Secure storage of local and remote events