ETSI en - 303645v020100v

Machine Translated by Google
Borrador final ETSI EN 303 645 V2.1.0 (2020-04)
ESTÁNDAR EUROPEO
CIBERNÉTICO;
Seguridad cibernética para Internet de las cosas del consumidor:

Requisitos de referencia
2 Borrador final ETSI EN 303 645 V2.1.0 (2020-04)
Referencia
REN/CIBER-0048
Palabras
clave ciberseguridad, IoT, privacidad
BÚSQUEDA
650 Camino de las luciérnagas

F-06921 Sophia Antipolis Cedex - FRANCIA
Teléfono: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret No. 348 623 562 00017 - NAF 742 C

Organización sin fines de lucro registrada en el
Subprefectura de Grasse (06) N° 7803/88
Noticia importante
El presente documento puede descargarse de: http://

www.etsi.org/standards-search
El presente documento puede estar disponible en versiones electrónicas y/o impresas. El contenido de las versiones electrónicas y/o impresas del
presente documento no se modificará sin la autorización previa por escrito de ETSI. En caso de cualquier diferencia existente o percibida en los contenidos
entre dichas versiones y/o en forma impresa, la versión prevaleciente de un entregable de ETSI es la que se pone a disposición del público en formato
PDF en www.etsi.org/deliver.
Los usuarios del presente documento deben saber que el documento puede estar sujeto a revisión o cambio de estado.
La información sobre el estado actual de este y otros documentos del ETSI está disponible en https://
portal.etsi.org/TB/ETSIDeliverableStatus.aspx
Si encuentra errores en el presente documento, envíe su comentario a uno de los siguientes servicios: https://portal.etsi.org/
People/CommiteeSupportStaff.aspx
Notificación de derechos de autor
Ninguna parte puede ser reproducida o utilizada de ninguna forma o por ningún medio, electrónico o mecánico, incluidas fotocopias y microfilmes,
excepto con la autorización por escrito de ETSI.
El contenido de la versión PDF no se modificará sin la autorización por escrito de ETSI.
Los derechos de autor y la restricción anterior se extienden a la reproducción en todos los medios.
© ETSI 2020.
Todos los derechos reservados.
DECT™, PLUGTESTS™, UMTS™ y el logotipo de ETSI son marcas comerciales de ETSI registradas en beneficio de sus miembros.
3GPP™ y LTE™ son marcas comerciales de ETSI registradas en beneficio de sus Miembros y de los Socios
organizacionales de 3GPP. El logotipo de oneM2M™ es una marca comercial
de ETSI registrada en beneficio de sus miembros y de los socios de oneM2M.
GSM® y el logotipo de GSM son marcas comerciales registradas y propiedad de GSM Association.
BÚSQUEDA
Contenido
Derechos de propiedad intelectual ............................................... .................................................... ............................... 4
Prólogo .................................................. .................................................... .................................................... ........ 4
Terminología de los verbos modales ............................................... .................................................... .................................... 4
Introducción ................................................. .................................................... .................................................... ... 4
1 Alcance ................................................. .................................................... .................................................... ... 6
Referencias .................................................. .................................................... ............................................. 6 Referencias

2 2.1 normativas .. .................................................... .................................................... ................................... 6 Referencias
2.2 informativas ............ .................................................... .................................................... .......................... 7
Definición de términos, símbolos y abreviaturas ............................................... ............................................ 9

3 Términos .... .................................................... .................................................... .................................................... ........ 9
3.1 Símbolos .......................................... .................................................... .................................................... ................ 11
3.2 3.3 Abreviaturas ................................ .................................................... .................................................... ............... 12
4 Implementación de informes .................................................. .................................................... ..................... 12
5 Disposiciones de seguridad cibernética para IoT de consumo .................................. ............................................. 13 Sin valor
5.1 predeterminado universal contraseñas .................................................. .................................................... ..................... 13
5.2 Implementar un medio para gestionar reportes de vulnerabilidades .................. .................................................... ........... 14
5.3 Mantener el software actualizado ............................... .................................................... .......................................... 15 De
5.4 forma segura almacenar parámetros de seguridad confidenciales ............................................. .................................................... 18 ....
5.5 Comunicarse de forma segura ........................................... .................................................... .......................................... 19
5.6 Minimice las superficies de ataque expuestas ..... .................................................... .............. ............................................. 20
5.7 Asegúrese de que el software integridad .................................................. .................................................... ............................. 21
5.8 Garantizar que los datos personales estén seguros ............ .................................................... .................................................... 21 ...
5.9 Hacer que los sistemas sean resistentes a las interrupciones .................................. .................................................... ....................... 22
5.10 Examinar los datos de telemetría del sistema .................. .................................................... ....................................................22
5.11 Facilite que los usuarios eliminen datos de usuario .................................. .................................................... ............... 23
5.12 Facilite la instalación y el mantenimiento de los dispositivos ....................... .................................................... ............ 23
5.13 Validar datos de entrada ............ .................................................... .................................................... ............................. 24
6 Disposiciones de protección de datos para el IoT del consumidor .................................. ............................................. 24
Anexo A (informativo): Conceptos básicos y modelos .............................................. ............................. 25
A.1 Arquitectura ................................................ .................................................... ............................................. 25
A.2 Estados del dispositivo .............................................. .................................................... ............................................. 27
Anexo B (informativo): Declaración de conformidad de implementación pro forma ........................... 29
Historia ................................................. .................................................... .................................................... ........ 32
BÚSQUEDA
Derechos de propiedad intelectual

Patentes esenciales
Los DPI esenciales o potencialmente esenciales para los entregables normativos pueden haber sido declarados al ETSI. La información relativa a estos DPI
esenciales, si los hubiere, está disponible públicamente para miembros y no miembros de ETSI, y se puede encontrar en ETSI SR 000 314: "Derechos de propiedad
intelectual (DPI); DPI esenciales o potencialmente esenciales notificados a ETSI con respecto a las normas del ETSI", que está disponible en la Secretaría del ETSI. Las
últimas actualizaciones están disponibles en el servidor web de ETSI (https://ipr.etsi.org/).
De conformidad con la Política de DPI del ETSI, el ETSI no ha llevado a cabo ninguna investigación, incluidas las búsquedas de DPI. No se puede garantizar la existencia
de otros DPI no mencionados en ETSI SR 000 314 (o las actualizaciones en el servidor web de ETSI) que son, o pueden ser, o pueden llegar a ser, esenciales para el
presente documento.
Marcas registradas
El presente documento puede incluir marcas y/o nombres comerciales que son afirmados y/o registrados por sus titulares.
ETSI no reclama la propiedad de estos, a excepción de los que se indican como propiedad de ETSI, y no otorga ningún derecho de uso o reproducción de ninguna
marca registrada y/o nombre comercial. La mención de esas marcas registradas en el presente documento no constituye una aprobación por parte de ETSI de productos,
servicios u organizaciones asociadas con esas marcas registradas.
Prefacio
Este borrador final de Norma Europea (EN) ha sido elaborado por el Comité Técnico de Seguridad Cibernética (CYBER) de ETSI y ahora se presenta para la fase de
Votación del Procedimiento de Aprobación de Normas EN de ETSI.
Fechas de transposición nacional propuestas
Fecha del último anuncio de esta EN (doa): 3 meses después de la publicación de ETSI
Fecha de la última publicación de la nueva norma nacional o aprobación

de esta norma EN (dop/e): 6 meses despues de doa
Fecha de retiro de cualquier Norma Nacional en conflicto (dow): 6 meses despues de doa
Terminología de los verbos modales

En el presente documento , "deberá", "no deberá", "debería", "no debería", "puede", "no es necesario", "hará", "no será", "puede" y "no puede" deben ser
interpretado como se describe en la cláusula 3.2 de las Reglas de Redacción del ETSI (Formas verbales para la expresión de disposiciones).
"debe" y "no debe" NO están permitidos en los entregables de ETSI, excepto cuando se usan en citas directas.
Introducción
A medida que más dispositivos en el hogar se conectan a Internet, la ciberseguridad del Internet de las cosas (IoT) se convierte en una preocupación creciente.
Las personas confían sus datos personales a un número cada vez mayor de dispositivos y servicios en línea. Los productos y dispositivos que tradicionalmente estaban
fuera de línea ahora están conectados y deben diseñarse para resistir las ciberamenazas.
El presente documento reúne buenas prácticas ampliamente consideradas en seguridad para dispositivos de consumo conectados a Internet en un conjunto de
disposiciones de alto nivel centradas en los resultados. El objetivo del presente documento es apoyar a todas las partes involucradas en el desarrollo y la fabricación
de IoT de consumo con orientación sobre cómo asegurar sus productos.
BÚSQUEDA
Las disposiciones se centran principalmente en los resultados, en lugar de ser prescriptivas, lo que brinda a las organizaciones la flexibilidad para
innovar e implementar soluciones de seguridad adecuadas para sus productos.
El presente documento no pretende resolver todos los desafíos de seguridad asociados con el IoT del consumidor. Tampoco se enfoca en la
protección contra ataques que son prolongados/sofisticados o que requieren acceso físico sostenido al dispositivo. Más bien, la atención se
centra en los controles técnicos y las políticas organizativas que más importan para abordar las deficiencias de seguridad más importantes y
generalizadas. En general, se considera un nivel básico de seguridad; esto tiene como objetivo proteger contra ataques elementales a las debilidades
fundamentales del diseño (como el uso de contraseñas fáciles de adivinar).
El presente documento proporciona un conjunto de disposiciones básicas aplicables a todos los dispositivos IoT de consumo. Está previsto que
se complemente con otras normas que definan disposiciones más específicas y requisitos totalmente comprobables y/o verificables para dispositivos
específicos que, junto con el presente documento, facilitarán el desarrollo de esquemas de aseguramiento.
Muchos dispositivos IoT de consumo y sus servicios asociados procesan y almacenan datos personales, el presente documento puede ayudar
a garantizar que cumplan con el Reglamento General de Protección de Datos (RGPD) [i.7]. La seguridad desde el diseño es un principio importante
que se respalda en el presente documento.
ETSI TS 103 701 [i.19] proporciona orientación sobre cómo evaluar y asegurar los productos de IoT frente a las disposiciones del presente
documento.
Las disposiciones del presente documento se han desarrollado tras la revisión de las normas, recomendaciones y orientaciones
publicadas sobre seguridad y privacidad de IoT, que incluyen: ETSI TR 103 305-3 [i.1], ETSI TR 103 309 [i.2], ENISA Baseline
Recomendaciones de seguridad [i.8], Departamento de Digital, Cultura, Medios y Deporte (DCMS) del Reino Unido Informe de seguridad por
diseño [i.9], Marco de cumplimiento de la base de seguridad de IoT [i.10], Pautas y evaluación de seguridad de IoT de GSMA [i .11], ETSI TR
103 533 [i.12], DIN SPEC 27072 [i.20] y OWASP Internet of Things [i.23].
NOTA: Los mapeos del panorama de los estándares, las recomendaciones y la orientación de seguridad de IoT están disponibles en
ENISA Baseline Security Recommendations for IoT - Interactive Tool [i.15] y en Copper Horse Mapping Security & Privacy in
the Internet of Things [i.14].
A medida que los productos de IoT para el consumidor se vuelvan cada vez más seguros, se prevé que las revisiones futuras del presente
documento exigirán disposiciones que actualmente son recomendaciones en el presente documento.
BÚSQUEDA
1 Alcance
El presente documento especifica las disposiciones de protección de datos y seguridad de alto nivel para los dispositivos IoT de consumo que
están conectados a la infraestructura de red (como Internet o la red doméstica) y sus interacciones con los servicios asociados. Los servicios
asociados están fuera del alcance. Una lista no exhaustiva de ejemplos de dispositivos IoT de consumo incluye:
• juguetes para niños conectados y monitores para bebés;
• detectores de humo conectados, cerraduras de puertas y sensores de ventanas;
• Puertas de enlace IoT, estaciones base y concentradores a los que se conectan múltiples dispositivos;
• cámaras, televisores y parlantes inteligentes;
• rastreadores de salud portátiles;
• sistemas de alarma y automatización del hogar conectados, especialmente sus puertas de enlace y centros;
• electrodomésticos conectados, como lavadoras y frigoríficos; y
• asistentes domésticos inteligentes.
Además, el presente documento aborda las consideraciones de seguridad específicas de los dispositivos restringidos.
EJEMPLO: Los sensores de contacto de ventana, los sensores de inundación y los interruptores de energía suelen ser dispositivos restringidos.
El presente documento proporciona una guía básica a través de ejemplos y texto explicativo para las organizaciones involucradas en el desarrollo y
fabricación de IoT de consumo sobre cómo implementar esas disposiciones. La Tabla B.1 proporciona un esquema para que el lector brinde
información sobre la implementación de las disposiciones.
Los dispositivos que no son dispositivos IoT de consumo, por ejemplo, aquellos que están destinados principalmente a ser utilizados en la fabricación,
el cuidado de la salud u otras aplicaciones industriales, no están dentro del alcance del presente documento.
El presente documento se ha desarrollado principalmente para ayudar a proteger a los consumidores; sin embargo, otros usuarios de IoT de
consumo se benefician igualmente de la implementación de las disposiciones aquí establecidas.
Se ha incluido el Anexo A (informativo) del presente documento para dar contexto a las cláusulas 4, 5 y 6 (normativo).
El Anexo A contiene ejemplos de dispositivos y arquitecturas de referencia y un modelo de ejemplo de estados de dispositivos, incluido el almacenamiento
de datos para cada estado.
2 Referencias
2.1 Referencias normativas

Las referencias son específicas (identificadas por fecha de publicación y/o número de edición o número de versión) o no específicas.
Para referencias específicas, solo se aplica la versión citada. Para referencias no específicas, se aplica la última versión del documento de referencia
(incluidas las modificaciones).
Los documentos de referencia que no estén disponibles públicamente en la ubicación esperada se pueden encontrar
en https://docbox.etsi.org/Reference/.
NOTA: Si bien los hipervínculos incluidos en esta cláusula eran válidos en el momento de la publicación, ETSI no puede garantizar su validez a
largo plazo.
Los siguientes documentos referenciados son necesarios para la aplicación del presente documento.
No aplica.
BÚSQUEDA
2.2 Referencias informativas

Las referencias son específicas (identificadas por fecha de publicación y/o número de edición o número de versión) o no específicas.
Para referencias específicas, solo se aplica la versión citada. Para referencias no específicas, se aplica la última versión del documento de
referencia (incluidas las modificaciones).
NOTA: Si bien los hipervínculos incluidos en esta cláusula eran válidos en el momento de la publicación, ETSI no puede garantizar su validez
a largo plazo.
Los siguientes documentos de referencia no son necesarios para la aplicación del presente documento, pero ayudan al usuario con respecto a
un tema en particular.
[i.1] ETSI TR 103 305-3: "CIBER; Controles de seguridad críticos para una ciberdefensa efectiva; Parte 3:
Implementaciones del sector de servicios".
[i.2] ETSI TR 103 309: "CYBER; Seguro por defecto - tecnología de seguridad de plataforma".
[i.3] Publicación especial del NIST 800-63B: "Pautas de identidad digital: autenticación y gestión del ciclo de vida".
NOTA: Disponible en https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf.
[i.4] ISO/IEC 29147: "Tecnología de la información - Técnicas de seguridad - Divulgación de vulnerabilidades".
NOTA: Disponible en https://www.iso.org/standard/45170.html.
[i.5] OASIS: "Marco común de informes de vulnerabilidad (CVRF) de CSAF".
NOTA: Disponible en http://docs.oasis-open.org/csaf/csaf-cvrf/v1.2/csaf-cvrf-v1.2.html.
[i.6] ETSI TR 103 331: "CIBER; Intercambio estructurado de información sobre amenazas".
[i.7] Reglamento (UE) 2016/679 del Parlamento Europeo y del Consejo, de 27 de abril de 2016, relativo a la protección de
las personas físicas en lo que respecta al tratamiento de datos personales y a la libre circulación de estos datos, y por
el que se deroga la Directiva 95/46/CE (Reglamento General de Protección de Datos).
[i.8] ENISA: "Recomendaciones de seguridad de referencia para IoT en el contexto de infraestructuras críticas de
información", noviembre de 2017, ISBN: 978-92-9204-236-3, doi: 10.2824/03228.
[i.9] Departamento de Digital, Cultura, Medios y Deporte del Reino Unido: "Secure by Design: Improving the cyber security
of Consumer Internet of Things Report", marzo de 2018.
NOTA: Disponible en https://www.gov.uk/government/collections/secure-by-design.
[I 10] Fundamentos de seguridad de IoT: "Marco de cumplimiento de seguridad de IoT", versión 2 de diciembre de 2018.
NOTA: Disponible en https://www.iotsecurityfoundation.org/wp-content/uploads/2018/12/IoTSF-IoT-Security Compliance-Framework-

Release-2.0-December-2018.pdf.
[i.11] GSMA: "Pautas y evaluación de seguridad de IoT de GSMA".
NOTA: Disponible en https://www.gsma.com/iot/iot-security/iot-security-guidelines/.
[i.12] ETSI TR 103 533: "SmartM2M; Seguridad; Panorama de estándares y mejores prácticas".
[i.13] Aviso de la Comisión: La "Guía azul" sobre la aplicación de las normas sobre productos de la UE de 2016 (Texto
pertinente a efectos del EEE), 2016/C 272/01.
NOTA: Disponible en el Diario Oficial de la Unión Europea, https://eur-lex.europa.eu/legal

contenido / EN / TODO /? uri = DO: C: 2016: 272: TOC.
[i.14] Caballo de Cobre: "Mapeo de Seguridad y Privacidad en el Internet de las Cosas".
NOTA: Disponible en https://iotsecuritymapping.uk/.
BÚSQUEDA
[i.15] ENISA: "Recomendaciones de seguridad de referencia para IoT - Herramienta interactiva".
NOTA: Disponible en https://www.enisa.europa.eu/topics/iot-and-smart-infrastructures/iot/baseline-security

recomendaciones-para-iot-herramienta-interactiva.
[i.16] IoT Security Foundation: "Comprender el uso contemporáneo de la divulgación de vulnerabilidades en las empresas
de productos de Internet de las cosas para el consumidor".
NOTA: Disponible en https://www.iotsecurityfoundation.org/wp-content/uploads/2018/11/Vulnerability

Divulgación-Diseño-v4.pdf.
[i.17] F-Secure: "Amenazas de IoT: la explosión de dispositivos 'inteligentes' que llenan los hogares conduce a riesgos crecientes".
NOTA: Disponible en https://blog.f-secure.com/iot-threats/.
[i.18] W3C: "Web de las Cosas en el W3C".
NOTA: Disponible en https://www.w3.org/WoT/.
[i.19] ETSI TS 103 701: "CYBER; Evaluación de ciberseguridad para productos de IoT de consumo".
NOTA: Está en desarrollo.
[i.20] DIN SPEC 27072: "Tecnología de la información - Dispositivos compatibles con IoT - Requisitos mínimos para la
seguridad de la información".
[i.21] GSMA: "Programa de divulgación coordinada de vulnerabilidades (CVD)".
NOTA: Disponible en https://www.gsma.com/security/gsma-coordinated-vulnerability-disclosure-programme/.
[i.22] IoT Security Foundation: "Divulgación de vulnerabilidades: pautas de mejores prácticas".
NOTA: Disponible en https://www.iotsecurityfoundation.org/wp-content/uploads/2017/12/Vulnerability Disclosure_WG4_2017.pdf.
[i.23] OWASP Internet de las cosas (IoT) Top 10 2018.
NOTA: Disponible en https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project#tab=IoT_Top_10.
[i.24] IEEE 802.15.4™-2015: "Estándar IEEE para redes inalámbricas de baja velocidad".
NOTA: Disponible en https://standards.ieee.org/content/ieee-standards/en/standard/802_15_4-2015.html.
[i.25] ETSI TS 102 221: "Tarjetas inteligentes; Interfaz UICC-Terminal; Características físicas y lógicas".
[i.26] GSMA: "Especificación técnica SGP.22 v2.2.1".
[i.27] ISO/IEC 27005:2018: "Tecnologías de la información - Técnicas de seguridad - Gestión de riesgos de seguridad de
la información".
[i.28] Microsoft Corporation: "El modelo de amenazas STRIDE".
NOTA: Disponible en https://msdn.microsoft.com/en-us/library/ee823878(v=cs.20).aspx.
[i.29] ETSI TR 121 905: "Sistema de telecomunicaciones celulares digitales (Fase 2+) (GSM); Sistema Universal de
Telecomunicaciones Móviles (UMTS); LTE; Vocabulario para Especificaciones 3GPP (3GPP TR 21.905)".
BÚSQUEDA
3 Definición de términos, símbolos y abreviaturas
3.1 Condiciones
A los efectos del presente documento, se aplican los siguientes términos:
administrador: usuario que tiene el nivel de privilegios más alto posible para un usuario del dispositivo, lo que puede significar que puede cambiar cualquier
configuración relacionada con la funcionalidad prevista
Servicios asociados: servicios digitales que, junto con el dispositivo, forman parte del producto general de IoT del consumidor y que normalmente se requieren
para proporcionar la funcionalidad prevista del producto.
EJEMPLO 1: Los servicios asociados pueden incluir aplicaciones móviles, computación/almacenamiento en la nube e interfaces de programación de
aplicaciones (API) de terceros.
EJEMPLO 2: un dispositivo transmite datos de telemetría a un servicio de terceros elegido por el fabricante del dispositivo. Esta
El servicio es un servicio asociado.
mecanismo de autenticación: método utilizado para probar la autenticidad de una entidad
NOTA: Una "entidad" puede ser un usuario o una máquina.
EJEMPLO: Un mecanismo de autenticación puede ser la solicitud de una contraseña, el escaneo de un código QR o el uso de un
escáner biométrico de huellas dactilares.
valor de autenticación: valor individual de un atributo utilizado por un mecanismo de autenticación
EJEMPLO: Cuando el mecanismo de autenticación es solicitar una contraseña, el valor de autenticación puede ser una cadena de caracteres. Cuando el
mecanismo de autenticación es un reconocimiento biométrico de huellas dactilares, el valor de autenticación puede ser la huella
dactilar índice de la mano izquierda.
criptografía de mejores prácticas: criptografía que es adecuada para el caso de uso correspondiente y no tiene indicios de un ataque factible con las técnicas
actuales fácilmente disponibles
NOTA 1: Esto no se refiere solo a las primitivas criptográficas utilizadas, sino también a la implementación, generación de claves y manejo de claves.
NOTA 2: Múltiples organizaciones, como SDO y autoridades públicas, mantienen guías y catálogos de
métodos criptográficos que se pueden utilizar.
EJEMPLO: El fabricante del dispositivo utiliza un protocolo de comunicación y una biblioteca criptográfica proporcionados con la plataforma IoT y donde esa
biblioteca y protocolo se han evaluado frente a posibles ataques, como la reproducción.
dispositivo restringido: dispositivo que tiene limitaciones físicas en la capacidad de procesar datos, la capacidad de comunicar datos, la capacidad
de almacenar datos o la capacidad de interactuar con el usuario, debido a restricciones que surgen de su uso previsto
NOTA 1: Las limitaciones físicas pueden deberse a la fuente de alimentación, la duración de la batería, la potencia de procesamiento, el acceso físico, la
funcionalidad limitada, la memoria limitada o el ancho de banda de red limitado. Estas limitaciones pueden requerir que un dispositivo restringido
sea compatible con otro dispositivo, como una estación base o un dispositivo complementario.
EJEMPLO 1: El usuario no puede cargar ni cambiar la batería de un sensor de ventana; este es un dispositivo restringido.
EJEMPLO 2: El dispositivo no puede actualizar su software debido a limitaciones de almacenamiento, lo que resulta en problemas de hardware.
el reemplazo o el aislamiento de la red son las únicas opciones para gestionar una vulnerabilidad de seguridad.
EJEMPLO 3: Un dispositivo de baja potencia utiliza una batería para permitir su implementación en una variedad de ubicaciones.
Realizar operaciones criptográficas de alta potencia reduciría rápidamente la duración de la batería, por lo que se basa en una
estación base o concentrador para realizar validaciones en las actualizaciones.
EJEMPLO 4: El dispositivo no tiene una pantalla para validar los códigos de vinculación para el emparejamiento de Bluetooth.
EJEMPLO 5: El dispositivo no tiene la capacidad de ingresar, como a través de un teclado, información de autenticación.
BÚSQUEDA
NOTA 2: Un dispositivo que tenga una fuente de alimentación por cable y pueda admitir protocolos basados en IP y criptográficos
Las primitivas utilizadas por esos protocolos no están restringidas.
EJEMPLO 6: Un dispositivo está alimentado por la red eléctrica y se comunica principalmente mediante TLS (Seguridad de la capa de transporte).
consumidor: persona física que actúa con fines ajenos a su oficio, negocio, oficio o profesión
NOTA: Las organizaciones, incluidas las empresas de cualquier tamaño, utilizan IoT de consumo. Por ejemplo, los televisores inteligentes se
implementan con frecuencia en las salas de reuniones y los kits de seguridad para el hogar pueden proteger las instalaciones de las
pequeñas empresas.
dispositivo IoT del consumidor: dispositivo conectado a la red (y conectable a la red) que tiene relaciones con los servicios asociados y que el
consumidor usa normalmente en el hogar o como dispositivos portátiles electrónicos
NOTA 1: Los dispositivos IoT de consumo también se usan comúnmente en contextos comerciales. Estos dispositivos permanecen clasificados como
dispositivos IoT de consumo.
NOTA 2: Los dispositivos IoT del consumidor a menudo están disponibles para que el consumidor los compre en entornos minoristas. Los dispositivos IoT de
consumo también se pueden poner en servicio y/o instalar profesionalmente.
parámetro crítico de seguridad: información secreta relacionada con la seguridad cuya divulgación o modificación puede comprometer la seguridad de un módulo
de seguridad
EJEMPLO: claves criptográficas secretas, valores de autenticación como contraseñas, PIN, componentes privados de certificados.
interfaz de depuración: interfaz física utilizada por el fabricante para comunicarse con el dispositivo durante el desarrollo o para realizar la clasificación de problemas
con el dispositivo y que no se utiliza como parte de la funcionalidad orientada al consumidor
EJEMPLO: Puntos de prueba, UART, SWD, JTAG.
período de soporte definido: período de tiempo mínimo, expresado como un período o por una fecha de finalización, durante el cual un fabricante proporcionará
actualizaciones de seguridad
NOTA: Esta definición se centra en los aspectos de seguridad y no en otros aspectos relacionados con el soporte del producto, como
garantía.
fabricante del dispositivo: entidad que crea un producto IoT ensamblado para el consumidor final, que probablemente contenga los productos y
componentes de muchos otros proveedores
predeterminado de fábrica: estado del dispositivo después del restablecimiento de fábrica o después de la producción/ensamblaje final
NOTA: Esto incluye el dispositivo físico y el software (incluido el firmware) que está presente después del ensamblaje.
inicialización: proceso que activa la conectividad de red del dispositivo para su funcionamiento y, opcionalmente, establece funciones de autenticación
para un usuario o para el acceso a la red
estado inicializado: estado del dispositivo después de la inicialización
Producto IoT: dispositivo IoT de consumo y sus servicios asociados
aislable: capaz de ser eliminado de la red a la que está conectado, donde cualquier pérdida de funcionalidad causada está relacionada solo con esa conectividad
y no con su función principal; alternativamente, capaz de colocarse en un entorno autónomo con otros dispositivos si y solo si se puede garantizar la integridad de los
dispositivos dentro de ese entorno
EJEMPLO: un Smart Fridge tiene una interfaz basada en pantalla táctil que está conectada a la red. Esta interfaz puede ser
retirado sin impedir que el frigorífico mantenga el contenido frío.
interfaz lógica: implementación de software que utiliza una interfaz de red para comunicarse a través de la red a través de canales o puertos
fabricante: operador económico relevante en la cadena de suministro (incluido el fabricante del dispositivo)
BÚSQUEDA
NOTA: Esta definición reconoce la variedad de actores involucrados en el ecosistema de IoT del consumidor y el
maneras complejas en las que pueden compartir responsabilidades. Más allá del fabricante del dispositivo, dichas entidades también
pueden ser, por ejemplo y dependiendo de un caso específico: importadores, distribuidores, integradores, proveedores de componentes
y plataformas, proveedores de software, proveedores de servicios de TI y telecomunicaciones, proveedores de servicios gestionados y
proveedores de servicios asociados. .
interfaz de red: interfaz física que se puede utilizar para acceder a la funcionalidad de IoT del consumidor a través de una red
propietario: usuario que posee o que compró el dispositivo
datos personales: cualquier información relativa a una persona física identificada o identificable
NOTA: Este término se utiliza para alinearse con la terminología conocida, pero no tiene significado legal en el presente
documento.
interfaz física: puerto físico o interfaz aérea (como radio, audio u óptica) que se utiliza para comunicarse con el dispositivo en la capa física
EJEMPLO: Radios, puertos ethernet, interfaces seriales como USB y las que se usan para depuración.
parámetro de seguridad pública: información pública relacionada con la seguridad cuya modificación puede comprometer la seguridad de un módulo de
seguridad
EJEMPLO 1: Una clave pública para verificar la autenticidad/integridad de las actualizaciones de software.
EJEMPLO 2: Componentes públicos de certificados.
accesible remotamente: destinado a ser accesible desde fuera de la red local
módulo de seguridad: conjunto de hardware, software y/o firmware que implementa funciones de seguridad
EJEMPLO: Un dispositivo contiene una raíz de confianza de hardware, una biblioteca de software criptográfico que opera dentro de un
entorno de ejecución confiable y software dentro del sistema operativo que impone seguridad, como la separación de usuarios
y el mecanismo de actualización. Todos ellos componen el módulo de seguridad.
actualización de seguridad: actualización de software que aborda las vulnerabilidades de seguridad descubiertas por el fabricante o informadas
al mismo
NOTA: Las actualizaciones de software pueden ser puramente actualizaciones de seguridad si la gravedad de la vulnerabilidad requiere una mayor
corrección de prioridad.
parámetros sensibles de seguridad: parámetros críticos de seguridad y parámetros de seguridad pública
servicio de software: componente de software de un dispositivo que se utiliza para soportar la funcionalidad
EJEMPLO: Un tiempo de ejecución para el lenguaje de programación utilizado en el software del dispositivo o un daemon que
expone una API utilizada por el software del dispositivo, por ejemplo, la API de un módulo criptográfico.
telemetría: datos de un dispositivo que pueden proporcionar información para ayudar al fabricante a identificar problemas o información relacionada con
el uso del dispositivo
EJEMPLO: Un dispositivo de IoT de consumo informa al fabricante sobre fallas de software, lo que le permite
identificar y remediar la causa.
único por dispositivo: único para cada dispositivo individual de una clase o tipo de producto determinado
usuario: persona física u organización
3.2 simbolos
Vacío.
BÚSQUEDA
3.3 abreviaturas
A los efectos del presente documento, se aplican las siguientes abreviaturas:
FUEGO Interfaz de programación de aplicaciones

ASLR Aleatorización del diseño del espacio de direcciones
ECV Divulgación de vulnerabilidad coordinada
FRCV Marco común de informes de vulnerabilidades
DDoS Denegación de servicio distribuida
DSC Componentes de seguridad dedicados
ENISA Agencia de la Unión Europea para la Seguridad de las Redes y la Información
I unión Europea
RGPD Reglamento General de Protección de Datos
GSMA Asociación GSM
IEEE Instituto de Ingenieros Eléctricos y Electrónicos
IoT Internet de las Cosas
IP protocolo de Internet
IMPORTANTE
Organización Internacional de Normalización
JTAG Grupo de acción de prueba conjunta
LAN Red de área local
Red de área amplia de largo alcance LoRaWAN
NIST Instituto Nacional de Normas y Tecnología
Fiscalía Contraseña de un solo uso
código QR Respuesta rápida
SBOM Lista de materiales del software
SDO Organización de Desarrollo de Estándares
SE Elementos seguros
SWD Depuración de cable serie
TEE Entorno de ejecución de confianza
TS Especificación técnica
UART Transmisor-receptor asíncrono universal
CEBOLLA Interfaz de usuario
USB Bus serie universal
CAMIONETA Red de área amplia
4 Implementación de informes
La implementación de las disposiciones del presente documento se basa en la evaluación de riesgos y el modelado de amenazas (como ISO/
IEC 27005:2018 [i.27] y STRIDE Threat Model [i.28]); esto lo realiza el fabricante del dispositivo y/u otras entidades relevantes y está fuera del
alcance del presente documento. Para ciertos casos de uso y después de la evaluación de riesgos, puede ser apropiado aplicar disposiciones
adicionales además de las contenidas en el presente documento.
El presente documento establece una línea base de seguridad; sin embargo, debido al amplio panorama del IoT de consumo, se
reconoce que la aplicabilidad de las disposiciones depende de cada dispositivo. El presente documento proporciona un grado de
flexibilidad mediante el uso de disposiciones no obligatorias de "debería" (recomendaciones).
Disposición 4-1 Se registrará una justificación para cada recomendación del presente documento que se considere no aplicable o no cumplida
por el dispositivo IoT del consumidor.
La Tabla B.1 proporciona un esquema para registrar estas justificaciones de manera estructurada. Esto es para permitir que otras partes
interesadas (por ejemplo, asesores de aseguramiento, miembros de la cadena de suministro, investigadores de seguridad o minoristas)
determinen si las disposiciones se han aplicado de manera correcta y apropiada.
EJEMPLO 1: El fabricante publica una versión completa de la tabla B.1 junto con la descripción del producto en su sitio web.
EJEMPLO 2: El fabricante completa la tabla B.1 para el mantenimiento de registros internos. Algún tiempo después, un externo
La organización de aseguramiento evalúa un producto contra el presente documento y solicita información
relacionada con el diseño de seguridad del producto. El fabricante puede proporcionar fácilmente esta información,
ya que se encuentra en la tabla B.1.
BÚSQUEDA
Los casos en los que una disposición no es aplicable o el dispositivo IoT del consumidor no la cumple pueden incluir:
• cuando un dispositivo es un dispositivo restringido de tal manera que la implementación de ciertas medidas de seguridad no es posible o no es
apropiada para el riesgo identificado (seguridad o privacidad);
• cuando no se incluye la funcionalidad descrita en la disposición (por ejemplo, un dispositivo que solo presenta datos sin
que requieren autenticación).
EJEMPLO 3: Un sensor de ventana con batería de duración limitada envía alertas a través de un servicio remoto asociado cuando
se activa y se controla a través de un concentrador. Debido a la duración limitada de la batería y la potencia de procesamiento en
comparación con otros dispositivos IoT de consumo, es un dispositivo limitado. Además, debido a que el usuario controla el
dispositivo a través de un concentrador, el usuario no necesita usar contraseñas u otros mecanismos de autenticación para
autenticarse directamente en el dispositivo.
5 Disposiciones de seguridad cibernética para IoT de consumo
5.1 Sin contraseñas predeterminadas universales

Disposición 5.1-1 Cuando se utilicen contraseñas y en cualquier estado que no sea el predeterminado de fábrica, todas las contraseñas de los
dispositivos IoT del consumidor serán únicas por dispositivo o definidas por el usuario.
NOTA 1: Hay muchos mecanismos que se utilizan para realizar la autenticación, y las contraseñas no son los únicos.
mecanismo para autenticar a un usuario en un dispositivo. Sin embargo, si se utilizan, se recomienda seguir las mejores prácticas
sobre contraseñas de acuerdo con la Publicación especial 800-63B [i.3] del NIST. El uso de contraseñas para la autenticación de
máquina a máquina generalmente no es apropiado.
Muchos dispositivos IoT de consumo se venden con nombres de usuario y contraseñas predeterminados universales (como "admin, admin") para interfaces
de usuario a través de protocolos de red. El uso continuo de valores predeterminados universales ha sido la fuente de muchos problemas de seguridad en
IoT [i.17] y la práctica debe interrumpirse. La disposición anterior se puede lograr mediante el uso de contraseñas preinstaladas que son únicas para cada
dispositivo y/o solicitando al usuario que elija una contraseña que siga las mejores prácticas como parte de la inicialización, o mediante algún otro método
que no utilice contraseñas.
EJEMPLO 1: Durante la inicialización, un dispositivo genera certificados que se utilizan para autenticar a un usuario en el
dispositivo a través de un servicio asociado como una aplicación móvil.
Para aumentar la seguridad, se puede utilizar la autenticación multifactor, como el uso de una contraseña más un procedimiento OTP, para proteger mejor
el dispositivo o un servicio asociado. La seguridad del dispositivo se puede fortalecer aún más al tener identidades únicas e inmutables.
Disposición 5.1-2 Cuando se utilicen contraseñas únicas por dispositivo preinstaladas, estas se generarán con un mecanismo que reduzca el riesgo de
ataques automatizados contra una clase o tipo de dispositivo.
EJEMPLO 2: Las contraseñas preinstaladas son suficientemente aleatorias.
Como contraejemplo, las contraseñas con contadores incrementales (como "contraseña1", "contraseña2", etc.) son fáciles de adivinar. Además, el uso de
una contraseña que está relacionada de manera obvia con la información pública (enviada por aire o dentro de una red), como la dirección MAC o el SSID
de Wi-Fi®, puede permitir la recuperación de la contraseña mediante medios automatizados.
Disposición 5.1-3 Los mecanismos de autenticación utilizados para autenticar a los usuarios contra un dispositivo deberán utilizar la criptografía
de mejores prácticas, adecuada a las propiedades de la tecnología, el riesgo y el uso.
Disposición 5.1-4 Cuando un usuario pueda autenticarse contra un dispositivo, el dispositivo debe proporcionar al usuario o al administrador un mecanismo
simple para cambiar el valor de autenticación utilizado.
EJEMPLO 3: Para los valores de autenticación biométrica, el fabricante del dispositivo permite este cambio en el valor de autenticación mediante el
reentrenamiento con una nueva biométrica.
EJEMPLO 4: Un padre en un hogar crea una cuenta en el dispositivo para su hijo y selecciona y administra
el PIN o contraseña que utiliza el niño. El padre es un administrador en el dispositivo y puede impedir que el niño cambie
el PIN o la contraseña.
BÚSQUEDA
EJEMPLO 5: Para que sea sencillo para el usuario cambiar una contraseña, el fabricante diseña la contraseña
proceso de cambio de manera que requiera un número mínimo de pasos. El fabricante explica el proceso en un manual de
usuario y en un videotutorial.
Un mecanismo de autenticación utilizado para autenticar a los usuarios, ya sea una huella digital, una contraseña u otro token, debe tener un valor
modificable. Esto es más fácil cuando este mecanismo es parte del flujo de uso normal del dispositivo.
Disposición 5.1-5 Cuando el dispositivo no sea un dispositivo restringido, deberá tener un mecanismo disponible que haga impracticables los ataques
de fuerza bruta a los mecanismos de autenticación a través de las interfaces de red.
EJEMPLO 6: Un dispositivo tiene una limitación en el número de intentos de autenticación dentro de un cierto intervalo de tiempo. También utiliza
intervalos de tiempo crecientes entre intentos.
EJEMPLO 7: la aplicación cliente puede bloquear una cuenta o retrasar intentos de autenticación adicionales después de una cantidad limitada de
intentos de autenticación fallidos.
Esta disposición aborda los ataques que realizan "relleno de credenciales" o agotan un espacio de claves completo. Es importante que el dispositivo
IoT del consumidor detecte estos tipos de ataques y se defienda de ellos, al mismo tiempo que protege contra una amenaza relacionada de 'agotamiento
de recursos' y ataques de denegación de servicio.
5.2 Implementar un medio para gestionar los informes de vulnerabilidades

Disposición 5.2-1 El fabricante deberá poner a disposición del público una política de divulgación de vulnerabilidades. Esta política incluirá, como
mínimo:
• información de contacto para la notificación de problemas; y
• información sobre los plazos para:
1) acuse de recibo inicial; y
2) actualizaciones de estado hasta la resolución de los problemas informados.
Una política de divulgación de vulnerabilidades especifica claramente el proceso a través del cual los investigadores de seguridad y otros pueden informar
problemas. Dicha política puede actualizarse según sea necesario para garantizar aún más la transparencia y la claridad en las relaciones del fabricante
con los investigadores de seguridad, y viceversa.
La divulgación coordinada de vulnerabilidades (CVD) es un conjunto de procesos para tratar las divulgaciones sobre posibles vulnerabilidades de
seguridad y para respaldar la reparación de estas vulnerabilidades. CVD está estandarizado por la Organización Internacional de Normalización (ISO)
en ISO/IEC 29147 [i.4] sobre divulgación de vulnerabilidades y se ha demostrado que tiene éxito en algunas grandes empresas de software de todo el
mundo.
En la industria de IoT, CVD actualmente no está bien establecido [i.16] ya que algunas empresas son reticentes a tratar con investigadores de
seguridad. Aquí, CVD proporciona a las empresas un marco para gestionar este proceso. Esto brinda a los investigadores de seguridad una vía
para informar a las empresas sobre problemas de seguridad, las coloca por delante de la amenaza de explotación maliciosa y les brinda la
oportunidad de responder y resolver vulnerabilidades antes de una divulgación pública.
Disposición 5.2-2 Se debe actuar sobre las vulnerabilidades reveladas de manera oportuna.
Una "manera oportuna" de actuar sobre las vulnerabilidades varía considerablemente y es específica del incidente; sin embargo, convencionalmente,
el proceso de vulnerabilidad se completa dentro de los 90 días para una solución de software, incluida la disponibilidad de parches y la notificación del
problema. Una corrección de hardware puede tardar mucho más en solucionarse que una corrección de software. Además, una solución que debe
implementarse en los dispositivos puede demorar en implementarse en comparación con una solución de software de servidor.
Disposición 5.2-3 Los fabricantes deben monitorear, identificar y rectificar continuamente las vulnerabilidades de seguridad dentro de los
productos y servicios que venden, producen, han producido y los servicios que operan durante el período de soporte definido.
NOTA 1: Se espera que los fabricantes ejerzan el debido cuidado con todos los componentes de software y hardware utilizados en el producto,
esto incluye el debido cuidado relacionado con los terceros seleccionados que brindan servicios asociados para respaldar las
funciones del producto.
BÚSQUEDA
Las soluciones de software a menudo contienen componentes de software de código abierto y de terceros. Crear y mantener una lista de todos los componentes
de software y sus subcomponentes es un requisito previo para poder monitorear las vulnerabilidades del producto.
Existen varias herramientas para escanear el código fuente y los archivos binarios y crear la denominada Lista de materiales del software (SBOM), que
identifica los componentes de terceros y las versiones utilizadas en el producto. Esta información luego se usa para monitorear los riesgos de licencia y seguridad
asociados de cada componente de software identificado.
Se espera que las vulnerabilidades se informen directamente a las partes interesadas afectadas en primera instancia. Si eso no es posible, las
vulnerabilidades se pueden informar a las autoridades nacionales. También se alienta a los fabricantes a compartir información con organismos industriales
competentes, como la GSMA [i.21] y la IoT Security Foundation. La orientación sobre la divulgación coordinada de vulnerabilidades está disponible en IoT Security
Foundation [i.22], que hace referencia a ISO/IEC 29147 [i.4].
Se espera que esto se realice para dispositivos dentro de su período de soporte definido. Sin embargo, los fabricantes pueden continuar con esto fuera de ese
período y lanzar actualizaciones de seguridad para corregir vulnerabilidades.
Los fabricantes que proporcionan productos IoT tienen el deber de cuidar a los consumidores y terceros que pueden verse perjudicados por no tener un programa
de CVD. Además, las empresas que comparten esta información a través de organismos de la industria pueden ayudar a otros que pueden estar sufriendo el
mismo problema.
Las divulgaciones pueden comprender diferentes enfoques dependiendo de las circunstancias:
• Vulnerabilidades relacionadas con productos o servicios individuales: se espera que el problema se informe directamente a la parte interesada
afectada (por lo general, el fabricante del dispositivo, el proveedor de servicios de IoT o el desarrollador de aplicaciones móviles).
La fuente de estos informes pueden ser investigadores de seguridad o colegas de la industria.
• Vulnerabilidades sistémicas: una parte interesada, como un fabricante de dispositivos, puede descubrir un problema que es potencialmente
sistémico. Si bien fijarlo en el propio producto del fabricante del dispositivo es crucial, existe un beneficio significativo para la industria y los
consumidores al compartir esta información. Del mismo modo, los investigadores de seguridad también pueden tratar de informar dichas
vulnerabilidades sistémicas. Para las vulnerabilidades sistémicas, un organismo industrial competente relevante puede coordinar una respuesta a
mayor escala.
NOTA 2: El marco común de notificación de vulnerabilidades (CVRF) [i.5] también puede ser útil para intercambiar
información sobre vulnerabilidades de seguridad.
El intercambio de información sobre amenazas a la seguridad cibernética puede ayudar a las organizaciones a desarrollar y producir productos seguros
de acuerdo con ETSI TR 103 331 [i.6].
5.3 Mantenga el software actualizado

Desarrollar e implementar actualizaciones de seguridad de manera oportuna es una de las acciones más importantes que un fabricante puede tomar para
proteger a sus clientes y al ecosistema técnico más amplio. Es una buena práctica que todo el software se mantenga actualizado y bien mantenido.
Cada disposición de 5.3-3 a 5.3-12 depende de la implementación de un mecanismo de actualización, según la disposición 5.3-1 o 5.3-2.
Disposición 5.3-1 Todos los componentes de software en los dispositivos IoT de consumo deben poder actualizarse de forma segura.
NOTA 1: La gestión correcta de las actualizaciones de software generalmente depende de la comunicación de la información de la versión para
componentes de software entre el dispositivo y el fabricante.
No todo el software de un dispositivo se podrá actualizar.
EJEMPLO 1: El cargador de arranque de primera etapa en un dispositivo se escribe una vez en el almacenamiento del dispositivo y, a partir de ese
momento, es inmutable.
EJEMPLO 2: En dispositivos con varios microcontroladores (por ejemplo, uno para la comunicación y otro para la aplicación), algunos de ellos podrían no ser
actualizables.
Disposición 5.3-2 Cuando el dispositivo no sea un dispositivo restringido, deberá contar con un mecanismo de actualización para la instalación
segura de actualizaciones.
NOTA 2: Hay casos en los que se aplica la disposición 5.3-1 incluso cuando no se aplica la 5.3-2.
"Actualizable de forma segura" e "instalación segura" significa que existen medidas adecuadas para evitar que un atacante haga un mal uso del mecanismo de
actualización.
BÚSQUEDA
dieciséis
Borrador final ETSI EN 303 645 V2.1.0 (2020-04)
EJEMPLO 3: Las medidas pueden incluir el uso de servidores de actualización de software auténticos, con integridad protegida
canales de comunicación, verificando la autenticidad e integridad de las actualizaciones de software. Se reconoce que
existen grandes variaciones en los mecanismos de actualización de software y lo que constituye "instalación".
EJEMPLO 4: Se puede usar una política antirretroceso basada en la verificación de versiones para evitar ataques de degradación.
Los mecanismos de actualización pueden variar desde que el dispositivo descargue la actualización directamente desde un servidor remoto, se transmita desde
una aplicación móvil o se transfiera a través de un USB u otra interfaz física. Si un atacante compromete este mecanismo, permite que se instale una versión
maliciosa del software en el dispositivo.
Disposición 5.3-3 Una actualización deberá ser simple de aplicar para el usuario.
Disposición 5.3-4 Deben utilizarse mecanismos automáticos para las actualizaciones de software.
El grado de simplicidad depende del diseño y el uso previsto del dispositivo. Una actualización que es fácil de aplicar se aplicará automáticamente, se iniciará
mediante un servicio asociado (como una aplicación móvil) o a través de una interfaz web en el dispositivo. Si una actualización es difícil de aplicar, eso aumenta la
posibilidad de que un usuario posponga repetidamente la actualización del dispositivo, dejándolo en un estado vulnerable.
Si falla una actualización automática, es posible que, en algunas circunstancias, un usuario ya no pueda usar un dispositivo. Los mecanismos de detección,
como los perros guardianes y el uso de particiones flash o de recuperación de banco dual, pueden garantizar que el dispositivo regrese a una buena versión
conocida o al estado de fábrica.
Las actualizaciones de seguridad se pueden proporcionar para los dispositivos de manera preventiva, como parte de las actualizaciones automáticas, que pueden
eliminar las vulnerabilidades de seguridad antes de que sean explotadas. Administrar esto puede ser complejo, especialmente si hay actualizaciones de servicios
asociadas paralelas, actualizaciones de dispositivos y otras actualizaciones de servicios con las que lidiar. Por lo tanto, un plan claro de administración e
implementación es beneficioso para el fabricante, al igual que la transparencia para los consumidores sobre el estado actual del soporte de actualizaciones.
En muchos casos, la publicación de actualizaciones de software implica múltiples dependencias de otras organizaciones, como fabricantes que
producen subcomponentes; sin embargo, esta no es una razón para retener las actualizaciones. Puede ser útil para el fabricante considerar toda la cadena de
suministro de software en el desarrollo e implementación de actualizaciones de seguridad.
A menudo es recomendable no agrupar actualizaciones de seguridad con actualizaciones de software más complejas, como actualizaciones de funciones.
Una actualización de características que introduce una nueva funcionalidad puede desencadenar requisitos adicionales y retrasar la entrega de la actualización a
los dispositivos.
EJEMPLO 5: Según la legislación de productos de la UE, una actualización de características podría cambiar el uso previsto de un dispositivo y, por lo tanto,
convertirlo en un nuevo producto, lo que requiere que se realice una nueva evaluación de conformidad. Sin embargo, una actualización
de software con un impacto limitado podría considerarse una actualización de mantenimiento que no requeriría una nueva evaluación
de la conformidad. Puede encontrar más información sobre el impacto de las actualizaciones de software en el contexto de la legislación
de productos de la UE en la Guía azul [i.13].
Provisión 5.3-5 El dispositivo debe verificar después de la inicialización y luego periódicamente, si hay actualizaciones de seguridad disponibles.
EJEMPLO 6: Se podría mostrar al usuario la existencia de actualizaciones a través de la interfaz con la que se inicializa el dispositivo.
EJEMPLO 7: un dispositivo busca actualizaciones disponibles diariamente en un horario aleatorio.
Para algunos productos, puede ser más apropiado para el servicio asociado, en lugar del dispositivo, realizar dichas comprobaciones.
Disposición 5.3-6 Si el dispositivo admite actualizaciones automáticas y/o notificaciones de actualización, estas deben estar habilitadas en el estado
inicializado y configurables para que el usuario pueda habilitar, deshabilitar o posponer la instalación de actualizaciones de seguridad y/o notificaciones de
actualización.
Desde la perspectiva de los derechos del consumidor y la propiedad, es importante que el usuario tenga el control de si recibe o no actualizaciones. Hay
buenas razones por las que un usuario puede optar por no actualizar, incluida la seguridad. Además, si se implementa una actualización y posteriormente se
descubre que causa problemas, los fabricantes pueden pedir a los usuarios que no actualicen su software para que esos dispositivos no se vean afectados.
Disposición 5.3-7 El dispositivo deberá utilizar la criptografía de mejores prácticas para facilitar los mecanismos de actualización seguros.
BÚSQUEDA
Disposición 5.3-8 Las actualizaciones de seguridad serán oportunas.
"Puntual" en el contexto de las actualizaciones de seguridad puede variar, según el problema y la solución en particular, así como otros factores, como la capacidad
de llegar a un dispositivo o las consideraciones del dispositivo restringido. Es importante que el fabricante gestione con la prioridad adecuada una actualización de
seguridad que solucione una vulnerabilidad crítica (es decir, una con efectos potencialmente adversos a gran escala). Debido a la compleja estructura del software
moderno y la ubicuidad de las plataformas de comunicación, varias partes interesadas pueden estar involucradas en una actualización de seguridad.
EJEMPLO 8: una actualización de software en particular involucra a un proveedor externo de bibliotecas de software, un fabricante de dispositivos IoT y un
operador de plataforma de servicios IoT. La colaboración entre estas partes interesadas garantiza la puntualidad adecuada de la
actualización del software.
Disposición 5.3-9 El dispositivo debe verificar la autenticidad e integridad de las actualizaciones de software.
Un enfoque común para confirmar que una actualización es válida es verificar su integridad y autenticidad. Esto se puede hacer en el dispositivo; sin embargo, los
dispositivos restringidos pueden tener limitaciones de energía que hacen que la realización de operaciones criptográficas sea costosa. En tales casos, la verificación
puede ser realizada por otro dispositivo en el que se confíe para realizar esta verificación. La actualización verificada luego se enviaría a través de un canal seguro al
dispositivo. Verificar las actualizaciones en un concentrador y luego en el dispositivo puede reducir el riesgo de compromiso.
Es una buena práctica que un dispositivo actúe ante la detección de una actualización no válida y potencialmente maliciosa. Más allá de rechazar la actualización, ya
título enunciativo, podrá comunicar la incidencia a un servicio adecuado y/o informar al usuario. Además, se pueden implementar controles de mitigación para evitar que
un atacante eluda o haga un mal uso de un mecanismo de actualización. Darle al atacante la menor cantidad de información posible como parte del mecanismo de
actualización reduce su capacidad para explotarla.
EJEMPLO 9: cuando un dispositivo detecta que una actualización no se pudo entregar o aplicar con éxito (al fallar
comprobaciones de integridad o autenticación), el dispositivo puede mitigar la fuga de información al no proporcionar ninguna
información sobre la falla al iniciador del proceso de actualización. Sin embargo, el dispositivo puede generar una entrada de registro
y enviar una notificación de la entrada de registro a un par de confianza (por ejemplo, un administrador de dispositivo) a través de un
canal seguro, de modo que se conozca la ocurrencia del incidente y el propietario o administrador del dispositivo pueda hacer una
respuesta apropiada.
Disposición 5.3-10 Cuando las actualizaciones se entregan a través de una interfaz de red, el dispositivo debe verificar la autenticidad e integridad de cada
actualización a través de una relación de confianza.
NOTA 3: Las relaciones de confianza válidas incluyen: canales de comunicación autenticados, presencia en una red que requiere que el dispositivo posea
un parámetro de seguridad crítico o contraseña para unirse, verificación de la actualización basada en firma digital o confirmación por parte
del usuario.
NOTA 4: La validación de la relación de confianza es esencial para garantizar que una entidad no autorizada (por ejemplo, una plataforma de gestión de
dispositivos o un dispositivo) no pueda instalar código malicioso.
Disposición 5.3-11 El fabricante debe informar al usuario de manera reconocible y aparente que se requiere una actualización de seguridad junto con información
sobre los riesgos mitigados por esa actualización.
EJEMPLO 10: El fabricante informa al usuario que se requiere una actualización mediante una notificación en la interfaz de usuario o mediante un correo electrónico.
Disposición 5.3-12 El dispositivo debe notificar al usuario cuando la aplicación de una actualización de software interrumpa el funcionamiento básico del
dispositivo.
NOTA 5: Esto no es necesario si la notificación la realiza un servicio asociado.
Esta notificación puede incluir detalles adicionales, como la duración aproximada esperada durante la cual el dispositivo estará fuera de línea.
EJEMPLO 11: una notificación incluye información sobre la urgencia y la duración esperada aproximada del tiempo de inactividad.
Puede ser crítico para los usuarios que un dispositivo continúe funcionando durante una actualización. Es por eso que la disposición anterior recomienda
notificar al usuario cuando una actualización interrumpa la funcionalidad cuando sea posible. En particular, se espera que los dispositivos que cumplen una función
relevante para la seguridad no se apaguen por completo en el caso de una actualización; se espera alguna capacidad funcional mínima del sistema. La interrupción
de la funcionalidad puede convertirse en un problema de seguridad crítico para algunos tipos de dispositivos y sistemas si no se considera o gestiona correctamente.
BÚSQUEDA
EJEMPLO 12: Durante una actualización, un reloj seguirá mostrando la hora, un termostato doméstico seguirá
mantenga una temperatura razonable y un Smart Lock continuará bloqueando y desbloqueando una puerta.
Disposición 5.3-13 El fabricante deberá publicar, de forma accesible, clara y transparente para el usuario, el período de soporte definido.
Al comprar un producto, el consumidor espera que este período de soporte de actualización de software sea claro.
Disposición 5.3-14 Para los dispositivos restringidos cuyo software no puede actualizarse, el fabricante debe publicar la justificación de la ausencia de
actualizaciones de software, el período y el método de soporte de reemplazo de hardware y un período de soporte definido de una manera accesible que
sea clara y transparente para el usuario.
Disposición 5.3-15 Para los dispositivos restringidos que no pueden actualizar su software, el producto debe ser aislable y el hardware reemplazable.
Hay algunas situaciones en las que los dispositivos no se pueden parchear. Para los dispositivos restringidos, se debe implementar un plan de reemplazo y
comunicarlo claramente al consumidor. Este plan generalmente detallaría un cronograma sobre cuándo será necesario reemplazar las tecnologías y, cuando
corresponda, cuándo finaliza el soporte para hardware y software.
Disposición 5.3-16 La designación del modelo del dispositivo IoT del consumidor debe ser claramente reconocible, ya sea mediante una etiqueta en el
dispositivo o mediante una interfaz física.
Esto a menudo se realiza comunicándose con un dispositivo a través de una interfaz lógica; sin embargo, también puede ser parte de una interfaz de usuario.
EJEMPLO 13: un dispositivo tiene una API HTTP (o HTTPS cuando corresponda) que informa la designación del modelo (después de la autenticación del
usuario).
A menudo se requiere conocer la designación específica del dispositivo para verificar el período de soporte definido de las actualizaciones de software o la
disponibilidad de las actualizaciones de software.
5.4 Almacene de forma segura parámetros de seguridad confidenciales

Disposición 5.4-1 Los parámetros de seguridad confidenciales en el almacenamiento persistente deben ser almacenados de forma segura por el dispositivo.
Se pueden utilizar mecanismos de almacenamiento seguro para proteger parámetros de seguridad confidenciales. Los mecanismos adecuados incluyen los
proporcionados por un entorno de ejecución de confianza (TEE), el almacenamiento cifrado asociado con el hardware, los elementos seguros (SE) o los
componentes de seguridad dedicados (DSC) y las capacidades de procesamiento del software que se ejecuta en una UICC, de acuerdo con ETSI TS 121 905
[i.29], ETSI TS 102 221 [i.25]/UICC integrada de acuerdo con la especificación técnica GSMA SGP.22 v.2.2.1 [i.26].
NOTA: Esta disposición se aplica al almacenamiento persistente, pero los fabricantes también pueden implementar enfoques similares para
parámetros de seguridad sensibles en la memoria.
EJEMPLO 1: Las claves raíz involucradas en la autorización y el acceso a frecuencias de radio con licencia (por ejemplo, acceso celular LTE-m) se
almacenan en una UICC.
EJEMPLO 2: Una cerradura de puerta con control remoto que usa un entorno de ejecución confiable (TEE) para almacenar y acceder
los parámetros de seguridad sensibles.
EJEMPLO 3: Un termostato inalámbrico almacena las credenciales de la red inalámbrica en un dispositivo protegido contra manipulaciones.
microcontrolador en lugar de en un almacenamiento flash externo.
Disposición 5.4-2 Cuando se utilice una identidad codificada única por dispositivo en un dispositivo con fines de seguridad, se implementará de tal manera
que resista la manipulación por medios físicos, eléctricos o de software.
EJEMPLO 4: Una clave maestra utilizada para el acceso a la red que es única para el dispositivo se almacena en UICC, que es
Cumple con los estándares ETSI relevantes (ver, por ejemplo, ETSI TS 102 221 [i.25]).
No se utilizará la disposición 5.4-3 Parámetros de seguridad críticos codificados de forma rígida en el código fuente del software del dispositivo.
La ingeniería inversa de dispositivos y aplicaciones puede descubrir fácilmente credenciales como nombres de usuario y contraseñas codificados en el
software. Estas credenciales también pueden ser claves API que permiten el uso de funciones sensibles a la seguridad en un servicio remoto, o claves
privadas utilizadas en la seguridad de los protocolos que utiliza el dispositivo para comunicarse. Tales credenciales a menudo se encontrarán dentro del código
fuente, lo cual es una mala práctica bien conocida. Los métodos de ofuscación simples que también se utilizan para ocultar o cifrar esta información codificada
de forma rígida se pueden descifrar de manera trivial.
BÚSQUEDA
Disposición 5.4-4 Todos los parámetros de seguridad críticos utilizados para las verificaciones de integridad y autenticidad de las actualizaciones de software y
para la protección de la comunicación con los servicios asociados en el software del dispositivo serán únicos para cada dispositivo y se generarán con un
mecanismo que reduzca el riesgo de ataques automatizados contra clases de dispositivos.
EJEMPLO 5: Se implementa una clave simétrica diferente en cada dispositivo de la misma clase de producto para generar
y verificación de códigos de autenticación de mensajes para actualizaciones de software.
EJEMPLO 6: El dispositivo utiliza la clave pública del fabricante para verificar una actualización de software. esto no es critico
parámetro de seguridad y no necesita ser único por dispositivo.
Aprovisionar un dispositivo con parámetros de seguridad críticos únicos ayuda a proteger la integridad y la autenticidad de las actualizaciones de software, así
como la comunicación del dispositivo con los servicios asociados. Si se utilizan parámetros de seguridad críticos globales, su divulgación puede permitir ataques a
gran escala en otros dispositivos IoT, como para permitir la creación de botnets.
5.5 Comunicarse de forma segura

Disposición 5.5-1 El dispositivo IoT del consumidor deberá utilizar la criptografía de mejores prácticas para comunicarse de forma segura.
La idoneidad de los controles de seguridad y el uso de la criptografía de mejores prácticas depende de muchos factores, incluido el contexto de uso. Dado que la
seguridad está en constante evolución, es difícil dar consejos prescriptivos sobre criptografía u otras medidas de seguridad sin el riesgo de que dichos consejos
se vuelvan obsoletos rápidamente.
Disposición 5.5-2 El dispositivo IoT del consumidor debe usar implementaciones revisadas o evaluadas para brindar funcionalidades de red y seguridad,
particularmente en el campo de la criptografía.
Las revisiones y evaluaciones pueden involucrar a una entidad interna o externa independiente.
EJEMPLO 1: Bibliotecas de software distribuidas dentro de la comunidad de desarrollo y prueba, software certificado
los módulos y los proveedores de servicios criptográficos de equipos de hardware (como el elemento seguro y el entorno de ejecución
de confianza) se revisan o evalúan.
Disposición 5.5-3 Los algoritmos criptográficos y las primitivas deben ser actualizables.
NOTA 1: Esto también se conoce como "criptoagilidad".
Para los dispositivos que no se pueden actualizar, es importante que la vida útil prevista del dispositivo no exceda la vida útil de uso recomendada de
los algoritmos criptográficos utilizados por el dispositivo (incluidos los tamaños de clave).
Disposición 5.5-4 El acceso a la funcionalidad del dispositivo a través de una interfaz de red en el estado inicializado solo debe ser posible después de la
autenticación en esa interfaz.
NOTA 2: La funcionalidad puede variar significativamente según el caso de uso y puede abarcar una variedad de cosas, incluido el acceso a datos personales
y actuadores de dispositivos.
Hay dispositivos que proporcionan datos públicos y abiertos, por ejemplo, en la Web de las cosas [i.18]. Estos dispositivos son accesibles sin autenticación para
brindar acceso abierto a todos.
El dispositivo puede verse comprometido a través de vulnerabilidades en los servicios de red. Un mecanismo de autenticación adecuado puede proteger
contra el acceso no autorizado y puede contribuir a la defensa en profundidad del dispositivo.
Disposición 5.5-5 La funcionalidad del dispositivo que permite cambios en la configuración relevantes para la seguridad a través de una interfaz de red solo será
accesible después de la autenticación. La excepción son los protocolos de servicio de red en los que se basa el dispositivo y en los que el fabricante no puede
garantizar qué configuración se requerirá para que el dispositivo funcione.
NOTA 3: Los protocolos que son una excepción incluyen ARP, DHCP, DNS, ICMP y NTP.
EJEMPLO 2: Los cambios relevantes para la seguridad incluyen la administración de permisos, la configuración de claves de red y cambios de contraseña.
Disposición 5.5-6 Los parámetros críticos de seguridad deben encriptarse en tránsito, con tal encriptación adecuada a las propiedades de la tecnología, el
riesgo y el uso.
Disposición 5.5-7 El dispositivo IoT del consumidor deberá proteger la confidencialidad de los parámetros de seguridad críticos que se comunican a
través de interfaces de red accesibles de forma remota.
BÚSQUEDA
Existen muchos métodos diferentes para la inscripción y la autenticación. Algunos valores de autenticación son proporcionados por mecanismos de
autenticación fuera de banda, como un código QR, y algunos son legibles por humanos, como una contraseña.
Cuando un mecanismo de autenticación utiliza valores únicos por intento de autenticación (p. ej., en un mecanismo de desafío-respuesta o
cuando se utilizan contraseñas de un solo uso como segundo factor), la respuesta no es el valor de autenticación en sí.
Sin embargo, sigue siendo una buena práctica aplicar la protección de la confidencialidad a esos valores.
La protección de la confidencialidad se puede lograr utilizando un canal de comunicación encriptado o encriptación de carga útil. Esto a menudo se
hace usando protocolos o algoritmos al menos tan fuertes como el material clave transmitido, sin embargo, hay otras mitigaciones disponibles, como
la necesidad de una proximidad especial.
Disposición 5.5-8 El fabricante deberá seguir procesos de gestión seguros para los parámetros críticos de seguridad relacionados con el dispositivo.
Se recomienda enfáticamente el uso de estándares abiertos revisados por pares para parámetros de seguridad críticos (comúnmente denominados
"administración de claves").
5.6 Minimice las superficies de ataque expuestas

El "principio del mínimo privilegio" es la piedra angular de una buena ingeniería de seguridad, aplicable a IoT tanto como a cualquier otro campo de
aplicación.
Disposición 5.6-1 Todas las interfaces lógicas y de red que no se utilicen se desactivarán.
EJEMPLO 1: una IU administrativa a la que se supone que se accede desde la LAN no es accesible desde la WAN de forma predeterminada.
EJEMPLO 2: un servicio de actualización directa de firmware (DFU) expuesto a través de Bluetooth Low Energy se usa para desarrollo,
pero no se espera que se use en producción. Está deshabilitado en el producto final.
Disposición 5.6-2 En el estado inicializado, las interfaces de red del dispositivo deben minimizar la divulgación no autenticada de información
relevante para la seguridad.
La información relevante para la seguridad se puede exponer a través de una interfaz de red como parte del proceso de inicialización. Cuando
un dispositivo comparte información relevante para la seguridad al establecer una conexión, los atacantes pueden usarla para identificar
dispositivos vulnerables.
EJEMPLO 3: al encontrar dispositivos vulnerables en todo el espacio de direcciones IP,

la información podría ser información sobre la configuración del dispositivo, la versión del kernel o la versión del
software.
Disposición 5.6-3 El hardware del dispositivo no debe exponer innecesariamente las interfaces físicas al ataque.
Un atacante puede utilizar las interfaces físicas para comprometer el firmware o la memoria de un dispositivo. "Innecesariamente" se refiere a la
evaluación del fabricante de los beneficios de una interfaz abierta, utilizada para la funcionalidad del usuario o con fines de depuración.
EJEMPLO 4: un puerto micro-USB destinado a ser utilizado para alimentar el dispositivo solo está configurado físicamente para no permitir también
operaciones de comando o depuración.
Disposición 5.6-4 Cuando se pueda acceder físicamente a una interfaz de depuración, se deberá deshabilitar en el software.
EJEMPLO 5: una interfaz serial UART se deshabilita a través del software del cargador de arranque en el dispositivo. No hay aviso de inicio
de sesión ni menú interactivo disponible debido a esta desactivación.
Disposición 5.6-5 El fabricante solo debe habilitar los servicios de software que se utilizan o requieren para el uso previsto o la operación del dispositivo.
EJEMPLO 6: El fabricante no proporciona al dispositivo ningún proceso en segundo plano, extensiones del kernel,
comandos, programas o herramientas que no son necesarios para el uso previsto.
La disposición 5.6-6 Código debe minimizarse a la funcionalidad necesaria para que funcione el servicio/dispositivo.
EJEMPLO 7: El código "muerto" o no utilizado se elimina y no se considera benigno.
BÚSQUEDA
Disposición 5.6-7 El software debe ejecutarse con los privilegios mínimos necesarios, teniendo en cuenta tanto la seguridad como la funcionalidad.
EJEMPLO 8: Los demonios/procesos mínimos se ejecutan con privilegios de "raíz". En particular, los procesos que utilizan interfaces de red requieren usuarios sin
privilegios en lugar de un usuario "raíz".
EJEMPLO 9: Las aplicaciones que se ejecutan en un dispositivo que incluye un sistema operativo multiusuario (por ejemplo, Linux) utilizan diferentes
usuarios para cada componente o servicio.
Los ataques de software en dispositivos que tienen como objetivo corromper la memoria se pueden mitigar a través de mecanismos como canarios de pila,
aleatorización del diseño del espacio de direcciones (ASLR). El fabricante puede utilizar las funciones de seguridad de la plataforma donde estén disponibles para
ayudar a reducir aún más el riesgo. Reducir los privilegios en los que se ejecutan y minimizar el código también ayuda a mitigar este riesgo.
Disposición 5.6-8 El dispositivo debe incluir un mecanismo de control de acceso a nivel de hardware para la memoria.
Los exploits de software a menudo usan la falta de control de acceso en la memoria para ejecutar código malicioso. Los mecanismos de control de acceso limitan si se
pueden ejecutar los datos en la memoria del dispositivo. Los mecanismos adecuados incluyen tecnologías como MMU o MPU, protección de espacio ejecutable (por
ejemplo, bits NX), etiquetado de memoria y entornos de ejecución confiables.
Disposición 5.6-9 El fabricante debe seguir procesos de desarrollo seguros para el software implementado en el dispositivo.
Los procesos de desarrollo seguros, incluido el uso del control de versiones o la habilitación de opciones de compilación relacionadas con la seguridad (por ejemplo,
protección de pila) pueden ayudar a garantizar que los artefactos de software sean más seguros. Los fabricantes pueden usar estas opciones cuando usan cadenas de
herramientas que las admiten.
5.7 Garantice la integridad del software

Disposición 5.7-1 El dispositivo IoT del consumidor debe verificar su software utilizando mecanismos de arranque seguro.
Una raíz de confianza de hardware es una forma de proporcionar una certificación sólida como parte de un mecanismo de arranque seguro. Una raíz de confianza de
hardware es un componente de un sistema del que todos los demás componentes derivan su "confianza", es decir, la fuente de confianza criptográfica dentro de ese
sistema. Para cumplir con su función, la raíz de confianza del hardware es confiable y resistente a la manipulación tanto física como lógica, ya que no existe un
mecanismo para determinar que el componente ha fallado o ha sido alterado. Al utilizar una raíz de confianza de hardware, un dispositivo puede confiar en los resultados
de las funciones criptográficas, como las que se utilizan para el arranque seguro. Una raíz de confianza de hardware puede estar respaldada por mecanismos utilizados
para el almacenamiento seguro de credenciales u otras alternativas que proporcionen niveles básicos de garantía de seguridad proporcionales al nivel de seguridad
requerido para un dispositivo determinado.
Disposición 5.7-2 Si se detecta un cambio no autorizado en el software, el dispositivo debe alertar al usuario y/o administrador sobre el problema y no
debe conectarse a redes más amplias que las necesarias para realizar la función de alerta.
La capacidad de recuperarse de forma remota de cambios no autorizados puede basarse en un buen estado conocido, como el almacenamiento local de una
buena versión conocida para permitir la recuperación y actualización seguras del dispositivo. Esto evitará la denegación de servicio y las costosas recuperaciones
o visitas de mantenimiento, al mismo tiempo que se gestiona el riesgo de que un atacante se apodere del dispositivo trastornando la actualización u otros
mecanismos de comunicación de la red.
Si un dispositivo IoT de consumo detecta un cambio no autorizado en su software, podrá informar a la parte interesada correcta.
En algunos casos, los dispositivos pueden tener la capacidad de estar en modo de administración.
EJEMPLO: Un termostato en una habitación puede tener un modo de usuario; este modo evita el cambio de otras configuraciones. Si se detecta un cambio no
autorizado en el software, es apropiado enviar una alerta al administrador, ya que el administrador tiene la capacidad de actuar sobre la
alerta (mientras que un usuario no).
NOTA: Un ataque que obliga a un dispositivo a volver a un buen estado conocido puede presentar un riesgo DoS si el dispositivo no puede realizar esto con
éxito o si el atacante puede causar este efecto repetidamente.
5.8 Asegúrese de que los datos personales estén seguros

Disposición 5.8-1 La confidencialidad de los datos personales que transitan entre un dispositivo y un servicio, especialmente los servicios asociados, debe
protegerse con las mejores prácticas criptográficas.
BÚSQUEDA
Disposición 5.8-2 Se protegerá la confidencialidad de los datos personales sensibles comunicados entre el dispositivo y los servicios asociados,
con criptografía adecuada a las propiedades de la tecnología y el uso.
NOTA 1: En el contexto de esta disposición, los "datos personales confidenciales" son datos cuya divulgación tiene un alto potencial para causar
daño al individuo. Lo que debe tratarse como "datos personales confidenciales" varía según los productos y los casos de uso, pero
algunos ejemplos son: transmisión de video de una cámara de seguridad doméstica, información de pago, contenido de datos de
comunicación y datos de ubicación con marca de tiempo. La realización de evaluaciones de impacto en la seguridad y la protección de
datos puede ayudar al fabricante a tomar las decisiones adecuadas.
NOTA 2: Los servicios asociados en este contexto suelen ser servicios en la nube. Además, estos servicios están controlados o pueden ser
influenciados por el fabricante. Estos servicios normalmente no son operados por el usuario.
NOTA 3: La protección de la confidencialidad a menudo incluye la protección de la integridad de acuerdo con las mejores prácticas criptográficas.
Disposición 5.8-3 Todas las capacidades de detección externa del dispositivo deben documentarse de manera accesible que sea clara y transparente
para el usuario.
EJEMPLO: Una capacidad de detección externa puede ser un sensor óptico o acústico.
La cláusula 6 del presente documento contiene disposiciones específicas para la protección de datos personales.
5.9 Hacer que los sistemas sean resistentes a las interrupciones

El objetivo de las disposiciones de la presente cláusula es garantizar que los servicios de IoT se mantengan en funcionamiento a medida que aumenta la
adopción de dispositivos de IoT en todos los aspectos de la vida de un consumidor, incluidas las funciones que son relevantes para la seguridad personal.
Es importante tener en cuenta que se pueden aplicar regulaciones relacionadas con la seguridad, pero la clave es evitar que las interrupciones sean la
causa del impacto en el usuario y diseñar productos y servicios que brinden un nivel de resiliencia a estos desafíos.
Disposición 5.9-1 La resiliencia debe incorporarse a los dispositivos y servicios de IoT del consumidor, teniendo en cuenta la posibilidad de cortes de
energía y redes de datos.
Disposición 5.9-2 Los dispositivos de IoT del consumidor deben permanecer operativos y funcionales localmente en caso de pérdida de acceso a la red
y deben recuperarse limpiamente en caso de restauración de una pérdida de energía.
NOTA: "Recuperar limpiamente" normalmente implica reanudar la conectividad y la funcionalidad en el mismo o mejorado
estado.
Disposición 5.9-3 El dispositivo IoT del consumidor debe conectarse a las redes en un estado esperado, operativo y estable y de manera ordenada,
teniendo en cuenta la capacidad de la infraestructura.
EJEMPLO 1: una casa inteligente pierde la conexión a Internet después de un corte de energía. Cuando la red
se restablece la conexión, los dispositivos en el hogar se vuelven a conectar después de un retraso aleatorio para minimizar
la utilización de la red.
EJEMPLO 2: Después de que una actualización esté disponible, el fabricante notifica a los dispositivos por lotes para evitar que todos descarguen la
actualización simultáneamente.
Los consumidores confían en los sistemas y dispositivos IoT para casos de uso cada vez más importantes que pueden ser relevantes para la seguridad
o afectar la vida. Mantener los servicios funcionando localmente si hay una pérdida de red es una de las medidas que se pueden tomar para aumentar la
resiliencia. Otras medidas pueden incluir la creación de redundancia en los servicios asociados, así como mitigaciones contra ataques de denegación de
servicio distribuido (DDoS) o tormentas de señalización, que pueden ser causadas por reconexiones masivas de dispositivos después de una interrupción.
Se espera que el nivel de resiliencia necesario sea proporcional y esté determinado por el uso, teniendo en cuenta a otros que dependen del sistema,
servicio o dispositivo dado que una interrupción puede tener un impacto más amplio de lo esperado.
Reconexión ordenada significa tomar medidas explícitas para evitar solicitudes simultáneas, como actualizaciones de software o reconexiones, de una
gran cantidad de dispositivos IoT. Dichos pasos explícitos pueden incluir la introducción de un retraso aleatorio antes de un intento de reconexión de
acuerdo con un mecanismo de retroceso incremental.
5.10 Examinar los datos de telemetría del sistema

Disposición 5.10-1 Si se recopilan datos de telemetría de dispositivos y servicios de IoT de consumidores, como datos de uso y medición, se deben
examinar para detectar anomalías de seguridad.
BÚSQUEDA
EJEMPLO 1: Las anomalías de seguridad se pueden representar por una desviación del comportamiento normal del dispositivo, como
expresado por los indicadores monitoreados, por ejemplo, un aumento anormal de intentos fallidos de inicio de sesión.
EJEMPLO 2: La telemetría de varios dispositivos permite que un fabricante se dé cuenta de que las actualizaciones están fallando debido a comprobaciones
de autenticidad de actualizaciones de software no válidas.
Examinar la telemetría, incluidos los datos de registro, es útil para la evaluación de la seguridad y permite identificar de manera temprana y tratar las circunstancias
inusuales, lo que minimiza el riesgo de seguridad y permite una rápida mitigación de los problemas.
La cláusula 6 del presente documento contiene disposiciones específicas para la protección de datos personales cuando se recopilan datos de telemetría.
5.11 Facilitar a los usuarios la eliminación de datos de usuario

Disposición 5.11-1 Se debe proporcionar al usuario una funcionalidad tal que los datos del usuario se puedan borrar del dispositivo de manera sencilla.
NOTA 1: Los datos de usuario en este contexto significan todos los datos individuales que se almacenan en el dispositivo IoT, incluidos los datos personales.
datos, configuración de usuarios y material criptográfico como contraseñas o claves de usuario.
Disposición 5.11-2 Se debe proporcionar al consumidor una funcionalidad en el dispositivo tal que los datos personales puedan eliminarse de los servicios
asociados de una manera sencilla.
Dicha funcionalidad está destinada a situaciones en las que se produce una transferencia de propiedad, cuando el consumidor desea eliminar datos personales,
cuando el consumidor desea eliminar un servicio del dispositivo y/o cuando el consumidor desea deshacerse del dispositivo. Se espera que dicha funcionalidad
cumpla con la ley de protección de datos aplicable, incluido el RGPD [i.7].
Eliminar datos personales "fácilmente" significa que se requieren pasos mínimos para completar esa acción, cada uno de los cuales implica una complejidad
mínima.
Tal funcionalidad puede potencialmente presentar un vector de ataque.
Disposición 5.11-3 Los usuarios deben recibir instrucciones claras sobre cómo eliminar sus datos personales.
Disposición 5.11-4 Se debe proporcionar a los usuarios una confirmación clara de que los datos personales se han eliminado de los servicios, dispositivos y
aplicaciones.
Los dispositivos de IoT de consumo a menudo cambian de propietario y eventualmente se reciclarán o desecharán. Se pueden proporcionar mecanismos que
permitan al consumidor mantener el control y eliminar datos personales de los servicios, dispositivos y aplicaciones. Cuando un consumidor desea eliminar
por completo sus datos personales, también espera la eliminación retrospectiva de las copias de seguridad.
La eliminación de datos personales de un dispositivo o servicio a menudo no se logra simplemente restableciendo un dispositivo a su estado predeterminado
de fábrica. Hay muchos casos de uso en los que el consumidor no es el propietario de un dispositivo, pero desea eliminar sus propios datos personales del
dispositivo y todos los servicios asociados, como servicios en la nube o aplicaciones móviles.
EJEMPLO: Un usuario puede tener un uso temporal de productos IoT de consumo dentro de un apartamento alquilado. Realizar un restablecimiento de
fábrica del producto puede eliminar los ajustes de configuración o desactivar el dispositivo en detrimento del propietario del
apartamento y de un futuro usuario. Sería un mecanismo técnico inapropiado eliminar todos los datos personales en este contexto.
NOTA 2: El Anexo A del presente documento contiene un modelo de ejemplo de estados del dispositivo, incluido el almacenamiento de datos para
cada Estado.
5.12 Facilite la instalación y el mantenimiento de los dispositivos

Disposición 5.12-1 La instalación y el mantenimiento de la IoT del consumidor debe involucrar decisiones mínimas por parte del usuario y debe seguir las
mejores prácticas de seguridad sobre usabilidad.
EJEMPLO: El usuario utiliza un asistente para configurar el dispositivo donde se presenta un subconjunto de opciones de configuración
con los valores predeterminados comunes ya especificados y con las opciones de seguridad adecuadas ya activadas de forma
predeterminada.
BÚSQUEDA
Disposición 5.12-2 El fabricante debe proporcionar a los usuarios orientación sobre cómo configurar de forma segura su dispositivo.
Sin embargo, lo ideal es un proceso que implique la mínima intervención humana y que logre una configuración segura de forma automática.
Disposición 5.12-3 El fabricante debe brindar a los usuarios orientación sobre cómo verificar si su dispositivo está configurado de manera segura.
Los problemas de seguridad causados por la confusión o la configuración incorrecta del consumidor se pueden reducir y, a veces, eliminar si se
aborda adecuadamente la complejidad y el diseño deficiente en las interfaces de usuario. Una guía clara para los usuarios sobre cómo configurar los dispositivos
de forma segura también puede reducir su exposición a las amenazas.
En el caso general, la sobrecarga promedio de configurar un dispositivo de forma segura es más alta que la sobrecarga promedio de verificar si un
dispositivo está configurado de manera segura. La verificación de una configuración segura, desde el punto de vista del proceso, puede ser realizada en gran
medida por el fabricante a través de un proceso automatizado que se comunica con el dispositivo de forma remota. Parte de dicho proceso automatizado podría
incluir la validación de la capacidad del dispositivo para establecer un canal de comunicación seguro.
5.13 Validar datos de entrada

Disposición 5.13-1 El software del dispositivo IoT del consumidor deberá validar la entrada de datos a través de interfaces de usuario o transferidos a
través de interfaces de programación de aplicaciones (API) o entre redes en servicios y dispositivos.
Los sistemas pueden ser subvertidos por datos con formato incorrecto o código transferido a través de diferentes tipos de interfaz.
Los atacantes o evaluadores pueden usar herramientas automatizadas como fuzzers para explotar posibles brechas y debilidades que surgen como
resultado de no validar los datos.
EJEMPLO 1: El dispositivo recibe datos que no son del tipo esperado, por ejemplo código ejecutable en lugar de
texto ingresado por el usuario. El software en el dispositivo ha sido escrito para que la entrada sea parametrizada o "escape",
impidiendo que se ejecute este código.
EJEMPLO 2: Un sensor de temperatura recibe datos fuera de rango, en lugar de tratar de procesar esta entrada, identifica que está fuera de los límites
posibles y se descarta y el evento se captura en telemetría.
6 Disposiciones de protección de datos para el IoT del consumidor

Muchos dispositivos IoT de consumo procesan datos personales. Se espera que los fabricantes proporcionen características dentro de los dispositivos IoT de
consumo que respalden la protección de dichos datos personales. Además, existen leyes y reglamentos que se relacionan con la protección de datos
personales en dispositivos IoT de consumo (por ejemplo, el RGPD [i.7]). El presente documento pretende ayudar a los fabricantes de dispositivos IoT de
consumo a proporcionar una serie de características para la protección de datos personales desde una perspectiva estrictamente técnica.
Disposición 6-1 El fabricante deberá proporcionar a los consumidores información clara y transparente sobre qué datos personales se procesan, cómo se
utilizan, por quién y con qué fines, para cada dispositivo y servicio. Esto también se aplica a terceros que pueden estar involucrados, incluidos los anunciantes.
Disposición 6-2 Cuando los datos personales se procesen sobre la base del consentimiento de los consumidores, este consentimiento se obtendrá de manera
válida.
Obtener el consentimiento "de una manera válida" normalmente implica dar a los consumidores una opción de aceptación libre, obvia y explícita de si sus
datos personales pueden usarse para un propósito específico.
Disposición 6-3 Los consumidores que dieron su consentimiento para el tratamiento de sus datos personales tendrán la capacidad de retirarlo en
cualquier momento.
Los consumidores esperan poder preservar su privacidad mediante la configuración adecuada de la funcionalidad del servicio y el dispositivo IoT.
Disposición 6-4 Si los datos de telemetría se recopilan de los dispositivos y servicios de IoT del consumidor, el procesamiento de datos personales debe
mantenerse al mínimo necesario para la funcionalidad prevista.
Disposición 6-5 Si los datos de telemetría se recopilan de los dispositivos y servicios de IoT del consumidor, los consumidores recibirán información sobre qué
datos de telemetría se recopilan, cómo se utilizan, por quién y con qué fines.
BÚSQUEDA
Anexo A (informativo):
Conceptos básicos y modelos.
A.1 Arquitectura
Un dispositivo IoT de consumo es una colección de componentes de hardware y software, generalmente con interfaces físicas que
también pueden ser interfaces de red. Un ejemplo general y un ejemplo sofisticado específico de "altavoz inteligente" se muestran a
continuación en la Figura A.1. Estas arquitecturas son informativas y no se espera que un dispositivo tenga todos o algunos de los
componentes ilustrados.
Figura A.1: Ejemplos de una arquitectura general de un dispositivo y de una arquitectura para un Altavoz Inteligente
El IoT del consumidor implementado en el hogar a menudo consistirá en una variedad de dispositivos restringidos y no restringidos
que se conectarán a la LAN, ya sea directamente a través de conectividad IP, como Ethernet o Wi-Fi®, o indirectamente a través de
una puerta de enlace o centro. Esta conexión indirecta a la LAN generalmente utilizará conectividad no IP (por ejemplo, protocolos
basados en IEEE 802.15.4 [i.24]). Luego, un enrutador conectará la LAN a la WAN (es decir, Internet). Sin embargo, en algunos casos,
un dispositivo dentro del hogar puede conectarse directamente a la WAN a través de otras conexiones IP o no IP (como GSM o
LoRaWAN).
BÚSQUEDA
Los dispositivos de IoT del consumidor en el hogar a menudo se conectarán hacia afuera (o se conectarán) a servicios en línea o locales.
En el presente documento, aquellos que son incluidos por el fabricante (por ejemplo, telemetría, o una aplicación móvil complementaria)
o que deben instalarse como parte de la inicialización se clasifican como servicios asociados, en los casos en que el
el usuario elige instalar un servicio o acceder a contenido externo, estos no contarían como servicios asociados. Por ejemplo,
algunos escenarios:
• los sitios web a los que se accede a través del navegador de un dispositivo probablemente no sean servicios asociados, ya que el usuario
decide acceder a ellos, no el desarrollador del software del dispositivo;
• aplicaciones de software (como una "aplicación" que podría instalarse en un Smart TV) que se ejecutan en un dispositivo; si
están instalados por defecto, generalmente se clasificarían como servicios asociados. Si por el contrario se instalan a través
de una tienda a elección del usuario, entonces no estarían asociados;
• la conexión a una plataforma de telemetría sería un servicio asociado, ya que suele estar preconfigurado por el fabricante
del dispositivo.
La figura A.2 proporciona un ejemplo de una arquitectura para este modelo de implementación. El límite de 'casa' representa la
extensión aproximada del alcance definido para el presente documento, incluida la comunicación con los servicios asociados.
Figura A.2: Ejemplo de una arquitectura de referencia para la implementación de IoT de consumo en un entorno doméstico
La Figura A.3 muestra un ejemplo, realista, de implementación de IoT de consumo dentro de un hogar. Los siguientes casos de uso
ilustran cómo se usaría esta configuración y aclaran qué se cubriría y qué no en las definiciones:
• La Smart TV se comunica con dos servicios externos. El primero es el Servicio de telemetría de dispositivos (un
servicio asociado); esto captura, con el permiso del usuario, información del televisor, como registros de fallas y datos sobre
el uso, para permitir que los desarrolladores corrijan los defectos del software y prioricen el desarrollo de nuevas funciones. El
Smart TV también se conecta a un Servicio de video compartido a través de una aplicación descargada por el usuario después
de la inicialización. Este Servicio de video compartido permite al usuario ver entretenimiento a través de una aplicación de
terceros, que se puede instalar dentro del sistema operativo que usa el televisor. Este servicio de streaming no sería un servicio
asociado.
• El Gateway brinda acceso a una variedad de dispositivos restringidos, incluida una malla IEEE 802.15.4 [i.24]
red y un sensor de luz, utilizados para monitorear y administrar el hogar. Se conecta a un servicio de acceso a la nube que
permite al usuario controlar su Smart Lock de forma remota y ver los datos de los sensores. Este es un servicio asociado.
BÚSQUEDA
• El Frigorífico Inteligente tiene un navegador web instalado; esto le permite al usuario ver los titulares de un sitio web de noticias mientras
está cerca. La web de noticias no sería un servicio asociado.
• El sensor meteorológico es utilizado por el usuario para comprobar la temperatura exterior de su casa. Como está físicamente alejado de la
propia casa, no puede conectarse a la LAN. En cambio, se comunica a través de GSM directamente con la WAN. El servicio al que se
conecta el sensor meteorológico es un servicio asociado.
Figura A.3: Arquitectura de ejemplo de una implementación de IoT de consumidor
A.2 Estados del dispositivo

El desmantelamiento de dispositivos está fuera del alcance del presente documento. Un dispositivo dado de baja se encuentra en un estado
en el que no hay datos confidenciales. Un dispositivo (desde la fabricación hasta el desmantelamiento) hará la transición entre varios estados.
Estas transiciones se ilustran en la Figura A.4, para aclarar cómo se podrían usar los estados definidos en un dispositivo. En este modelo, un
dispositivo dado de baja estaría en el estado predeterminado de fábrica, ya que es probable que el proceso de restablecimiento de fábrica sea el
proceso utilizado para eliminar todos los datos y la configuración del usuario.
EJEMPLO 1: Cuando se da de baja, un dispositivo se puede reciclar, revender o destruir.
BÚSQUEDA
Figura A.4: Diagrama de estado para estados de dispositivos IoT de consumo
Dentro de estos estados, la Figura A.5 muestra un modelo de ejemplo de qué datos se almacenarían dentro de un dispositivo arbitrario. No se
espera que esto sea lo mismo para todos los casos.
Figura A.5: Modelo de almacenamiento de dispositivo de ejemplo en estados
BÚSQUEDA
Anexo B (informativo):
Declaración de conformidad de implementación pro forma
Sin perjuicio de las disposiciones de la cláusula de derechos de autor relacionadas con el texto del presente documento, ETSI garantiza
que los usuarios del presente documento pueden reproducir libremente la proforma en el presente anexo para que pueda usarse para los
fines previstos y puedan publicar la versión completa. anexo que incluye la Tabla B.1.
La Tabla B.1 puede proporcionar un mecanismo para que el usuario del presente documento (que se espera que sea una entidad involucrada
en el desarrollo o fabricación de IoT de consumo) brinde información sobre la implementación de las disposiciones del presente documento.
La columna de referencia hace referencia a las disposiciones del presente documento.
La columna de estado indica el estado de una disposición. Se utilizan las siguientes notaciones:
METRO
la disposición es un requisito obligatorio
R la disposición es una recomendación
MC la disposición es un requisito obligatorio y condicional
RC la disposición es una recomendación y condicional
NOTA: Cuando se usa la notación condicional, está condicionada al texto de la disposición. Las condiciones se proporcionan en la parte
inferior de la tabla con referencias proporcionadas para las disposiciones relevantes para ayudar con la claridad.
La columna de soporte puede ser llenada por el usuario del presente documento. Se utilizan las siguientes notaciones:
Y apoyada por la implementación
norte
no soportado por la implementación
N/A la disposición no es aplicable (permitido solo si una disposición es condicional como se indica en la columna de
estado y si se ha determinado que la condición no se aplica al producto en cuestión)
La columna de detalle puede ser llenada por el usuario del presente documento:
• Si una disposición está respaldada por la implementación, la entrada en la columna de detalles debe contener información sobre
las medidas que se han implementado para lograr el respaldo.
• Si una disposición no está respaldada por la implementación, la entrada en la columna de detalle debe contener información sobre
las razones por las cuales la implementación no es posible o no es apropiada.
• Si una disposición no es aplicable, la entrada en la columna de detalle debe contener la justificación de esta determinación.
Tabla B.1: Implementación de disposiciones para la seguridad de IoT del consumidor
Número y título de la cláusula

Estado de referencia 5.1 Sin Apoyo Detalle
contraseñas predeterminadas universales
Disposición 5.1-1 MC (1)
Disposición 5.1-3 METRO

5.2 Implementar un medio para gestionar los reportes de vulnerabilidades
Disposición 5.2-2 R
BÚSQUEDA

Referencia Estado Apoyo Detalle
5.3 Mantener el software actualizado
Disposición 5.3-1
Disposición 5.3-2 RMC (5)
Disposición 5.3-4 RC (12)
Disposición 5.3-6 RC (9, 12)
Disposición 5.3-10 M (11, 12)
Disposición 5.3-13 M Disposición
5.3-14 RC (3, 4)
Disposición 5.3-15 RC (3, 4)
Disposición 5.3-16 M 5.4 Almacenar
de forma segura parámetros de seguridad confidenciales


Disposición 5.4-4 5.5 METRO
Comunicarse de forma segura

Minimizar las superficies de ataque expuestas

5.7 Garantizar la integridad del software

Disposición 5.7-1 R Disposición
5.7-2 R 5.8 Garantizar que los
datos personales estén seguros
Hacer que los sistemas sean resistentes a las interrupciones

5.10 Examinar los datos de telemetría del sistema

5.11 Facilitar a los usuarios la eliminación de datos de usuario
Disposición 5.11-1 M Disposición
5.11-2 R Disposición 5.11-3
R
BÚSQUEDA

Referencia Estado Soporte Detalle
5.12 Facilite la instalación y el mantenimiento de los dispositivos
Disposición 5.12-1 R Disposición
5.12-2 R Disposición 5.12-3 R
5.13 Validar datos de entrada
Disposición 5.13-1 M
6 Disposiciones de protección de datos para el IoT del consumidor
Provisión 6.1 M Provisión 6.2 MC
(7)
Disposición 6.3 M Disposición
6.4 RC (6)
Disposición 6.5 MC (6)
Condiciones
1) se utilizan contraseñas; 2) se
utilizan contraseñas preinstaladas; 3) los
componentes de software no son actualizables; 4) el dispositivo
está restringido; 5) el dispositivo no está restringido; 6) datos
de telemetría que se recopilan; 7) los datos personales se
procesan sobre la base del consentimiento de los
consumidores; 8) el dispositivo que permite la autenticación del usuario; 9) el dispositivo
admite actualizaciones automáticas y/o notificaciones de actualización; 10) se utiliza una
identidad codificada única por dispositivo con fines de seguridad; 11) las actualizaciones se
entregan a través de una interfaz de red; 12) se implementa un mecanismo de actualización; 13)
una interfaz de depuración es físicamente accesible.
BÚSQUEDA
Historia
Historia del documento
V1.1.1 febrero 2019 Publicación como ETSI TS 103 645
V2.0.0 Noviembre de 2019 Procedimiento de aprobación de EN AP 20200224: 2019-11-26 a 2020-02-24
V2.1.0 abril 2020 Votar V 20200619: 2020-04-20 a 2020-06-19
BÚSQUEDA

ETSI en - 303645v020100v

Cargado por

Copyright:

Formatos disponibles

ETSI en - 303645v020100v

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

ETSI en - 303645v020100v

Cargado por

Copyright:

Formatos disponibles

Machine Translated by Google

Borrador final ETSI EN 303 645 V2.1.0 (2020-04)

Seguridad cibernética para Internet de las cosas del consumidor:

2 Borrador final ETSI EN 303 645 V2.1.0 (2020-04)

650 Camino de las luciérnagas

Teléfono: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16

Siret No. 348 623 562 00017 - NAF 742 C

El presente documento puede descargarse de: http://

Notificación de derechos de autor

3 Borrador final ETSI EN 303 645 V2.1.0 (2020-04)

Prólogo .................................................. .................................................... .................................................... ........ 4

Terminología de los verbos modales ............................................... .................................................... .................................... 4

Introducción ................................................. .................................................... .................................................... ... 4

1 Alcance ................................................. .................................................... .................................................... ... 6

Referencias .................................................. .................................................... ............................................. 6 Referencias

Definición de términos, símbolos y abreviaturas ............................................... ............................................ 9

4 Implementación de informes .................................................. .................................................... ..................... 12

6 Disposiciones de protección de datos para el IoT del consumidor .................................. ............................................. 24

Anexo A (informativo): Conceptos básicos y modelos .............................................. ............................. 25

A.1 Arquitectura ................................................ .................................................... ............................................. 25

A.2 Estados del dispositivo .............................................. .................................................... ............................................. 27

Anexo B (informativo): Declaración de conformidad de implementación pro forma ........................... 29

Historia ................................................. .................................................... .................................................... ........ 32

4 Borrador final ETSI EN 303 645 V2.1.0 (2020-04)

Derechos de propiedad intelectual

Fechas de transposición nacional propuestas

Fecha de la última publicación de la nueva norma nacional o aprobación

Terminología de los verbos modales

5 Borrador final ETSI EN 303 645 V2.1.0 (2020-04)

6 Borrador final ETSI EN 303 645 V2.1.0 (2020-04)

• juguetes para niños conectados y monitores para bebés;

• detectores de humo conectados, cerraduras de puertas y sensores de ventanas;

• cámaras, televisores y parlantes inteligentes;

• rastreadores de salud portátiles;

• electrodomésticos conectados, como lavadoras y frigoríficos; y

• asistentes domésticos inteligentes.

2.1 Referencias normativas

7 Borrador final ETSI EN 303 645 V2.1.0 (2020-04)

2.2 Referencias informativas

NOTA: Disponible en https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf.

[i.4] ISO/IEC 29147: "Tecnología de la información - Técnicas de seguridad - Divulgación de vulnerabilidades".

NOTA: Disponible en https://www.iso.org/standard/45170.html.

[i.5] OASIS: "Marco común de informes de vulnerabilidad (CVRF) de CSAF".

NOTA: Disponible en http://docs.oasis-open.org/csaf/csaf-cvrf/v1.2/csaf-cvrf-v1.2.html.

NOTA: Disponible en https://www.gov.uk/government/collections/secure-by-design.

NOTA: Disponible en https://www.iotsecurityfoundation.org/wp-content/uploads/2018/12/IoTSF-IoT-Security Compliance-Framework-

[i.11] GSMA: "Pautas y evaluación de seguridad de IoT de GSMA".

NOTA: Disponible en https://www.gsma.com/iot/iot-security/iot-security-guidelines/.

NOTA: Disponible en el Diario Oficial de la Unión Europea, https://eur-lex.europa.eu/legal

[i.14] Caballo de Cobre: "Mapeo de Seguridad y Privacidad en el Internet de las Cosas".

NOTA: Disponible en https://iotsecuritymapping.uk/.

8 Borrador final ETSI EN 303 645 V2.1.0 (2020-04)

[i.15] ENISA: "Recomendaciones de seguridad de referencia para IoT - Herramienta interactiva".

NOTA: Disponible en https://www.enisa.europa.eu/topics/iot-and-smart-infrastructures/iot/baseline-security

NOTA: Disponible en https://www.iotsecurityfoundation.org/wp-content/uploads/2018/11/Vulnerability

NOTA: Disponible en https://blog.f-secure.com/iot-threats/.

[i.18] W3C: "Web de las Cosas en el W3C".

NOTA: Disponible en https://www.w3.org/WoT/.

NOTA: Está en desarrollo.