michaelh/zephyr
1
0
Fork 0
Code Releases Activity

doc: security: Add ETSI 303 645 standard

Browse source 
Add a new section for standards with ETSI 303-645 in
the security related documentation.

Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
This commit is contained in:
Flavio Ceolin 2023-03-08 21:43:44 -08:00 • committed by Carles Cufí
commit 8d446d345b
3 changed files with 754 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

1
doc/security/index.rst
View file

@ -16,3 +16,4 @@ for ensuring security is addressed within the Zephyr project.
sensor-threat.rst
hardening-tool.rst
vulnerabilities.rst
standards/index.rst

731
doc/security/standards/etsi-303645.rst Normal file
View file

@ -0,0 +1,731 @@
.. _etsi_303645:
ETSI 303-645
############
`ETSI EN 303 645`, also known as "Cyber Security for Consumer Internet
of Things: Baseline Requirements," is a standard developed by the
European Telecommunications Standards Institute (ETSI).
The standard includes provisions for secure software updates, data
protection, secure communication, and the minimization of exposed
attack surfaces, among other things. It is part of a broader effort to
address the challenges and risks associated with IoT devices.
Full version of the standard can be found `here <https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf>`_.
Terminology
***********
.. list-table:: ETSI 303645 terminology
:widths: 17 43
* - administrator
- user who has the highest-privilege level possible for a user of the device,
which can mean they are able to change any configuration related to the intended
functionality.
* - associated services
- digital services that, together with the device, are part of the overall consumer
IoT product and that are typically required to provide the product's intended
functionality.
* - authentication mechanism
- method used to prove the authenticity of an entity.
* - authentication value
- individual value of an attribute used by an authentication mechanism.
* - best practice cryptography
- cryptography that is suitable for the corresponding use case and has no
indications of a feasible attack with current readily available techniques.
* - constrained device
- device which has physical limitations in either the ability to process data, the
ability to communicate data, the ability to store data or the ability to interact
with the user, due to restrictions that arise from its intended use.
* - consumer
- natural person who is acting for purposes that are outside her/his trade,
business, craft or profession.
* - consumer IoT device
- network-connected (and network-connectable) device that has relationships to
associated services and are used by the consumer typically in the home or as
electronic wearables.
* - critical security parameter
- security-related secret information whose disclosure or modification can compromise
the security of a security module.
* - debug interface
- physical interface used by the manufacturer to communicate with the device during
development or to perform triage of issues with the device and that is not used as part
of the consumer-facing functionality
* - defined support period
- minimum length of time, expressed as a period or by an end-date, for which a
manufacturer will provide security updates.
* - device manufacturer
- entity that creates an assembled final consumer IoT product, which is likely to contain
the products and components of many other suppliers.
* - factory default
- state of the device after factory reset or after final production/assembly.
* - initialization
- process that activates the network connectivity of the device for operation and
optionally sets authentication features for a user or for network access.
* - initialized state
- state of the device after initialization.
* - IoT product
- consumer IoT device and its associated services.
* - isolable
- able to be removed from the network it is connected to, where any functionality loss
caused is related only to that connectivity and not to its main function; alternatively,
able to be placed in a self-contained environment with other devices if and only if the
integrity of devices within that environment can be ensured
* - logical interface
- software implementation that utilizes a network interface to communicate over the network
via channels or ports.
* - manufacturer
- relevant economic operator in the supply chain (including the device manufacturer).
* - network interface
- physical interface that can be used to access the functionality of consumer IoT via a network.
* - owner
- user who owns or who purchased the device.
* - personal data
- Any information relating to an identified or identifiable natural person.
* - physical interface
- physical port or air interface (such as radio, audio or optical) used to communicate with the
device at the physical layer.
* - public security parameter
- security related public information whose modification can compromise the security of a
security module.
* - remotely accessible
- intended to be accessible from outside the local network.
* - security module
- set of hardware, software, and/or firmware that implements security functions.
* - security update
- software update that addresses security vulnerabilities either discovered by or reported
to the manufacturer.
* - sensitive security parameters
- critical security parameters and public security parameters.
* - software service
- software component of a device that is used to support functionality.
* - telemetry
- data from a device that can provide information to help the manufacturer identify issues
or information related to device usage.
* - unique per device
- unique for each individual device of a given product class or type.
* - user
- natural person or organization.
Provisions Assessment
*********************
The following table is a self-assessment using Table B.1 from ETSI EN
303 645, specifically focusing on the Zephyr RTOS as a component
within IoT products.
According with ETSI 303 645, table B.1 provides a mechanism to give information
about the implementation of the provisions presented in the standard. Zephyr has
adopted the following notations used in the standard:
.. list-table:: ETSI 303645 Table B.1 notations
:widths: 17 43
* - M
- the provision is a mandatory requirement
* - R
- the provision is a recommendation
* - M C
- the provision is a mandatory requirement and conditional
* - R C
- the provision is a recommendation and conditional
* - Y
- The provision is supported by Zephyr
* - N
- The provision is not supported by Zephyr
* - N/A
- The provision is not applicable to Zephyr or it is product makers responsibility
.. list-table:: ETSI 303645 provisions assessment using table B.1
:header-rows: 1
:widths: 17 63 17 63 63
* - Provision
- Description
- Status
- Support
- Detail
.. _ETSI_Provision_5_1_1:
* - Provision 5.1-1
- Where passwords are used and in any state other than the
factory default, all consumer IoT device passwords shall be
unique per device or defined by the user.
- M C
-
-
.. _ETSI_Provision_5_1_2:
* - Provision 5.1-2
- Where pre-installed unique per device passwords are used,
these shall be generated with a mechanism that reduces the
risk of automated attacks against a class or type of device.
- M C
-
-
.. _ETSI_Provision_5_1_3:
* - Provision 5.1-3
- Authentication mechanisms used to authenticate users against a
device shall use best practice cryptography, appropriate to
the properties of the technology, risk and usage.
- M
-
-
.. _ETSI_Provision_5_1_4:
* - Provision 5.1-4
- Where a user can authenticate against a device, the device
shall provide to the user or an administrator a simple
mechanism to change the authentication value used.
- M C
-
-
.. _ETSI_Provision_5_1_5:
* - Provision 5.1-5
- When the device is not a constrained device, it shall have a
mechanism available which makes brute-force attacks on
authentication mechanisms via network interfaces
impracticable.
- M C
-
-
.. _ETSI_Provision_5_2_1:
* - Provision 5.2-1
- The manufacture shall make a vulnerability disclosure policy publicly
available.
- M
-
-
.. _ETSI_Provision_5_2_2:
* - Provision 5.2-2
- Disclosed vulnerabilities should be acted on in a timely manner.
- R
-
-
.. _ETSI_Provision_5_2_3:
* - Provision 5.2-3
- Manufacturers should continually monitor for, identify and rectify security
vulnerabilities within products and services they sell, produce, have produced
and services they operate during the defined support period.
- R
-
-
.. _ETSI_Provision_5_3_1:
* - Provision 5.3-1
- All software components in consumer IoT devices should be securely updatable.
- R
-
-
.. _ETSI_Provision_5_3_2:
* - Provision 5.3-2
- When the device is not a constrained device, it shall have an update mechanism
for the secure installation of updates.
- M C
-
-
.. _ETSI_Provision_5_3_3:
* - Provision 5.3-3
- An update shall be simple for the user to apply.
- M C
-
-
.. _ETSI_Provision_5_3_4:
* - Provision 5.3-4
- Automatic mechanisms should be used for software updates.
- R C
-
-
.. _ETSI_Provision_5_3_5:
* - Provision 5.3-5
- The device should check after initialization, and then periodically, whether
security updates are available.
- R C
-
-
.. _ETSI_Provision_5_3_6:
* - Provision 5.3-6
- If the device supports automatic updates and/or update notifications, these
should be enabled in the initialized state and configurable so that the user
can enable, disable, or postpone installation of security updates and/or
update notifications.
- R C
-
-
.. _ETSI_Provision_5_3_7:
* - Provision 5.3-7
- The device shall use best practice cryptography to facilitate secure update mechanisms.
- M C
-
-
.. _ETSI_Provision_5_3_8:
* - Provision 5.3-8
- Security updates shall be timely.
- M C
-
-
.. _ETSI_Provision_5_3_9:
* - Provision 5.3-9
- The device should verify the authenticity and integrity of software updates.
- R C
-
-
.. _ETSI_Provision_5_3_10:
* - Provision 5.3-10
- Where updates are delivered over a network interface, the device shall verify
the authenticity and integrity of each update via a trust relationship.
- M
-
-
.. _ETSI_Provision_5_3_11:
* - Provision 5.3-11
- The manufacturer should inform the user in a recognizable and apparent manner
that a security update is required together with information on the risks
mitigated by that update.
- R C
-
-
.. _ETSI_Provision_5_3_12:
* - Provision 5.3-12
- The device should notify the user when the application of a software update
will disrupt the basic functioning of the device.
- R C
-
-
.. _ETSI_Provision_5_3_13:
* - Provision 5.3-13
- The manufacturer shall publish, in an accessible way that is clear and
transparent to the user, the defined support period.
- M
-
-
.. _ETSI_Provision_5_3_14:
* - Provision 5.3-14
- For constrained devices that cannot have their software updated, the rationale
for the absence of software updates, the period and method of hardware replacement
support and a defined support period should be published by the manufacturer in an
accessible way that is clear and transparent to the user.
- R C
-
-
.. _ETSI_Provision_5_3_15:
* - Provision 5.3-15
- For constrained devices that cannot have their software updated, the product
should be isolable and the hardware replaceable.
- R C
-
-
.. _ETSI_Provision_5_3_16:
* - Provision 5.3-16
- The model designation of the consumer IoT device shall be clearly recognizable,
either by labelling on the device or via a physical interface.
- M
-
-
.. _ETSI_Provision_5_4_1:
* - Provision 5.4-1
- Sensitive security parameters in persistent storage shall be stored securely by the device.
- M
-
-
.. _ETSI_Provision_5_4_2:
* - Provision 5.4-2
- Where a hard-coded unique per device identity is used in a device for security purposes,
it shall be implemented in such a way that it resists tampering by means such as physical,
electrical or software.
- M C
-
-
.. _ETSI_Provision_5_4_3:
* - Provision 5.4-3
- Hard-coded critical security parameters in device software source code shall not be used.
- M
-
-
.. _ETSI_Provision_5_4_4:
* - Provision 5.4-4
- Any critical security parameters used for integrity and authenticity checks of software
updates and for protection of communication with associated services in device software
shall be unique per device and shall be produced with a mechanism that reduces the risk
of automated attacks against classes of devices.
- M
-
-
.. _ETSI_Provision_5_5_1:
* - Provision 5.5-1
- The consumer IoT device shall use best practice cryptography to communicate securely.
- M
-
-
.. _ETSI_Provision_5_5_2:
* - Provision 5.5-2
- The consumer IoT device should use reviewed or evaluated implementations to deliver
network and security functionalities, particularly in the field of cryptography.
- R
-
-
.. _ETSI_Provision_5_5_3:
* - Provision 5.5-3
- Cryptographic algorithms and primitives should be updatable.
- R
-
-
.. _ETSI_Provision_5_5_4:
* - Provision 5.5-4
- Access to device functionality via a network interface in the initialized state should
only be possible after authentication on that interface.
- R
-
-
.. _ETSI_Provision_5_5_5:
* - Provision 5.5-5
- Device functionality that allows security-relevant changes in configuration via a
network interface shall only be accessible after authentication. The exception is for
network service protocols that are relied upon by the device and where the manufacturer
cannot guarantee what configuration will be required for the device to operate.
- M
-
-
.. _ETSI_Provision_5_5_6:
* - Provision 5.5-6
- Critical security parameters should be encrypted in transit, with such encryption
appropriate to the properties of the technology, risk and usage.
- R
-
-
.. _ETSI_Provision_5_5_7:
* - Provision 5.5-7
- The consumer IoT device shall protect the confidentiality of critical security
parameters that are communicated via remotely accessible network interfaces.
- M
-
-
.. _ETSI_Provision_5_5_8:
* - Provision 5.5-8
- The manufacturer shall follow secure management processes for critical security
parameters that relate to the device.
- M
-
-
.. _ETSI_Provision_5_6_1:
* - Provision 5.6-1
- All unused network and logical interfaces shall be disabled.
- M
-
-
.. _ETSI_Provision_5_6_2:
* - Provision 5.6-2
- In the initialized state, the network interfaces of the device shall minimize the
unauthenticated disclosure of security-relevant information.
- M
-
-
.. _ETSI_Provision_5_6_3:
* - Provision 5.6-3
- Device hardware should not unnecessarily expose physical interfaces to attack.
- R
-
-
.. _ETSI_Provision_5_6_4:
* - Provision 5.6-4
- Where a debug interface is physically accessible, it shall be disabled in software.
- M C
-
-
.. _ETSI_Provision_5_6_5:
* - Provision 5.6-5
- The manufacturer should only enable software services that are used or required for
the intended use or operation of the device.
- R
-
-
.. _ETSI_Provision_5_6_6:
* - Provision 5.6-6
- Code should be minimized to the functionality necessary for the service/device to operate.
- R
-
-
.. _ETSI_Provision_5_6_7:
* - Provision 5.6-7
- Software should run with least necessary privileges, taking account of both security
and functionality.
- R
-
-
.. _ETSI_Provision_5_6_8:
* - Provision 5.6-8
- The device should include a hardware-level access control mechanism for memory.
- R
-
-
.. _ETSI_Provision_5_6_9:
* - Provision 5.6-9
- The manufacturer should follow secure development processes for software deployed on
the device.
- R
-
-
.. _ETSI_Provision_5_7_1:
* - Provision 5.7-1
- The consumer IoT device should verify its software using secure boot mechanisms.
- R
-
-
.. _ETSI_Provision_5_7_2:
* - Provision 5.7-2
- If an unauthorized change is detected to the software, the device should alert the
user and/or administrator to the issue and should not connect to wider networks than
those necessary to perform the alerting function.
- R
-
-
.. _ETSI_Provision_5_8_1:
* - Provision 5.8-1
- The confidentiality of personal data transiting between a device and a service,
especially associated services, should be protected, with best practice cryptography.
- R
-
-
.. _ETSI_Provision_5_8_2:
* - Provision 5.8-2
- The confidentiality of sensitive personal data communicated between the device and
associated services shall be protected, with cryptography appropriate to the
properties of the technology and usage.
- M
-
-
.. _ETSI_Provision_5_8_3:
* - Provision 5.8-3
- All external sensing capabilities of the device shall be documented in an accessible
way that is clear and transparent for the user.
- M
-
-
.. _ETSI_Provision_5_9_1:
* - Provision 5.9-1
- Resilience should be built in to consumer IoT devices and services, taking into
account the possibility of outages of data networks and power.
- R
-
-
.. _ETSI_Provision_5_9_2:
* - Provision 5.9-2
- Consumer IoT devices should remain operating and locally functional in the case of a
loss of network access and should recover cleanly in the case of restoration of a
loss of power.
- R
-
-
.. _ETSI_Provision_5_9_3:
* - Provision 5.9-3
- The consumer IoT device should connect to networks in an expected, operational and
stable state and in an orderly fashion, taking the capability of the infrastructure
into consideration.
- R
-
-
.. _ETSI_Provision_5_10_1:
* - Provision 5.10-1
- If telemetry data is collected from consumer IoT devices and services, such as usage
and measurement data, it should be examined for security anomalies.
- R C
-
-
.. _ETSI_Provision_5_11_1:
* - Provision 5.11-1
- The user shall be provided with functionality such that user data can be erased from
the device in a simple manner.
- M
-
-
.. _ETSI_Provision_5_11_2:
* - Provision 5.11-2
- The consumer should be provided with functionality on the device such that personal
data can be removed from associated services in a simple manner.
- R
-
-
.. _ETSI_Provision_5_11_3:
* - Provision 5.11-3
- Users should be given clear instructions on how to delete their personal data.
- R
-
-
.. _ETSI_Provision_5_11_4:
* - Provision 5.11-4
- Users should be provided with clear confirmation that personal data has been deleted
from services, devices and applications.
- R
-
-
.. _ETSI_Provision_5_12_1:
* - Provision 5.12-1
- Installation and maintenance of consumer IoT should involve minimal decisions by the
user and should follow security best practice on usability.
- R
-
-
.. _ETSI_Provision_5_12_2:
* - Provision 5.12-2
- The manufacturer should provide users with guidance on how to securely set up their device.
- R
-
-
.. _ETSI_Provision_5_12_3:
* - Provision 5.12-3
- The manufacturer should provide users with guidance on how to check whether their
device is securely set up.
- R
-
-
.. _ETSI_Provision_5_13_1:
* - Provision 5.13-1
- The consumer IoT device software shall validate data input via user interfaces or
transferred via Application Programming Interfaces (APIs) or between networks in
services and devices.
- M
-
-
.. _ETSI_Provision_6_1_1:
* - Provision 6.1-1
- The manufacturer shall provide consumers with clear and transparent information about
what personal data is processed, how it is being used, by whom, and for what purposes,
for each device and service. This also applies to third parties that can be involved,
including advertisers.
- M
-
-
.. _ETSI_Provision_6_1_2:
* - Provision 6.1-2
- Where personal data is processed on the basis of consumers' consent, this consent
shall be obtained in a valid way.
- M C
-
-
.. _ETSI_Provision_6_1_3:
* - Provision 6.1-3
- Consumers who gave consent for the processing of their personal data shall have
the capability to withdraw it at any time.
- M
-
-
.. _ETSI_Provision_6_1_4:
* - Provision 6.1-4
- If telemetry data is collected from consumer IoT devices and services, the
processing of personal data should be kept to the minimum necessary for the
intended functionality.
- R C
-
-
.. _ETSI_Provision_6_1_5:
* - Provision 6.1-5
- If telemetry data is collected from consumer IoT devices and services, consumers
shall be provided with information on what telemetry data is collected, how it is
being used, by whom, and for what purposes.
- M C
-
-

22
doc/security/standards/index.rst Normal file
View file

@ -0,0 +1,22 @@
.. _security_standards:
Security standards and Zephyr
#############################
For a long period organizations were, more or less, left responsible to deal
with cyber security on their own. This included how to assess the scale and impact
of the problem and who to properly respond it.
Now, governments started looking how to regulate it and several regulations
and enforcements are rapidly emerging, and consequently, security standards. These
standards provide guidelines and outline requirements that products have to follow
to achieve compliance.
This section aims to identify and assess which Zephyr project components are impacted
by security standards requirements and provide the right information to enable
organizations developing certifiable products using Zephyr project.
.. toctree::
:maxdepth: 1
etsi-303645.rst