Gestionar la seguridad del Internet de las cosas

Pablo Ballarín Usieto

linkedin

 

RESUMEN

Como profesional de la Ciberseguridad, me encuentro cada vez más escenarios de riesgo asociados a dispositivos que entran dentro de la categoría de Internet of Things (IoT) y que son incorporados de forma masiva por las organizaciones, ya sea directamente (software SCADA) o en forma de wearable technology, smart cars o dispositivos de salud y fitness usados por los trabajadores.

Llevamos tiempo hablando de esta tecnología como si conociéramos en detalle de qué se trata, y de las implicaciones que tiene en cuanto a seguridad, y en algunos casos hasta de cómo podemos gestionarlo. ¿Pero qué sabemos realmente?

Con este artículo pretendo aportar un poco de luz a esta nueva situación, respondiendo a las siguientes preguntas: ¿Cuáles son las vulnerabilidades? ¿Cuál es el estado de la regulación? ¿De qué manera podemos afrontar el nuevo riesgo?

 

VULNERABILIDADES: El nuevo escenario en las organizaciones

La siguiente analogía refleja la situación paradójica que existe en muchas organizaciones a través de la introducción de lo que se empieza a llamar el Internet Of Insecure Things (1). Imaginemos que en nuestro propio hogar hubiéramos pasado los últimos años guardando los objetos de valor en cajas fuertes, y hubiéramos reforzado la seguridad global a través de sensores, puertas blindadas y empresas de vigilancia, para luego tirar todo por la borda al hacer una reforma necesaria pero que requiriera tirar abajo paredes que dieran acceso a nuestra caja fuerte original.

¿Qué dispositivos entrarían dentro de la categoría de IoT? Realmente cualquier objeto cotidiano que disponga de algún tipo de sensor y capacidades de interconexión hacia el exterior que le permita intercambiar información, logrando con ello un aumento de sus funcionalidades y una mayor independencia. Termostatos (smart grids), software SCADA, fotocopiadoras, dispositivos médicos, dispositivos fitness, vehículos inteligentes, frigoríficos o cámaras web IP son objetos que han multiplicado sus capacidades y su valor para el cliente final que los adquiere. Al igual que ocurre en muchas tecnologías emergentes, se ha puesto el foco en la usabilidad y la innovación, y se ha dejado de lado la seguridad.

Grafico1

Las vulnerabilidades abarcan generalmente los siguientes ámbitos:

  • Interfaz Web Insegura
  • Autenticación y Autorización insuficientes
  • Servicios de transmisión inseguros
  • Falta de medidas de cifrado
  • Problemas de privacidad
  • Interfaces inseguros con servicios en la nube y servicios móviles
  • Software/Firmware inseguro
  • Seguridad Física inadecuada

La explotación de dichas vulnerabilidades por parte de amenazas externas o internas puede tener como impacto un acceso a información confidencial de la organización, la creación de una pasarela de salto hacia otros dispositivos, o la modificación del comportamiento de los dispositivos a fines distintos para provocar daño económico, físico, e incluso atentar contra la vida de las personas (2).

El problema añadido es el elevadísimo número de dispositivos previstos: se esperan 26.000 Millones de dispositivos para 2020, 15 trillones en 2035, 250 millones de coches conectados a Internet en 2020 (3). Esto hace que la posibilidad de materialización de las amenazas sea aún mayor que las amenazas tradicionales, haciendo que el riesgo de cualquier organización se multiplique.

Con esta tendencia al alza, nos encontraremos con organizaciones que protegen muy adecuadamente los datos almacenados, procesados o transmitidos por sistemas clásicos (servidores, redes, sistemas de almacenamiento, …), mientras que desconocen los riesgos mucho más probables asociados a los nuevos dispositivos.

 

REGULACIONES

Solemos repetir una y otra vez que a pesar del crecimiento que ha experimentado el IoT en los últimos años, no existe todavía una regulación al respecto. Veamos el punto en el que están las principales organizaciones:

  • IEEE (Institute of Electrical and Electronic Engineers) ha creado un nuevo grupo de trabajo de estandarización para el IoT (4), en el cual se especifican los aspectos de seguridad que se deben implementar en funcionalidades relativas al descubrimiento/reconocimiento del dispositivo, la autenticación del usuario, el rastreo de items/personas bajo el control del usuario, alertas, o gestión de la privacidad.
  • NIST (National Institute of Standards and Technology) creó en 2015 un framework (5), cuyo objetivo es proveer una metodología para entender, diseñar y crear CPS (CyberPhysical Systems). Este framework está todavía en revisión.
  • ENISA (European Network and Information Security Agency) anunció en Octubre del 2015 que ampliaba sus actividades del 2016 a la seguridad del IoT (6), pero no parece tener nada publicado todavía.
  • ISO/IEC JTC 1/SWG 5: (International Organization for Standardization, International Electronic Commission) trabaja desde 2012 en la creación de estándares para tecnologías IoT. El Informe preliminar publicado en 2014 aborda algunos aspectos de seguridad a tener en cuenta, pero sólo a modo de alineamiento (7)
  • ITU (International Telecommunications Union, ITU) estableció en 2011 la “Joint Coordination Activity on Internet of Things” (JCA-IoT), del cual se deriva un grupo global de estandarización en IoT (8). El documento Y.2060 “Overview of the Internet of Things” (9) describe la tecnología IoT, su arquitectura en capas, y los aspectos de seguridad que debe existir en cada una de dichas capas.
  • OWASP (Open Web Application Security Project) ha creado un proyecto interesante que ofrece recursos libres destinados a desarrolladores y usuarios finales de IoT (10). <imagen>

Teniendo en cuenta que esta tecnología está en constante evolución y crecimiento, y que establecer estándares es una tarea que requiere tiempo y dedicación (no es nada fácil reunir a expertos de diferentes países para acordar un conjunto de reglas y especificaciones que sean válidas en una gran diversidad de países), es lógico que no existan todavía estándares de seguridad de IoT. Como referencia, los estándares ISO/IEC 27000 iniciaron su recorrido en 1987 desde el Centro de Seguridad Computacional Comercial (CCSC) del departamento de Industria y Comercio Británico (DTI), y culminaron casi 20 años después (en 2005) con el primer estándar internacional que hoy conocemos (11).

 

CÓMO AFRONTAR LOS NUEVOS ESCENARIOS DE RIESGO

Que no exista una regulación específica para esta tecnología no significa que los profesionales de la seguridad no podamos afrontar el reto de la securización. La tecnología es emergente, pero la gestión de la seguridad lleva mucho tiempo funcionando. En este apartado describimos una propuesta basada en la disciplina GRC, que combina un gobierno efectivo de todas las iniciativas de seguridad liderado por una Dirección comprometida, un enfoque de seguridad basado en riesgos que permita determinar qué debemos securizar, y un catálogo de controles adaptados a la nueva situación.

Gobierno de seguridad

Cuando hablamos de gobierno de seguridad de IoT nos referimos a las siguientes iniciativas:

  • Establecer una estrategia de seguridad alineada con la nueva realidad y liderada por la Dirección.
  • Especificar un alcance de lo que queremos securizar, teniendo en cuenta que cuantos más elementos entren dentro del alcance, mayor seguridad tendremos, pero también requeriremos mayor esfuerzo.
  • Definir una política que tenga en cuenta los elementos identificados en el alcance, y que establezca la intención de la organización y las directrices que guíen el resto de iniciativas.
  • Designar un responsable de la seguridad (si no existe ya uno) que gestione todas las iniciativas que se lleven a cabo, monitorice su eficacia, y tenga informado a la Dirección.

Enfoque de seguridad basado en riesgos

No podemos empezar a establecer controles sin saber dónde debemos focalizar nuestra atención: corremos el riesgo de no abarcar dimensiones críticas o implementar medidas redundantes. Un Análisis de Riesgos permite identificar en qué medida se pueden explotar las nuevas vulnerabilidades, y cuáles son aquéllas que superan el apetito de riesgo permitido por la organización. El resultado debe ser evaluado por la Dirección que decidirá qué riesgos deben ser tratados y de qué manera: reduciendo el riesgo, eliminándolo, derivándolo a terceros, o asumiéndolo. Para identificar los riesgos, pueden ser muy útil los recursos del framework COBIT de ISACA relativos a los escenarios de riesgo (12) (de pago), o el excelente trabajo llevado a cabo por la comunidad OWASP y disponible de forma gratuita (13).

Controles y cumplimiento

Podemos encontrar diferentes catálogos de controles que contrarresten las vulnerabilidades introducidas por estas tecnologías. La propia comunidad OWASP identifica un conjunto de medidas para cada una de las vulnerabilidades encontradas, y que no difieren mucho de los controles de ISO/IEX 27002:2013. Generalmente, estas medidas abarcan los siguientes aspectos:

  • Medidas para las Interfaces Web Inseguras, también válidas para interfaces inseguras con servicios en la nube y servicios móviles: cambiar las contraseñas por defecto en la configuración inicial, habilitar mecanismos de recuperación de contraseñas robustos que no proporcionen información de la cuenta, securizar la interfaz web para que no sea susceptible a ataques (XSSI, SQLi o CSRF), reforzar la política de acceso de manera que no permita el uso de contraseñas débiles y los usuarios se bloqueen tras 3-5 intentos de acceso fallidos.
  • Medidas para la Autenticación y Autorización insuficientes: reforzar las políticas de contraseñas, implantar un control de acceso granular, proteger las credenciales de acceso, implementar autenticación de dos factores.
  • Medidas para los servicios de transmisión inseguros: habilitar únicamente los puertos de red necesarios, reforzar los servicios de red para que no sean vulnerables a ataques externos (buffer overflow, fuzzing, DDOS).
  • Medidas para la falta de cifrado en la transmisión de datos: cifrar los datos transmitidos mediante protocolos como SSL o TLS, usar únicamente estándares de cifrado aceptados y limitar el uso de protocolos propietarios.
  • Medidas para los problemas de privacidad: almacenar únicamente la información necesaria para el funcionamiento del dispositivo, proteger debidamente la información recogida mediante cifrado (existen soluciones ligeras de cifrado), proteger adecuadamente la información personal almacenada en los dispositivos y sus componentes, permitir el acceso a la información personal sólo a las personas autorizadas.
  • Medidas para el Software/Firmware inseguro: permitir actualizaciones (muy importante), cifrar el fichero de actualización y usar una conexión cifrada en el envío, no incluir información privada en el fichero de configuración, firmar el fichero de configuración, securizar el servidor de actualización.
  • Seguridad Física inadecuada: asegurar que el dispositivo de almacenamiento no puede retirarse fácilmente, cifrar la información almacenada en reposo, inhabilitar por defecto los puertos externos (USB u otros), asegurar que los dispositivos no se pueden desmontar, limitar las capacidades de administración.

Grafico2

Obviamente no se trata aquí de implementar todas estas medidas. Se trata de tenerlas como base para usar aquéllas que vayan a bajar el riesgo que no es aceptable por la organización. Una buena práctica adicional puede ser su uso para realizar un Análisis Diferencial y conocer el nivel de madurez en cada una de las dimensiones, tal y como afrontaríamos un proyecto de cumplimiento.

 

CONCLUSIÓN: ¿Viejas medidas para nuevos problemas?

Si habéis llegado hasta este punto, habréis comprobado que estamos usando como base el ciclo PDCA establecido por ISO/IEC 27001:2013, y que lo hemos adaptado a las particularidades del IoT (elevadísimo número de dispositivos, tecnología en constante cambio, impacto brutal de las amenazas) que obligan a revisar constantemente el alcance, los riesgos y los controles necesarios.

En resumen, podemos hacer frente a este nuevo desafío usando un enfoque de seguridad basado en riesgos, que tenga como base un gobierno consolidado por una Dirección comprometida que es consciente del nuevo escenario, y que a falta de regulación existente tome como referencia de cumplimiento catálogos como los establecidos por OWASP.

Como apunte final, insistiré que, debido a la constante evolución de estas tecnologías que pueden derivar en nuevas amenazas de forma inesperada, es vital para nuestra supervivencia una mayor periodicidad de análisis de los riesgos, lo cual seguramente derivará en un futuro en metodologías de evaluación de riesgos cada vez más ágiles. Pero esto es otra historia.

Bibliografía

(1) http://www.forbes.com/sites/moorinsights/2015/09/15/the-internet-of-insecure-things/#3d14975146ef

(2) https://www.washingtonpost.com/news/the-switch/wp/2015/08/03/connected-medical-devices-the-internet-of-things-that-could-kill-you/

(3) http://www.comsoc.org/blog/infographic-internet-things-iot

(4) https://standards.ieee.org/develop/wg/P1912_WG.html

(5) http://www.cpspwg.org/Portals/3/docs/CPS%20PWG%20Draft%20Framework%20for%20Cyber-Physical%20Systems%20Release%200.8%20September%202015.pdf

(6) https://www.enisa.europa.eu/media/press-releases/enisa-work-programme-for-2016-adopted-agency-builds-on-successful-activities-and-broadens-scope-in-2018smart2019-studies-and-iot-security

(7) http://www.iso.org/iso/internet_of_things_report-jtc1.pdf

(8) http://www.itu.int/en/ITU-T/jca/iot/Pages/default.aspx

(9) http://www.itu.int/rec/T-REC-Y.2060-201206-I

(10) https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project

(11) http://www.gammassl.co.uk/27001/history.php

(12) http://www.isaca.org/Knowledge-Center/Research/ResearchDeliverables/Pages/Risk-Scenarios-Using-COBIT-5-for-Risk.aspx?cid=pr_1104761&appeal=pr

(13) https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project#tab=Top_10_IoT_Vulnerabilities__282014_29

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *