Fundamentos de seguridad de sistemas operativos: una guía gratuita

Busca «fundamentos de seguridad de sistemas operativos» y encontrarás muchos módulos de pago que prometen enseñártelos. Pero los fundamentos de verdad no son propiedad de nadie: son un conjunto de conocimientos bien documentado y disponible públicamente que cualquier profesional de TI, analista junior o principiante con curiosidad por la seguridad puede aprender gratis. Esta guía cubre las ideas básicas: qué son, por qué existe cada una y qué se rompe cuando falta. Sin registro, sin curso y sin trampa.

Gran parte de lo que sigue se corresponde con los Essential Eight de la Australian Signals Directorate: la autoevaluación de los Essential Eight de PlayCISO estima dónde estás.

La seguridad del sistema operativo es la base sobre la que se apoya todo lo demás en un programa de seguridad. Los controles de red, las políticas de identidad y la seguridad de las aplicaciones dan por hecho que el sistema operativo de debajo no está ya comprometido. Si fallan los fundamentos del sistema operativo, todas las capas que hay por encima son decorativas.

Por qué el sistema operativo es el objetivo de mayor valor

El sistema operativo media en todos los recursos de un dispositivo: archivos, procesos, memoria, sockets de red, periféricos. Un atacante que compromete el sistema operativo (o una cuenta con privilegios suficientes en él) no necesita vencer una a una todas las aplicaciones que funcionan encima; hereda la visión que el sistema operativo tiene de todo. Por eso el compromiso a nivel de sistema operativo, y no una sola contraseña robada o un correo de phishing, suele ser el objetivo real de una intrusión. Todo lo de esta guía existe para hacerlo más difícil, más lento y más visible.

Gestión de parches: cerrar las puertas conocidas antes de que se usen

Un parche corrige una vulnerabilidad que ya se ha descubierto y, a menudo, ya se ha publicado. El intervalo entre la publicación de un parche y su aplicación es una ventana conocida que el escaneo automatizado y los atacantes oportunistas explotan activamente; no hace falta un adversario sofisticado, solo uno que ejecute un escáner a gran escala contra los sistemas sin parchear.

Cómo es una buena gestión de parches

• Primero, el inventario. No puedes parchear lo que no sabes que ejecutas. Un inventario exacto de activos y de software es el requisito previo, poco vistoso, del que depende todo lo demás.
• Prioriza por explotabilidad, no solo por gravedad. Un fallo de gravedad crítica sin exploit conocido y un fallo de gravedad media que se está explotando activamente no son igual de urgentes: trata las vulnerabilidades que se sabe que se explotan como la máxima prioridad, sea cual sea su puntuación CVSS.
• Prueba antes del despliegue general, pero no dejes que las pruebas se conviertan en un retraso indefinido. Un despliegue por fases (un grupo piloto y después un despliegue más amplio) detecta el raro parche que rompe algo sin dejar toda la flota expuesta durante semanas.
• Parchea el sistema operativo y todo lo demás. Los navegadores, los lectores de PDF y los agentes de terceros son puntos de apoyo habituales precisamente porque los programas de parcheo a veces olvidan que existen.

El modo de fallo práctico no es la ignorancia: la mayoría del personal de TI sabe que parchear importa. Es que el parcheo compite con los requisitos de disponibilidad, la fricción del control de cambios y, sencillamente, no saber qué está sin parchear. Un programa de gestión de parches es en realidad un problema de inventario y de procesos con una etiqueta técnica.

Mínimo privilegio y control de acceso

El principio del mínimo privilegio dice que cada cuenta, proceso y servicio debería tener solo el acceso que necesita para hacer su trabajo, nada más, y solo durante el tiempo que lo necesite. Parece obvio y se incumple sistemáticamente, normalmente porque un acceso amplio es el camino más fácil durante la configuración y nadie vuelve después a reducirlo.

Dónde se nota en la práctica

• Cuentas de usuario estándar para el trabajo diario. Los derechos de administrador local deberían ser la excepción, concedidos de forma deliberada y limitados en el tiempo, no el inicio de sesión por defecto de quien use la máquina.
• Identidades separadas para administrar y para el día a día. La cuenta de correo y navegación diaria de un administrador de TI no debería ser la misma que tiene derechos de administrador del dominio: una cuenta diaria víctima de phishing con privilegios de administrador permanentes entrega al atacante todo de golpe.
• Cuentas de servicio limitadas a una sola finalidad. Una cuenta de servicio que ejecuta una aplicación no debería tener también derechos de inicio de sesión interactivo ni acceso a sistemas sin relación.
• Revisión periódica de los accesos. Los privilegios se acumulan con el tiempo a medida que las personas cambian de puesto; sin una revisión periódica, el «mínimo privilegio» se convierte discretamente en «cualquier privilegio que se haya concedido alguna vez».

El mínimo privilegio no es principalmente un control de prevención: un atacante decidido con un punto de apoyo inicial a menudo acabará entrando en algún sitio. Su valor real es la contención: convierte «una cuenta comprometida controla todo el entorno» en «una cuenta comprometida controla una parte pequeña y acotada», lo que da tiempo a que la detección se ponga al día.

Bastionado: reducir la superficie de ataque por defecto

Un sistema operativo recién instalado viene configurado por lo general para la compatibilidad y la facilidad de configuración, no para la seguridad. El bastionado es el proceso de endurecer esa configuración por defecto: desactivar los servicios que nadie usa, cerrar los puertos innecesarios, imponer ajustes de autenticación fuertes, eliminar las cuentas por defecto o de ejemplo y desactivar los protocolos heredados que solo existen por compatibilidad con software que ya nadie ejecuta.

No hace falta inventar un estándar de bastionado desde cero. Los CIS Benchmarks, líneas de base de configuración gratuitas y elaboradas por consenso que publica el Center for Internet Security, cubren la mayoría de los grandes sistemas operativos (Windows, macOS, las distribuciones de Linux habituales) con ajustes concretos y comprobables y la justificación de cada uno. El NIST publica orientaciones complementarias, incluida la muy citada serie de Special Publications 800, que cubren la gestión de la configuración y el bastionado de sistemas a nivel de programa. Ninguno de los dos exige pagar para leerlos.

Una breve lista de comprobación de bastionado representativa

• Desactiva o elimina los servicios y funciones que no se usan activamente (protocolos de red sin uso, aplicaciones de ejemplo, métodos de acceso remoto heredados).
• Impón una política de autenticación fuerte (requisitos mínimos de contraseña o, mejor, passkeys o MFA respaldada por hardware donde el sistema operativo lo admita) y desactiva o restringe mucho las cuentas con credenciales vacías o por defecto.
• Limita la administración remota a redes de confianza y exige MFA para ella.
• Aplica el principio de la mínima funcionalidad: un servidor que hace un trabajo no debería ejecutar software sin relación que amplíe lo que puede hacer un atacante una vez dentro.
• Restringe las reglas del firewall local al tráfico que el dispositivo necesita de verdad enviar o recibir.

El bastionado y el parcheo se confunden a menudo, pero resuelven problemas distintos. El parcheo corrige vulnerabilidades en el código; el bastionado reduce lo que está expuesto, se haya encontrado ya una vulnerabilidad o no. Un sistema totalmente parcheado con valores por defecto permisivos sigue siendo un objetivo fácil: el bastionado es lo que marca la diferencia entre «técnicamente no vulnerable a un CVE conocido» y «difícil de verdad de conseguir un punto de apoyo».

Cifrado del disco y arranque seguro: proteger el propio dispositivo

El parcheo y el bastionado dan por hecho que el sistema operativo funciona con normalidad. Otros dos controles protegen el dispositivo cuando esa suposición no se cumple: cuando se pierde, lo roban o un atacante tiene acceso físico o previo al arranque.

Cifrado de disco completo

El cifrado de disco completo (BitLocker en Windows, FileVault en macOS, LUKS en la mayoría de las distribuciones de Linux) garantiza que, si se extrae el almacenamiento de un dispositivo o el propio dispositivo se pierde o lo roban, los datos que contiene sean ilegibles sin la clave de descifrado. Sin él, el acceso físico a un disco equivale en la práctica al acceso de lectura completo a todo lo que contiene, sin ninguna petición de contraseña, porque la pantalla de inicio de sesión solo protege el sistema operativo en marcha, no el disco en bruto.

Arranque seguro e integridad del sistema operativo

El arranque seguro verifica, en cada fase del inicio, que el firmware, el gestor de arranque y el kernel del sistema operativo que se cargan están firmados por una autoridad de confianza y no se han manipulado. Defiende frente a una clase concreta y muy dañina de malware (bootkits y rootkits) que se instala por debajo del sistema operativo, antes incluso de que arranque el software de seguridad, y que resulta invisible para las defensas normales a nivel de sistema operativo. Las funciones modernas de integridad del sistema operativo (arranque medido, comprobaciones de integridad del código del kernel) se basan en la misma idea: establecer la confianza en el momento más temprano posible y verificarla en cada paso posterior.

Juntos, estos dos controles responden a una pregunta que el parcheo y el bastionado no responden: ¿qué pasa cuando el atacante no tiene que iniciar sesión en absoluto, porque tiene el dispositivo en sus manos o controla lo que se carga antes que el sistema operativo?

Escalada de privilegios: cómo un pequeño punto de apoyo se convierte en un compromiso total

Casi ninguna intrusión real empieza con el atacante teniendo el control administrativo total. Empieza en pequeño (una credencial de usuario estándar obtenida con phishing, una aplicación vulnerable, una tarea programada mal configurada) y la escalada de privilegios es el proceso de convertir ese pequeño punto de apoyo en un control más amplio.

Patrones habituales de escalada de privilegios

• Vulnerabilidades locales sin parchear en el kernel o en un servicio privilegiado que permiten a un usuario estándar ejecutar código como administrador o root.
• Permisos mal configurados: un archivo, script o tarea programada que se ejecuta con privilegios elevados pero que un usuario estándar puede modificar, lo que le permite sustituirlo por su propio código.
• Exposición de credenciales: contraseñas en texto plano, credenciales en caché o tokens de acceso que quedan en memoria, en archivos de configuración o en el historial de la shell y que un usuario estándar puede leer pero no debería poder usar para nada privilegiado.
• Abuso de rutas de confianza: engañar a un proceso privilegiado para que ejecute código controlado por el atacante, por ejemplo aprovechando cómo busca el sistema operativo un programa o una biblioteca.

Por eso importan juntos el mínimo privilegio y el bastionado: el mínimo privilegio limita lo que puede hacer por sí sola una cuenta comprometida, y el bastionado cierra las configuraciones incorrectas concretas de las que dependen las técnicas de escalada de privilegios. Ninguno es una defensa completa por sí solo; un atacante que no puede escalar privilegios sigue limitado a lo que ya alcanzaba la cuenta comprometida, y por eso la monitorización de los endpoints en busca de cambios de privilegios inusuales importa como tercera capa.

Registro y auditoría: hacer visible el compromiso

Todos los controles anteriores pueden fallar. Se pasan por alto parches, las configuraciones se desvían, un atacante encuentra una vía de escalada de privilegios que nadie previó. El registro y la auditoría son lo que convierte un fallo silencioso en uno detectable: la diferencia entre una intrusión que se detecta en horas y una que descubre otra persona ocho meses después.

Qué merece la pena registrar en un endpoint

• Eventos de autenticación: inicios de sesión con éxito y fallidos, sobre todo las escaladas de privilegios (un usuario estándar que de repente se ejecuta como administrador) y los inicios de sesión a horas o desde lugares inusuales.
• Creación de procesos: qué se ejecutó y qué proceso padre lo lanzó. Así se detectan las técnicas de «living off the land» (herramientas de administración legítimas usadas con fines maliciosos): la herramienta en sí es normal, pero que un navegador lance un motor de scripts no lo es.
• Cambios de configuración y de políticas: software de seguridad desactivado, reglas del firewall que cambian, nuevas tareas programadas o elementos de inicio que aparecen.
• Acceso a archivos y al registro en rutas sensibles, cuando el sistema operativo permite auditarlo.

Los logs solo sirven si alguien (o algo) los revisa de verdad, y si quien los revisa sabe cómo es lo normal lo bastante bien como para detectar lo que no lo es. Esa capacidad de reconocer patrones se puede aprender sin un entorno de producción en directo ni un incidente real con el que trabajar. El SOC Log Triage Trainer de PlayCISO, gratuito y en el navegador, emite mil logs sintéticos de fuentes de identidad, EDR, firewall, DNS y endpoint, te deja marcar los campos que te parecen sospechosos y explica después cada indicador real: una forma rápida y sin registro de crear el hábito de leer los logs con sentido crítico en lugar de pasarlos por encima.

El control de acceso tiene su propio problema de visibilidad que merece nombrarse aparte: no siempre es evidente lo arriesgada que es una identidad concreta hasta que sopesas a la vez su privilegio, su exposición y su monitorización. El Identity Risk Calculator de PlayCISO (Pro) puntúa una identidad humana, de servicio o de IA justo en esos factores, una forma útil de ver cómo el principio del mínimo privilegio anterior se traduce en una cifra real.

Juntar los fundamentos

Ninguno de estos controles funciona de forma aislada, y ninguno basta por sí solo:

• El parcheo cierra las vulnerabilidades conocidas, pero un sistema parcheado con una configuración débil sigue expuesto: eso es lo que aborda el bastionado.
• El bastionado reduce la superficie de ataque, pero no ayuda cuando un dispositivo se pierde físicamente: eso es lo que abordan el cifrado del disco y el arranque seguro.
• El mínimo privilegio contiene lo que alcanza una cuenta comprometida, pero a un atacante que sí escala privilegios hay que detectarlo de alguna forma: eso es lo que abordan el registro y la auditoría.
• Y el registro solo compensa si se entiende lo bastante bien lo que es normal como para notar lo que no lo es, lo cual es una habilidad que se practica, no una configuración que se hace una vez.

Esta superposición, en la que cada control da por hecho que los demás pueden fallar, es lo que significa de verdad la «defensa en profundidad» a nivel de sistema operativo. Y no es casualidad que sea exactamente la estructura de los estándares públicos y gratuitos de los que se nutre: los CIS Benchmarks y las orientaciones del NIST citados a lo largo de esta guía los escribieron profesionales que documentaban lo que funciona de verdad, y siguen estando disponibles gratis para cualquiera que quiera leerlos y practicar su aplicación.