2016-12 Indispensable Sec Reqs

Indispensable baseline security requirements for the procurement of secure ICT products and services
v.1.0 | Public | December 2016
Indispensable baseline security requirements for the procurement of

secure ICT products and services
1 Introduction
The procurement of key ICT products or outsourced managed services may result in intentional or
unintentional security risks and incidents. In 2012 the EC drew up detailed guidelines1 on how to make
best use of ICT standards in tender specifications in the context of Action 23 of the Digital Agenda of
Europe and in 2013 issued a Communication on Standardisation and Public Procurement2 . Use of
standards promotes a level playing-field, allowing a broader range of participation, including SMEs, and
avoids “lock-in” to specific brands with proprietary features. However, due to the evolution of technology
in ICT and the lack of expertise to decide which standards are relevant and appropriate for the particular
ICT needs, it is not always the case that ICT procurements are standards-based.
Therefore, it is important to help procurers overcome these difficulties through common and sufficiently
generic minimum indispensable requirements that will cover the whole lifecycle of the procured product
or service and will eventually contribute to an appropriate (and desired) minimum level of security and
resilience. In this context, ENISA set up an Expert Group composed of experts nominated from Member
States to identify existing best practises and requirements and to use them to identify a set of
indispensable baseline security requirements. This collaborative approach will support all Digital Single
Market stakeholders to develop a more unified, integrated and cost-effective approach for standards-
based procurement of secure ICT products, and helps providers in specifically dealing with security risks
involved in the procurement and outsourcing processes.
1.1 Purpose
This document can be of use to suppliers and procurement officers when planning, offering and purchasing
ICT products, systems and services. It is meant as a practical, technologically neutral document with clear,
simple and sector-agnostic minimum necessary indispensable requirements for secure ICT products and
services. Any ICT product or service that fails to be compliant with one or more of the minimum security
requirements should be considered as insecure and therefore it shall not be purchased or put in operation
on the Digital Single Market (DSM). It focusses on a few indispensable conditions, commonly agreed
among experts and based on standards and best practices, but does not claim to cover completely and
sufficiently all possible security requirements. It is not intended to substitute existing security certifications
schemes and standards: instead it is a complementary security baseline.
1
http://ec.europa.eu/newsroom/dae/document.cfm?doc_id=2326
2
http://ec.europa.eu/newsroom/dae/document.cfm?doc_id=2327
European Union Agency for Network and Information Security

ENISA - The EU Cyber Security Agency 01
Follow the EU cyber security affairs of ENISA: www.enisa.europa.eu & Facebook, Twitter, LinkedIn, YouTube, RSS feeds
1.2 Approach
Secure
by
design
Secure Verifiably
by Secure
default
Secure
through
life
Figure 1: Four principles for supply and procurement
Figure 1 above depicts the four principles that were stated by the Expert Group as a basis for the
development of the indispensable requirements. Components of the system, the services that they and
the system use, and the services the system provides shall be secure:
• By design – the product, or service, has been conceived, designed and implemented to ensure the
key security properties are maintained: availability, confidentiality, integrity and accountability.
• By default – the product, or service, is supplied with the confirmed capability to support these
security properties at installation.
• Throughout their lifecycle – security should be maintained from initial deployment through
maintenance to decommissioning.
• And that each of the above principles should be verifiable.
The indispensable baseline security requirements are expressed as a limited collection of principles
written, as far as possible, in non-specialist terms – a set of “Commandments” listed in Section 2. In
addition, Section 3 provides explanations and examples than can be used for compliance checks.
1.3 Obligations for the Customer (Procurer)

The security requirements for the specific ICT system will have wider, or different, scope than those stated
in this baseline and will be identified by a risk-assessment that takes account of the desired system
objectives and the prevailing security landscape. The baseline may be sufficient but users of this guide
must ensure that security requirements beyond the baseline are fulfilled effectively by appropriate
measures.

2 Overview of Indispensable Baseline Security Requirements
Note: All the requirements presented below apply also to the supplier’s subcontractors or its third party
service providers.
The provider shall design and pre-configure the delivered product such that
Security by Design functionalities are based on well-established security practices and are
reduced to the strict minimum required for system operations.
The provider shall design and pre-configure the product according to the
least privilege principle, whereby administrative rights are only used when
Least Privilege
absolutely necessary, sessions are technically separated and all accounts will
be manageable.
The product shall provide and support strong authentication mechanisms for
Strong Authentication all accounts. If authentication is unsuccessful the product shall not allow any
user specific activities to be performed.
The product shall provide adequate level of protection for critical information
Asset Protection
assets during storage and transmission.
The provider shall give means to ensure that the product is genuine, cannot
Supply Chain Security be tainted during operation, and its integrity are warranted throughout the
product’s lifecycle.
The provider shall offer comprehensive and understandable documentation

about the overall design of the product, describing its architecture,
Documentation functionalities and protocols, their realisation in hardware or software
Transparency components, the interfaces and interactions of components with each other
and with internal and external services, in order to be able to implement and
use the product in the most secure way possible.

The provider shall be able to provide evidence that a managed security by

design approach has been adopted, including documented secure software
Quality Management
development, quality management and information security management
processes.
The provider shall guarantee support throughout the agreed lifetime of the
Service Continuity
product such that the system can work as agreed and is secure.
The provider shall accept that all contracts refer to EU Member State law and
only EU Member State law and place of jurisdiction in an EU Member State
EU Jurisdiction
country and only an EU Member State country, including those with
subcontractors.
The provider shall explicitly declare, justify and document, context and
Data Usage
purpose wise, all data collection and processing activities that take or may
Restriction
take place, including relevant legal obligations stipulating them.

3 Guidance on using the requirements

This Section provides more detailed explanation of requirements that the supplier shall address in
complying with the baseline requirements.
3.1 Security by Design
The provider shall design and pre-configure the delivered product such that functionalities are
based on well-established security practices and are reduced to the strict minimum required for
system operations.
 Functionalities that are not needed shall not be installed.

 Functionalities that are installed shall have no undocumented capabilities, especially not those that
run against the security and privacy interests of the operator (free from malware, spyware, hidden
functionalities, un-documented backdoors or any other unapproved or unwanted functionalities such
as non-authorised data forwarding).
 Logging and auditing functions shall be included and supported by design. They shall be based on open
interoperable standards and best practices in order to work properly with Security Information &
Event Management (SIEM) and logging and monitoring systems.
 The system shall log user activities as well as security relevant events and errors in a format that can
be evaluated and analysed during operations or afterwards. The log files shall be protected against
tampering.
 All systems shall provide a widely acceptable standard system time and possibility to sync it with an
external time source in order to achieve exactness of system time to the second.
 The supplier shall not use technologies, protocols and functionalities that are outdated or already
recognised as insecure (e.g. SSL 3.0, MD5, or RC4, among others)
 The complete system with all its components, i.e. including extensions and enhancements, must be
ready for mitigating known vulnerabilities.
3.2 Least Privilege
The provider shall design and pre-configure the product according to the least privilege principle,
whereby administrative rights are only used when absolutely necessary, sessions are technically
separated and all accounts will be manageable.
 An administrator shall be able to manage all accounts (incl. technical and service accounts) without
support from the provider.
 Every service and every user shall have by default only the minimal rights that are required for specific
activities.
 Every user shall obtain its own user account.
 Passwords shall be changeable in all cases by the operator.

 The password complexity must be configurable by the administrator:

 minimal password length;
 maximum password length (system must support at least up to 128 characters);
 minimum number of specific characters or character groups, e.g. small and capital letters,
numbers, special characters (incl. space), etc.;
 minimum and maximum usage period;
 prevention of re-use of previous passwords; and
 maximum number of password changes per time (e.g. per day).
3.3 Strong Authentication
The product shall provide and support strong authentication mechanisms for all accounts. If
authentication is unsuccessful the product shall not allow any user specific activities to be
performed.
 Applications shall have the capability to enforce rules or policies for identification and authorisation of
users that execute them.
 Access to data shall only be given after successful authentication and authorisation. Without successful
authentication and authorisation, the system shall not allow any activities.
 Service accounts shall not be usable for interactive logon.
3.4 Asset Protection
The product shall provide adequate level of protection for critical information assets during
storage and transmission.
 Physical assets are the products that the provider supplies to the operator to be installed, including
equipment of any kind, documentation, and premises.
 Logical assets are the information generated by applications, stored, and communicated between
components of the system.
 Physical and logical assets shall be verifiably protected during design, manufacture, delivery,
operation, and decommissioning.
 No cryptographic means shall be used if there are indications that they have been vulnerable to
cryptanalysis.
 Sensitive data (e.g. credentials) may be stored in the system respectively transmitted only in encrypted
form
 Only established and well-known encryption algorithms may be used and encryption key lengths,
which are considered as safe according to the state-of-art. Proprietary encryption algorithms are not
allowed.

 The implementation must be done based on well-established encryption libraries to avoid

implementation weaknesses.
 The key generation must create secure keys and keys must be stored securely.
3.5 Supply Chain Security
The provider shall give means to ensure that the product is genuine, cannot be tainted during
operation, and its integrity are warranted throughout the product’s lifecycle.
 The authenticity checking method(s) of the product shall be capable of tracing back software and/or
hardware components to their genuine sources.
 The authenticity checking method of the product shall protect the properly authorized configuration
information assets of the system.
 The integrity checking method shall be capable of verifying the correctness of all compatibility and
dependability requirements in the product.
 Ongoing authenticity and integrity checks during operations shall detect and indicate any unauthorized
change in the configuration of the system.
3.6 Documentation Transparency
The provider shall offer comprehensive and understandable documentation about the overall
design of the product, describing its architecture, functionalities and protocols, their realisation
in hardware or software components, the interfaces and interactions of components with each
other and with internal and external services, in order to be able to implement and use the
product in the most secure way possible.
 The documentation shall be updated securely without the need for a permanent reference to external
servers.
 The documentation shall be updated when there are major changes to design or functionality.
 Users shall be made aware of changes to documentation and encouraged to switch to the new
documentation set.
3.7 Quality Management
The provider shall be able to provide evidence that a managed security by design approach has
been adopted, including documented secure software development, quality management and
information security management processes.

 The provider should possess a current valid security certification in the relevant area or something
equivalent (e.g. development, production), such as ISO27001 or corresponding).
 At least, a rationale of fulfilment of requirements addressed by such security or quality assurance
certifications should be available
 The provider shall be able to provide the relevant information security directives which are applicable
to its product/service.
3.8 Service Continuity
The provider shall guarantee support throughout the agreed lifetime of the product such that
the system can work as agreed and is secure.
 The provider shall guarantee:

 A minimum lifecycle during which support is assured.
 An ongoing research for potential vulnerabilities (e.g. a responsible disclosure program).
 If critical vulnerabilities (according to their CVE rating) get known, the provider is obliged to check
in a timely manner and at his own expense, whether his product is affected by the weakness and
to inform the operator of the result.
 Timely provisioning of security patches or other appropriate risk mitigation measures, when new
vulnerabilities get known. As a first remediation step the provider should at least respond with a
remediation plan at the latest within seven (7) working days. The plan shall indicate the timeframe for
resolving the vulnerability.
3.9 EU Jurisdiction
The provider shall accept that all contracts refer to EU Member State law and only EU Member
State law and place of jurisdiction in an EU Member State country and only an EU Member State
country, including those with subcontractors.
 The provider must inform the operator about non-EU laws that it is obliged to obey.
 The provider shall inform the operator about all countries’ laws that apply to the operator by using its
product and services.
3.10 Data Usage Restriction
The provider shall explicitly declare, justify and document, context and purpose wise, all data
collection and processing activities that take or may take place, including relevant legal
obligations stipulating them.

 The provider shall inform the operator about non-EU laws that must be obeyed concerning data
collection or forwarding.
 The provider and the operator shall agree on the use of the Traffic Light Protocol (TLP) when sharing
security relevant information between operator, provider, supplier(s), other operators, end users and
the general public.
4 Conclusions
This document introduced the need for a set of indispensable baseline security requirements that will be
used by procurers and suppliers of ICT systems and services. The approach to developing such
requirements was outlined along to the requirements themselves followed by clarifying examples of
detailed issues that must be addressed. Envisioned next steps include consultation with European Cyber
Security Organisation (ECSO) community as the established representative of private sector from all
sectors, to initiate a broader discussion, structured feedback and improvements in order to find consensus
on the applicability of this document. Subject to advice from the community, future work could include a
mapping of the baseline requirements to a catalogue of relevant standards, and further detail on the
verification that ICT products are secure: by design, by default, and throughout their life.
Contact
For queries in relation to this paper, please use [email protected]
Acknowledgements
ENISA would like to thank the following members of the Expert Group for their active engagement and
support throughout this activity: Mr. Wolfgang Schwabl - A1 Telekom Austria AG (AT), Mr. Thomas
Stubbings - TSMC (AT), Mr. Aurélien Leteinturier - ANSSI (FR), Mr. Tobias Mikolasch - BSI (DE), Mr. Martin
Konecny - NBU (CZ), Ms. Gema Carbonell - CCN (ES), Mr. Rob Huisman - NINCSA (NL) and Ms. Heidi Kivekäs
- FICORA (FI).


2016-12 Indispensable Sec Reqs

Uploaded by

Copyright:

Available Formats

2016-12 Indispensable Sec Reqs

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

2016-12 Indispensable Sec Reqs

Uploaded by

Copyright:

Available Formats

Indispensable baseline security requirements for the procurement of secure ICT products and services

v.1.0 | Public | December 2016

Indispensable baseline security requirements for the procurement of

European Union Agency for Network and Information Security

Figure 1: Four principles for supply and procurement

1.3 Obligations for the Customer (Procurer)

European Union Agency for Network and Information Security

2 Overview of Indispensable Baseline Security Requirements

The provider shall offer comprehensive and understandable documentation

European Union Agency for Network and Information Security

The provider shall be able to provide evidence that a managed security by

European Union Agency for Network and Information Security

3 Guidance on using the requirements

3.1 Security by Design

 Functionalities that are not needed shall not be installed.

3.2 Least Privilege

European Union Agency for Network and Information Security

 The password complexity must be configurable by the administrator:

3.3 Strong Authentication

3.4 Asset Protection

European Union Agency for Network and Information Security

 The implementation must be done based on well-established encryption libraries to avoid

3.5 Supply Chain Security

3.6 Documentation Transparency

3.7 Quality Management

European Union Agency for Network and Information Security

3.8 Service Continuity

 The provider shall guarantee:

3.10 Data Usage Restriction

European Union Agency for Network and Information Security

European Union Agency for Network and Information Security

You might also like