En el post anterior comenté algunos riesgos asociados a los dispositivos conectador a la red. Por este motivo, sin cambiar mucho de tema, en este artículo hablaré sobre los controles a tomar en estos dispositivos, así como de los puntos clave que habría que tener en cuenta a la hora de realizar una auditoría.
Antes de empezar a listar los controles, creo que es importante recordar que existen muchos dispositivos IoT diferentes, así como los sistemas de comunicación que emplean estos dispositivos para comunicarse. Esto hace que no sea una tarea fácil crear un estándar.
En este caso, he decidido listar una seria de controles aplicables basados en la NIST 800-53 [1] [2]:
| ID | Capa | ID NIST | Nombre del control | Objetivo del control |
|---|---|---|---|---|
| IoT-1 | 1 | PE-3 | Control de acceso físico | El fabricante verifica tanto las autorizaciones de acceso al dispositivo como las autorizaciones de acceso individuales. A su vez, mantiene registros de auditoría sobre el acceso físico y controla el acceso a las diversas áreas del dispositivo. Finalmente, el fabricante es el encargado de cambiar las combinaciones y claves del dispositivo cuando estas sean comprometidas. |
| IoT-2 | 1 | SC-8 | Transmisión, confidencialidad e integridad | Los dispositivos IoT protegen la confidencialidad e integridad de la información transmitida. Este control se aplica tanto a las redes internas como a las externas. |
| IoT-3 | 2 | SC-7 | Protección de límites | Los dispositivos monitorean y controlan las comunicaciones tanto en el límite externo como en los límites externos claves. Deben tener implementadas subredes para los datos de acceso público y deben conectarse a redes externas únicamente mediante interfaces administradas. |
| IoT-4 | 3 | IA-3 | Identificación y Autentificación del dispositivo | Los dispositivos deben identificar al resto de dispositivos antes de establecer conexión. |
| IoT-5 | 3 | SC-15 | Dispositivos de computación colaborativa | Los dispositivos únicamente pueden activarse remotamente cuando el fabricante lo permita. También, tienen que indicar el uso a los usuarios presentes en el dispositivo. |
| IoT-6 | 4 | IA-2 | Identificación y autentificación para los usuarios | Los dispositivos deben identifican y autentifican a los usuarios. |
| IoT-7 | 4 | AC-2 | Gestión de cuentas | El fabricante asigna las cuentas de respaldo y funciones comerciales. Además, establece administradores de cuentas y establece grupos y roles. Posibilidad de que el fabricante o el propietario pueda administrar cuentas del dispositivo. |
| IoT-8 | 5 | CM-7 | Funcionalidad mínima | El fabricante configura el dispositivo para realizar únicamente lo esencial. Además, restringe el uso de algunas funciones. |
| IoT-9 | 5 | SC-28 | Protección de la información en reposo | El dispositivo protege la confidencialidad y la integridad de la información en reposo. |
| IoT-10 | 5 | PL-2 | Plan de seguridad del sistema | El fabricante desarrolla un plan de seguridad consistente con la arquitectura empresarial y define los límites de autorización. También, describe el contexto y el entorno operativo del dispositivo y proporciona una descripción de los requisitos de seguridad. Además, describe los controles de seguridad implementados, junto con el motivo de estos. |
| IoT-11 | 6 | PM-11 | Definición de misión / proceso empresarial | El fabricante define la misión / procesos teniendo en cuenta la seguridad de la información y el riesgo resultante. Además, determina las necesidades de protección de la información que surgen. |
| IoT-12 | 7 | PM-1 | Plan del programa de seguridad de la información | El fabricante desarrolla y publica un programa de seguridad de la información. A su vez, ofrece una descripción de los requisitos y los controles para cumplir los requisitos. |
Tengo que mencionar, que además de los controles, existen frameworks que permiten comprender ideas complejas mediante preguntas simples. Un ejemplo es el framework Zachman. Este framework se muestra en la siguiente imagen [3].
A la hora de realizar una auditoría, el IoT no requiere habilidades adicionales que una auditoría TI tradicional. El IoT únicamente necesita un nuevo enfoque que vincule las estrategias con las soluciones IoT. Algunas preguntas que considerar a la hora de auditar IoT serían las siguientes [4]:
- ¿Como está el IoT desplegado en la organización hoy en día y quién es el propietario o cuáles son sus respectivos componentes?
- ¿Sabemos qué datos se recopilan, almacenan y analizan, y hemos evaluado las posibles implicaciones legales, de seguridad y de privacidad?
- ¿Tenemos planes de contingencia implementados en caso de que nuestros dispositivos de IoT sean hackeadas o modificadas para fines no deseados?
En conclusión, existen un gran número de controles y frameworks para poder auditar correctamente entornos con dispositivos IoT y tener el entorno bajo control. En mi opinión, un gran número de incidencias ocurren por no cumplir con estos controles o no haberse preguntado algunas de las preguntas mostradas a lo largo de este artículo.
[1] <<An IoT Control Audit Methodology>>, ISACA, consultado el 23/11/2020, https://www.isaca.org/resources/isaca-journal/issues/2017/volume-6/an-iot-control-audit-methodology
[2] <<Control List>>, Twelve IoT Controls, consultado el 23/11/2020, https://twelveiotcontrols.com/
[3] <<IoT Needs Better Security>>, ISACA, consultado el 23/11/2020, https://www.isaca.org/resources/isaca-journal/issues/2017/volume-3/iot-needs-better-security
[4] <<Internal Audit, Risk, Business & Technology ConsultingThe Internet of Things: A Game Changer for IT Audit>>, Knowledge Leader, consultado el 23/11/2020, https://www.knowledgeleader.com/knowledgeleader/resources.nsf/description/HITheInternetofThingsAGameChangerforITAudit/$FILE/HI%20The%20Internet%20of%20Things%20-%20A%20Game%20Changer%20for%20IT%20Audit.pdf
koldourrosolo
Latest posts by koldourrosolo (see all)
- IoT y cierre - 5 enero, 2021
- Más riesgos y cierre - 24 noviembre, 2020
- Controles y auditoría IoT - 23 noviembre, 2020
RCG says
26 noviembre, 2020 at 11:32 amMuy bien, suerte de fuente tan completa, que te ha llevado a NIST 800-53 (que se ha puesto de moda), que es un marco general. Pero haber ido un poco más allá vía NIST, de paso? Un pequeño reto …