Cámaras de seguridad: ¿productos importantes del CRA?
Resumen
Una cámara conectada para hogar inteligente vendida para seguridad física debe planificarse como producto Clase I Importante. La clase puede cambiar cuando el mismo hardware se vende para otro fin: videollamadas, CCTV profesional, infraestructura de grabación, control de acceso u otro producto de seguridad.
El primer registro que se debe crear es un memorando de clasificación y límites para la variante exacta de la cámara. Debe nombrar la función de seguridad prevista, el contexto de venta, los elementos digitales suministrados, el periodo de soporte y el motivo de la ruta elegida.
El registro del periodo de soporte debe partir del uso previsto de la cámara, las expectativas razonables del usuario, la naturaleza del producto, la finalidad prevista y el soporte de los componentes relevantes. El mínimo del CRA es de al menos cinco años, salvo que el producto esté previsto para usarse menos tiempo, y la fecha de fin, al menos mes y año, debe quedar claramente indicada en el momento de la compra.
¿Cómo se clasifica una versión de cámara?
Empieza por la oferta, no por la carcasa de la cámara. La ruta depende de la afirmación comercial, de la función en la que confía el comprador y de los elementos digitales suministrados con esa versión.
Vendida para videollamadas, reuniones o comunicación general.
Periférico de comunicación; no vigilancia de seguridad doméstica.
Firmware del dispositivo, controlador o integración con app de reuniones. Sin nube de vigilancia ni flujo de alarma suministrados.
Vendida para vigilancia doméstica, monitorización de bebés, seguridad de timbre con vídeo o integración con alarma.
La seguridad o vigilancia doméstica es la función en la que confía el comprador.
Firmware, almacenamiento local, app, nube del fabricante, servicio de actualización y gestión de vulnerabilidades cuando se suministran para esa función.
Vendida como vigilancia profesional, infraestructura de grabación o parte de otro producto de seguridad.
El grabador, VMS, cortafuegos, VPN, control de acceso, función biométrica o de identidad puede ser el producto real.
Cámara más grabador, servidor de gestión, nube de instalador, servicio de control de acceso o appliance de seguridad.
Usa el diagrama como ayuda de enrutamiento, no como el registro final de clasificación. El registro escrito sigue necesitando la afirmación exacta, el uso previsto y el límite enviado. Para una cámara de hogar inteligente, la expresión clave es productos de hogar inteligente con funcionalidades de seguridad. Una cámara vendida para vigilancia doméstica, monitorización de intrusiones, monitorización de bebés o integración con alarma encaja en esa categoría. Una webcam de uso general normalmente no.
Después comprueba si otra función listada está haciendo el trabajo de control. La clasificación de productos importantes sigue la funcionalidad principal del producto, no las partes que viajan dentro: incorporar un componente relevante para la seguridad no arrastra al resto de la oferta a la ruta de productos importantes. Si la cámara se vende en realidad como cortafuegos, pasarela VPN, lector de control de acceso, dispositivo de autenticación biométrica, sistema de gestión de identidades o producto de gestión de acceso privilegiado que casualmente incluye una lente, clasifica primero esa función principal.
Para vigilancia profesional, no fuerces la categoría de hogar inteligente. Una cámara CCTV profesional, VMS o NVR puede seguir siendo un producto con elementos digitales bajo el CRA y seguir necesitando requisitos de seguridad, planificación del periodo de soporte, gestión de vulnerabilidades y documentación técnica. La clase depende del uso previsto, del límite enviado y de la función principal.
El memorando de clasificación debe responder a cuatro preguntas:
- ¿La cámara se vende para seguridad doméstica, monitorización de bebés, seguridad de timbre con vídeo o integración con alarma?
- ¿La cámara es la función principal del producto o es un cortafuegos, VPN, control de acceso, función biométrica o de identidad el que hace el trabajo real?
- ¿Qué elementos digitales se suministran para la función prevista: firmware, almacenamiento local, app, nube del fabricante, servicio de actualización y gestión de vulnerabilidades?
- ¿Qué sistemas quedan fuera de la oferta del fabricante: router del cliente, grabador de tercero, red del instalador, proveedor de identidad externo o centro de vigilancia?
Límite del producto y elementos suministrados
Para un fabricante de cámaras, el límite de cumplimiento rara vez se reduce a la carcasa de plástico. Debe seguir al producto introducido en el mercado y a los elementos digitales necesarios para la función de seguridad prevista.
Dentro del límite del fabricante por defecto: firmware del dispositivo y cada servicio que se ejecuta en él, la pila de interfaz de red, el almacenamiento en el dispositivo, la app complementaria que se indica al comprador que instale, cualquier nube alojada por el fabricante que proporcione las funciones documentadas del producto, la infraestructura de actualización OTA y el proceso de gestión de vulnerabilidades que la sustenta.
Fuera de ese límite, salvo que el fabricante venda realmente esa capa: el router doméstico del comprador, un VMS o NVR de tercero que el cliente eligió, la red del sitio del instalador, un proveedor de identidad externo usado para SSO y un centro de vigilancia profesional bajo contrato separado.
Ninguna cuando estos productos vienen de otros fabricantes. Si el fabricante de la cámara también vende el grabador, VMS, servicio de identidad o puente a la nube como parte de su oferta, cada uno puede ser un producto CRA separado con su propio expediente de producto.
Expediente del producto · Declaración UE de conformidad · Marcado CE · Declaración del periodo de soporte · Instrucciones de usuario · Registro de evaluación de la conformidad
Conservado por el fabricante de la cámara durante diez años después de la introducción en el mercado o durante el periodo de soporte, lo que sea mayor. Si se usa una ruta de evaluación por tercero, conserva ese resultado con el mismo expediente.
Expediente de riesgos de ciberseguridad · Inventario de componentes · Proceso de gestión de vulnerabilidades · Política de divulgación · Mecanismo de actualización segura
Incluye el punto único de contacto publicado, la evidencia de pruebas para configuración segura por defecto, la verificación de actualización firmada y el motivo del periodo de soporte.
Registro de diligencia sobre componentes · Declaración de conformidad del proveedor · Avisos de seguridad del proveedor
El fabricante de la cámara sigue siendo responsable de la elección del chip. Cuando un chip, módulo o elemento seguro es a su vez un producto CRA, la declaración de conformidad del proveedor y sus avisos apoyan la diligencia del fabricante, no la sustituyen.
El inventario de componentes se monitoriza frente a nuevas vulnerabilidades; el proceso de vulnerabilidades clasifica los hallazgos; las actualizaciones de seguridad gratuitas distribuyen correcciones con avisos, de forma automática cuando es viable.
Una vulnerabilidad de cámara explotada activamente arranca un reloj: la alerta temprana se debe enviar en un plazo de 24 h, la notificación de vulnerabilidad en 72 h y el informe final de vulnerabilidad en los 14 días siguientes a que esté disponible una medida correctiva o mitigadora. Un incidente grave de seguridad corre por un reloj separado con los mismos pasos de 24 h y 72 h, más un informe final de incidente en el plazo de un mes desde la notificación del incidente.
Los hogares con las cámaras afectadas también reciben aviso del fabricante. El fabricante informa a los propietarios afectados y, cuando la exposición lo justifica, al conjunto más amplio de clientes, sobre qué falla y qué pasos pueden aplicar ellos mismos: actualización forzada de firmware, actualización de app, restablecimiento de contraseña, desactivación opcional de servicio o restablecimiento de fábrica antes de la reventa.
Puntos de comprobación de la arquitectura de la cámara
El expediente de la versión de la cámara debe seguir al producto de vídeo real, no a una lista genérica IoT. Una cámara Wi-Fi a pilas, una cámara domo PoE, una cámara exterior celular y una cámara vendida con un NVR pueden compartir la conversación de clase mientras necesitan registros de ingeniería diferentes.
Lee el diagrama como un mapa del expediente de versión, no como un patrón de despliegue obligatorio. El fabricante sigue necesitando escribir el límite exacto de la variante para su propia cámara, app, servicio en la nube, ruta de actualización y modelo de soporte.
- Ruta de vídeo y control. Identifica cada ruta que pueda visualizar, almacenar, exportar o controlar el vídeo: flujo local, interfaz web, sesión de app, retransmisión en la nube, enlace compartido, exportación de soporte y compatibilidad declarada con NVR o VMS.
- Exposición local. Escanea la cámara tras la puesta en marcha y tras la actualización. Muestra qué servicios son accesibles, cuáles requieren autenticación y qué rutas de flujo o administración permanecen desactivadas.
- Sistemas del cliente. Trata el router, la red del instalador, el grabador de tercero, el proveedor de identidad externo y el centro de vigilancia como elementos fuera del producto del fabricante de la cámara, salvo que el fabricante suministre esa capa como parte de la oferta.
- Backends suministrados por el fabricante. Decide qué entra y qué no: servicio de cuentas, canal de firmado, servicio de eventos o notificaciones, portal de soporte, servicio de banderas de funciones de pago y cualquier ruta de ML en la nube.
- Autoridad de actualización. Trata la autoridad de actualización como un intercambio de doble sentido: la cámara consulta o recibe metadatos de actualización, y el servicio de actualización devuelve un paquete de firmware o app firmado para esa variante exacta. Conserva con la versión los registros de actualización firmada, ranura de recuperación, rechazo de versión anterior y aviso al usuario.
- Entradas de proveedor. Asigna al SoC, módulo Wi-Fi, pila de medios, modelo de IA, SDK P2P y bootloader un responsable, una versión, un seguimiento de avisos y una decisión de versión.
- Bucle postventa. Los informes de vulnerabilidad, incidentes graves, avisos de proveedor y fallos en campo deben actualizar el modelo de amenazas, el registro de riesgo residual, el expediente técnico y la siguiente puerta de versión.
Evaluación de riesgos trabajada de la cámara
Lee el resto de esta sección como un ejemplo trabajado de una cámara, no como una lista que copiar. La intención es mostrar la profundidad de decisión que un fabricante de cámaras debe poder defender para una variante concreta: el chipset y la elección de módulos, la compilación de firmware, la retransmisión en la nube, el canal OTA, los avisos de proveedor que realmente se siguen, el canal de venta contratado y la ventana de soporte comprometida.
¿Qué producto se está evaluando?
Producto ilustrativo, no un dispositivo real: ExampleCo IndoorCam X1, una cámara interior para hogar inteligente vendida en la UE para vigilancia doméstica. Graba vídeo y audio en 1080p, almacena clips en una tarjeta microSD, transmite vídeo en directo al propietario a través de una app móvil, expone una interfaz web local de administración durante la puesta en marcha, usa BLE para la vinculación inicial, se conecta por Wi-Fi y recibe actualizaciones de firmware firmadas del fabricante.
El límite de producto de este ejemplo incluye el hardware de la cámara, el firmware embebido, la grabación en microSD, el flujo de emparejamiento de la app móvil, la retransmisión en la nube del fabricante, el servicio de cuentas, el servicio de actualización OTA, el proceso de avisos de seguridad y el contacto de notificación de vulnerabilidades. No incluye el router del cliente, un VMS/NVR de tercero, una plataforma de domótica ni un centro de vigilancia profesional.
El producto está previsto para usuarios domésticos no técnicos en un entorno interior. No está previsto para CCTV industrial, vigilancia de espacios públicos, control de acceso, autenticación biométrica o verificación de identidad, vigilancia de lugares de trabajo ni operaciones de seguridad en infraestructura crítica.
Antes de escribir la tabla de amenazas, prueba las tres rutas de la cámara que suelen marcar la evaluación de riesgos: custodia del vídeo, identidad del dispositivo y exposición tras la puesta en marcha. Estos diagramas convierten el ejemplo trabajado en preguntas de ingeniería en lugar de en una lista genérica de amenazas.
Detalles de custodia del vídeo: el origen es el sensor de la cámara, el micrófono y el codificador, con blobs de ajuste de imagen, ruta de audio, máscara de privacidad, entradas de detección por IA y perfiles de flujo ligados a una compilación de firmware. La ruta de visualización local incluye ONVIF, RTSP, vista previa web o navegador y se verifica con un escaneo de autenticación y exposición. La ruta de visualización remota incluye retransmisión en la nube, SDK P2P o app del propietario y se verifica con una prueba de alcance de token y de retransmisión. La ruta de medios locales incluye clips en microSD y almacenamiento extraíble y se verifica con pruebas de restablecimiento y de extracción de tarjeta. La ruta de soporte incluye paquete de soporte y exportación de diagnóstico y se verifica con una lista de comprobación de redacción.
Las pruebas de restablecimiento, desvinculación y borrado RMA demuestran qué vídeos, tokens y vínculos de cuenta se eliminan antes de reventa, reacondicionamiento o traspaso a soporte.
La propiedad es una comprobación distinta de la custodia del vídeo. Una cámara puede tener un flujo protegido y aun así fallar si un antiguo propietario, usuario compartido o teléfono recuperado conserva el acceso tras la transferencia.
Detalles del ciclo de vida de identidad: el aprovisionamiento crea la clave o certificado de la cámara, registra la identidad hardware y bloquea el acceso de depuración de producción. La puesta en marcha del propietario usa una cuenta verificada más un token de reclamación QR, BLE o app de un solo uso y vida corta y cierra la ventana de primer uso una vez vinculada la cámara. La operación normal usa el mismo modelo de revocación para restablecimiento de contraseña, recuperación de cuenta, recuperación de teléfono perdido, uso compartido familiar, visores invitados y sesiones de navegador. La transferencia de propietario exige una ruta de desvinculación autorizada, elimina la cuenta anterior, revoca a los usuarios compartidos y cierra las sesiones activas antes de que la cámara pueda reclamarse de nuevo. El restablecimiento de fábrica, el RMA y el reacondicionamiento eliminan el vínculo de cuenta, las credenciales, los clips y los diagnósticos según el diseño del producto; la gestión RMA no debe convertirse en una ruta para blanquear robos.
Pruebas de abuso: un token de puesta en marcha caduca, es de un solo uso y no puede ser reutilizado por un atacante cercano tras la reclamación del propietario; un teléfono antiguo, usuario invitado o sesión de navegador no puede conservar acceso en directo o grabado tras la recuperación; y un restablecimiento local no deja vínculo a la nube, tokens de cuenta ni clips.
Tras probar la propiedad, comprueba qué sigue siendo accesible desde la red, la app, el medio extraíble y los flujos de soporte. Esto mantiene la revisión de exposición ligada al comportamiento real enviado, no a un resultado genérico de escaneo de puertos.
Detalles de las superficies de acceso: los servicios LAN locales incluyen RTSP, ONVIF, interfaz web y endpoints de descubrimiento, y el registro de versión es el escaneo de exposición. La visualización remota incluye retransmisión en la nube, uso compartido e identidad de dispositivo, y el registro de versión es la prueba de alcance de token de nube. Los medios extraíbles incluyen clips en microSD, comportamiento de restablecimiento y decisiones de almacenamiento, y el registro de versión es el resultado del restablecimiento de microSD. El diagnóstico de soporte incluye logs, volcados de fallo y modo soporte, y el registro de versión es la muestra de auditoría de modo soporte.
¿Qué activos se protegen?
Las cámaras protegen cosas muy diferentes dentro de la misma carcasa. Un clip grabado del dormitorio de un niño, una cuenta de propietario que puede mover la lente y una clave de firmado de firmware que controla cada dispositivo enviado este año conviven en un mismo producto. Lístalos primero como activos separados, porque el conjunto de controles, la evidencia de pruebas y el registro de versión divergen mucho entre ellos.
| Activo | Por qué importa | Dónde reside |
|---|---|---|
| Vídeo y audio en directo y grabado | Expone habitaciones privadas, rutinas, visitas, niños, mascotas y conversaciones | Sensor, RAM, codificador, microSD, buffer de flujo, retransmisión en la nube |
| Cuenta de propietario y factor de recuperación | Una toma de control puede conceder visualización remota, restablecimiento del dispositivo y cambios en el uso compartido | App móvil, servicio de identidad, ruta de recuperación por correo o SMS |
| Credencial dispositivo-nube | Token de confianza persistente; difícil de rotar en una flota desplegada | Elemento seguro o almacenamiento protegido, servicio de vinculación de cuenta |
| Ancla de confianza de firmado de firmware | Si se compromete, el canal de actualización puede convertirse en canal de malware | Cadena de arranque, almacén de claves, servicio de firmado, canalización de versión |
| Posición en la red local | La cámara se sitúa dentro de la LAN doméstica y puede ver a sus pares locales | Interfaz Wi-Fi, concesión DHCP, vista mDNS/SSDP |
| Paquete de diagnóstico y soporte | Puede filtrar números de serie, identificadores de cuenta, nombres de red y trazas de fallo | Logs del dispositivo, portal de soporte, herramientas internas de soporte |
| Instrucciones de usuario y fecha de soporte | Guía la puesta en marcha segura, las expectativas de actualización y la gestión del fin de soporte | Embalaje, manual web, interfaz de la app, ficha del producto |
¿Dónde están los principales límites de confianza?
Una cámara está a la vez en cinco sitios: el propio dispositivo, la tarjeta microSD que cualquiera en la habitación puede retirar, la red doméstica que comparte con teléfonos y pares IoT desconocidos, el backend del fabricante que toca cada cámara en campo y el teléfono o navegador del propietario que mantiene la sesión en directo. Cada uno cambia la oportunidad del atacante y exige una superficie de control diferente, así que el modelo de límites de confianza los lista por separado aunque estén conectados.
| Entorno | Protección esperada | Por qué cambia la probabilidad |
|---|---|---|
| Dentro de la cámara | El acceso físico es limitado, pero existen reparación, robo, reventa y pads de depuración | Menor probabilidad remota, mayor consecuencia si las claves son extraíbles |
| microSD / medio local | Cualquier persona con acceso a la habitación puede retirar o copiar la tarjeta | El acceso local es plausible en hogares con invitados, personal de limpieza, inquilinos o reventa |
| Red doméstica | Compartida con portátiles, teléfonos, televisores, impresoras y dispositivos IoT desconocidos | Un par comprometido puede atacar administración local, descubrimiento o servicios de flujo |
| Backend del fabricante | Expuesto a internet y compartido con toda la flota instalada | Un error de backend escala de un hogar a muchos |
| Endpoint del propietario | Teléfonos y navegadores están expuestos a phishing, malware y reutilización de cuentas | El compromiso de cuenta suele saltarse el endurecimiento del dispositivo |
¿Qué amenazas deben evaluarse primero?
Este ejemplo arranca con dieciséis amenazas específicas del producto. El objetivo no es ser exhaustivo, sino mostrar el nivel de trazabilidad que un fabricante debería poder defender.
| ID | Escenario de amenaza | Activo en riesgo | Punto de entrada |
|---|---|---|---|
| T1 | Un secreto compartido o predecible de primer uso permite a un atacante reclamar la cámara antes de que el propietario termine la puesta en marcha | Cuenta de propietario, flujo de vídeo | Vinculación BLE / puesta en marcha local |
| T2 | La interfaz web local de administración acepta credenciales débiles o queda abierta tras la puesta en marcha | Configuración, acceso al flujo | Red doméstica |
| T3 | Un token robado de la app móvil sigue siendo válido tras el restablecimiento de contraseña y continúa abriendo el flujo de la cámara | Cuenta de propietario, vídeo y audio en directo | Endpoint del propietario / retransmisión en la nube |
| T4 | El respaldo P2P, la gestión de STUN/TURN/ICE, UPnP o hole punching expone directamente la cámara cuando la ruta de retransmisión falla o está bloqueada | Servicios de firmware, acceso al flujo | Ruta de retransmisión adyacente a internet |
| T5 | ONVIF/RTSP responde en la LAN con autenticación débil o URLs de flujo descubribles | Vídeo y audio en directo | Red doméstica |
| T6 | La ranura de recuperación acepta una imagen de firmware sin firmar, antigua o degradada | Integridad del firmware, ancla de firmado | OTA / ruta de recuperación |
| T7 | Los pads UART/JTAG permiten acceso en arranque durante robo, reparación o reventa | Secretos del dispositivo, firmware, logs | Acceso físico de depuración |
| T8 | Los clips en microSD son legibles tras retirar la tarjeta o tras la reventa de la cámara | Vídeo y audio grabados | Medio local |
| T9 | La vinculación BLE expone la credencial Wi-Fi o el secreto de emparejamiento del dispositivo a un atacante cercano | Credencial Wi-Fi, cuenta de propietario | Ventana de configuración BLE |
| T10 | Los paquetes de soporte incluyen serie, cuenta, SSID, fragmentos de token o trazas de fallo privadas | Datos de diagnóstico, vinculación con la cuenta | Subida a soporte |
| T11 | Una vulnerabilidad de proveedor en el módulo Wi-Fi o la pila de medios no se detecta durante el periodo de soporte | Firmware, disponibilidad, confidencialidad del flujo | Brecha en avisos de proveedor |
| T12 | El restablecimiento RMA o de reventa no borra la vinculación de cuenta, los clips o las credenciales del dispositivo | Cuenta de propietario, medios grabados, credencial dispositivo-nube | Ruta de devolución |
| T13 | Los servicios de descubrimiento revelan modelo, firmware, serie o metadatos de flujo a todos los dispositivos de la LAN | Huella del dispositivo, exposición del flujo | ONVIF / WS-Discovery / mDNS |
| T14 | El servidor RTSP está protegido de forma diferente a la interfaz web, dejando un flujo en directo accesible tras endurecer la administración | Vídeo y audio en directo | Servicio de flujo local |
| T15 | Un fallo de SDK P2P o de medios de tercero permite predicción o enumeración de UID de dispositivo, suplantación de dispositivo o compromiso de sesión de flujo | Vídeo y audio en directo, credencial de dispositivo | Retransmisión en la nube / SDK |
| T16 | El firmware de la cámara usa un blob de ISP, Wi-Fi o IA de proveedor que no está en el proceso de seguimiento de SBOM | Integridad del firmware, gestión de vulnerabilidades | Firmware de proveedor |
¿Cómo deben priorizarse los riesgos iniciales?
Usa una rúbrica interna sencilla antes de elegir controles. En este ejemplo, la probabilidad se basa en la exposición y la oportunidad del atacante; el impacto se basa en el daño a la privacidad, la escala de flota, la persistencia y si la amenaza compromete un mecanismo de seguridad. Las etiquetas exactas importan menos que el motivo escrito junto a cada decisión.
Usa una escalera de puerta de versión para que no todas las amenazas reciban la misma decisión:
| Decisión de puerta | Significado para esta versión de cámara |
|---|---|
| Bloquear la versión | La cámara no se envía hasta que pase la prueba que falla: emparejamiento, autenticación de flujo, verificación de actualización firmada, borrado RMA o escaneo de exposición de servicios tras la puesta en marcha, según la amenaza. |
| Bloquear salvo documentación | La versión solo puede avanzar cuando se escribe, revisa y se fija al expediente de versión un control compensatorio, una limitación específica de la variante o un motivo de modo instalador. |
| Enviar con monitorización | La cámara se envía, pero el expediente de versión nombra la señal de monitorización activa (feed CVE del proveedor, avisos de SDK P2P, telemetría de abuso) y el ingeniero responsable durante el periodo de soporte. |
| Trasladar a guía | La exposición depende de la red doméstica, el teléfono del propietario o un grabador de tercero fuera de la oferta del fabricante, así que el expediente mantiene guía al instalador o al usuario en lugar de intentar controlar el lado del cliente. |
| Aceptar | Algunas superficies de la cámara (respuestas de descubrimiento documentadas, metadatos LAN) llevan un riesgo residual inherente, así que el expediente registra la evidencia de minimización y el motivo de aceptar lo que queda. |
| ID | Probabilidad | Impacto | Decisión de puerta | Por qué |
|---|---|---|---|---|
| T1 | Media | Alto | Bloquear la versión | La toma de control en primer uso es realista y socava la propiedad |
| T2 | Alta | Medio | Bloquear la versión | Las LAN domésticas contienen pares no fiables y contraseñas reutilizadas |
| T3 | Media | Alto | Bloquear la versión | El robo de token de cuenta concede visualización remota sin tocar la cámara |
| T4 | Baja | Alto | Bloquear salvo documentación | Ruta poco frecuente, pero la exposición directa puede escalar; un producto en venta necesita una decisión documentada sobre retransmisión y NAT |
| T5 | Media | Alto | Bloquear la versión | La exposición de flujo local es un fallo directo de privacidad |
| T6 | Baja | Alto | Bloquear la versión | El compromiso de actualización es persistente y afecta a toda la flota |
| T7 | Media | Medio | Bloquear salvo documentación | La depuración física es plausible durante robo, reparación o reventa; la versión necesita motivo de bloqueo de depuración o de servicio |
| T8 | Alta | Medio | Bloquear salvo documentación | La retirada local de la tarjeta es habitual; o se protegen los clips o se documenta con claridad la limitación del medio extraíble |
| T9 | Media | Alto | Bloquear la versión | La vinculación es corta pero expone la credencial de red doméstica |
| T10 | Media | Medio | Bloquear salvo documentación | Las fugas de datos de soporte pueden pasar desapercibidas; la exportación de soporte debe minimizarse, redactarse o desactivarse explícitamente |
| T11 | Media | Alto | Enviar con monitorización | Los CVE de proveedor son esperables durante el periodo de soporte; la versión necesita responsable y seguimiento de avisos |
| T12 | Media | Alto | Bloquear la versión | Las rutas de devolución y reventa son previsibles en dispositivos de consumo |
| T13 | Media | Medio | Aceptar | Algunos metadatos LAN son inherentes a los protocolos de descubrimiento documentados; el riesgo residual se acepta solo con minimización de exposición y guía al usuario para descubrimiento opcional cuando esté soportado |
| T14 | Media | Alto | Bloquear la versión | La autenticación del flujo no puede ser más débil que el modelo de acceso documentado |
| T15 | Baja | Alto | Enviar con monitorización | Las debilidades de SDK o retransmisión pueden afectar a muchos dispositivos, así que la versión necesita responsable de versión y monitorización de abuso |
| T16 | Media | Alto | Bloquear salvo documentación | Los blobs cerrados o mantenidos por el proveedor necesitan responsable de versión, canal de avisos y ruta de actualización, o una decisión escrita de riesgo residual |
¿Qué controles de diseño cambian el panorama de riesgo?
Vincula cada fila de control a una prueba concreta de cámara, no a una lista genérica de desarrollo seguro. El expediente de versión debe poder apuntar desde un ID de amenaza al registro exacto de prueba de emparejamiento, escaneo de autenticación de flujo, verificación de actualización firmada, inventario de servicios tras la puesta en marcha o borrado RMA que demuestra que el control está vivo en la compilación de la cámara enviada.
| Amenazas | Control de diseño | Evidencia que el fabricante debe conservar |
|---|---|---|
| T1, T2 | Secreto de puesta en marcha por dispositivo, alta obligatoria del propietario, sin contraseña por defecto compartida, cierre de la interfaz de puesta en marcha tras el alta | Registro de prueba de puesta en marcha, política de credenciales, prueba negativa de acceso de administración sin autenticación |
| T3 | Tokens de app de vida corta, sesiones vinculadas al dispositivo, revocación en servidor al restablecer contraseña, monitorización de anomalías de inicio de sesión | Política de vida del token, pruebas de revocación, pruebas de abuso de recuperación de cuenta |
| T4, T5 | Desactivar UPnP por defecto, retransmisión autenticada, ONVIF/RTSP autenticado, inventario de servicios tras la puesta en marcha | Escaneo de exposición de red, pruebas de autenticación del flujo, revisión de la configuración de retransmisión |
| T6 | Arranque seguro, OTA firmada, contador monotónico de versión, comprobación de firma en la ranura de recuperación, política de reversión | Evidencia de cadena de arranque, pruebas de verificación de actualización, pruebas de rechazo de versión anterior |
| T7 | Fusibles de producción para depuración, pads de depuración sellados o documentados, sin secretos en la salida UART legible | Lista de comprobación de hardware en producción, verificación de bloqueo de depuración, nota de riesgo de teardown |
| T8 | Grabación cifrada en microSD cuando la variante de cámara lo soporte (Eufy, TP-Link Tapo en modelos compatibles); borrado seguro en restablecimiento de fábrica; aviso claro al usuario impreso en el manual y en la app para variantes que graban sin cifrar | Nota de diseño de almacenamiento, prueba de restablecimiento, captura de la instrucción de usuario, captura del aviso en la app |
| T9 | Emparejamiento BLE autenticado, ventana corta de emparejamiento, secreto Wi-Fi nunca transmitido en claro, límites de frecuencia de emparejamiento | Revisión del protocolo de emparejamiento, prueba de RF, prueba de modos de fallo |
| T10 | Minimización del paquete de soporte, redacción de tokens, consentimiento del usuario antes de subida, límite de retención | Esquema de soporte, pruebas de redacción, evidencia del flujo de soporte |
| T11 | Monitorización del SBOM, seguimiento de avisos de proveedor, triaje de componente afectado, proceso de publicación de actualización firmada | Registro de diferencias del SBOM, registro de avisos de proveedor, decisiones de triaje |
| T12 | Flujo de borrado RMA, desvinculación de la nube, rotación de credenciales en restablecimiento, lista de comprobación de dispositivo reacondicionado | Lista de comprobación de la línea de devoluciones, evidencia de restablecimiento, auditoría de desvinculación de la nube |
| T13, T14 | Inventario de servicios tras la puesta en marcha, URLs de flujo autenticadas, minimización de respuestas de descubrimiento, evidencia de pruebas de perfil y versión | Escaneos de exposición, pruebas de autenticación ONVIF/RTSP, auditoría de respuestas de descubrimiento |
| T15 | Inventario de SDK P2P, alcance del token de sesión, entropía del UID de dispositivo, seguimiento de avisos del SDK, pruebas de suplantación y casos de abuso | Registro de versión del SDK, prueba de enumeración de UID, prueba de suplantación de dispositivo |
| T16 | Inventario de firmware de proveedor para ISP, Wi-Fi, codificador y componentes de IA; responsable de componente y ruta de actualización | Lista de materiales del proveedor, registro de seguimiento de avisos, registro de decisión de versión |
¿Qué riesgo residual queda tras los controles?
Los controles no cierran el expediente. Tras enviar la cámara, el fabricante sigue gestionando activamente los riesgos: el canal de actualización de firmware, las rutas de toma de control de la cuenta de propietario y la cola larga de CVE de proveedor en la pila Wi-Fi, las librerías de medios y los SDK P2P que aparecen a lo largo del periodo de soporte. El registro residual solo resulta creíble cuando el fabricante puede apuntar a la monitorización en vivo de esas señales, las decisiones de triaje de avisos nuevos, las actualizaciones firmadas que llegaron realmente a las cámaras instaladas, los avisos a propietarios que se enviaron y la acción correctiva registrada detrás de cada uno.
| Área residual | Por qué permanece | Evidencia operativa |
|---|---|---|
| Endpoint de propietario comprometido | El fabricante no puede controlar del todo el teléfono, navegador, correo o higiene de contraseñas del usuario | Soporte MFA, revocación de tokens, alertas de inicio de sesión sospechoso, guía al usuario |
| Vulnerabilidad de proveedor descubierta tras la versión | Librerías de medios, firmware Wi-Fi, kernels y librerías TLS seguirán recibiendo CVE | Seguimiento de SBOM, recepción de avisos de proveedor, análisis de impacto, registro de parche |
| Acceso físico local | Una cámara en un hogar puede ser robada, revendida, reparada o accedida por invitados | Flujo de restablecimiento, evidencia de bloqueo de depuración, aviso de almacenamiento, registro de borrado RMA |
| Deriva de exposición de red | Actualizaciones de firmware, cambios de retransmisión o banderas de funciones pueden reabrir servicios | Escaneo de exposición versión por versión, inventario de servicios, aprobación de cambios |
La puerta de versión es el propio registro de riesgos. No añadas una tarjeta separada de «seguridad revisada» que repita el mismo trabajo. En la firma, el responsable de versión debe poder apuntar desde las amenazas bloqueadas o condicionales a la evidencia de cierre: pruebas de emparejamiento y de flujo para T1/T2/T5/T14, revocación de token para T3, pruebas de actualización firmada para T6, evidencia de almacenamiento y restablecimiento para T8, evidencia de borrado RMA para T12 y monitorización de proveedor para T11/T16.
Propiedad del desarrollo de la cámara, de concepto a soporte
La responsabilidad principal cambia a medida que la cámara pasa de definición de producto a soporte vivo. Usa este traspaso para asignar un responsable, un registro mantenido y una puerta de revisión en cada fase mientras el producto cambia.
Detalles de responsabilidad: producto y seguridad asumen el memorando de límites de variante en concepto. Seguridad de producto con firmware y nube asumen el mapa de límites de confianza, el registro de amenazas y la escalera de puertas en arquitectura. Los responsables de firmware, nube, app y proveedor mantienen las reglas de actualización firmada, los controles de token y sesión, el manifiesto de componentes, los feeds de avisos de proveedor y las decisiones de banderas de funciones durante la implementación. QA con seguridad de producto mantiene los escaneos de exposición, las pruebas de autenticación de flujo, las pruebas de custodia del vídeo, los simulacros de restablecimiento o borrado RMA y las decisiones de riesgo residual durante la verificación. Cumplimiento y el responsable de versión mantienen el paquete de versión, el índice del expediente técnico, las instrucciones, la declaración del periodo de soporte, la declaración firmada, el paquete del importador y la preparación para notificación. PSIRT, soporte e ingeniería mantienen la recepción, el triaje de avisos de proveedor, los avisos a usuarios, las correcciones firmadas, la retirada de endpoints, las pruebas de regresión y los registros de acción correctiva tras la versión.
Detalles de traspaso: congela el límite antes del trabajo de arquitectura, congela la intención de diseño antes de la implementación, congela el candidato antes de la verificación, congela la decisión antes de la versión y mantén la versión en operación durante el periodo de soporte. Los informes entrantes, los avisos de proveedor, los resultados de incidente y los resultados de regresión reabren el siguiente memorando de límites, registro de amenazas y manifiesto de componentes.
Mapa de evidencia del fabricante
Un revisor o evaluador de organismo notificado recorre el expediente técnico de la cámara como un instalador recorre la caja: desde el producto etiquetado, pasando por los elementos digitales suministrados, hasta la evidencia de soporte prometida al comprador. Las filas siguientes nombran los registros que el fabricante de la cámara mantiene al día para ese recorrido; cada fila debe ser un expediente mantenido en la carpeta del producto, no una captura tomada justo antes de la firma.
| Área de evidencia | Qué recoger para una cámara de seguridad |
|---|---|
| Identidad del producto | Modelo, versiones de firmware, app complementaria, servicio en la nube, revisiones de hardware |
| Finalidad prevista | Si el producto se vende para seguridad doméstica, monitorización de bebés, seguridad de timbre con vídeo o vigilancia profesional |
| Evaluación de riesgos | Acceso a la cámara, confidencialidad del vídeo, configuración de credenciales, exposición de la red local, exposición de la API en la nube |
| SBOM y evidencia de componentes hardware | Paquetes de firmware, componentes de Linux embebido / RTOS, librerías de procesamiento de imagen, firmware del módulo Wi-Fi / Ethernet, SoC y elemento seguro cuando esté presente |
| Configuración segura por defecto | Sin contraseña por defecto compartida, puesta en marcha segura, acceso de administración autenticado, acceso remoto protegido |
| Mecanismo de actualización | Actualizaciones de firmware firmadas, estrategia de reversión, disponibilidad de actualizaciones durante el periodo de soporte |
| Gestión de vulnerabilidades | Política CVD, contacto de notificación, flujo de triaje, proceso de avisos de seguridad |
| Instrucciones de usuario | Instalación segura, configuración de cuenta, ajustes de actualización, comunicación del fin de soporte |
| Trazabilidad y contacto | Esquema de modelo y serie de la cámara, identificador de lote, marcas en embalaje, contacto del fabricante o importador en la UE, fecha de fin del periodo de soporte impresa donde el comprador pueda leerla antes de la compra y una dirección publicada de notificación de vulnerabilidades atendida por un equipo de seguridad humano |
Ruta de evaluación de la conformidad
Elige la ruta de conformidad después de tener claros el límite de la cámara, la evaluación de riesgos, los controles y los riesgos residuales. De lo contrario, la decisión de ruta puede adelantarse al registro de ingeniería.
Clase I Importante no exige automáticamente organismo notificado en todos los casos. La ruta de control interno solo está disponible cuando las normas, especificaciones o esquemas requeridos se aplican plenamente a los requisitos aplicables.
Confirma si existen normas armonizadas relevantes, especificaciones comunes o esquemas europeos de certificación con nivel de garantía al menos sustancial que cubran los requisitos esenciales aplicables. Si no existen, solo se aplican parcialmente o no cubren todos los requisitos relevantes, usa Módulo B+C o Módulo H.
Para una versión real de cámara, prepara el expediente de versión como si pudiera ser necesaria una revisión por tercero y confirma la ruta una vez que las normas y esquemas aplicables estén claros para el producto cámara exacto.
Conserva la ruta seleccionada con el registro de firma de versión, incluidas las referencias en las que se apoya, los requisitos que cubren y las brechas que forzaron una ruta por tercero.
Firma de versión del fabricante
Antes de liberar la cámara al mercado de la UE, la firma debe reunir la clasificación, el límite, el modelo de amenazas, los controles, la ruta de actualización y el proceso postventa en una sola decisión. La tabla siguiente es el expediente corto de versión por el que un revisor debería poder navegar.
| Pregunta de versión | Evidencia específica de la cámara |
|---|---|
| ¿Por qué se clasifica este producto como cámara de seguridad para hogar inteligente? | Declaración de uso previsto, canal de venta, contexto de instalación, variantes del producto y motivo de la clasificación |
| ¿Cuál es exactamente el producto con elementos digitales? | Cuerpo de la cámara, firmware, interfaces locales, app móvil, procesamiento en la nube suministrado con el producto, servicio de actualización y sistemas de despliegue de tercero excluidos |
| ¿Cuáles son las rutas de acceso de mayor riesgo? | Interfaz de administración, ONVIF/RTSP, descubrimiento en la red local, APIs en la nube, recuperación de cuenta, visualización remota, acceso a microSD, puertos de depuración y credenciales de servicio |
| ¿Qué se ha asegurado por defecto? | Sin contraseña por defecto compartida, puesta en marcha protegida, acceso de administración autenticado, revisión de servicios expuestos, decisiones de cifrado y acceso remoto seguro |
| ¿Cómo se actualizará la cámara de forma segura? | Firmware firmado, custodia de claves, comportamiento de reversión, recuperación de flash parcial, disponibilidad de actualizaciones, notificación al usuario y actualizaciones de seguridad gratuitas durante el periodo de soporte |
| ¿Cómo se gestionarán las vulnerabilidades tras el envío? | Contacto público, política CVD, flujo de triaje, monitorización del SBOM, seguimiento de avisos de proveedor, proceso de avisos de seguridad, preparación para alerta temprana de 24 h, preparación para notificación de 72 h y evidencia de informe final |
Comprobaciones de traspaso entre operadores económicos
El expediente de versión debe hacer verificable el traspaso de fabricante a importador, distribuidor y vendedor con marca propia. En cámaras, el punto débil no suele ser solo el marcado CE; es si el envío, la ficha, la app, el servicio en la nube y el canal de actualización siguen coincidiendo con la versión evaluada.
Detalles del traspaso entre operadores económicos: el fabricante o vendedor con marca propia asume el expediente del fabricante para la versión exacta de la cámara. El importador verifica el motivo de la clasificación, la declaración, el control del marcado CE, el índice del expediente técnico, la declaración del periodo de soporte, el contacto de notificación de vulnerabilidades, la gestión del inventario de componentes, las instrucciones en el idioma de destino y la identidad del importador antes de introducir el envío en el mercado de la UE. El distribuidor revisa señales visibles de diligencia antes de la venta, incluidos marcado CE, documentos suministrados, trazabilidad del fabricante e importador, instrucciones en el idioma de destino, declaraciones de soporte y actualización, coherencia de la ficha online y señales conocidas de no conformidad.
Condiciones de parada: detén el envío o la ficha si el expediente de versión, la trazabilidad, la declaración de soporte, la dependencia de app o nube, el canal de actualización o una vulnerabilidad conocida da motivos para creer que la versión no es conforme. Lee cualquier mandato de representante autorizado por separado de la diligencia del importador o distribuidor. Activador del rol de fabricante: ejecuta un análisis nuevo de rol de fabricante cuando un cambio de marca propia, firmware, app, nube, canal de actualización, puente, paquete con NVR o finalidad prevista pueda afectar a la conformidad o a la finalidad prevista. Mantén separadas las preguntas de RGPD, ciberseguridad de la Directiva de Equipos Radioeléctricos, biometría, Reglamento de IA y NIS2 de la respuesta de clasificación CRA.
Usa la figura siguiente como lista de roles. El primer diagrama de traspaso muestra el flujo de envío y ficha; este separa las comprobaciones que asumen importador, distribuidor, representante autorizado, vendedor con marca propia y revisor de régimen adyacente.
Cada panel de rol empareja las verificaciones que el operador debe ejecutar con la condición de parada que detiene envío, ficha o versión. El importador y el distribuidor se sitúan en el propio flujo CRA. El representante autorizado solo se aplica cuando el fabricante no está en la UE y se lee por separado de la diligencia del importador o distribuidor. Las comprobaciones del vendedor con marca propia pueden crear un rol de fabricante si el cambio puede afectar a la conformidad o a la finalidad prevista; la clasificación, la declaración de conformidad, la documentación técnica, el proceso de notificación y el plan de periodo de soporte no se heredan como promesa informal del proveedor. Los regímenes adyacentes (RGPD, ciberseguridad de la Directiva de Equipos Radioeléctricos, Reglamento de IA, NIS2) quedan fuera de la respuesta de clasificación CRA y requieren sus propias evaluaciones separadas.
Preguntas frecuentes
¿Las cámaras de seguridad inteligentes son Clase I o Críticas bajo el CRA?
Las cámaras de seguridad para hogar inteligente suelen ser Clase I Importante cuando su función principal es la seguridad física del hogar inteligente. Una cámara no es Crítica solo porque procese vídeo o se encuentre en una red sensible.
Registro de clasificación: un memorando que nombre la variante exacta de la cámara, la afirmación comercial, la función de seguridad prevista, los elementos digitales suministrados y el motivo de la ruta.
¿Una cámara de seguridad para hogar inteligente necesita organismo notificado?
No siempre. La prueba práctica es si el fabricante puede apoyarse plenamente en las normas aplicables, las especificaciones comunes o la cobertura de un esquema de certificación de ciberseguridad cualificado para los requisitos esenciales de ciberseguridad de la cámara. Si esa cobertura falta o es solo parcial, planifica la ruta por tercero en lugar de dar por hecho el control interno.
Registro de ruta de conformidad: lista las referencias en las que se apoya el producto cámara exacto, los requisitos que cubren, cualquier brecha y la ruta seleccionada.
¿Una cámara CCTV profesional o NVR está automáticamente en la misma categoría?
No. No clasifiques la vigilancia profesional por la palabra «cámara» a secas. Una cámara CCTV, VMS o NVR puede seguir siendo un producto con elementos digitales y seguir necesitando trabajo CRA de seguridad, pero la ruta depende del uso previsto, de los elementos suministrados y de la función en la que confía el cliente.
Registro de límites: un memorando de variante de vigilancia profesional que cubra cámara, grabador, VMS, nube del instalador, ruta de acceso remoto y cualquier producto separado suministrado con la oferta.
¿Qué pasa si la cámara incluye reconocimiento facial, control de acceso, cortafuegos o funciones VPN?
Trátalo como señal de advertencia de clasificación. Si la cámara es principalmente una cámara de seguridad para hogar inteligente, esas funciones pueden formar parte de la evaluación de riesgos de la cámara. Si el producto es principalmente un lector de control de acceso, un dispositivo de autenticación biométrica, una pasarela VPN, un cortafuegos, un IDS/IPS u otro producto de ciberseguridad listado, clasifica primero esa función principal y no fuerces el producto a la categoría de cámara. Esto importa porque algunas categorías llevan una ruta más estricta; por ejemplo, los cortafuegos y los IDS/IPS son Clase II.
Activador de revisión: abre una comprobación separada de función principal cuando la cámara controla identidad, acceso, filtrado de red, acceso VPN o detección de intrusiones, no solo vigilancia por vídeo.
¿El almacenamiento de vídeo en la nube cambia el límite del producto?
El almacenamiento en la nube no cambia automáticamente la clase. Si el procesamiento en la nube suministrado por el fabricante está diseñado por el fabricante o bajo su responsabilidad, y la cámara no realizaría una de sus funciones sin él, trata ese procesamiento como parte del límite del producto, de la evidencia y de la evaluación de riesgos. La clasificación del producto sigue la funcionalidad principal de la cámara salvo que otra función listada sea la principal.
Registro de límites: un mapa de dependencia en la nube que muestre qué servicios en la nube se suministran con la cámara, qué funciones fallan sin ellos, qué datos procesan y qué sistemas quedan fuera de la oferta del fabricante.
¿ONVIF, RTSP o la interfaz web local de administración deben quedar activos tras la puesta en marcha?
Solo si la versión tiene un modelo de acceso documentado para esa superficie. Una cámara de consumo puede exponer streaming local o administración para uso legítimo de puesta en marcha, instalador o grabador, pero el expediente de versión debe mostrar si la superficie sigue accesible tras el alta, qué autenticación la protege, si se usa cifrado de transporte y qué ajuste de usuario o afirmación de variante lo justifica.
Artefacto de prueba: escaneos de servicios tras la puesta en marcha y tras la actualización, pruebas de autenticación ONVIF/RTSP, revisión de respuestas de descubrimiento y decisión de versión para cada superficie local.
¿Cuándo debe actualizarse la evaluación de riesgos?
Actualízala siempre que cambie el estado liberado de la cámara de un modo que afecte a la confianza: nuevo perfil ONVIF, modo de visualización remota, flujo de recuperación de cuenta, retransmisión en la nube, canal OTA, chipset, base de firmware, cambio de autenticación de la app móvil, campo del paquete de soporte o comportamiento de restablecimiento de fábrica. Una nota de versión no basta si la función modificada reabre una ruta de ataque.
Activador de revisión: cualquier cambio de función o de proveedor que altere acceso, autoridad de actualización, vídeo almacenado, vinculación de cuenta, datos de soporte o comportamiento de restablecimiento reabre el límite y la evaluación de riesgos.