Capítulo 12 — Sistemas operativos
Mapa de la lección
Lección 12 publicada. Mapa, ejemplo, EX023.
flowchart TD
N0["Resultados de aprendizaje y conexión"]
N1["12.1 Qué hace un sistema operativo"]
N2["12.2 Sistemas operativos de tiempo real"]
N3["12.3 Mecanismos de seguridad del sistema operativo"]
N4["12.4 Parches bajo restricciones de disponibilidad"]
N5["12.6 Actividad práctica"]
N6["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX023"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje y conexión"]
N1["12.1 Qué hace un sistema operativo"]
N2["12.2 Sistemas operativos de tiempo real"]
N3["12.3 Mecanismos de seguridad del sistema operativo"]
N4["12.4 Parches bajo restricciones de disponibilidad"]
N5["12.6 Actividad práctica"]
N6["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX023"]
[Resultados de aprendizaje y conexión]
|
v
[12.1 Qué hace un sistema operativo]
|
v
[12.2 Sistemas operativos de tiempo real]
|
v
[12.3 Mecanismos de seguridad del sistema operativo]
|
v
[12.4 Parches bajo restricciones de disponibilidad]
|
v
[12.6 Actividad práctica]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX023]
Resultados de aprendizaje y conexión
Al terminar este capítulo, usted podrá (1) explicar los procesos, los hilos, la planificación, la gestión de memoria y los sistemas de archivos; (2) distinguir los sistemas operativos de propósito general de los de tiempo real y elegir entre ellos; (3) aplicar los mecanismos de seguridad del sistema operativo (cuentas, permisos, aislamiento, registro, parches) a los servidores del centro de control y a las estaciones de ingeniería; y (4) planificar los parches y el endurecimiento bajo las restricciones de disponibilidad de la tecnología operativa. Se apoya en el capítulo 8 y prepara los capítulos 18 y 39.
12.1 Qué hace un sistema operativo
Un sistema operativo reparte el hardware entre los programas y ofrece abstracciones: procesos (espacios de direcciones aislados), hilos (ejecución concurrente dentro de un proceso), memoria virtual, archivos y dispositivos. El núcleo se ejecuta con privilegios; las aplicaciones solicitan servicios mediante llamadas al sistema. El planificador decide qué hilo se ejecuta; su política determina la latencia. En LRWA, los servidores SCADA y las estaciones de ingeniería ejecutan sistemas operativos de propósito general, mientras que la lógica de protección de las bombas se ejecuta en las RTU y los PLC de cada estación. Saber qué código se ejecuta dónde le indica qué máquinas necesitan garantías de tiempo real y cuáles necesitan endurecimiento, parches y registro del tipo que se describe a continuación.
12.2 Sistemas operativos de tiempo real
Un sistema operativo de tiempo real garantiza una respuesta acotada: las tareas con plazos se planifican de modo que, si el análisis dice que caben, cumplen sus plazos. La planificación por prioridades fijas con asignación de prioridades monótona en la tasa (rate-monotonic) es un enfoque clásico; el análisis de Liu y Layland da una cota de utilización suficiente para tareas periódicas bajo esa política. Los sistemas operativos de propósito general (Windows, Linux de escritorio) optimizan el rendimiento y la equidad; su latencia de peor caso no está acotada sin una configuración especial. Regla: las funciones de protección se ejecutan en controladores de tiempo real; las funciones de supervisión (HMI, historiador) pueden ejecutarse en sistemas de propósito general.
12.3 Mecanismos de seguridad del sistema operativo
- Mínimo privilegio: los servicios se ejecutan con cuentas dedicadas que tienen solo los derechos necesarios; no hay cuentas de administrador compartidas. Saltzer y Schroeder (1975) formularon el mínimo privilegio, los valores predeterminados a prueba de fallos, la mediación completa y la economía de mecanismo como principios de diseño que siguen vigentes.
- Control de acceso: permisos sobre archivos y objetos; control de acceso obligatorio donde esté disponible.
- Lista de aplicaciones permitidas: solo se ejecutan los ejecutables aprobados; es práctico en equipos de TO de propósito único cuyo software rara vez cambia.
- Registro: autenticación, uso de privilegios, cambios de servicios y creación de procesos, reenviados fuera del equipo.
- Endurecimiento: eliminar los servicios no usados, cerrar los puertos no usados, deshabilitar la ejecución automática de medios extraíbles.
- Parches: aplicar las actualizaciones de seguridad, probadas y programadas.
12.4 Parches bajo restricciones de disponibilidad
Los sistemas de TO a menudo no pueden reiniciarse a voluntad, y los proveedores pueden dar soporte solo a niveles de parche concretos. Por tanto, la aplicación de parches se basa en el riesgo: evalúe la explotabilidad de cada vulnerabilidad en su arquitectura (¿es alcanzable el servicio vulnerable?), su consecuencia y el riesgo para la disponibilidad de aplicarlo; después, aplique el parche, mitigue (bloquee el puerto, deshabilite la función) o acepte con una fecha de revisión. Mantenga un sistema de pruebas que refleje la producción para validar los parches. La guía de TO del NIST (SP 800-82 Rev. 3) analiza estas compensaciones.
12.5 Ejemplo resuelto: endurecimiento de los servidores SCADA (sintético)
Los dos servidores SCADA de LRWA ejecutan un sistema operativo de propósito general. La línea base del TMRP: cuentas de servicio dedicadas; los operadores inician sesión con cuentas nominativas; administrador local deshabilitado salvo una cuenta de emergencia (break-glass) cuya contraseña está sellada y cuyo uso genera una alarma; lista de aplicaciones permitidas habilitada tras un periodo de aprendizaje de dos semanas en un entorno de pruebas; almacenamiento USB bloqueado; registros reenviados al recolector de la DMZ; una ventana mensual de parches que alterna entre servidores para que uno esté siempre en funcionamiento. El riesgo residual (el proveedor certifica los parches 30 días después de su publicación) se mitiga con reglas de red que exponen al campo y a la DMZ solo los puertos de la aplicación SCADA.
12.6 Actividad práctica
En una máquina virtual Linux que le pertenezca, enumere los servicios a la escucha (ss -tulpn), las cuentas locales con intérprete de inicio de sesión y los servicios habilitados. Escriba una nota de endurecimiento: qué servicios deshabilitaría en un equipo de historiador de propósito único y por qué. No ejecute esto contra ningún sistema que no le pertenezca. Registre la salida con la fecha y el nombre de la máquina y, para cada servicio que deshabilitaría, anote qué se rompería si usted se equivocara. Un equipo de historiador de LRWA necesitaría su servicio de base de datos y el reenvío de registros, pero rara vez un servidor de correo o un servicio para compartir archivos. Compare su lista con las medidas de endurecimiento del ejemplo de SCADA y explique cualquier diferencia. El ejercicio entrena el hábito de preguntar por qué se ejecuta cada servicio antes de decidir si debería ejecutarse.
12.7 Errores comunes y límites
- Ejecutar la lógica de protección en un sistema operativo de propósito general.
- Cuentas compartidas que destruyen la rendición de cuentas.
- Aplicar parches por calendario sin evaluar la explotabilidad, o no aplicarlos nunca porque «la TO es especial».
- Registros guardados solo en el equipo que controla el atacante.
- Lista de aplicaciones permitidas activada en producción sin un periodo de aprendizaje.
El endurecimiento del SCADA de LRWA evita cada uno de estos errores: las cuentas nominativas sustituyen a las compartidas, los registros salen del equipo, la lista de permitidos se activó tras dos semanas de aprendizaje en un entorno de pruebas y la ventana mensual de parches alterna entre los dos servidores. El riesgo residual queda registrado.
Ejercicios — capítulo 12
EX023 — Comprobación monótona en la tasa. Objetivo: probar la planificabilidad con la cota de Liu–Layland. Entradas: tres tareas periódicas en una RTU: (C=2 ms, T=10 ms), (C=4 ms, T=40 ms), (C=10 ms, T=100 ms). Pasos: calcule la utilización; calcule la cota $n(2^{1/n}-1)$ para $n = 3$; concluya. Evidencia esperada: números y conclusión. Rúbrica: 3 = U = 0,40, cota ≈ 0,780, planificable según la prueba suficiente, con la salvedad de que superar la cota no probaría que no es planificable; 2 = falta la salvedad; 1 = error aritmético; 0 = nada.
EX024 — Decisión sobre un parche. Objetivo: tomar una decisión de parcheo basada en el riesgo. Entradas: una vulnerabilidad de ejecución remota de código en el servicio para compartir archivos del sistema operativo; el servicio está habilitado en el historiador, pero el cortafuegos de la zona de control lo bloquea desde todas las zonas salvo la de ingeniería; faltan 30 días para que el proveedor certifique el parche. Pasos: recomiende parchear / mitigar / aceptar, con controles provisionales y una fecha de revisión. Evidencia esperada: nota de decisión. Rúbrica: 3 = mitigación inmediata (deshabilitar el servicio o restringirlo más), parche tras la certificación, monitoreo, fecha; 2 = sin control provisional; 1 = «parchear de inmediato» ignorando el soporte del proveedor, o «aceptar» sin razonamiento; 0 = nada.
Síntesis del capítulo
El sistema operativo determina tanto la temporización como la línea base de seguridad. Ponga los plazos en plataformas de tiempo real. Aplique el mínimo privilegio, las listas de aplicaciones permitidas, el endurecimiento y el registro fuera del equipo. Aplique los parches según el riesgo evaluado, con procedimientos probados y controles compensatorios cuando aún no pueda parchear, y mantenga un entorno espejo que lo haga posible.
Siga estudiando — capítulo 12 de 50
← Capítulo 11 · Índice de capítulos del curso · Capítulo 13 →
Continúe con la siguiente lección escrita.