Vendor security assessment

Assessing the security of network equipment.

Version 1.0

Published March 2022

© Crown Copyright 2022

2 Vendor security assessment

Contents
Introduction .............................................................................................................................. 3

Summary of approach to assessment ............................................................................ 4

External audits and international schemes .................................................................. 5

Support from the security research community ......................................................... 6

The approach to assessment ..............................................................................................7

Vendor security assessment criteria .............................................................................. 9

 Vendor security assessment 3

Introduction
The security of network equipment is critical to the security of any network. When selecting equipment that will
support a critical service or critical infrastructure, customers should make an assessment of the security of that
equipment and consider that assessment as part of their procurement and risk management processes.
This guidance provides advice on how to assess the security of network equipment. It provides guidance to
support public telecommunications operators (the providers of Public Electronic Communications Networks and
Services), in meeting their duties under the Telecommunications (Security) Act 2021, and, when they are finalised
following the Government’s consultation, the Electronic Communications (Security Measures) Regulations 2022.
For example, under draft Regulation 3.(3)(e), the network provider would be required:

(e) to take appropriate measures in the procurement, configuration, management and testing of equipment to ensure the
security of the equipment and functions carried out on the equipment

This guidance is referenced in the draft Telecommunications Security Code of Practice, in particular draft
measures 5.01 and 10.1. Whilst this guidance is not expected to form part of that code (when it is finalised) and
will not be necessary or sufficient to meet new supply chain legal requirements, it is important advice that
providers can use to help their compliance.
While written to support telecommunications operators, the advice within this guidance may also be useful to
other providers of critical services or critical infrastructure who rely on network equipment to deliver their
services. The NCSC acknowledge that the degree of assessment of the security of network equipment advised in
this document is most appropriate where the network equipment is supporting a critical service. In addition, to
perform the assessment described in this document effectively, customers may require appropriate contractual
rights to perform the recommended audits and tests.
This guidance should be used when making selection decisions for network equipment. However, as noted
below, security is an ongoing activity. As with other areas of performance, customers should continue to assess
and retain evidence of the vendor’s track record in security during the equipment’s lifetime, as this will support
future security assessments.
This guidance does not take account of, and cannot mitigate, the threats that may arise because of additional
risks specific to a particular vendor in the supply chain. These risks include the degree to which it might be
susceptible to being influenced or required to act contrary to the interests of the customer or their national
security. In such circumstances, additional controls specific to the vendor in question may be required.
4 Vendor security assessment

Summary of approach to assessment

This document provides guidance on how to assess a vendor’s security processes and their supplied network
equipment. The purpose of the approach is to objectively assess the cyber risk due to use of the vendor’s
equipment. This is performed by gathering objective, repeatable evidence on the security of the vendor’s
processes and network equipment.
Assessing the cyber risk due to a vendor requires:
• evidence from the vendor themselves
• testing to validate the vendor’s claims
• third party evidence
For each criterion in this document, there are a range of product-specific spot checks that may be performed
and evidence may be obtained directly from lab-tests on the product itself. These three components together
will help build an understanding of how well a vendor is building a new product.
However, such an approach will always be fallible. While evidence will be customer-driven, it can only provide
examples of vendor behaviour. To be effective, both the approach and security standards needs to be sustained
over many years, with evidence of good and bad practice recorded to support future security assessments and
procurement decisions.
When assessing vendor security practices, the NCSC recommends operators to not rely exclusively upon vendor
documentation to assess vendor security. Security assessments should be based on the vendor’s implemented
security behaviour. This includes product-line specific spot checks, and objective evidence extracted from the
product.
 Vendor security assessment 5

External audits and international

schemes
One of the biggest challenges when assessing the security of network equipment is the industry practice of
producing regional or operator-specific versions of products. Where vendors follow this practice, international
customers cannot share the burden of gaining evidence or assurance about product quality or security, whether
through working with each other or through international testing schemes.
It may be possible to rely on independent, external sources to provide some of the required evidence, provided:
• it is applicable to the customer’s product (specifically the same hardware and code base)
• all evidence can be revalidated by the customer, and some evidence has been randomly selected to be
revalidated
Generally, vendor audits or evaluations that rely on vendor documentation are unlikely to provide useful
evidence unless it is possible to verify that the audit relates to the security of the network equipment. For the
same reason, audits or evaluations where the evidence behind the audit is not widely available and testable
should also not be considered. For example, as currently defined, the private, paper-based assessments
1
performed under GSMA’s NESAS scheme are unlikely to provide useful evidence in support of the customer’s
assessment of product security.

1
https://www.gsma.com/security/network-equipment-security-assurance-scheme/
6 Vendor security assessment

Support from the security research

community
Given the range, scale and complexity of network equipment participation from the global security research
community (including both commercial labs and academia) is essential to support customers in understanding
security risk. For this reason, vendors should be encouraged to be transparent and open about their security
practices, and should be encouraged to support responsible, independent security researchers in performing
their own testing and analysis.
To support the development of increasingly secure and open telecommunications equipment, DCMS has stated
that it intends to establish a UK National Telecommunications Lab (UKTL). This will be a secure research facility
that will bring together telecommunications operators, existing and new suppliers, academia, and the
government to create representative networks in which to research and test new ways of increasing security and
interoperability.
 Vendor security assessment 7

The approach to assessment

Assessing a vendor’s approach to security requires a four-tiered approach:

Assess
Assessing a Security Declaration provided by the vendor. This should state the vendor’s approach to security, and
the security promises that the vendor makes to its customers. In the interests of developing the security
ecosystem, the NCSC recommends that the vendor openly publishes their Security Declaration. This provides
confidence to customers that the vendor’s approach is consistent for all customers and product lines, and allows
the wider security community to participate in the security discussion.

Check
Performing Spot Checks on the vendor’s implemented security processes for specific, independently chosen
product releases. As all details should be readily available to the vendor within their own systems, providing
advance notice of the choice should not be necessary.

Analyse
Performing Lab Tests against equipment. The tests should either be against all equipment or the equipment
should be randomly selected from the equipment provided by the vendor. Lab tests should be automated
wherever possible so they can be easily repeated at low cost. Lab tests performed independent of the customer
should be against the same product version track, hardware, software, firmware, and configuration as used by
the customer.

Sustain
Holding vendors to the standard in the Security Declaration throughout the entire period of the customer’s
relationship with the vendor. Customers should analyse root causes of issues and record the vendor’s security
performance to ensure future assessments are made with a rigorous evidence base.
Recommendations for applying this four-tiered approach are provided below.

Assessing vendor security performance

When assessing vendor security practises one essential source of data is the vendor’s security performance.
Customers should consider both the vendor’s security culture and behaviour as evidenced by:
• maturity of vendor risk assessment and security assessment processes
• vendor transparency, openness, and collaboration with the security research community
• vendor assessment, management, and support to customers in relation to any security vulnerabilities and
incidents
• vendor compliance with security obligations and requirements
• vendor approach to product and component support
Security incidents in themselves are not evidence of poor security practice. All major companies are likely to be
impacted by security incidents and depending on their cause and how they are handled, security incidents may
provide an example of good practice. The customer should consider whether the incident could have been
reasonably avoided, or its impact could have been reasonably reduced.
8 Vendor security assessment

Similarly, product security vulnerabilities or issues are not in themselves evidence of poor security practice as
such issues will occur in all products. However, where issues are simplistic, or due to poor product management
or maintenance, this may be evidence of poor practice.
 Vendor security assessment 9

Vendor security assessment criteria

The following table can be used to assist in assessing the security processes of vendors and their network
equipment. The table describes the information that customers should expect within the Security Declaration,
Spot Checks that should be considered to collect evidence, and the Lab Testing that customers or third parties
should consider making against equipment. For Spot Checks and Lab Testing, it is assumed that the customer will
be given sufficient access to vendor processes and equipment to perform an effective evaluation prior to making
decisions based upon this evaluation.
When third parties are used, the customer should satisfy themselves that the third party was sufficiently
independent, had sufficient technical competence, and gained sufficient information about the vendor’s day-to-
day practices to provide them with the confidence required reliable evidence.

Topic Security expectation Why it matters Evaluation: security Evaluation: customer or Evaluation: customer
declaration 3rd party spot checks or 3rd party lab test

V.A: Product lifecycle management

V.A: The vendor’s To provide As part of the - -

products are properly confidence that a Security Declaration,
Overall aim
supported product will be the vendor describes
throughout the maturely managed by how products are
lifetime of the the vendor, receiving supported.
product. updates and security
critical fixes for the
supported lifetime of
the product.

V.A.1: The vendor clearly To provide The vendor describes Check product release -
identifies the lifecycle confidence that their product’s history. Explore how the
Product
for each product. products will be lifecycle within the vendor is keeping
lifecycle process
Vendors should have supported until a Security Declaration. components up-to-date.
an End of Life Policy given date. Also, that
For each release
which details how the vendor’s support
within a product line,
long products will be dates apply globally,
the vendor publishes
supported after End meaning that the
End of Sale dates on
of Sale. vendor is likely to
their website as soon
continue to invest in
as they become
product maintenance
applicable. The End
throughout this
of Life Policy should
period.
detail how long, and
in what way, products
will be supported
after the End of Sale
date has been
announced. The
location of this
information is
referenced in the
Security Declaration.

V.A.2: Each product is To provide The vendor clearly View records showing the Pick a sample of known
maintained through confidence that describes how they history of security fixes vulnerabilities for a
Software
its published life products can be will support products applied to the product, customer-selected
maintenance
cycle. This patched against during their lifetime, including a roadmap for product and check how
maintenance, as a security issues including what resolution of any and when they were
minimum, covers discovered in the support they will outstanding patched in accordance
security fixes for the product throughout provide under each vulnerabilities. with the vendor’s
product. its supported lifetime. support class. policies. (see V.A.7).
10 Vendor security assessment

Topic Security expectation Why it matters Evaluation: security Evaluation: customer or Evaluation: customer
declaration 3rd party spot checks or 3rd party lab test

Test the product to

verify that the
equipment is no longer
vulnerable to the
vulnerability or variants
of the vulnerability.

V.A.3: Each product has a To provide The vendor describes The vendor demonstrates
version-controlled confidence to that how they maintain how changes are made
Software
code repository the vendor can track the integrity of their based on normal
version control
which logs every exactly what code is code base. processes, and how
code modification. being deployed changes via other means
This audit log will within products. It is would be rejected.
detail: essential for effective Explore a change and
investigation of verify that processes were
-what code has been
supply chain attacks. followed.
modified, added, or
removed

-why the change was

made

-who made the

change

-when the change

was made

-which version of the

code has been built
into the released
product.

V.A.4: Each product goes This requirement The vendor describes View the build and test Check accuracy of a set
through a rigorous exists to provide their software release process. of the vendor’s test
Software
software release cycle confidence that cycle, including the results by repeating the
releases Review the testing
including internal vendors test their gates, and the testing tests in the customer’s
performed against a
testing before a software releases and performed. or third party’s lab.
customer-chosen product
version is released for validate that their
line and version. Check
general availability. internal secure
that testing tools are well
Software will not be engineering
configured and view the
released if it does not processes have been
test results. Verify that
comply with the followed.
tests are included to
Secure Engineering
The tests should also check for previously
requirements detailed
ensure that previously resolved vulnerabilities
below. Each product
resolved security and issues.
should have regular
vulnerabilities are not
external testing The vendor demonstrates
reintroduced.
carried out on it by that issues were correctly
an independent third fixed as a result of any
party. failed tests.

V.A.5: There is one primary This requirement The Security

release train of the exists to provide Declaration describes
Development
product. confidence that the the vendor’s
processes and
vendor is shipping development process,
feature Forking of new
them a generally including how and
development versions is minimised.
available version of when new product
Where necessary,
the product, so they versions are released,
customer-specific
know the product can and how the number
functionality is
be supported of versions is kept to
provided as optional
throughout its a manageable level.
modules.
lifetime using the
general support
routes.
 Vendor security assessment 11

Topic Security expectation Why it matters Evaluation: security Evaluation: customer or Evaluation: customer
declaration 3rd party spot checks or 3rd party lab test

Any new features are It is highly unlikely

brought into the that the vendor will
main product line be able to properly
during the standard support a
development proliferation of
roadmap. feature-specific
product versions.

V.A.6: The vendor maintains This requirement The vendor publishes The vendor describes the Based on the vendor’s
a single, global exists to provide the details of all released full release train of the published information,
International
version line for each confidence that the versions of their product, including why or otherwise, test that
release and
product. There are a product is globally products, including each version was created. product versions
forking
minimal number of supported and that binary hashes. It is supplied by the vendor
other versions (ideally any issues discovered expected that this are the ‘global’ versions
none). can easily be information will be on and have matching
mitigated. the vendor’s website. binary hashes.

It is highly unlikely The vendor

that the vendor will references its public
be able to properly list of product
support a versions within its
proliferation of Security Declaration.
customer-specific
product versions.

V.A.7: Third party tools (e.g. Out-of-support tools, The Security For a customer-selected Scan product interfaces
code compilers) software Declaration describes product, the vendor to inventory known
Use of tools,
software components components, how third party provides a list of third third party tools and
software and
and software libraries software or libraries software components party components that determine if they are
libraries
that are used within are unlikely to use are maintained, are material to the being maintained.
and in the modern security explicitly stating security of the product, Examine the product to
development of the features. If exposed, when, if ever, out-of- (e.g. those components verify that the vendor’s
product are they can cause support components exposed via interfaces). component list appears
inventoried. Any of known vulnerabilities will be included in Verify that these accurate.
the above that are to be embedded in any product versions, components are still
material to the the product. stating justifications. actively maintained, and
security of the Vulnerabilities in there is a support plan for
vendor’s software are critical security the lifetime of the
maintained protections of the product.
throughout its product must be
lifetime. patched, to minimize
the impact of exploits.

V.A.8: The vendor provides This provides the The Security Using documentation,
up-to-date and customer with the Declaration makes set up, operate,
Software
technically accurate information they commitments about configure, and update
documentation
documentation require to help them the release of the product without
alongside new securely deploy and product support from the
releases of the manage the product documentation to vendor.
product. This throughout its customers.
documentation, as a lifetime in their
minimum, shall detail networks, and
how to securely independently assess
configure, manage, the security of that
and update the configuration.
product.
This helps to reduce
the customer’s
ongoing dependence
on the vendor.

V.B: Product security management

12 Vendor security assessment

Topic Security expectation Why it matters Evaluation: security Evaluation: customer or Evaluation: customer
declaration 3rd party spot checks or 3rd party lab test

V.B: Products will be These requirements

developed in a exist to provide
Overall aim
‘secure by default’ confidence that a
manner. product they deploy
has been developed
using standard
security mitigations
and secure coding
techniques.

V.B.1: The vendor has a This provides The Security - -

security culture which confidence that Declaration describes
Security culture
ensures that security developers within the the senior ownership
principles are company are of the security culture
followed. known to follow the within the vendor,
security principles and the mechanisms
and development that exist to allow
requirements. staff to raise security
concerns.

V.B.2: The vendor has a This provides The Security The vendor demonstrates Search for signs that
Secure Development confidence that Declaration describes how they gain confidence the vendor’s security
Secure
Lifecycle2 to embed security is embedded how the vendor that the Secure controls built into their
Development
security into product in the development develops secure Development Lifecycle Secure Development
Lifecycle
development. All process and that products, including has been followed by Lifecycle are working
development teams there is a consistent how the vendor developers. (e.g. that
follow, and can security culture within verifies that its secure subcomponents are
The vendor describes
evidence that they the company. coding standards are resistant to malformed
how they ensure their
follow, the Secure followed. inputs).
code is of high quality.
Development
Verify examples of
Lifecycle processes.
security controls built into
the product development
processes.

V.B.3: Any shared internal This provides The Security For a customer-selected In a lab, verify that the
components or confidence that any Declaration makes product, the vendor can released product
Internal
libraries are kept up internal shared clear commitments list the product’s software contains only one
component
to date and only the components being around the and hardware version of each internal
management
latest stable, used within a product maintenance of components. software component or
supported version is will be maintained internal components. library, and that all
Verify that only recently
used. These throughout the internal components
released versions of
components and lifetime of the main have been recently
shared internal
libraries are not to be product. built.
components and libraries
modified for specific
are used.
builds and are
supported for the Explore whether the
lifetime of the product line has forked
product. any shared libraries.

V.B.4: Only supported This provides The Security For a customer-selected In a lab, verify that the
external components confidence that any Declaration makes product release, verify released product is only
External
are used within a third party clear commitments that it is only using using fully supported
component
product. The vendor component a vendor on the use of supported versions of versions of all external
management
monitors the external chooses to use will be supported external external components and components.
component’s currently supported, components. libraries.
Search for evidence of
changelog so that and that any security
Explore how these internally-forked
only the latest issue discovered with
components will be external components or
supported, stable the component will
updated when they reach libraries.
version is used within be patched.
end-of-life.
the product.

2
The ‘Secure Development Lifecycle’ is the process through which the vendor integrates security considerations throughout the product
development lifecycle.
 Vendor security assessment 13

Topic Security expectation Why it matters Evaluation: security Evaluation: customer or Evaluation: customer
declaration 3rd party spot checks or 3rd party lab test

Additionally, the Extended support Explore whether the

vendor monitors the contracts are likely to product line has forked
external component’s increase security risk any externally-developed
security advisories and should be code, and if so, explore
and pull in any avoided. how it is maintained.
security fixes and
integrate them into
their product with a
security update.

V.B.5: There are no unsafe These functions are The Security Request code metrics on
functions used within frequently the cause Declaration clearly use of unsafe functions
Unsafe
the vendor’s released of product states whether unsafe
Functions
code. Unsafe vulnerabilities . functions are used
functions are those within the vendor’s
commonly associated code base.
with security
vulnerabilities or
those considered
unsafe by industry
best practise.

V.B.6: The vendor’s source Redundant code The Security Request code metrics on
tree is maintained to makes a product Declaration makes how much duplicated
Redundant and
a level that there is more difficult to clear statements code exists within the
duplicate code
limited redundant or understand and about how the source tree
duplicate code. maintain. Increases vendor produces
the likelihood that code to reduce
security critical complexity and
changes won’t be increase
applied to access the maintainability.
product.

V.B.7: The vendor’s source Code clarity reduces The Security

tree is maintained to the risk of error or Declaration makes
File structure
a level where code vulnerability and clear statements
complexity is makes issues easier to about how the
minimised, and spot. vendor produces
functions perform code to reduce
single, clear actions. complexity and
increase
maintainability.

V.B.8: There is no Engineering debug The Security Ask the vendor to

engineering debug functionality may be Declaration makes demonstrate that
Debug
functionality present used by an attacker clear statements inclusion of debug
functionality
within the vendor’s to exploit a product. confirming that no functionality within a
released products engineering debug release build results in a
that could weaken or functionality is build failure.
bypass the product’s present within a
security mechanisms. released version of a
product.

V.B.9: The source tree has Commenting helps The Security

suitable and ensure product can Declaration makes
Comments
understandable be easily supported in clear statements
comments through it, the future and speeds about how the
explaining what the up vulnerability fixes. vendor produces
code is for and code to reduce
why it performs its complexity and
actions. increase
maintainability.

V.C: Protected development and build environments

14 Vendor security assessment

Topic Security expectation Why it matters Evaluation: security Evaluation: customer or Evaluation: customer
declaration 3rd party spot checks or 3rd party lab test

V.C: The NCSC expects A secure environment The Security

the product is helps to maintain the Declaration describes
Overall aim
developed within a integrity of the how the vendor
secure environment. product and reduces maintains the
the risk of supply integrity of its
chain attack. products through
securing the
development and
build environments.

V.C.1: Development This protects the Ask to see details of

environment is development penetration-tests or
Segregation of
segregated from environment from red team3 exercises,
development
corporate network compromise via where the objective was
environment
and protected from straightforward to modify the vendor’s
the internet. attacks. codebase or
development
environment.

V.C.2: Build environment is This protects the Ask to see details of

segregated from build environment penetration-tests or
Segregation of
corporate network from compromise via red team exercise ,
build
and protected from straight-forward where the objective was
environment
the internet. Very few attacks. to modify the vendor’s
people can make build environment.
changes.

V.C.3: Build environments Simple build The Security For a customer-selected

are simple, and the environments and an Declaration describes product release, the
Build
build process is automated build how the vendor vendor explains the build
environments
automated. process makes the build process can be environment and its
and automation
product build understood and dependencies, and
easier to understand, maintained. demonstrates the
less likely to have automated process via
errors and reduces which a build is
the risk of performed.
compromise.

V.C.4: Only individuals with Minimising access The Security The vendor demonstrates
a need have access reduces the impact of Declaration describes that access to the
Role-based
to the internal code a malicious insider. how the vendor development and build
access
base, and access is enforces role-based environment is limited.
controlled and limited access controls to its
based on role. development and
build environments.

V.C.5: All code is Code review is The Security For any change made to -
independently essential to Declaration describes the code, the vendor can
Code review
reviewed prior to maintaining coding how and when the demonstrate how that
acceptance. standards, and to vendor caries out change was reviewed or
Feedback processes reduce the risk due to internal code review audited.
exist. a malicious insider. and audit.

3
A ‘red-team’ exercise is one where responsible penetration testers are seeking to gain access to an asset within the vendor’s network, such
as their development environment.
 Vendor security assessment 15

Topic Security expectation Why it matters Evaluation: security Evaluation: customer or Evaluation: customer
declaration 3rd party spot checks or 3rd party lab test

V.C.6: All builds of released Replicated builds The Security The vendor reproduces a A released build and a
software can be allow the vendor to Declaration makes previous build and reproduced build are
Repeatable
replicated at a future demonstrate what clear statements confirms that it is compared to verify
builds
date. components were about how the functionally identical to a functional equivalence.
included in a past vendor maintains version that was released.
build. their build
The vendor demonstrates
environment and
Tracking of each that they have retained
code base to enable
build, what copies of any external
repeated builds with
components are built dependencies necessary
a minimal number of
into it and which for the build.
differences – with an
versions of the
explanation for each
components were
difference.
used is critical to
verifying the integrity
of a build.
16 Vendor security assessment

Topic Security expectation Why it matters Evaluation: security Evaluation: customer or Evaluation: customer
declaration 3rd party spot checks or 3rd party lab test

V.D: Exploit mitigations

V.D: The vendor Each of these The Security

implements standard mitigations has a Declaration describes
Overall aim
security mitigations demonstrable the vendor’s policy
used in a modern positive impact on with respect to the
product. the security of a use of defensive
product by helping to security techniques.
mitigate well known
vulnerability classes.
Modern platforms,
operating systems,
development
languages, libraries
and development
tools regularly offer
security enhancing
technologies to both
minimise the
occurrence of security
defects, and to
minimise their impact
should they occur.

V.D.1: The vendor makes Widely used to make The Security Verify that heap
use of modern heap it more difficult for an Declaration states mitigations are enabled
Heap
protection mitigations attacker to exploit whether the vendor’s by (automatically)
protections
to help prevent heap- any security issues. products use heap inspecting the product
based memory protections for this mitigation.
corruption attacks throughout their
against the product. product.

V.D.2: The vendor only ships Widely used to make The Security Verify that stack
executable code that it more difficult for an Declaration states mitigations are enabled
Stack
has been compiled attacker to exploit whether the vendor’s by (automatically)
protections
using modern stack any security issues. products use stack inspecting the product
mitigations. protections for this mitigation.
throughout their
product.

V.D.3: The vendor supports Widely used to make The Security Verify that data
hardware-enforced it more difficult for an Declaration states execution prevention
Data execution
data execution attacker to exploit whether the vendor’s mitigations are enabled
prevention
prevention (for any security issues. products use by (automatically)
example DEP or NX). hardware-enforced inspecting the product
data execution for this mitigation.
prevention
throughout their
product.

V.D.4: The vendor only ships Widely used to make The Security Verify that address
executable code that it more difficult for an Declaration states space layer
Address space
has been compiled attacker to exploit whether the vendor’s randomisation
layout
using modern ASLR any security issues. products use ASLR mitigations are enabled
randomisation
techniques. throughout their by (automatically)
product. inspecting the product
for this mitigation.
 Vendor security assessment 17

Topic Security expectation Why it matters Evaluation: security Evaluation: customer or Evaluation: customer
declaration 3rd party spot checks or 3rd party lab test

V.D.5: The vendor’s product Widely used to make The Security Verify that there are no
will have no memory it more difficult for an Declaration states executables that map
Memory
pages mapped by attacker to exploit whether the vendor’s memory pages as both
mapping
default as both any security issues. products have any writable and executable
protections
‘Writable’ and read-write memory by (automatically)
‘Executable’. This pages. If any Just-In- inspecting the product.
excludes areas of the Time code
code required to do compilation is
Just-In-Time code required, this should
compilation. be described in the
security declaration.

V.D.6: The vendor follows a Products that run at The Security Verify that executable
‘least privilege’ higher privilege levels Declaration states the code running on the
Least Privilege
methodology when than required can vendor’s ‘least vendor’s platform runs
code
developing and provide a route for privilege’ with the least level of
executing code within attackers to exploit a methodology. privilege required.
their products. host system.
Verify that any
The vendor ensures privileged executables
that their product drop privilege after
only runs at or completing their
requests the privileged task.
minimum privilege
level required for it to
fulfil its advertised
purpose. If higher
privilege levels are
ever required, then
the product
implements
segregations to
elevate privilege for
the specific task.

V.D.7: The vendor has plans Product security Explore the vendor’s
to continue to needs to continue to future security roadmap,
Security
improve its product’s evolve to keep pace discussing how the
improvement
security. As an with the threat vendor's product security
and secure
example, this may environment. will increase over time.
execution
include detailing how
environments
and when they plan
to implement secure
execution
environments4.

V.E: Secure updates and software signing

V.E: The source of the Reduces the risk of

code that runs on the supply chain attack
Overall aim
device is known, and between code
the mechanisms to production by the
change the code on vendor, and delivery
the device are secure. to the device.

4
Secure execution environments are a significant upcoming security technology that increases product security by enabling execution of
sensitive workloads on untrusted hardware.
18 Vendor security assessment

Topic Security expectation Why it matters Evaluation: security Evaluation: customer or Evaluation: customer
declaration 3rd party spot checks or 3rd party lab test

V.E.1: Vendor’s software Signing of software The Security Test that shipped
and firmware is and firmware Declaration describes executable code
Software and
digitally signed. provides strong whether software and (binaries, scripts, etc)
firmware
evidence that the firmware are digitally are digitally signed
signing
developer produced signed, and any using the vendor’s
the code. processes for public code signing
allowing customers to certificate by
deploy their own automatically
code. inspecting each file.

V.E.2: Software signatures Allows the device to The Security Test that a modification
are verified before check the source of Declaration describes of a signed binary
Signature
binaries are executed. the code. how signatures are results in the device
verification
checked prior to code refusing to run the
execution. States binary.
whether that check is
hardware backed.

V.E.3: Updates are delivered Using a secure The Security Perform the update
via a secure channel channel reduces the Declaration describes process, verifying that
Secure update
that is mutually risk of an attacker the security updates are delivered
authenticated exploiting the update properties of the over a secure channel.
between the device mechanism. update mechanism.
and the update
server.

V.E.4 Built-in detection Publicly known The Security Test that a signed
capabilities alert vulnerabilities in an Declaration describes update which is of an
Downgrade
whenever software is older version of the how downgrade older version to that
protection
downgraded during product are common attacks are prevented currently installed
an install process. causes of exploit and by the vendor. produces a log
compromise. message or other alert
likely be seen by the
system administrator.

V.F: Hardware roots of trust and secure boot

V.F: The vendors use a A hardware root of The Security

secure hardware root trust enables the Declaration describes
Overall aim
of trust within their vendor to use the vendor’s
products. These are modern security approach to the
commonly referred to mitigations such provision of
as one of the secure boot and code hardware-backed
following: TEE signing. security.
(Trusted Execution
Environment), TPM
(Trusted Platform
Module), or DSC
(Dedicated Security
Component).

V.F.1: The equipment A hardware root-of- The Security - Test that private keys
contains a hardware trust is necessary to Declaration states the associated with identity
Hardware root-
root-of-trust for provide hardware- presence and or device secrets are
of-trust
identity and storage. backed functionality properties of any not stored in the
that cannot be hardware root of trust filesystem in clear text.
remotely modified by with the products.
an attacker.
 Vendor security assessment 19

Topic Security expectation Why it matters Evaluation: security Evaluation: customer or Evaluation: customer
declaration 3rd party spot checks or 3rd party lab test

V.F.2: Each product will Secure boot makes it The Security - Verify that the product
support a secure harder for any Declaration describes can be returned to a
Secure Boot
boot process, compromise of the the vendor’s support known good state.
initiated by the device to persist after
of a secure boot, and
Test that the device fails
hardware root-of- a power cycle. how the vendor’s
to boot should one or
trust (V.F.1) to bring products can be
Should devices be more of the signed
the equipment into a returned to a known
compromised, secure binaries or scripts used
known good state on good state in the
boot is required to during the boot
restart. event of compromise.
restore trust in the process be modified.
equipment.
Otherwise, the
equipment may need
to be scrapped.

V.F.3: Each compute With physical access, Test that JTAG

element on a product debug interfaces like equipment cannot
Securing JTAG
will have debug JTAG can be used to establish
interfaces (such as circumvent the communication with
JTAG and UART) integrity of a product any of the system’s
access disabled. or steal device JTAG TAP controllers.
secrets.

V.G: Security testing

V.G: The vendor rigorously Through security The Security

tests the security of testing and Declaration describes
Overall aim
their products prior resolution, the the vendor’s
to release. number of approach to security
vulnerabilities in the testing across its
product is reduced, product range.
as is the risk of
exploitation.

V.G.1: Once developed, This ensures that The Security For a customer-chosen The customer, or third
extensive security testing is at a scale Declaration describes product release, ask to party, applies their own
Automated
tests are comparable to that the automated tests see the test results from automated tests where
testing
automatically run employed by an run against every automated testing. possible.
against all versions of attacker. product version.
applicable products.

V.G.2: Developers cannot Developers may seek The Security For a customer-chosen
modify the build to bypass checks if Declaration states product release, ask to
Testing rigour
environment to hide permitted, leading to whether tests can be see build results. Verify
or disregard build more vulnerable bypassed. that the results do not
issues, or issues products. highlight issues that
detected by should not be accepted
automated tests. in a released build.
Failing builds are
automatically
rejected.

Therefore, code used

in released products
do not create any
compiler errors or
security related
warnings during
build.

V.G.3: Security functionality If security The Security For a customer-chosen Repeat tests of security
is tested to functionality is mis- Declaration states product release, ask to functionality.
Security Testing
demonstrate correct implemented, the whether security see the results from
operation. device will likely be testing is performed security testing. Verify
vulnerable. to verify correct that issues were resolved,
operation. including root-causes.
20 Vendor security assessment

Topic Security expectation Why it matters Evaluation: security Evaluation: customer or Evaluation: customer
declaration 3rd party spot checks or 3rd party lab test

V.G.4: Extensive negative By testing with The Security For a customer-chosen Perform negative tests
testing is performed extensive negative Declaration states product release, ask to against the product,
Negative
against every product test cases, the vendor whether negative see the test results from ideally using a distinct
testing5
release, including a is more likely to catch testing is performed negative testing. Verify toolset to the vendor.
wide range of easy-to-detect issues. and describes the that issues were resolved,
potential failure scale of this testing. including root-causes.
cases, inappropriate
message sequencing
and malformed
messages.

V.G.5: Fuzzing is performed A specific form of The Security For customer-chosen Perform fuzzing of the
against the product, negative testing, the Declaration states product release, ask to product, ideally using a
Fuzzing 6
especially focusing on vendor tests their whether fuzz testing see the test results from distinct toolset to the
interfaces which cross products against is performed and fuzzing, alongside data vendor.
security boundaries. randomly-generated, indicates the scope of on code coverage. Verify
The approach is malformed data, to this testing. that issues were resolved,
sophisticated catch easy-to-detect including root-causes.
enough to ensure issues.
that a high
proportion of code is
tested.

V.G.6: External security By subjecting the The Security Ask to see the results
research teams device to an external Declaration contains from external tests. Verify
External testing
perform testing third party, explicit details about that issues were resolved,
against a selection of vulnerabilities are how the vendor including root-causes.
major product more likely to be partners with external
releases. Some of this detected and labs and academics
testing is un-scoped. remediated. to ensure the security
of their products is
independently tested.

V.G.7: The vendor has a Applying DAST The Security Ask to see the results Perform dynamic
DAST solution during testing can Declaration states from the DAST suite. application security
Dynamic
integrated into the identify different how the vendor Verify that issues were testing on the product,
application
vendor’s test process. types of performs dynamic resolved, including root- ideally using a distinct
security testing
vulnerabilities to that application security causes. toolset to the vendor.
(DAST)7
of fuzzing and testing.
negative testing.

V.H: Secure management and configuration

V.H: Any product can be Insecurely configured The Security

easily set up to run products are more Declaration describes
Overall aim
securely. likely to be exploited. the vendor’s
approach to helping
operators securely
configure products.
This includes whether
products are released
in a ‘secure’
configuration.

5
‘Negative Testing’ is the testing of failure conditions to check they are handled gracefully by the equipment.
6
‘Fuzzing’ is a testing technique that involves providing invalid, unexpected, or random data to check that these inputs are handled gracefully
by the equipment.
7
Dynamic Application Security Testing (DAST) a procedure that actively investigates running applications with penetration tests to detect
possible security vulnerabilities.
 Vendor security assessment 21

Topic Security expectation Why it matters Evaluation: security Evaluation: customer or Evaluation: customer
declaration 3rd party spot checks or 3rd party lab test

V.H.1: The product can be Insecurely configured The Security Verify that guidance is Test that the
easily hardened into products are more Declaration states provided on secure hardening guide can be
Product
a secure likely to be exploited. whether products can configuration for easily deployed as-is to
hardening
configuration. be easily hardened provided products. the product without
Documentation exists into a secure impacting necessary
to help customers configuration. functions.
perform this
Test that alerts are
hardening process.
created should the
Alerts are created
device be taken out of
should the device be
the hardened state.
taken out of the
hardened state.

V.H.2: The product can be Proprietary protocols Analyse traffic from the
configured to only do not allow for equipment to ensure
Protocol
use standardised thorough, that there are no
Standardisation
protocols. independent security proprietary protocols in
testing, or correct use.
behaviour to be
understood by the
customer.

V.H.3: By default, the Without secure The Security Test that no weak or
product is configured protocols and user- Declaration confirms deprecated security
Management
to only use up-to- based access it is not whether the product protocols are enabled
plane security
date, secure possible to securely only uses secure on the management
protocols on the manage equipment management plane.
management plane. and associate protocols by-default.
administrative
changes with a
specific administrator.

V.H.4: Access to the This allows customers Test that the

management plane is to limit administrative management plane
Management
user-based and privilege and gives administrators
access
supports asymmetric- investigate potentially user-based access and
key-based (e.g. X.509 malicious changes. supports asymmetric-
certificates or SSH The use of key-based
keys). asymmetric key authentication.
based authentication
allows for more
secure authentication
and helps mitigate
the risk of password
sharing.

V.H.5: Secure protocols are To prevent the use of Test that there are no
used whenever insecure protocols, unencrypted protocols
No
possible (e.g. SSH which increases the and services are
unencrypted
and HTTPS). If an risk of exploitation. enabled by default on
protocols
unencrypted protocol the product.
is enabled, and a
Test that enabling an
secure alternative
unencrypted protocol
exists, the product
on the product results
warns the
in appropriate warnings
administrator, and
and alerts.
provides the option
to create a security
alert.
22 Vendor security assessment

Topic Security expectation Why it matters Evaluation: security Evaluation: customer or Evaluation: customer
declaration 3rd party spot checks or 3rd party lab test

V.H.6: The product does not Undocumented The Security Search for evidence of
have any administrative Declaration explicitly undocumented
No
undocumented accounts may be states whether there administrator accounts
undocumented
administrator exploited without are any in released products.
administrative
accounts. Examples customer awareness. undocumented
mechanisms
include, but are not administrative
limited to, hard accounts on the
coded passwords, product.
access key pairs (SSH
keys) or other
administrative access
tokens.

V.H.7: The product does not Undocumented The Security Search for evidence of
have any administrative Declaration explicitly undocumented
No
undocumented features may be states whether there administrator features
undocumented
administration exploited without are any in released products.
administrative
features. customer awareness. undocumented
features
administrative
features on the
product.

V.H.8: No default passwords Failure to disable any The Security Test that there are no
are left on the device non-unique or Declaration explicitly default credentials on
No default
after the initial setup. hardcoded accounts states how default the device after initial
credentials
renders the credentials are setup.
For clarity, this also
equipment highly removed from all
means there are no Scan products for
vulnerable to devices, and whether
administrative potential hardcoded
exploitation. hard-coded
accounts coded into password strings.
administrative
the vendor’s software.
accounts exist.

V.H.9: The vendor is explicit By helping The Security For a customer-chosen

about the threats to understand the Declaration describes product, explore the
Good Practice
the equipment that security decisions the vendors vendor’s product security
Guidance
they have sought to taken by the vendor, approach to security analysis, and consider
mitigate, and those and set up the analysis, and how whether the vendor has
they have not. The equipment securely, they support understood the risk
vendor provides security mistakes are customers in environment and
detailed configuration less likely to be made. minimising risk. established appropriate
and notes on how the mitigations.
equipment can be
protected in
networks.

V.J: Vulnerability and Issue Management

V.J: Effective processes Products are most The Security

exist to manage vulnerable from when Declaration describes
Overall aim
security issues and an issue is discovered the vendors
vulnerabilities. These until it is patched. approach to resolving
issues are quickly and Effective issue issues.
effectively resolved. management reduces
this risk.

V.J.1: The vendor has a If issues are not The Security Assuming a software Test whether a
process for issuing resolved across all Declaration provides component is vulnerable, previously reported and
Issue tracking
remediation. This versions of all the vendor’s ask to see all products resolved vulnerability
and
ensures the product lines, the timescales on the that contain that may still be exploited
remediation
vulnerability is same issue may resolution of security component. across a range of
resolved in all continue to be issues and describes products.
impacted products. exploitable in some how the vendor
Vulnerabilities are product version. traces vulnerabilities
patched within across all products.
appropriate
timeframes.
 Vendor security assessment 23

Topic Security expectation Why it matters Evaluation: security Evaluation: customer or Evaluation: customer
declaration 3rd party spot checks or 3rd party lab test

V.J.2: For issues, the vendor Proper vulnerability For a customer-chosen

identifies the root management vulnerability, the vendor
Issue
cause analysis of the requires the vendor can provide details of the
comprehension
issue and is able to to understand its own vulnerability, the root
.
detail the origin of product and quickly cause of the vulnerability,
the vulnerability. assess impact of a and how and when the
vulnerability. vulnerability was correctly
resolved.

V.J.3: The vendor provides This allows external The Security Explore how the vendor
a publicly advertised people and Declaration describes resolved a previously
Vulnerability
route for disclosure of organisations to how vulnerabilities reported issue.
reporting
security issues that responsibly disclose may be reported to
links into their security issues to the the vendor.
vulnerability vendor.
management
process.

V.J.4: The vendor is In the sector, most The Security

transparent about security issues are Declaration provides
Issue
their patching of patched without metrics on security
transparency
security issues. customers becoming issues, both reported
aware of their and resolved.
existence. This makes
A list of all patched
it difficult for
security issues in the
customers to judge
product is available.
risk.

V.J.5 The vendor has set Product security is The Security Ask the vendor for When vulnerabilities are
up the PSIRT not restricted to R&D. Declaration describes Product Security Incident found during lab
Product
structures within its PSIRT brings together how to contact Response plan of testing, report these to
Security
organisation. R&D, QM, TAC, OPS vendor's PSIRT team. selected release. the PSIRT team and
Incident
to be responsible for verify that the vendor’s
Response Team
secure product response is effective.
(PSIRT)8
operation by
customers.

8
Product Security Incident Response Team (PSIRT) is the common name for the vendor’s team that handles the receipt, investigation and
public reporting of security vulnerability information relating to the vendor’s products.