11  Unidad 8: Protección y Seguridad

El sistema operativo controla qué archivos puede abrir un proceso, qué memoria puede utilizar y qué operaciones puede realizar sobre los dispositivos. Las aplicaciones también necesitan controles: comprobar una contraseña, permitir una modificación o rechazar una descarga sin autorización.

La unidad explica estos mecanismos y sus límites. La primera sesión presenta los objetivos de la protección, los dominios y la matriz de acceso. Las siguientes desarrollan la administración de permisos, la protección de programas y datos, y el análisis de incidentes mediante registros.

11.1 Objetivos de Aprendizaje

Al finalizar la unidad, el estudiante podrá:

• Explicar quién puede leer o modificar un recurso y representar esos permisos en una matriz de acceso.
• Comparar una lista de permisos asociada a un archivo con una capacidad entregada a un proceso.
• Explicar qué ocurre al retirar un permiso y por qué un acceso ya abierto puede continuar.
• Distinguir la comprobación de una identidad de la autorización para realizar una acción.
• Describir cómo se verifica una contraseña y para qué sirven el cifrado, los resúmenes digitales y las firmas digitales.
• Reconocer amenazas mediante ejemplos y utilizar registros para investigar lo ocurrido.

---

11.2 Sesión 1: Objetivos, dominios y matriz de acceso

11.2.1 Protección y seguridad: conceptos relacionados, no sinónimos

La protección es el conjunto de mecanismos que controla el uso de los recursos de un sistema. Se ocupa de decisiones concretas: permitir o denegar lectura, escritura, ejecución, señalización, montaje, impresión o cambio de configuración.

La seguridad es una propiedad y una disciplina más amplia. Incluye las políticas, los mecanismos de protección, la gestión de identidades, la criptografía, el monitoreo y la respuesta ante incidentes. Un sistema puede implementar correctamente una ACL y aun así ser inseguro si las cuentas se autentican débilmente, las claves se exponen o nadie revisa las alertas. En este punto, una ACL es una lista de control de acceso.

Concepto	Pregunta que responde	Ejemplo
Política	¿Qué debería estar permitido?	Solo el docente puede modificar calificaciones.
Mecanismo	¿Cómo se hace cumplir?	Una ACL concede escritura al grupo docentes.
Protección	¿Se autoriza esta operación concreta?	El kernel permite o deniega open(..., O_WRONLY).
Seguridad	¿Cómo reducimos y gestionamos el riesgo total?	Autenticación multifactor, permisos, cifrado, registros y respuesta.

Nota

Idea clave. Una política puede ser correcta y estar mal implementada. También puede ocurrir lo contrario: un mecanismo puede funcionar exactamente como fue programado, pero aplicar una política insegura.

11.2.2 Elementos de una decisión de acceso

Toda decisión de protección puede describirse con cuatro elementos:

1. Sujeto: entidad activa que solicita la operación. Suele ser un proceso o un hilo que actúa con las credenciales de una cuenta o un servicio.
2. Objeto: recurso sobre el cual se quiere operar. Puede ser un archivo, una región de memoria, un dispositivo, un proceso, un socket o una entrada de configuración.
3. Derecho: operación autorizable, como leer, escribir, ejecutar, borrar, imprimir o administrar.
4. Contexto: información que influye en la decisión: dominio actual, identidad efectiva, grupo, etiqueta de seguridad, hora, procedencia o estado del objeto.

No debe confundirse usuario con sujeto. Un usuario puede iniciar varios procesos y cada uno puede tener un conjunto diferente de derechos. Del mismo modo, un servicio sin una persona frente al teclado también es un sujeto.

flowchart TB
    S[Sujeto en un dominio] --> R[Solicita una operación]
    R --> M[Mecanismo de referencia]
    O[(Objeto)] --> M
    P[Política y credenciales] --> M
    M --> D{¿Derecho vigente?}
    D -->|Sí| A[Permitir y ejecutar]
    D -->|No| N[Denegar]
    A --> L[Registrar si corresponde]
    N --> L

Figura 11.1: Decisión de acceso simplificada. La autenticación previa no reemplaza la autorización que se realiza sobre cada recurso.

11.2.3 Objetivos de la protección

La protección no pretende impedir todo intercambio. Un sistema operativo útil debe permitir compartir recursos de manera controlada. Sus objetivos principales son:

• Aislamiento: un proceso no debe leer o modificar la memoria privada de otro por accidente ni por decisión propia.
• Uso autorizado: cada operación debe corresponder con una regla de la política.
• Compartición controlada: dos sujetos pueden colaborar sin abrir el recurso a todo el sistema.
• Limitación del daño: si un proceso falla o es comprometido, sus derechos acotan lo que puede afectar.
• Responsabilidad: los eventos relevantes deben poder asociarse con un sujeto, un objeto y un momento.
• Continuidad: la protección también debe impedir que un sujeto monopolice recursos y perjudique la disponibilidad de los demás.

Estos objetivos se apoyan en principios clásicos de diseño. Saltzer y Schroeder formularon varios que continúan siendo útiles para razonar sobre sistemas actuales.[1]

11.2.3.1 Mínimo privilegio

Cada usuario, proceso o componente debe recibir únicamente los derechos necesarios, durante el tiempo necesario y sobre los objetos necesarios.

El servicio de impresión del caso conductor necesita leer el archivo enviado y comunicarse con la impresora. No necesita modificar calificaciones, crear cuentas ni leer todos los directorios personales. Si se compromete el servicio, el mínimo privilegio reduce el alcance del incidente.

11.2.3.2 Denegación por defecto

La ausencia de una autorización explícita debe producir una denegación. Una lista de excepciones prohibidas suele ser frágil: todo caso olvidado queda permitido. Una lista de operaciones concedidas obliga a justificar cada apertura.

11.2.3.3 Mediación completa

Todo acceso relevante debe pasar por un mecanismo que verifique la autorización. La frase no significa necesariamente que cada byte leído provoque una búsqueda completa en una ACL. El sistema puede validar al abrir un archivo y entregar un identificador protegido para las operaciones posteriores. Lo esencial es que no exista una ruta alternativa que eluda el control.

11.2.3.4 Separación de privilegios

Las acciones especialmente sensibles pueden requerir condiciones independientes. Por ejemplo, modificar la política de copias de seguridad podría exigir una cuenta administrativa y una confirmación adicional. Comprometer una sola condición no bastaría.

Tip

Comprobación conceptual. Ejecutar toda una aplicación como root porque una de sus funciones necesita un privilegio puntual contradice el mínimo privilegio. Una solución mejor separa esa función o concede una autoridad más específica.

11.2.4 Dominio de protección

Un dominio de protección es el conjunto de derechos que un sujeto puede ejercer en un momento determinado. Puede representarse como un conjunto de pares:

D = {<objeto1, derechos1>, <objeto2, derechos2>, ...}

Un proceso se ejecuta dentro de un dominio. El dominio no tiene por qué coincidir exactamente con una persona. Puede derivarse de:

• el modo de ejecución de la CPU, como usuario o kernel;
• la identidad efectiva y los grupos de un proceso;
• un rol activado durante una tarea;
• un contenedor o entorno aislado;
• el conjunto de identificadores y capacidades que posee el proceso;
• una combinación de credenciales, etiquetas y reglas.

11.2.4.1 Modo usuario y modo kernel

El hardware ofrece al menos una separación esencial. En modo usuario, las instrucciones privilegiadas y ciertas regiones de memoria no están disponibles. En modo kernel, el sistema operativo puede configurar memoria, dispositivos e interrupciones.

Una llamada al sistema produce una transición controlada: la CPU entra al kernel por un punto definido, el kernel valida los argumentos y realiza una operación acotada. La llamada no entrega al proceso el dominio completo del kernel.

11.2.4.2 Cambio de dominio

Los dominios pueden cambiar. Un proceso puede adquirir temporalmente un rol, ejecutar un programa con credenciales diferentes o recibir un identificador que habilita un objeto. Todo cambio debe estar autorizado y debería reducirse al mínimo necesario.

En el caso conductor, el proceso de respaldo obtiene acceso de lectura durante la ventana de copia. Terminado el trabajo, ese derecho puede expirar. Mantenerlo indefinidamente amplía la superficie de ataque sin aportar utilidad.

11.2.5 Matriz de acceso

La matriz de acceso es un modelo abstracto del estado de protección. Las filas representan dominios; las columnas, objetos; cada celda contiene los derechos que el dominio posee sobre el objeto.

Si A[Di, Oj] = {leer, escribir}, un proceso que ejecuta en el dominio Di puede leer y escribir el objeto Oj. Una celda vacía significa que no existe derecho concedido.

Dominio / objeto	Entrega de Ana	Calificaciones	Impresora	Respaldo	Configuración
Estudiante Ana	leer, escribir, entregar	leer propias	solicitar	—	—
Docente	leer, comentar	leer, escribir	solicitar	—	—
Servicio de impresión	leer trabajo enviado	—	imprimir	—	—
Servicio de respaldo	leer	leer	—	escribir copia	—
Administrador	administrar permisos	administrar permisos	administrar	restaurar	modificar

Tabla 1: Estado simplificado de protección del servidor de prácticas.

La matriz ayuda a detectar errores de política. Si el servicio de impresión aparece con derecho de escritura sobre calificaciones, el exceso de privilegio resulta visible. También permite formular dos preguntas que conducirán a las implementaciones de la sesión siguiente:

• Al mirar una columna: ¿quién puede acceder a este objeto?
• Al mirar una fila: ¿a qué objetos puede acceder este dominio?

11.2.5.1 Derechos especiales

Algunos modelos incorporan derechos administrativos, además de leer o escribir:

• propietario: permite modificar los derechos sobre un objeto;
• control: permite modificar derechos de un dominio;
• copiar o delegar: permite transferir un derecho a otro dominio;
• cambiar: permite pasar de un dominio a otro.

No son derechos universales ni tienen idéntico significado en todos los sistemas. Sirven para analizar cómo evoluciona la matriz, no solo cómo se consulta.

Tip

Cierre de la sesión. El docente puede presentar una segunda matriz con tres errores: acceso de estudiantes a notas ajenas, respaldo con permiso de modificación y servicio web con privilegios administrativos. El objetivo es justificar qué principio viola cada celda.

---

11.3 Sesión 2: Concesión y Revocación de Permisos

La apertura de un archivo implica una validación de permisos por parte del sistema operativo, que distingue las operaciones solicitadas, como lectura y escritura. Esta sesión formaliza cómo se almacenan, consultan y retiran dichas autorizaciones.

11.3.1 Listas de control de acceso (ACL)

Una lista de control de acceso (ACL) asocia un recurso protegido con los sujetos, como cuentas o grupos, y sus correspondientes derechos de acceso. Por ejemplo, en un archivo informe.txt, la ACL puede asignar lectura y modificación al propietario y restringir a un grupo de revisión exclusivamente a la lectura. La propia ACL debe estar protegida contra alteraciones no autorizadas.

Sujeto	Recurso	Derechos concedidos
Propietario	informe.txt	Lectura y escritura.
Grupo de revisión	informe.txt	Lectura.

La validación se realiza durante la apertura: el sistema operativo evalúa las credenciales del proceso, es decir, la cuenta y los grupos con los que se ejecuta, frente a los permisos del recurso. Si la operación solicitada no está autorizada, deniega la apertura. Un proceso con permiso de lectura no obtiene por ello permiso de escritura.

El modelo tradicional de propietario, grupo y otros establece una distribución básica de permisos. Las ACL permiten añadir autorizaciones más específicas. En la matriz de acceso, una ACL representa una columna: reúne los sujetos que pueden utilizar un recurso y los derechos que poseen sobre él.

11.3.2 Capacidades de objeto

Las capacidades de objeto (object capabilities) son autorizaciones protegidas contra falsificación. Cada capacidad asocia un recurso con un conjunto de operaciones permitidas. Un proceso que posee una capacidad puede solicitar esas operaciones, siempre que la autorización siga vigente. No puede fabricar capacidades válidas ni ampliar por su cuenta sus derechos.

Un conversor de imágenes ejecutado en un entorno limitado, por ejemplo, puede recibir una capacidad de lectura para el archivo de origen y otra de escritura para el archivo de destino. Esos accesos no le conceden permisos sobre otros archivos. La restricción depende de que el sistema la implemente.

flowchart TB
    P[Proceso conversor] --> A[Capacidad de lectura]
    A --> E[Archivo de origen]
    P --> B[Capacidad de escritura]
    B --> S[Archivo de destino]

Figura 11.2: Capacidades de lectura y escritura concedidas a un conversor limitado.

Una forma de prevenir la falsificación consiste en guardar las capacidades en tablas gestionadas por el núcleo. Los procesos utilizan referencias numéricas para identificar entradas, y el núcleo valida el recurso y los derechos asociados. Cambiar un índice no crea una autorización. seL4 implementa capacidades para controlar los recursos administrados por su microkernel.[2]

La delegación permite transferir una capacidad a otro proceso, según las reglas del sistema. Puede incluir versiones con menos derechos, también llamadas capacidades atenuadas. Por ejemplo, un proceso con lectura y escritura puede entregar a un visor únicamente lectura. Si el sistema permite nuevas delegaciones, se forma una cadena de autorizaciones que debe considerarse al retirar el acceso.

Comparación estructural. Las ACL organizan los permisos alrededor del recurso protegido, como una columna de la matriz. Las listas de capacidades los organizan alrededor del proceso o dominio que puede ejercerlos, como una fila. Esta diferencia describe la organización de la información, no obliga a que la comprobación física se realice en un único lugar.

En Unix, un descriptor de archivo actúa de manera análoga a una capacidad: después de validar los permisos durante la apertura, el sistema devuelve un número que referencia el archivo abierto y el modo de acceso concedido. El programa lo utiliza en operaciones posteriores. Esta analogía no implica que Unix sea un sistema completo de capacidades ni que toda apertura utilice una ACL extendida.[3]

11.3.3 Revocación de permisos

La revocación invalida un acceso previamente concedido. Requiere especificar el recurso, los sujetos afectados y las operaciones que se retiran. También deben revisarse los permisos que una cuenta conserva por pertenecer a grupos.

Criterio	Modalidades	Ejemplo
Alcance	Parcial o total.	Quitar escritura o retirar todos los derechos sobre el archivo.
Sujetos afectados	Selectiva o general.	Retirar el acceso a una cuenta o a todos los autorizados.
Duración	Temporal o permanente.	Suspender el acceso durante una revisión o eliminarlo definitivamente.
Momento de aplicación	Inmediata o diferida.	Exigir que cese ahora o aceptar que termine más adelante.

La dificultad técnica incluye la gestión de los accesos activos. En muchos sistemas tipo Unix, modificar los permisos de un archivo no invalida automáticamente los descriptores que los procesos ya tenían abiertos. El cambio puede impedir nuevas aperturas mientras una lectura anterior continúa. Si se requiere una interrupción inmediata, hay que intervenir sobre los procesos o las sesiones que mantienen esos accesos, según los mecanismos disponibles.

Retirar un permiso de lectura tampoco tiene efecto retroactivo sobre las copias obtenidas antes del cambio. La revocación controla accesos posteriores al recurso original, pero no borra archivos que ya se copiaron fuera de él.

En sistemas basados en capacidades se utilizan alternativas como las siguientes:

• Plazo de validez: la capacidad vence después de un período determinado. Esto no equivale a poder cancelarla en cualquier instante anterior.
• Indirección: la capacidad depende de una autorización intermedia cuya vigencia se comprueba antes de permitir la operación. Desactivarla permite retirar el acceso.
• Árboles de delegación: el sistema conserva las relaciones entre capacidades y permite retirar también las autorizaciones derivadas. Esta es una forma de revocación transitiva.

---

11.4 Sesión 3: Aislamiento Lógico, Autenticación y Criptografía

Las políticas de acceso del sistema de archivos no bastan frente a errores de ejecución, credenciales expuestas o acceso físico a los medios de almacenamiento. Estos problemas requieren controles sobre el programa, la autenticación y la información almacenada o transmitida.

11.4.1 Protección basada en lenguaje

La protección basada en lenguaje aplica restricciones durante la compilación y la ejecución. La seguridad de memoria previene accesos inválidos, como leer fuera de los límites de un arreglo. La seguridad de tipos restringe operaciones incompatibles con los tipos de datos. Las garantías concretas dependen del lenguaje, del entorno y de las funciones utilizadas.

La máquina virtual de Java (JVM) ejemplifica este mecanismo mediante la verificación estructural y de tipos del bytecode, el código intermedio que ejecuta. Esa verificación puede rechazar código que no cumple las reglas de la máquina virtual.[4]

Estos controles se complementan con los límites de recursos del sistema operativo. Un programa puede respetar las reglas de tipos y memoria y, aun así, borrar un archivo equivocado si tiene permiso para hacerlo. La verificación del código no demuestra que todas sus decisiones sean correctas.

11.4.2 Identidad, autenticación y autorización

El control de acceso distingue funciones que no deben confundirse:

• Identificación: declaración de la cuenta o del sujeto que solicita acceso. Un nombre de usuario identifica la cuenta, pero por sí solo no demuestra quién la controla.
• Autenticación: comprobación de una prueba asociada a la identidad declarada. Puede utilizar factores de conocimiento, como contraseñas, de posesión, como llaves de seguridad, o biométricos.
• Autorización: decisión del sistema o de la aplicación para conceder o denegar una operación específica sobre un recurso. Autenticarse no concede automáticamente todos los permisos.

La autenticación multifactor (MFA) combina factores de categorías distintas y puede reducir el riesgo de acceso con una contraseña robada. Su resistencia al phishing depende del método: los códigos de un solo uso introducidos manualmente pueden ser reenviados por una página falsa. Los mecanismos que vinculan la prueba al sitio legítimo, como WebAuthn, ofrecen protección específica frente a ese engaño.[5]

El registro de auditoría (log) deja constancia de acciones y resultados, pero no reemplaza el mecanismo que controla el acceso. Además, una cuenta registrada no identifica con certeza a la persona que la utilizó si sus credenciales quedaron expuestas o su sesión permaneció abierta.

11.4.3 Almacenamiento seguro de credenciales

Las contraseñas utilizadas para autenticación no deben almacenarse en texto plano. Se guardan verificadores obtenidos mediante funciones diseñadas para procesar contraseñas. El cálculo incorpora dos elementos:

• Sal: un valor aleatorio específico para cada contraseña almacenada. Dificulta reutilizar cálculos preparados, como tablas arcoíris, contra muchas cuentas. Se guarda junto al verificador y no necesita ser secreta.
• Costo: parámetros que determinan el trabajo y, según el método, la memoria que requiere cada cálculo. Aumentan el costo de probar muchas contraseñas, especialmente en ataques offline, realizados después de obtener una copia de los verificadores.

Para comprobar una contraseña, el sistema recupera la sal y la configuración almacenadas, repite el cálculo con el valor recibido y compara el resultado con el verificador. No necesita recuperar la contraseña original.

flowchart TB
    A[Contraseña recibida] --> C[Función para contraseñas]
    B[Sal y costo almacenados] --> C
    C --> D[Resultado calculado]
    D --> E{Comparar}
    F[Verificador almacenado] --> E
    E -->|Coinciden| G[Prueba aceptada]
    E -->|Difieren| H[Prueba rechazada]

Figura 11.3: Comprobación de una contraseña con sal, configuración de costo y verificador.

Argon2id es una función de procesamiento de contraseñas con parámetros de memoria, iteraciones y paralelismo. OWASP la recomienda como una opción principal para este propósito. El costo del cálculo también afecta al servicio legítimo y debe configurarse de acuerdo con sus recursos.[6]

11.4.4 Primitivas criptográficas

El cifrado protege la confidencialidad al transformar texto plano en texto cifrado que no puede interpretarse de manera práctica sin la clave adecuada. La operación inversa es el descifrado.

• Cifrado simétrico: utiliza la misma clave secreta para cifrar y descifrar. AES es un algoritmo de este tipo. Su eficiencia permite utilizarlo para grandes volúmenes de información, incluidos archivos, discos y datos transmitidos.[7]
• Criptografía de clave pública o asimétrica: utiliza pares de claves relacionadas. En un esquema de cifrado, la clave pública del destinatario permite proteger información que se recupera con su clave privada. En un esquema de firma, la clave privada firma y la pública verifica. Son operaciones distintas y deben emplear el esquema adecuado para cada uso.[8]
• Cifrado híbrido: combina el cifrado simétrico del contenido con un mecanismo de clave pública para proteger o establecer la clave simétrica. Así permite procesar grandes volúmenes y resolver la distribución de claves entre las partes.

Un ejemplo de cifrado híbrido consiste en generar una clave simétrica, cifrar un archivo con ella y proteger esa clave con la clave pública del destinatario. Este utiliza su clave privada para recuperarla y después descifra el archivo. Antes del envío debe comprobarse que la clave pública corresponda al destinatario previsto.

Las herramientas de comprobación de integridad y origen cumplen funciones diferentes:

Herramienta	Función	Condición o límite
Resumen digital (hash)	Comparar el contenido con una referencia.	La referencia debe ser confiable. Un hash solo no identifica al autor.
Código de autenticación de mensajes (MAC)	Comprobar integridad y origen entre partes que comparten una clave.	Cualquiera de las partes que conoce la clave puede producir el código.
Firma digital	Verificar integridad y correspondencia con una clave privada mediante la clave pública.	Atribuirla a una persona u organización exige verificar la relación entre esa identidad y la clave.

Una firma digital puede contribuir al no repudio, es decir, aportar evidencia del origen de una acción o documento. Esa propiedad requiere garantías sobre la identidad del titular, la validez de las claves y el control de la clave privada. No surge automáticamente por agregar una firma a un archivo.[9]

La administración del ciclo de vida de las claves comprende su generación, almacenamiento, uso, sustitución y recuperación. La exposición de una clave puede permitir descifrar información anterior protegida con ella si también se dispone de los datos cifrados. El alcance depende del tipo de clave y del protocolo, no de toda la información del sistema. Reemplazarla no elimina copias antiguas que ya se obtuvieron.

---

11.5 Sesión 4: Modelado de Amenazas, Auditoría y Respuesta a Incidentes

El análisis inicial de un sistema con comportamiento anómalo debe distinguir fallas operativas de incidentes de seguridad. Una interrupción puede deberse a un error de configuración, agotamiento de recursos o actividad deliberada. El síntoma por sí solo no establece la causa.

11.5.1 Tríada CID y superficie de ataque

La tríada CID reúne tres propiedades de seguridad:

• Confidencialidad: evitar el acceso a información sin autorización.
• Integridad: conservar la información frente a alteraciones indebidas o accidentales.
• Disponibilidad: permitir el uso de los recursos cuando se necesitan.

Un incidente puede afectar varias propiedades a la vez. Por ejemplo, la extracción no autorizada de archivos seguida de su cifrado extorsivo puede exponer la información e impedir su uso.

El análisis de riesgos distingue una amenaza, que puede causar daño, de una vulnerabilidad, que es una debilidad aprovechable. Un ataque es una acción deliberada contra el sistema y el impacto es la consecuencia que produce. El riesgo considera la probabilidad y la magnitud de esas consecuencias, con estimaciones cualitativas o cuantitativas.

La superficie de ataque comprende los puntos por los que se puede intentar influir en el sistema, como servicios de red, entradas de datos y funciones administrativas. Desactivar servicios innecesarios reduce esos puntos. Aplicar mínimo privilegio limita las acciones disponibles y el daño posible si un componente resulta comprometido.

11.5.2 Taxonomía de incidentes

• Software malicioso (malware): incluye virus, que se incorporan a otros archivos o programas, gusanos, que se replican y propagan habitualmente por la red, troyanos, que aparentan ser software legítimo, y ransomware, que bloquea o cifra datos para exigir un pago y puede extraerlos. Sus permisos iniciales condicionan el daño, aunque puede intentar ampliarlos explotando fallas.
• Escalada de privilegios: adquisición ilegítima de derechos adicionales. Un proceso puede pasar de permisos comunes a operaciones reservadas al administrador.
• Denegación de servicio (DoS/DDoS): ataque que impide el uso legítimo de un servicio, por ejemplo agotando capacidad de procesamiento, memoria o ancho de banda. DDoS indica que el ataque procede de varios equipos coordinados.
• Ingeniería social y errores operativos: el engaño puede inducir a una persona a revelar credenciales o permitir una acción. Los errores también pueden exponer datos o alterar una configuración, sin que exista manipulación ni negligencia deliberada.

La defensa en profundidad combina controles, como aislamiento de procesos, permisos, autenticación y cifrado TLS de los datos en tránsito. Busca reducir la probabilidad y el impacto de un incidente cuando un control falla. No garantiza por sí sola la contención: los controles deben estar bien configurados, cubrir el problema y evitar fallas comunes entre ellos.

La protección también requiere responsabilidades para detectar, responder y recuperar el funcionamiento. El marco de ciberseguridad de NIST integra estas funciones con la identificación de riesgos y la gestión de la organización.[10]

11.5.3 Monitoreo, registros (logs) y respuesta

Los registros de eventos permiten reconstruir acciones mediante datos como fecha y hora, cuenta o proceso, recurso afectado y resultado. Deben omitir secretos como contraseñas y claves, y estar protegidos frente a acceso, modificación y eliminación no autorizados. La inmutabilidad es una propiedad que debe implementarse mediante controles específicos, no una característica automática de un log.[11]

Campo	Información que aporta
Fecha y hora	Cuándo se registró la acción.
Cuenta o proceso	Con qué identidad de ejecución se solicitó.
Recurso	Sobre qué archivo, cuenta u objeto se actuó.
Operación y resultado	Qué se pidió y si se aceptó, se rechazó o falló.

El monitoreo utiliza modelos complementarios:

• Detección por firmas: identificación de patrones conocidos asociados a actividades maliciosas. Aquí, firma significa patrón de detección, no firma digital.
• Detección por anomalías: identificación de desviaciones respecto de una referencia de comportamiento habitual. Una desviación también puede tener una causa legítima.

Ambos modelos pueden producir falsos positivos, alertas sobre actividad legítima, y falsos negativos, actividad maliciosa que no se detecta. Estos últimos no se limitan a ataques sofisticados. Las alertas necesitan revisión y contexto antes de concluir que hubo un incidente.

La respuesta a incidentes relaciona los registros disponibles, limita el acceso indebido y corrige las causas. La contención puede incluir revocar credenciales o terminar sesiones. La recuperación puede requerir restaurar desde respaldos verificados y comprobar que no reintroducen el problema. Durante el proceso se conserva la evidencia necesaria para investigar. Restaurar archivos no elimina copias de información que hayan sido extraídas.

---

11.6 Síntesis de la Unidad

Requisito técnico	Mecanismo de control	Limitación operativa
Restringir el acceso a lectura.	Permisos estándar y ACL.	Revisar también los permisos obtenidos por pertenencia a grupos.
Limitar un proceso a archivos concretos.	Capacidades de objeto.	Impedir falsificación y controlar la delegación.
Invalidar accesos compartidos.	Revocación.	Considerar descriptores abiertos y copias obtenidas previamente.
Comprobar una identidad declarada.	Autenticación.	La autorización de operaciones sigue siendo necesaria.
Proteger la confidencialidad de medios en reposo.	Cifrado y administración de claves.	Depender de claves adecuadas, protegidas y recuperables.
Investigar comportamientos anómalos.	Monitoreo y auditoría.	Relacionar evidencias y comprobar las alertas en su contexto.

La seguridad de un sistema operativo combina protecciones con funciones diferentes. El hardware y el núcleo controlan recursos y accesos. Los mecanismos del lenguaje restringen operaciones inválidas bajo las garantías que ofrecen. La criptografía protege o verifica información fuera del control directo de los permisos de archivos.

El diseño debe seleccionar el mecanismo adecuado para cada necesidad y comprobar sus límites. Identificar el recurso, la operación y la amenaza permite justificar qué control corresponde y qué evidencia se necesita para verificar su funcionamiento.

[1]

J. H. Saltzer y M. D. Schroeder, «The Protection of Information in Computer Systems», Proceedings of the IEEE, vol. 63, n.º 9, pp. 1278-1308, 1975, doi: 10.1109/PROC.1975.9939.

[2]

seL4 Foundation, «Capabilities». Disponible en: https://docs.sel4.systems/Tutorials/capabilities.html

[3]

Linux man-pages project, «open(2): Open and possibly create a file». Disponible en: https://man7.org/linux/man-pages/man2/open.2.html

[4]

Oracle, «The Java Virtual Machine Specification, Java SE 25: Verification of Class Files». 2025. Disponible en: https://docs.oracle.com/javase/specs/jvms/se25/html/jvms-4.html#jvms-4.10

[5]

National Institute of Standards and Technology, «Digital Identity Guidelines: Authentication and Authenticator Management», National Institute of Standards; Technology, NIST SP 800-63B-4, 2025. Disponible en: https://pages.nist.gov/800-63-4/sp800-63b/authenticators/

[6]

OWASP Foundation, «Password Storage Cheat Sheet». Disponible en: https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html

[7]

National Institute of Standards and Technology, «Advanced Encryption Standard (AES)», National Institute of Standards; Technology, FIPS 197, 2023. doi: 10.6028/NIST.FIPS.197-upd1.

[8]

K. Moriarty, B. Kaliski, J. Jonsson, y A. Rusch, «PKCS #1: RSA Cryptography Specifications Version 2.2», RFC Editor, RFC 8017, 2016. Disponible en: https://www.rfc-editor.org/info/rfc8017

[9]

E. Barker, «Recommendation for Obtaining Assurances for Digital Signature Applications», National Institute of Standards; Technology, NIST SP 800-89, 2006. doi: 10.6028/NIST.SP.800-89.

[10]

C. Pascoe, S. Quinn, y K. Scarfone, «The NIST Cybersecurity Framework (CSF) 2.0», National Institute of Standards; Technology, NIST CSWP 29, 2024. doi: 10.6028/NIST.CSWP.29.

[11]

OWASP Foundation, «Logging Cheat Sheet». Disponible en: https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html