Un producto conectado son cuatro objetivos que fingen ser uno: hardware, firmware, una radio y un servidor cloud con una app por delante. Este es el orden en que los probamos, qué acaba en tu mesa al final y qué deja fuera el proyecto a propósito.
Pide a tres proveedores que prueben el dispositivo y te darán tres alcances distintos. Un producto conectado no es un objetivo, es un pequeño sistema distribuido, y los fallos que merece la pena encontrar viven en las costuras entre sus partes: la placa y sus interfaces de depuración, el firmware y su mecanismo de actualización, las radios y sus flujos de emparejamiento, y la API cloud con la que habla toda la flota.
Un test que se para en la placa es una revisión de hardware. Uno que se para en la API es un pentest de API. Un pentest de IoT sigue un hallazgo cruzando las fronteras: la clave leída de un chip de memoria flash que después autentica contra la API de producción.
La IoT Security Testing Guide de OWASP parte un dispositivo igual, en unidades de procesamiento, memoria, firmware, servicios de intercambio de datos, e interfaces internas, físicas, inalámbricas y de usuario.
Antes de que salga un tornillo acordamos por escrito qué revisiones de hardware y qué versiones de firmware entran en el alcance, a qué entorno cloud apuntamos, en qué bandas de radio podemos transmitir y qué pasa cuando una unidad se muere.
Las pruebas físicas destruyen dispositivos. Si la única unidad que existe es la del expositor de tu demostración, el proyecto se termina cuando se resbale un soldador.
Las rules of engagement zanjan la logística que, si no, se come una semana: a quién llamamos a las 02:00, qué direcciones son nuestras, si la telemetría de producción entra en juego y si el departamento jurídico ha dado el visto bueno a la ingeniería inversa de componentes de terceros.
La norma marca el reloj. El Reglamento de Ciberresiliencia de la Unión Europea (CRA) entró en vigor el 10 de diciembre de 2024, con las obligaciones de notificación desde el 11 de septiembre de 2026 y las obligaciones principales desde el 11 de diciembre de 2027. Si tu producto lleva marcado CE y se conecta a algo, se te aplica.
Aquí el reconocimiento tiene menos de escanear y más de dibujar bien la cosa. Desmontamos una unidad, identificamos los componentes y construimos un modelo del dispositivo: qué corre dónde, qué guarda qué, y cada interfaz que lleva datos hacia dentro o hacia fuera. En paralelo lo vemos arrancar y darse de alta en una red controlada, capturamos su tráfico y enumeramos los endpoints del servidor que usa.
Después la capa física, donde un test de IoT deja de parecerse a nada más. Una consola UART que sigue imprimiendo su registro de arranque. Un puerto de depuración JTAG o SWD. Memoria flash SPI o I2C legible desde la placa. Puntos de prueba que dejó la línea de fabricación. Las preguntas son sencillas: ¿se puede conseguir un intérprete de comandos sin credenciales?, ¿se pueden recuperar secretos de la flash?, ¿se puede arrancar código modificado?, ¿el arranque seguro está aplicado de verdad o solo está presente?
La línea base de consumo es directa con esto. La ETSI EN 303 645 exige que las interfaces de red y lógicas que no se usen estén desactivadas, y que las interfaces de depuración estén desactivadas o protegidas por autenticación o por control de acceso. En una planta de producción en vez de en una cocina, la referencia pasa a ser la IEC 62443: la parte 4-2 cubre componentes y la 3-3 cubre sistemas y niveles de seguridad.
El firmware es el centro de gravedad. Obtenemos la imagen de tu servidor de compilación, del punto de actualización o del propio chip, y después la recorremos por orden. La Firmware Security Testing Methodology de OWASP establece nueve etapas justo para esto, desde obtener el firmware hasta la explotación de binarios, pasando por extraer y analizar el sistema de ficheros, la emulación y el análisis dinámico y en tiempo de ejecución. El análisis de firmware es la fase que los clientes dan por opcional y la que paga el proyecto.
Lo que sale de ella, una vez y otra:
El camino de actualización es el único control que puede reparar todo lo demás después de fabricar: una comprobación de firma que se puede rodear convierte un hallazgo local de hardware en uno remoto y de toda la flota.
Primero la red: qué puertos escuchan, en qué estado del dispositivo, y si los servicios alcanzables durante la instalación siguen siendo alcanzables después.
Después las radios, que dependen del producto. En Wi-Fi probamos el flujo de aprovisionamiento y el punto de acceso temporal que levanta casi cualquier dispositivo durante el alta, y si esa ventana autentica a alguien siquiera. En Bluetooth de baja energía probamos el modo de emparejamiento, los permisos de las características y si un servicio GATT acepta órdenes sin vínculo establecido. En Zigbee, LoRaWAN o un enlace propietario por debajo de 1 GHz probamos el aprovisionamiento de claves, la protección contra repetición y el comportamiento bajo interferencia. El cifrado en tránsito se comprueba, nunca se supone: una sesión de TLS que no valida el certificado del servidor es un hallazgo frecuente en dispositivos con pocos recursos.
La mayor parte del valor, sin embargo, no está en un dispositivo, sino en la flota, y el servidor que atiende a cien mil unidades falla como fallan las API multiinquilino. La prueba suelta más productiva es la autorización a nivel de objeto: coger tu propia cuenta, coger un identificador de dispositivo que no es tuyo y pedírselo a la API. La autorización rota a nivel de objeto es la primera entrada del OWASP API Security Top 10 de 2023, y aquí pocas veces es teórica: los identificadores van impresos en la caja, se emiten por el aire o son secuenciales.
La app que acompaña se prueba contra los grupos de control de OWASP MASVS, y comprobamos si la fijación de certificados sobrevive al contacto con un atacante y no solo si existe. La app la leemos además como documentación: muchas veces es la descripción más completa de la API que nadie haya escrito.
Y la cadena que hay que buscar cruza las dos superficies: una clave sacada del firmware que abre la API de la flota y devuelve los dispositivos de otros clientes. Ese es el hallazgo, no la clave por sí sola.
Nada llega al informe porque lo haya marcado un escáner. Cada hallazgo candidato se demuestra en el banco de pruebas: construimos el exploit, lo lanzamos contra un dispositivo que controlamos y capturamos la evidencia.
El encadenado es donde está el valor. Una consola UART por sí sola es una nota de hardware. Una consola UART que entrega una clave de API compartida, que autentica contra el servidor de producción, que expone los dispositivos de otros clientes, es el hallazgo que cambia una hoja de ruta. PTES mantiene la explotación y la postexplotación como fases separadas justo por esto, y la NIST SP 800-115 hace que su fase de ataque vuelva al descubrimiento, porque el acceso gana información nueva.
La priorización sigue a la evidencia, no a una puntuación copiada de una base de datos. Cuando un componente ya está siendo atacado de verdad, el catálogo de vulnerabilidades explotadas conocidas de CISA es un buen criterio de desempate: registra los fallos con explotación confirmada, que es una pregunta distinta de lo alta que sea una puntuación.
El entregable es un documento, no la exportación de una herramienta. Contiene:
Hacemos también una explicación en directo con los técnicos que van a hacer el trabajo: media hora recorriendo el exploit con un equipo de firmware vale más que el párrafo que lo describe. Si necesitas una carta de atestación, dilo al acordar el alcance, porque lo que puede afirmar con honestidad depende de qué entró en él.
Un hallazgo no está cerrado porque lo esté un ticket. Cuando tu equipo despliegue las correcciones hacemos un retest contra el nuevo firmware y el nuevo servidor, relanzando la prueba original de cada asunto y confirmando que la corrección aguanta en vez de moverse de sitio. Y como las correcciones se publican en una versión de firmware, el retest confirma además que el mecanismo de actualización entregó el cambio de verdad.
Rangos, no promesas; la primera reunión los convierte en una fecha. Un solo dispositivo con una radio, una app que lo acompaña y una API pequeña son normalmente de dos a tres semanas de pruebas. Una familia de productos con varias revisiones de hardware, varias radios y una plataforma cloud de peso se va a cuatro o seis. El informe y la explicación añaden unos días.
Qué mueve el rango:
Lo que no mueve el rango es cuántas unidades tengas desplegadas. Probar una como se debe nos dice cosas de todas.
Conviene decirlo con claridad, porque un test que se vende como que cubre todo no cubre bien nada.
Si eso suena a una promesa más pequeña que la que has oído en otro sitio, es justamente el punto. La página del servicio de pentesting de IoT explica cómo acotamos un proyecto; la forma más rápida de saber si este es el test correcto es describir el producto.
La secuencia real de un pentest de red externa: alcance y rules of engagement, reconocimiento, análisis del perímetro, explotación, informe y retest, además de lo que el test no va a cubrir.
La secuencia de un pentest de red interna real: el punto de partida que acordamos, en qué se convierte una cuenta de dominio, qué recibes al final, cuánto dura y qué cosas no cubre el ejercicio a propósito.
La secuencia real de un pentest wifi, de las rules of engagement al retest: qué pasa en cada fase, qué necesitas tener listo, cuánto dura y qué cosas no cubre este test a propósito.
Si algo de aquí se parece a un problema que llevas encima, media hora de llamada para acotarlo con un pentester senior vale más que leer otro artículo.
Hablar con un pentester seniorElige la hora que mejor te venga. Nos cuentas qué necesitas y en qué punto estás, y te explicamos cómo trabajamos y de qué forma podemos ayudarte.
