El creciente número de dispositivos IoT ha hecho plantearse a la industria la necesidad de una metodología de evaluación específica para este tipo de productos.
Cuando hablamos de metodologías de evaluación de seguridad TIC, la que lleva más años establecida en el mercado es Common Criteria. Por esto, la metodología SESIP se diseñó usando los principios y nomenclatura utilizada en Common Criteria, de forma que sea de fácil adopción para todas las partes implicadas en la certificación.
Entones, la pregunta que surge es: ¿realmente es necesaria una metodología específica para IoT?, Veámoslo.
¿Porque necesitamos una metodología para IoT?
Los dispositivos IoT, tienen ciertas características que los diferencian de cualquier otro producto IT.
Ciclo de vida
Para comenzar son dispositivos físicos que, a diferencia de otro tipo de productos, tienen un ciclo de vida específico:
- El fabricante proporciona el producto al usuario.
- Este lo personaliza introduciendo los datos y configuraciones pertinentes.
- El usuario utiliza el producto, actualiza su firmware y eventualmente, puede hacer un “reset” a configuración de fábrica, volviendo al segundo punto.
- Finalmente, el usuario no necesita más el producto, en algunos casos devolviéndolo al fabricante.
Una metodología de evaluación orientada a IoT puede centrarse en este ciclo de vida, mientras que una metodología genérica no tiene esta capacidad.
Entorno y amenazas
Al acotar a productos IoT, la metodología SESIP puede acotar el tipo de amenazas que tiene que cubrir un dispositivo de este tipo.
En este aspecto SESIP define un escenario base en el que hay que comprobar la fortaleza e idoneidad de los mecanismos de seguridad para proteger al producto de ataques por sus interfaces de red. No obstante, en este escenario el atacante puede contar con un dispositivo físico para realizar ingeniería inversa con la única limitación del potencial de ataque durante la fase de preparación del ataque.
Este escenario inicial se puede ampliar con acceso físico y software no confiable.
La ampliación con acceso físico es simplemente añadir al escenario base la posibilidad de que el atacante pueda tener acceso físico al producto a la hora de ejecutar el ataque.
Cuando ampliamos con software no confiable se pretende comprobar la resistencia del producto a actualizar/remplazar el software legitimo del producto con software malicioso.
¿Y como definimos que en nuestro alcance se incluyen estas ampliaciones? Muy fácil, simplemente añadiendo la funcionalidad de seguridad (SFRs) que protegen ante dicho tipo de ataques.
Modularidad y reusabilidad
Cualquier dispositivo IoT es una combinacion de hardware, software y firmware que en conjunto proporciona su funcionalidad final.
Si un mismo procesador o librería criptográfica se esta utilizando por distintos fabricantes para desarrollar sus productos ¿Qué sentido tiene evaluar varias veces la funcionalidad proporcionada por estos?
SESIP es una metodología que tiene como una de sus prioridades apoyarse en las evaluaciones de los distintos elementos que componen un producto, centrándose en como se realiza la integración de estos y la funcionalidad de seguridad proporcionada no previamente evaluada.
¿Es fácil certificarse con esta metodología?
SESIP ofrece a los fabricantes una forma sencilla de demostrar la seguridad de sus productos.
Entregables flexibles
A diferencia de Common Criteria, los entregables (documentación) que hay que generar para esta metodología no tiene una estructura tan estricta, SESIP se centra en que la información necesaria para llevar a cabo la evaluación llegue al evaluador, independientemente de su formato.
Por lo tanto, los desarrolladores, en la mayoría de los casos, no tienen que generar documentación específica para la evaluación, a parte de la declaración de seguridad.
Autoevaluación
SESIP tiene cinco niveles de aseguramiento (assurance). Esto implica que cuanto más alto es el nivel de aseguramiento, más información tiene que proporcionar el desarrollador y el laboratorio tiene que realizar pruebas más exigentes.
El primer nivel de aseguramiento (SESIP1), el desarrollador realiza una autoevaluación, indicando en un documento como el producto implementa las distintas funcionalidades de seguridad. El laboratorio analizará dicho documento, dando un veredicto sobre el mismo.
Este nivel facilita la entrada de los desarrolladores que no están acostumbrados a este tipo de metodologías. Niveles de aseguramiento mayores implican pruebas de caja negra, caja blanca…
