1. Introducción
Esta primera parte del estándar UL 2900 aplica a productos con conexión a internet que deben ser evaluados contra vulnerabilidades, malware y brechas de seguridad definiendo para ellos los requisitos generales a cumplir desde un punto de vista software, es decir, no contiene requisitos pare verificar la operación funcional del producto ni tampoco requisitos de hardware.
- A grandes rasgos, este estándar describe:
- a) Los requisitos documentales para poder afrontar la evaluación de forma satisfactoria.
- b) Requisitos con respecto a la presencia de control de riesgos de seguridad en la arquitectura y el diseño del producto.
- c) Requisitos con respecto al proceso de gestión de riesgos de los desarrolladores.
- d) Métodos para evaluar un producto en presencia de vulnerabilidades y malware.
- e) Las técnicas para asegurar que el código fuente no contiene ninguna vulnerabilidad diferente a las que se ha identifique en el proceso de gestión de riesgos.
En las siguientes secciones y subsecciones se describen a alto nivel los requisitos de seguridad que deben cumplir el producto y el proveedor para superar con éxito toda la evaluación.
2. Requisitos documentales
El vendedor deberá proporcionar documentación del producto que describa las funciones de diseño, seguridad y gestión de riesgos del mismo, identificando todos sus interfaces y uso, así como identificando todas las librerías y código ejecutable contenidas en el producto.
La documentación de diseño deberá contener un análisis de riesgos del producto conforme se detalla en este estándar y que permita evaluar cada uno de los riesgos especificados en el mismo.
Por otra parte, la documentación de uso del producto deberá demostrar el cumplimiento de los objetivos generales de seguridad durante todo el ciclo de vida del producto, lo cual implica que se den indicaciones de configuración y uso seguros, de actualización del software, de entorno de uso y de protocolos utilizados, así como de los métodos de autorización y autenticación utilizados.
3. Control de riesgos
El producto deberá cumplir con todos los requisitos de control de riesgos definidos a en las siguientes subsecciones, teniendo en cuenta que, será necesario llevar a cabo un análisis de riesgos para las medidas que no se cumplan o implementen.
3.1. Control de accesos, autenticación y autorización
El producto deberá integrar medidas de autenticación y autorización para las operaciones que puedan afectar a su seguridad, implementando mecanismos que prevengan la autorización perpetua implementando medidas como límite de tiempo de inactividad
Por otra parte, si permite hacer uso de credenciales de autenticación, deberá permitir poder configurar la complejidad y longitud de la contraseña respetando que tenga al menos 6 caracteres, e implementando medidas contra ataques de fuerza bruta como puede ser el uso de retardos para nuevos intentos de autenticación por cada 10 intentos fallidos.
En caso de hacer uso de autenticación basada en roles, el producto deberá permitir llevar a cabo administración de la lista de usuarios, pudiendo modificar sus privilegios y asegurando que en caso de usar mecanismos de autenticación distintos a usuario/contraseña (uso de certificado, por ejemplo), estos no pueden ser “bypaseados”.
3.2. Comunicación remota
Para las comunicaciones llevadas a cabo de forma remota, el producto deberá asegurar la integridad y autenticidad de toda la comunicación remota implementando mecanismos tales como: hash, firma digital, MAC, etc.
3.3. Información sensible
El producto deberá asegurar la confidencialidad de la información sensible generada, almacenada, utilizada o comunicada por el mismo haciendo uso de los mecanismos adecuados que se detallan en el Apéndice B de este estándar (Algoritmos de cifrado y descifrado basados en claves simétrica o asimétrica).
3.4. Gestión del producto
El producto deberá implementar mecanismos de actualización y mecanismos para revertir actualizaciones fallidas, para ello, será necesario que se implementen medidas para verificar la autenticidad y la integridad de las actualizaciones en modo online y offline (MAC, firma digital, hash, etc..).
También deberá implementar un log de eventos de seguridad relacionados con intentos de autenticación, cambios de credenciales de acceso, actualizaciones fallidas, etc. Este log de eventos deberá estar almacenado en una memoria no volátil evitando que usuarios sin permiso puedan modificarlo o borrarlo.
Con respecto al decomisado del producto, el mismo debe ser capaz de permitir borrado de datos de configuración, información sensible e información personal haciendo uso de uno de los mecanismos detallados en la SP 800-88.
4. Gestión de riesgos
De cara a poder llevar a cabo una buena gestión de riesgos, el vendedor deberá llevar a cabo las siguientes tareas durante la fase de diseño:
- Identificación de todas las funcionalidades del producto, así como de todos los datos sensibles asociados a las mismas.
- Lista de amenazas identificando las funcionalidades y datos a los que afecta, así como el análisis de impacto de las mismas, considerando su probabilidad de ocurrencia, los datos que pueden verse afectados y las suposiciones de uso del producto del vendedor.
- Establecimiento de controles de riesgos para reducir el riesgo de las amenazas a un nivel aceptable, considerando los controles de las secciones anteriores (8 a 11) y controles adicionales y definiendo una matriz de trazabilidad que mapee riesgos a controles.
La clasificación de las posibles amenazas identificadas se debe llevar a cabo haciendo uso de esquemas conocidos como son el Common Attack Pattern Enumeration and Classification (CAPEC) o el Damage, Reproducibility, Eploitability, Affected Users, Discoverability (DREAD).
Adicionalmente, en caso de que las amenazas identificadas sean vulnerabilidades conocidas asociadas al software, el análisis de riesgos deberá:
- Describir la amenaza e indicar su identificador asociado en el Common Weakness Enumeration (CWE)
- Identificar las partes del software a las que afecta.
- Mostrar el resultado del análisis de riesgos para la misma, así como medidas adicionales de control para reducir el riesgo residual.
5. Vulnerabilidades y exploits
5.1. Test de vulnerabilidades conocidas
Todo el código fuente incluyendo el de terceros, deberá ser testeado para verificar que no contiene vulnerabilidades conocidas excepto las aceptadas con riesgo aceptable por el vendedor en el apartado anterior. Las vulnerabilidades conocidas pueden consultarse en el National Vulnerability Database (NVD).
5.2. Test de malware
Se debe analizar el código en busca de malware pudiendo hacer uso de herramientas de malware en función del sistema operativo sobre el que se instala el producto.
5.3. Fuzz testing
Se requiere hacer uso de fuzzing para verificar que el uso de entradas inválidas o inesperadas en las interfaces de entrada del dispositivo, no causa ningún comportamiento inesperado como reinicios, corrupción de los datos almacenados, reinicio de la configuración, revelado de información, modificación de información o fallos del sistema sin que se recupere de los mismos antes de alcanzar los dos minutos de test.
5.4. Test de intrusión
El producto no debe contener vulnerabilidades conocidas que permitan completar el test de intrusión en 2 minutos o menos. Los test de intrusión deben tratar de eludir los controles de riesgos utilizados por el producto, intentando producir una denegación de servicio, explotando vulnerabilidades calificadas con riesgo aceptable, consiguiendo credenciales de acceso o elevación de privilegios. Adicionalmente se pueden usar herramientas para escaneo de puertos y servicios y herramientas de explotación y scripts.
6. Bugs de seguridad del software
6.1. Análisis de bugs de seguridad
El código fuente no puede tener bugs de seguridad que no se contemplen dentro de los clasificados como aceptados en el análisis de riesgos. Para llevar a cabo el análisis del código se puede hacer uso de análisis estático fuente y análisis estático de binario y bytecode.
7. Conclusión
Este breve articulo proporciona una visión rápida sobre los requisitos generales que deben cumplir los dispositivos que se van a evaluar contra los requisitos del estándar 2900 para hacer frente a posibles amenazas, malware y brechas de seguridad. Debido a que estos requisitos generales se aplican a los dispositivos conectables a la red de los sistemas de salud y bienestar (UL 2900-2-1), los sistemas de control industrial (UL 2900-2-2) y los sistemas de señalización de seguridad y protección de la vida (UL 2900-2-3), será necesario consultar cada uno de estos documentos además de la UL 2900-1 para conocer en profundidad todas las características de seguridad y los requisitos documentales que deben cumplirse teniendo en cuenta el nivel de seguridad contra el producto que se va a evaluar o contar con la ayuda de un experto en el sector como jtsec Beyond IT Security, donde a través de sus servicios E-Health e Industrial-IoT, pondrá encontrar el soporte necesario para desarrollar su dispositivo, así como para verificar si cumple con el estándar requerido en caso de que ya haya sido desarrollado.
