Fundamentos de la seguridad en el IoT

El proceso PDCA

PLAN (planificar)

Como sucede con cualquier proyecto, el desarrollo de un ecosistema IoT seguro comienza con un plan sólido que debe garantizar que los problemas de seguridad se abordan lo antes posible en el ciclo de desarrollo.

Este plan tiene que identificar los riesgos de negocio y los recursos de alta prioridad que requieren protección y deberían incluir una evaluación de riesgos rigurosa y la puesta en marcha de las medidas de seguridad necesarias para la mitigación efectiva de las amenazas.

El modelo y la evaluación de riesgos se convierten en la práctica de seguridad clave y la metodología STRIDE (Figura 2), creada por los ingenieros de seguridad de Microsoft, es una herramienta usada normalmente en esta fase.

El resultado de esta evaluación es un documento que forma la base del enfoque de gestión de riesgo integrado del cliente y facilita la futura conformidad y la certificación oficial.

DO (hacer): diseño de la arquitectura de seguridad en el IoT

Las conclusiones de la evaluación de amenazas ahora tienen que incorporarse en el diseño de la arquitectura de seguridad de la solución IoT. El ámbito de este diseño alcanza tanto al hardware como al software y, para garantizar la adaptación a los ciberataques en evolución, los profesionales deben asegurarse de lo siguiente:

• Cualquier dispositivo IoT posee una ID exclusiva que no se puede clonar, poniendo los cimientos para el resto de las funciones de seguridad. Esta funcionalidad raíz de confianza – Root of Trust (RoT) permite que todas las partes confíen en la identidad, la autenticación, la comunicación y los datos procedentes del dispositivo. El RoT también ofrece las capacidades criptográficas de hardware y software requeridas para respaldar funciones de confianza y capas API y posibilitar que las aplicaciones externas acceden a dichas capacidades.
• La CPU, la memoria y la conectividad no se pueden usar en tareas no designadas, limitando así la amenaza de las actividades de los piratas informáticos.
• La privacidad, la confidencialidad y la conformidad regulatoria quedan garantizadas al proteger la integridad de todos los datos, tanto estáticos como en movimiento.
• Las decisiones tomadas usando los datos de un ecosistema IoT se ejecutan en un entorno seguro, a salvo de sabotaje y vulneración de propiedad intelectual.
• Cualquier comando enviado a un dispositivo IoT (por ejemplo, “inyectar insulina”, “abrir / cerrar la válvula”, “activar los frenos”, etc.) se valida en cuanto proviene de una fuente válida.

Esta fase del proyecto resulta esencial al establecer una arquitectura de seguridad IoT eficaz y requiere el uso de una fuente experta. Pero estas fuentes escasean en la industria y la retención puede ser más complicada por la naturaleza cíclica del desarrollo de producto: el diseño de seguridad se suele hacer una sola vez y, posteriormente, se reutiliza para toda una familia de producto, lo que significa que los recursos de seguridad internos no se pueden usar continuamente. Por lo tanto, parece tener sentido que muchas organizaciones consideren trabajar con socios externos, que no sólo ofrecen la experiencia de diseño de seguridad requerida, sino también dotan de asesoramiento y orientación durante el proceso PDCA de principio a fin.

Tras completar la fase DO (hacer) del proceso PDCA, el diseño de la arquitectura segura está listo para someterse a las pruebas.

CHECK (verificar): defender, atacar y marcar

Para garantizar que el dispositivo satisface las necesidades de seguridad de su mercado objetivo, debe ser testado para recibir la conformidad o la certificación oficial de un organismo independiente, como la CSPN. Las pruebas de una organización independiente evitan los conflictos de intereses que se pudieran producir con organismos y estándares respaldados por las empresas, como los Criterios Comunes (Common Criteria), y aseguran la objetividad del proceso. La evaluación del nivel de seguridad de un dispositivo IoT requiere el uso de las referencias y las metodologías aceptadas para valorar su robustez ante las amenazas identificadas formalmente. Dicha evaluación se puede llevar a cabo usando un enfoque cuantitativo o cualitativo.

Attack scoring es un método cuantitativo ampliamente usado donde el nivel de confianza en la evaluación (Evaluation Assurance Level – EAL) se depura con una puntuación determinada a través de un proceso de investigación, dirigido por un laboratorio de seguridad independiente. Los dos mecanismos de puntuación que se aplican normalmente son la metodología Joint Interpretation Library, usada por la CSPN, o el Common Vulnerability Scoring System (CVSS), gestionado por FIRST (Forum of Incident Response and Security Teams – Foro de Equipos de Respuesta a Incidentes y Seguridad).

Las evaluaciones cualitativas, también llevadas a cabo por laboratorios de seguridad independientes, comprueban las brechas de seguridad en el dispositivo, que podrían respaldar el éxito de los ataques de alta probabilidad y elevado impacto. El grado de evaluación de esta metodología se basa en el nivel de experiencia y la complejidad de las herramientas que serían necesarias para organizar un ataque realista. Este enfoque establece un nivel de seguridad o confianza en el dispositivo, con el nivel asignado que se puede alcanzar al testar los fallos de actividad y revelar una brecha para el ataque definido.

Un análisis desde el punto de partida cualitativo es suficiente para la mayoría de productos IoT y esta valoración se puede simplificar para aquellos productos basados en dispositivos que ya han pasado un proceso de evaluación de seguridad, como los módulos IoT móviles del catálogo de u-blox. Los módulos certificados como estos se someterán a evaluaciones extensas, simulando los caminos de ataque típicos y comprobando la seguridad embebida de los dispositivos ente las amenazas, incluyendo la inyección de fallas y un análisis de ataque de canal lateral. Al integrar módulos que han sido testados a este nivel, los desarrolladores se aseguran de que un “atacante” con acceso físico al dispositivo no podrá derribar las contramedidas de seguridad y que los algoritmos criptográficos, las claves privadas y otras funciones mantienen la seguridad.

ACT (actuar)

Tras las fases de planificación, diseño y evaluación, la seguridad del dispositivo IoT se debe desplegar, adecuar y mantener a lo largo de todo el ciclo de vida.

Aunque las implementaciones de seguridad de software pueden ser suficientes en situaciones de poco valor de negocio y amenaza “baja”, los dispositivos empleados en aplicaciones de alto valor y elevada exposición requieren una RoT de hardware, disponible en un lugar de confianza, durante la fase de producción. Los retos de seguridad de los despliegues de ecosistemas IoT a gran escala también deben demandar la inclusión de características como aprovisionamiento sin contacto, zero-touch provisioning, conectividad de nube (cloud) segura y gestión de clave eficiente de alimentación y ancho de banda.

La reducción de la exposición en vivo a las amenazas de seguridad requiere la recopilación y la monitorización de grandes cantidades de datos de fuentes internas y externas. A pesar de que esto puede ser una tarea exigente, resulta crucial garantizar la detección oportuna y las medidas correctivas de las amenazas. Las organizaciones sin las fuentes internas necesarias deberían considerar seriamente trabajar con un socio contrastado en esta actividad.