Capítulo 11 — Sistemas operativos | Grado Seguridad de infraestructuras críticas y sectores

Aprendizaje gratuito y abierto para quienes desean proteger a las personas y la tecnología. No se necesita una cuenta para estudiar ni consultar las respuestas.

Mapa de la lección

Lección 11 publicada. Mapa, ejemplo, EX021.

flowchart TD
  N0["Resultados de aprendizaje y conexión"]
  N1["11.1 Qué hace el sistema operativo"]
  N2["11.2 Tipos de SO en los servicios críticos"]
  N3["11.3 Bastionado"]
  N4["11.4 El parcheo en operaciones"]
  N5["11.6 Actividad práctica"]
  N6["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Ejemplo resuelto"]
  EX --> Q["Ejercicio EX021"]

Dibujo lógico

flowchart LR
  N0["Resultados de aprendizaje y conexión"]
  N1["11.1 Qué hace el sistema operativo"]
  N2["11.2 Tipos de SO en los servicios críticos"]
  N3["11.3 Bastionado"]
  N4["11.4 El parcheo en operaciones"]
  N5["11.6 Actividad práctica"]
  N6["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX021"]

[Resultados de aprendizaje y conexión]
    |
    v
[11.1 Qué hace el sistema operativo]
    |
    v
[11.2 Tipos de SO en los servicios críticos]
    |
    v
[11.3 Bastionado]
    |
    v
[11.4 El parcheo en operaciones]
    |
    v
[11.6 Actividad práctica]
    |
    v
[Síntesis del capítulo]
    |
    v
[Ejemplo resuelto] --> [Ejercicio EX021]

Resultados de aprendizaje y conexión

Después de este capítulo usted podrá (1) explicar los procesos, la protección de memoria, los permisos de archivo y los privilegios; (2) describir cómo un sistema operativo aplica el mínimo privilegio y dónde no puede hacerlo; (3) comparar los sistemas operativos de propósito general, de tiempo real y embebidos en los servicios críticos; y (4) elaborar una lista de comprobación de bastionado y una decisión de parcheo para un dispositivo que no puede reiniciarse a voluntad. Se apoya en las capas del capítulo 2 y prepara el capítulo 13 (identidad) y el capítulo 24 (controles).

11.1 Qué hace el sistema operativo

El sistema operativo (SO) reparte una sola máquina entre muchos programas y usuarios. Un proceso es un programa en ejecución con su propia memoria; el SO usa la protección de memoria del hardware para que un proceso no pueda leer ni sobrescribir la memoria de otro. El núcleo (kernel) es el componente central privilegiado que gestiona el hardware; los programas de usuario le piden servicios mediante llamadas al sistema. Los archivos llevan permisos (en los sistemas tipo Unix, lectura, escritura y ejecución para el propietario, un grupo y los demás) y el SO los comprueba en cada acceso. El privilegio es la capacidad de saltarse esas comprobaciones: la cuenta root de Unix, el Administrador de Windows. Los principios de mínimo privilegio y mediación completa de Saltzer y Schroeder (cada acceso comprobado, cada programa con solo los derechos que necesita) siguen siendo la base (Saltzer and Schroeder, 1975).

11.2 Tipos de SO en los servicios críticos

Los sistemas de propósito general (Windows, Linux, macOS) hacen funcionar servidores, estaciones de trabajo de operadores y PC de oficina; tienen muchas funciones, se parchean con frecuencia y son muy atacados. Los sistemas operativos de tiempo real (RTOS) garantizan que las tareas cumplan sus plazos (un relé de protección debe actuar en milisegundos) y funcionan en controladores, relés y dispositivos médicos; son pequeños y se parchean con menos frecuencia. El firmware embebido de sensores y dispositivos sencillos puede no tener ninguna separación entre programas. La consecuencia: las protecciones de SO más fuertes están en las máquinas más fáciles de sustituir, y las más débiles en las máquinas que más duran.

11.3 Bastionado

El bastionado reduce lo que un atacante puede aprovechar. Una lista de comprobación práctica: eliminar o desactivar los servicios y el software que no se usan; cambiar las cuentas y contraseñas por defecto; ejecutar los servicios con cuentas sin privilegios; activar el registro de eventos y enviar los registros fuera del equipo; restringir los soportes extraíbles; activar las listas de aplicaciones permitidas donde la carga de trabajo es estable (las estaciones de trabajo de operadores son buenas candidatas: ejecutan los mismos pocos programas durante años); mantener la hora sincronizada para poder correlacionar los registros. Cada elemento debe poder comprobarse: una norma de bastionado que no puede verificarse es un deseo.

11.4 El parcheo en operaciones

En la TI de oficina, parchear es una rutina. En una estación de trabajo de operador o en un controlador, un parche puede requerir la validación del fabricante, una ventana de mantenimiento y un plan de vuelta atrás, porque una actualización fallida puede detener el proceso. Una decisión de parcheo basada en el riesgo se pregunta: ¿es explotable la falla en este dispositivo tal como está desplegado (¿es alcanzable?, ¿requiere acceso local?); ¿se sabe que se está explotando; qué controla el dispositivo; qué controles compensatorios existen; cuándo es la próxima ventana? El resultado es uno de estos: parchear ya (cambio de emergencia), parchear en la próxima ventana, mitigar y supervisar hasta la sustitución, o aceptar con un responsable nombrado. La guía de TO del NIST analiza estos compromisos (SP 800-82 Rev. 3).

11.5 Ejemplo resuelto: estación de trabajo de señalización de CT (sintético)

Este caso es sintético. La estación de trabajo de control de señalización de Calder Transit funciona con un SO de propósito general. Una actualización mensual corrige una falla que permite a un usuario local con pocos privilegios convertirse en administrador. La estación no tiene acceso a internet ni correo electrónico, tiene activada la lista de aplicaciones permitidas y solo inician sesión tres señalistas con nombre. El fabricante valida las actualizaciones del SO cada trimestre; el próximo paquete validado llega dentro de siete semanas. Decisión: parchear en la próxima ventana, porque la explotación necesita una cuenta local en una máquina estrictamente controlada; mientras tanto, confirmar que la lista de permitidos se aplica y revisar las tres cuentas. Si la falla hubiera sido explotable de forma remota a través de un servicio de red que la estación expone, la respuesta habría sido un cambio de emergencia o desactivar ese servicio.

11.6 Actividad práctica

En su propio ordenador, enumere los procesos en ejecución y la cuenta con la que se ejecuta cada uno; busque un servicio que no use y averigüe cómo podría desactivarse (no desactive nada de lo que no esté seguro). Redacte una lista de comprobación de bastionado de cinco elementos para una estación de trabajo de atención de llamadas del CEDC, cada uno con la forma de verificarlo. Para la estación del CEDC, redacte elementos como «los operadores de llamadas inician sesión con cuentas individuales sin derechos de administrador; comprobación: listar los administradores locales cada mes» o «almacenamiento USB bloqueado; comprobación: insertar una unidad de prueba durante la revisión trimestral».

11.7 Errores comunes y límites

Ejecutarlo todo como administrador «para evitar problemas de permisos».
Bastionar una vez y no verificar nunca la deriva.
Aplicar a la TO la cadencia de parcheo de la TI de oficina sin validación ni vuelta atrás.
Suponer que un dispositivo sin interfaz de usuario del SO no tiene SO.

La estación de señalización de CT muestra las alternativas: la lista de permitidos y tres cuentas con nombre en lugar del uso de administrador, un paquete trimestral validado por el fabricante en lugar de la cadencia mensual de la oficina, y una revisión que comprueba que la lista de permitidos se sigue aplicando. El cuarto error abarca las bombas de infusión del CVH, que funcionan con un RTOS que necesita actualizaciones del fabricante.

Ejercicios — capítulo 11

EX021 — Decisión de parcheo. Objetivo: aplicar las preguntas basadas en el riesgo. Entradas: una falla explotable de forma remota en la interfaz web de un controlador del BMS del CVH; la interfaz es alcanzable desde la red corporativa; la corrección del fabricante requiere reiniciar el controlador durante 30 minutos; la ventilación de los quirófanos depende del BMS. Pasos: responda las cinco preguntas de la decisión de parcheo basada en el riesgo de este capítulo y haga una recomendación. Evidencia esperada: respuestas y recomendación con controles provisionales. Rúbrica: 3 = restringir de inmediato el acceso a la interfaz, programar el reinicio con mantenimiento de instalaciones y quirófanos en una ventana planificada, supervisar; 2 = resultado correcto, controles provisionales débiles; 1 = «parchear de inmediato» sin tener en cuenta la ventilación; 0 = nada.

EX022 — Bastionado verificable. Objetivo: hacer que los controles se puedan comprobar. Entradas: tres elementos vagos: «proteger las cuentas», «activar el registro», «bloquear el USB». Pasos: reescriba cada uno como una afirmación específica y verificable, con su comprobación. Evidencia esperada: tres elementos reescritos. Rúbrica: 3 = específicos, observables, con un método de comprobación; 2 = específicos pero sin comprobación; 1 = siguen siendo vagos; 0 = nada.

Síntesis del capítulo

El SO aplica la separación, los permisos y los privilegios; el mínimo privilegio y la mediación completa son sus ideas rectoras. En los servicios críticos, los dispositivos más duraderos suelen tener las protecciones más débiles, por lo que el bastionado debe ser verificable y el parcheo debe basarse en el riesgo, estar programado y ser reversible.