Parte 33 · Clase 329 de 830

ARQ-329 · Ciberseguridad de sistemas de edificio

Parte 33 · Clase desarrollada · Incorporada en v0.19.0.

Prerrequisitos conceptuales: ARQ-328, ARQ-325, ARQ-326, ARQ-327. Sin calendario. Casos, observaciones y parámetros ficticios salvo antecedentes atribuidos. Material educativo; revisión externa especializada pendiente.

Pregunta central

¿Cómo proteger los sistemas conectados de un edificio manteniendo sus funciones físicas y la capacidad de recuperación, sin convertir una revisión de ciberseguridad en una prueba riesgosa sobre equipos reales?

Resultado y continuidad

ARQ-328 dejó separadas conectividad y funcionamiento del transporte vertical. Esta clase construye un inventario y un escenario ficticio OT-REC-01 de recuperación documental. No explora redes, no utiliza credenciales y no prueba vulnerabilidades. Entregarás un mapa defensivo de dependencias, una revisión de respaldos y una secuencia de recuperación cuya suma pueda comprobarse sin afectar una instalación.

1. Información digital con consecuencias físicas

Los sistemas de operación pueden observar o modificar procesos del edificio: ventilación, acceso, energía, medición y otros servicios. Una pérdida de información puede afectar diagnóstico o supervisión; una configuración incorrecta puede cambiar la operación. No todas las consecuencias son iguales ni se estiman únicamente por el número de archivos afectados.

La presentación de NIST SP 800-82 Rev. 3 identifica estos sistemas dentro de tecnología operacional y destaca sus condiciones de rendimiento, fiabilidad y seguridad [BMS-OT]. En esta consulta se leyó la presentación oficial, no el documento íntegro. El expediente no se anuncia como una implementación completa de la guía.

La página consultada también identifica una propuesta inicial de revisión posterior en septiembre de 2026. Un borrador no se confunde con una edición final adoptada. La referencia del capítulo conserva Rev. 3 y su alcance, sin reemplazar automáticamente el año en todos los documentos del programa.

2. Inventariar funciones, no solamente direcciones

Un inventario defensivo debe relacionar equipo, función, ubicación, responsable, versión y dependencias. La dirección de red puede cambiar y no describe por sí sola qué hace el dispositivo. Un sensor y un controlador pueden compartir fabricante y tener consecuencias diferentes si dejan de funcionar.

Registra entradas, salidas y qué servicio depende de ellas. Incluye también componentes no conectados que condicionan el conjunto: alimentación, actuadores, accesos físicos y procedimientos. El mapa no intenta reproducir una instalación real ni contiene rutas que permitan acceder a sistemas ajenos.

El resultado permite formular preguntas: quién puede cambiar una configuración, cómo se conoce su versión, qué ocurre cuando falta comunicación y cómo se verifica la recuperación. No hace falta ejecutar un escaneo para elaborar esas preguntas sobre los datos ficticios del curso.

3. Separar supervisión, control local y servicios externos

Un tablero de supervisión puede depender de una red o servicio externo mientras una función local conserva otras dependencias. El diseño debe explicitar qué se mantiene y qué no. No se presume autonomía porque un equipo tenga una pantalla local ni se presume interrupción total por perder una visualización.

La separación de funciones y límites de acceso debe diseñarse por responsables competentes. El curso propone documentar fronteras, no aplicar una receta de segmentación a cualquier edificio. Cambiar conexiones sin conocer secuencias y requisitos puede introducir un problema operativo.

Tampoco se supone que la nube o la red local sean inherentemente suficientes para todas las funciones. Deben compararse disponibilidad, responsabilidades, tratamiento de datos y condiciones de recuperación. El argumento se apoya en requisitos y evidencia, no en etiquetas comerciales.

4. Capacidades del dispositivo y condiciones del conjunto

NISTIR 8259A propone una línea base de capacidades de ciberseguridad para dispositivos IoT [BMS-IOT]. La consulta de su tabla permite distinguir identificación, configuración, protección de datos, control de interfaces, actualización y conocimiento del estado de ciberseguridad. Se usa para organizar preguntas al proveedor, no para declarar certificado un dispositivo.

Por ejemplo, identificar una versión es distinto de poder actualizarla; actualizarla es distinto de demostrar que conserva la función del edificio. Limitar acceso a una interfaz no garantiza que las cuentas estén bien administradas. Las capacidades necesitan configuración, responsabilidades y pruebas apropiadas.

El expediente del curso no publica contraseñas, claves o datos de acceso. Documenta su gestión y custodia por roles autorizados, sin convertir el manual de usuario en un repositorio de secretos. Los archivos sintéticos contienen identificadores sin correspondencia con dispositivos reales.

5. Respaldo existente y respaldo recuperable

OT-REC-01 fija un incidente documental ficticio a las 13:00. La última copia cuya recuperación se comprobó dentro del escenario corresponde a las 10:00. Existe además una copia de las 12:00, pero su prueba de recuperación falló. No se considera disponible solo por tener una fecha reciente.

La separación temporal respecto de la última copia comprobada es tres horas. El objetivo ficticio de punto de recuperación, RPO, permite como máximo dos. La exposición temporal del escenario supera ese objetivo en una hora. No se concluye cuántos datos se perdieron, porque no se proporcionó una serie de modificaciones durante el intervalo.

Contar la copia de las doce reduciría artificialmente la brecha a una hora y escondería su condición no recuperable. La revisión conserva archivo, estado y evidencia. Un tamaño de archivo o un mensaje de «copia completada» no reemplaza una comprobación adecuada de recuperación.

6. Tiempo de recuperación y orden de las tareas

La secuencia ficticia contiene cuatro tareas sucesivas: preparar un entorno autorizado, recuperar la configuración, verificarla y comprobar el servicio. Sus duraciones adoptadas son veinte, treinta, veinticinco y cuarenta minutos. Son tiempos docentes, no promesas para una instalación.

Como se declaró ejecución serial, el total es 20+30+25+40=115 minutos. Un objetivo ficticio de tiempo de recuperación, RTO, de noventa minutos no se satisface: faltan veinticinco respecto de ese límite. El cálculo no debe sumar solo recuperación de archivos y omitir la comprobación de la función.

Realizar tareas en paralelo necesitaría justificar independencia, recursos y precedencias. No se cambia una suma por un máximo únicamente para cumplir el objetivo. Tampoco una reducción del tiempo justifica omitir revisiones de seguridad o uso. Las duraciones no son procedimientos de intervención real.

Figura 329. La copia más reciente no es la última recuperable. El escenario conserva una brecha de tres horas y una secuencia de ciento quince minutos.

7. Recuperar un archivo no acredita recuperar una función

Un archivo puede abrirse y contener una versión inadecuada. Una configuración puede cargarse y utilizar unidades o nombres incompatibles. Un equipo puede responder a mensajes y no mover el actuador como requiere la tarea. La revisión debe conectar contenido, versión y resultado físico.

Por eso la aceptación del escenario se divide en datos, configuración y servicio. Cada nivel tiene evidencias y límites. La recuperación no se anuncia como completa si alguna condición necesaria queda desconocida. No se compensa con otras comprobaciones favorables.

Los ejercicios no conectan la recuperación a controladores, puertas, ascensores o equipos de climatización. Sirven para diseñar preguntas, dependencias y criterios que un equipo autorizado debe desarrollar mediante procedimientos pertinentes, evitando pruebas disruptivas sobre operación real.

8. Cambios, actualizaciones y documentación

Antes de modificar un componente deben identificarse versiones, dependencias, compatibilidades y efectos sobre las funciones. Una actualización necesaria puede requerir coordinación de ventanas, recursos y verificaciones. El programa no prescribe ejecutar o posponer una actualización concreta sin ese análisis.

El control de cambios permite conservar línea base, modificación y documentos afectados [NASA-CHANGE]. La aplicación al edificio es una propuesta docente propia: relaciona software con planos de puntos, secuencias, manuales y evidencias. No se presentan procedimientos contractuales o de seguridad copiados de la fuente.

Si cambian nombres o unidades, el registro debe llegar a quienes interpretan tendencias. Un dato recibido después de una actualización puede ser numéricamente válido y tener otra semántica. La continuidad de la información necesita algo más que conservar el formato del archivo.

9. Responder a incidencias sin ampliar el daño

La planificación debe identificar contactos responsables, conservación de evidencias, límites de intervención y decisiones autorizadas. No se utiliza el curso para probar contraseñas, desactivar protecciones o introducir fallos. El propósito es defensivo: comprender dependencias y preparar una revisión segura.

Un comportamiento anómalo no demuestra por sí solo un ataque. Puede relacionarse con configuración, sensor, comunicación, proceso o múltiples causas. La investigación debe mantener hipótesis y evidencia sin atribuir intenciones antes de contar con respaldo.

También se distingue confidencialidad de publicación. Un informe educativo puede describir categorías y controles sin revelar información que facilite intervenir el edificio. La trazabilidad no exige exponer secretos ni datos personales; exige que los responsables puedan relacionar hallazgos y decisiones.

10. Qué debería contener la entrega

El expediente incluye inventario funcional, mapa de dependencias, roles autorizados, requisitos de dispositivos, configuración de referencia y evidencias de recuperación. Para cada documento registra versión, acceso y responsable de mantenimiento. No afirma conformidad con una norma por enumerar sus títulos.

La conclusión de OT-REC-01 es limitada: la copia comprobada deja tres horas frente a un objetivo de dos, y la secuencia serial requiere 115 minutos frente a noventa. Se necesitan alternativas y comprobaciones adicionales. No demuestra que un edificio sea vulnerable ni que una solución concreta resuelva esos objetivos.

La profundidad está en reconocer que respaldo, restauración, validación y servicio forman partes distintas. La entrega siguiente reunirá esas relaciones con climatización, energía, acceso y transporte, manteniendo los modelos separados.

Práctica independiente

Un incidente ficticio ocurre a las 12:00 y la última copia recuperable corresponde a las 09:30. El objetivo de punto de recuperación es sesenta minutos. La recuperación serial necesita quince minutos de preparación, veinticinco de restauración, veinte de comprobación documental y treinta de prueba de servicio. El objetivo temporal es setenta y cinco minutos.

Calcula las diferencias y redacta una conclusión que no confunda objetivos con resultados. Explica qué evidencia pedirías antes de declarar recuperado el servicio y por qué una copia más reciente no comprobada no puede utilizarse automáticamente para mejorar el indicador.

Autoevaluación y enlace

Separa inventario, capacidad de dispositivo, configuración, recuperación y función. Explica objetivos y resultados sin intercambiarlos. ARQ-330 integrará pruebas y entrega de servicios, sin tratar un resultado digital favorable como certificación de todo el edificio.

Decisión pedagógica y posición curricular

Por qué existe

Esta clase existe para resolver una necesidad concreta del recorrido: ¿Cómo proteger los sistemas conectados de un edificio manteniendo sus funciones físicas y la capacidad de recuperación, sin convertir una revisión de ciberseguridad en una prueba riesgosa sobre equipos reales?

Por qué está exactamente aquí

Ocupa el lugar 9 de la Parte 33. Se estudia después de ARQ-328 · Ascensores, plataformas y escaleras mecánicas porque usa esa base para responder «¿Cómo proteger los sistemas conectados de un edificio manteniendo sus funciones físicas y la capacidad de recuperación, sin convertir una revisión de ciberseguridad en una prueba riesgosa sobre equipos reales?». Se ubica antes de ARQ-330 · Pruebas integradas, manuales y recepción porque la evidencia producida aquí debe estar disponible para ese paso.

• Prerrequisitos: ARQ-328, ARQ-325, ARQ-326, ARQ-327
• Capacidad que introduce: ARQ-328 dejó separadas conectividad y funcionamiento del transporte vertical. Esta clase construye un inventario y un escenario ficticio OT-REC-01 de recuperación documental. No explora redes, no utiliza credenciales y no prueba vulnerabilidades.
• Clases o experiencias que dependen de ella: ARQ-330, ARQ-349, ARQ-357

flowchart LR
    A["Prerrequisitos · ARQ-328, ARQ-325, ARQ-326, ARQ-327"] --> B["ARQ-329 · necesidad y fundamento"]
    S["Fuentes · BMS-OT NIST SP 800-82 Revision 3: Guide to Operational Technology Security + BMS-IOT NISTIR 8259A: IoT Device…"] --> B
    B --> C["Actividad auténtica"]
    C --> D["Evidencia auditable"]
    D --> E["Continuidad · ARQ-330, ARQ-349, ARQ-357"]

El diagrama permite comprobar una relación que el texto lineal oculta con facilidad: esta clase recibe capacidades previas, toma decisiones apoyadas por fuentes, exige una experiencia y produce evidencia que habilita trabajo posterior. No representa un procedimiento de obra.

Resultado observable, evidencia y evaluación

1. Identificar y delimitar las condiciones necesarias para responder la pregunta central de ciberseguridad de sistemas de edificio.
2. Producir y comprobar la evidencia declarada por la clase: ARQ-328 dejó separadas conectividad y funcionamiento del transporte vertical. Esta clase construye un inventario y un escenario ficticio OT-REC-01 de recuperación documental. No explora redes, no utiliza credenciales y no prueba vulnerabilidades.
3. Justificar una decisión de ciberseguridad de sistemas de edificio mediante fuentes, supuestos, alternativas y límites explícitos.

Actividad, evidencia y criterio de aceptación

Actividad: Un incidente ficticio ocurre a las 12:00 y la última copia recuperable corresponde a las 09:30. El objetivo de punto de recuperación es sesenta minutos. La recuperación serial necesita quince minutos de preparación, veinticinco de restauración, veinte de comprobación documental y treinta de prueba de servicio.

Evidencia mínima: ARQ-328 dejó separadas conectividad y funcionamiento del transporte vertical. Esta clase construye un inventario y un escenario ficticio OT-REC-01 de recuperación documental. No explora redes, no utiliza credenciales y no prueba vulnerabilidades.

Archivo sugerido: evidence/ARQ-329/evidencia.md.

Criterio de aceptación: la entrega se acepta cuando:

• La entrega responde explícitamente a la pregunta: ¿Cómo proteger los sistemas conectados de un edificio manteniendo sus funciones físicas y la capacidad de recuperación, sin convertir una revisión de ciberseguridad en una prueba riesgosa sobre equipos reales?
• La actividad conserva las fronteras del caso y permite reconstruir el procedimiento: Un incidente ficticio ocurre a las 12:00 y la última copia recuperable corresponde a las 09:30. El objetivo de punto de recuperación es sesenta minutos. La recuperación serial necesita quince minutos de preparación, veinticinco de restauración, veinte de comprobación documental y treinta de prueba de servicio.
• Cada afirmación externa puede seguirse hasta una fuente, su alcance consultado y su límite.
• La evidencia deja disponible una entrada comprobable para ARQ-330.
• Separa inventario, capacidad de dispositivo, configuración, recuperación y función. Explica objetivos y resultados sin intercambiarlos.

La rúbrica común complementa estos criterios; no los reemplaza. Una entrega puede superar un promedio y continuar pendiente si oculta una condición crítica.

Trazabilidad de las decisiones

La tabla permite auditar las relaciones; la explicación, el caso y la práctica de la clase siguen siendo la documentación principal.

Autoevaluación, recuperación y continuidad

Errores diagnósticos

Antes de avanzar, comprueba si puedes reconstruir cada resultado sin mirar la solución, señalar qué evidencia lo sostiene y nombrar una condición que obligaría a revisar tu decisión. Conserva la primera versión, la objeción recibida y la revisión.

Conexión siguiente: La continuidad inmediata es ARQ-330 · Pruebas integradas, manuales y recepción; conserva el método y vuelve a verificar datos y límites.

Fuentes y alcance de uso

Los casos, datos, diagramas y soluciones son elaboraciones originales. Las fuentes nuevas se consultaron el 23 de septiembre de 2026; las heredadas conservan su alcance. No se declara lectura integral cuando el acceso fue parcial ni se anuncian ensayos reales.

[BMS-OT] NIST SP 800-82 Revision 3: Guide to Operational Technology Security

Keith Stouffer y colaboradores / NIST. https://csrc.nist.gov/pubs/sp/800/82/r3/final

Consulta: Ficha y resumen de la revisión 3 final de 2023. Nota de 21 de septiembre de 2026 remite al borrador inicial de revisión 4. El PDF completo no pudo recuperarse. Apoyo: La tecnología operacional incluye automatización, acceso y monitorización de edificios, con requisitos de seguridad física y fiabilidad. Límite: No se presenta la revisión 4 en borrador como final ni se declara aplicación íntegra de la guía. La arquitectura defensiva y los ejercicios son propuestas didácticas propias.

[BMS-IOT] NISTIR 8259A: IoT Device Cybersecurity Capability Core Baseline

Michael Fagan y colaboradores / NIST. https://nvlpubs.nist.gov/nistpubs/ir/2020/NIST.IR.8259A.pdf

Consulta: Introducción y sección 2; tabla 1 revisada en texto e imágenes, páginas impresas 5–10. Apoyo: Identidad, configuración, protección de datos, acceso a interfaces, actualización y conocimiento del estado como capacidades a investigar. Límite: Base inicial, no lista universal suficiente ni certificación. No se implementaron controles sobre dispositivos reales.

[NASA-CHANGE] NASA Systems Engineering Handbook, 6.0: Crosscutting Technical Management

National Aeronautics and Space Administration. https://www.nasa.gov/reference/6-0-crosscutting-technical-management/

Consulta: Apartados 6.2 y 6.5 sobre requisitos y configuración Apoyo: Línea base, trazabilidad y análisis del impacto de cambios Límite: Los formularios y el caso arquitectónico son originales; no se copian procedimientos contractuales.