La tríada CIA: confidencialidad, integridad y disponibilidad

La tríada CIA es el modelo que usa la comunidad de seguridad para decir qué protege un control. Nombra tres propiedades de la información y de los sistemas: confidencialidad, integridad y disponibilidad. La mayoría de los controles de seguridad existen para mantener verdadera una o más de ellas. Si puedes decir qué propiedad rompió un evento, ya sabes qué tipo de daño causó y qué tipo de control debía haberlo detenido.

Este artículo continúa donde termina ¿Qué es la ciberseguridad?. Ese texto dijo que la seguridad consiste en proteger la información y los sistemas contra el daño. Este reduce la idea a tres objetivos y te da una forma de clasificar eventos reales.

#Qué es la tríada CIA

Cada propiedad responde a una pregunta distinta:

• Confidencialidad: ¿quién puede leer esto?
• Integridad: ¿esto está sin cambios y realmente viene de quien dice venir?
• Disponibilidad: ¿las personas correctas pueden usarlo cuando lo necesitan?

El NIST usa estos tres términos en sus publicaciones de seguridad. La FIPS 199 construye sobre ellos las categorías de información federal de Estados Unidos: cada categoría pregunta cuánto daño causaría la pérdida de cada propiedad. Las definiciones formales son más largas y más cuidadosas que el resumen anterior. Las fuentes al final de este artículo las enlazan, y conviene leerlas cuando ya tengas clara la idea básica.

Las letras son una ayuda para la memoria, no un ranking. La C no va primero porque sea la más importante. Un sistema de citas de un hospital puede tratar la disponibilidad como su preocupación principal, mientras que un libro mayor de pagos puede darle más peso a la integridad. La prioridad correcta depende del sistema y de lo que pasa cuando falla.

#Por qué tres propiedades y no una

"Mantenerlo seguro" esconde los compromisos. Un sistema puede guardar bien sus secretos y ser inútil porque nadie puede llegar a él. Puede estar siempre en línea y servir datos incorrectos. Puede ser exacto, estar siempre disponible y aun así filtrar registros a las personas equivocadas. Nombrar tres propiedades permite hacer una pregunta precisa sobre cada una y elegir controles que la respondan.

Otros marcos añaden más términos, como autenticidad, rendición de cuentas y no repudio. Algunas definiciones incluyen la autenticidad y el no repudio dentro de la integridad. La FIPS 199 lo hace así. Con cualquier definición, el modelo de tres propiedades es el punto de partida común, así que aprende primero ese.

#Confidencialidad: el archivo filtrado

Imagina que una empresa exporta su lista de clientes a una hoja de cálculo y la guarda en una carpeta compartida. Todas las personas de la empresa pueden abrir esa carpeta. Un contratista que solo debía ver un proyecto descarga el archivo completo. Nada cambió. El servicio siguió en línea. La información, sin embargo, salió del lugar donde debía quedarse, y se perdió la confidencialidad.

La confidencialidad trata de quién puede leer los datos. Cubre los datos en reposo (en un disco, en una base de datos), los datos en tránsito (que viajan por la red) y los datos en uso (abiertos en memoria o en pantalla).

#Controles típicos para la confidencialidad

• El cifrado vuelve los datos ilegibles sin una clave. Protege discos robados y tráfico interceptado, pero no detiene a quien ya tiene la clave o está autorizado a leer los datos.
• El control de acceso y el mínimo privilegio dan a cada persona solo los permisos que necesita su trabajo. El contratista del ejemplo no debería haber podido llegar a toda la carpeta.
• La autenticación multifactor hace que una contraseña robada sirva menos por sí sola.

#Comprobación opcional: el cifrado en acción

Los comandos siguientes se ejecutan sobre un archivo de prueba. Muestran lo que hace el cifrado en la práctica. Es una ilustración, no un laboratorio evaluado, y la contraseña es solo para esta demostración. Nunca pongas secretos reales en la línea de comandos ni en el historial del shell.

printf 'Patient: J. Example, diagnosis: placeholder\n' > record.txt
export DEMO_PASS='lab-only-passphrase'
openssl enc -aes-256-cbc -pbkdf2 -salt -pass env:DEMO_PASS -in record.txt -out record.enc
od -A x -t x1z record.enc | head -3
openssl enc -d -aes-256-cbc -pbkdf2 -pass env:DEMO_PASS -in record.enc
openssl enc -d -aes-256-cbc -pbkdf2 -pass pass:wrong -in record.enc -out /dev/null

En la máquina donde se ejecutó esto (Windows 11, Git Bash, OpenSSL 3.2.4), la salida fue:

000000 53 61 6c 74 65 64 5f 5f e4 81 09 19 9d 68 fe de  >Salted__.....h..<
000010 54 5b 6c 39 12 1a 38 01 b3 03 ac b8 66 be 3b 4b  >T[l9..8.....f.;K<
000020 68 ae 58 39 8f 74 f1 59 23 27 09 fe b7 cf cc 58  >h.X9.t.Y#'.....X<
Patient: J. Example, diagnosis: placeholder
bad decrypt
D4C00000:error:1C800064:Provider routines:ossl_cipher_unpadblock:bad decrypt:../openssl-3.2.4/providers/implementations/ciphers/ciphercommon_block.c:107:

Las tres primeras líneas son el comienzo del texto cifrado. Los bytes que siguen a la cabecera Salted__ parecen aleatorios y cambian en cada ejecución, porque OpenSSL elige una sal nueva cada vez, así que tu hexadecimal será distinto. La contraseña correcta devuelve la línea original. La incorrecta falla con bad decrypt, y ese error es todo lo que produce la clave equivocada. El texto del error no revela el contenido. El código de ocho caracteres al inicio del mensaje también varía entre ejecuciones.

#Integridad: la descarga alterada

Alguien descarga un instalador desde un sitio espejo. Si el archivo fue modificado, puede seguir funcionando perfectamente. La pregunta no es si funciona. La pregunta es si sus bytes coinciden con lo que publicó el fabricante.

La integridad también cubre datos de una base de datos editados sin autorización, un registro borrado después de una intrusión y un archivo de configuración cambiado por un script que nadie aprobó. En todos esos casos, el daño es que ya no puedes confiar en lo que dicen los datos.

#Hashes: detectar un cambio

Una función hash lee un archivo y produce una huella de longitud fija. Si cambias un byte, la huella cambia por completo. Comparar huellas permite comprobar que dos copias son idénticas sin leer los dos archivos uno al lado del otro.

Los comandos siguientes crean un archivo, registran su hash SHA-256 y cambian su contenido:

printf 'Transfer: 10.00 USD to account A\n' > transfer.txt
sha256sum transfer.txt
printf 'Transfer: 1000.00 USD to account A\n' > transfer.txt
sha256sum transfer.txt

Salida observada:

f5ff0bd125880721c12f4eeecd95eb1a03fbc98f61dbd4ea2235cd7c902aa936 *transfer.txt
486ca9f3224c8003ff043ae09f3d1bc6cbe5008859a81c08e95da91945812b04 *transfer.txt

El segundo hash no tiene nada en común con el primero, aunque el cambio fuera un cero de más. La comprobación se vuelve útil cuando guardas el hash esperado y lo comparas. Guarda el hash original en release.sha256 y luego verifica:

sha256sum -c release.sha256

Para el archivo original imprimió release.txt: OK. Después de alterar el archivo, imprimió esto:

release.txt: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match

El comando termina con estado 1, así que un script puede detenerse con él.

El hash tiene un límite. Si el atacante reemplaza el archivo y también reemplaza el hash publicado en la misma página, la comparación pasa y no prueba nada. El hash solo dice que el archivo coincide con el hash que recibiste, así que necesitas una copia confiable de ese hash.

#Firmas digitales: probar quién lo publicó

La firma digital resuelve ese problema. El editor firma el archivo con una clave privada. Quien tiene la clave pública correspondiente puede verificar la firma. Un atacante sin la clave privada no puede producir una firma válida para un archivo alterado.

Los siguientes comandos usan una clave RSA desechable creada en una carpeta de prueba. No reutilices esa clave para nada real.

openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out priv.pem
openssl pkey -in priv.pem -pubout -out pub.pem
openssl dgst -sha256 -sign priv.pem -out release.sig release.txt
openssl dgst -sha256 -verify pub.pem -signature release.sig release.txt

Con el archivo original, la verificación imprimió Verified OK. Después del cambio, la misma verificación imprimió Verification failure, seguido de líneas de error de OpenSSL con rutas de código fuente. Esas líneas se omiten aquí.

Una firma válida demuestra que el archivo fue firmado por quien tiene la clave privada. No demuestra que esa clave pertenezca al fabricante que esperabas. Ese vínculo llega por un paso aparte: un certificado, una distribución de claves de confianza o una huella que verificas por otro canal.

#Controles típicos para la integridad

• Hashes publicados por un canal distinto al de la descarga, para que quien edita el archivo no pueda editar también la referencia.
• Firmas digitales en paquetes de software, actualizaciones y documentos.
• Registros de auditoría y control de cambios que anotan quién cambió qué y cuándo. Los registros también necesitan protección, o un intruso puede borrarlos.
• Control de versiones para código y configuración, de modo que cada cambio deje un diff y un revisor.

#Disponibilidad: el sitio que está caído

Una clínica ejecuta su sistema de citas en un solo servidor. Un lunes por la mañana falla un disco. Los pacientes no pueden reservar durante un día. No robaron nada y nada cambió. Simplemente el servicio no estaba cuando la gente lo necesitaba.

Los ataques producen el mismo resultado. Un ataque de denegación de servicio distribuido (DDoS) inunda un servicio de tráfico hasta que los usuarios legítimos no pueden entrar. Un ransomware puede bloquear archivos para que el personal no pueda trabajar, incluso cuando ningún dato sale de la organización. La disponibilidad también incluye el camino de las personas: una cuenta bloqueada tras demasiados intentos fallidos de inicio de sesión es una pequeña pérdida de disponibilidad.

#Controles típicos para la disponibilidad

• Copias de seguridad guardadas en un lugar separado. Una copia que nunca has restaurado es una esperanza, no un control, así que prueba las restauraciones periódicamente.
• Redundancia y conmutación por error: un segundo servidor, una segunda ruta de red o una base de datos en espera que toma el relevo cuando falla la primera.
• Planificación de capacidad y limitación de tasa para absorber picos normales y frenar el tráfico abusivo.
• Protección contra DDoS de tu proveedor de hosting o de red, que filtra el tráfico antes de que llegue a tus servidores.
• Un plan de recuperación escrito que indique cuánto tiempo puede estar caído el servicio (tiempo de recuperación) y cuántos datos recientes puedes permitirte perder (punto de recuperación).

Las copias de seguridad tienen un matiz. Una copia puede proteger la integridad cuando permite restaurar una versión limpia después de una intrusión, pero solo si se hizo antes de la intrusión y quedó fuera del alcance del atacante. Además, la copia es un dato confidencial, así que también necesita cifrado y control de acceso.

#Cómo las tres propiedades se conectan con los controles

La mayoría de los controles tocan más de una propiedad. La pregunta útil es de cuál propiedad dependes para un riesgo determinado.

#Un método que puedes reutilizar

1. Nombra el activo: un archivo, una base de datos, un sistema de inicio de sesión, un sitio web.
2. Para cada propiedad, pregúntate cuál sería el daño si el activo se revelara, se alterara o quedara no disponible.
3. Clasifica cada daño como bajo, moderado o alto. Es el mismo razonamiento que la FIPS 199 aplica a los sistemas federales.
4. Elige controles para los daños más altos primero.
5. Pregúntate cómo sabrías que el control falló. Una copia necesita una prueba de restauración, una firma necesita una verificación y una política de contraseñas necesita una forma de detectar abuso.

#Ejercicio en papel: clasifica diez incidentes

Lee cada descripción y escribe una letra: C (confidencialidad), I (integridad) o A (disponibilidad). Si encajan dos propiedades, elige la que la descripción enfatiza más y anota la otra entre corchetes. No necesitas computadora. Intenta los diez antes de leer la clave de respuestas.

1. Roban un portátil de un coche. Su disco no está cifrado y la lista de clientes que contiene es legible.
2. Un sitio espejo sirve un instalador modificado. Los usuarios que comparan su hash SHA-256 con el valor publicado por el fabricante encuentran una diferencia.
3. Un ransomware cifra el servidor de archivos de la empresa. El personal no puede abrir los archivos compartidos durante tres días.
4. Una persona de la empresa envía por error una hoja de nómina a una dirección personal.
5. Una oleada de tráfico golpea el sitio web público de la empresa. Los clientes ven tiempos de espera agotados durante seis horas.
6. Una persona interna edita un registro de transferencia para que el importe aparezca como 1.000 en lugar de 10. Ningún registro anota el cambio.
7. Un atacante hace phishing a la contraseña de un administrador de base de datos y descarga la tabla de clientes.
8. El servicio de citas de un hospital funciona en un único servidor, sin respaldo. La falla de un disco lo deja fuera de línea durante un día.
9. Una página de pago envía el precio desde el navegador al servidor, y el servidor lo acepta. Un usuario cambia el precio de 100 a 1, y el pedido queda registrado en 1.
10. Un portal de soporte muestra nombres y direcciones de otros clientes a cualquier usuario que haya iniciado sesión.

#Clave de respuestas

1. C. Quien tenía el portátil podía leer los datos. El cifrado en reposo lo habría protegido.
2. I. El archivo modificado ya no coincide con el hash publicado. La comparación del hash detectó el cambio.
3. A. El personal perdió el acceso a sus archivos. El cifrado que hace el ransomware también altera los archivos, así que podrías marcar [I] también. La descripción se centra en la interrupción.
4. C. Datos de nómina llegaron a una dirección fuera de la empresa. Es un error de divulgación y sigue siendo una pérdida de confidencialidad.
5. A. El tráfico impidió que los clientes legítimos llegaran al sitio.
6. I. El registro se cambió sin autorización, y el registro faltante además debilita la rendición de cuentas.
7. C. Una contraseña robada llevó a la divulgación de la tabla de clientes. La autenticación es un control de confidencialidad, así que el robo de la contraseña es el primer impacto.
8. A. El servidor único no tenía conmutación por error, así que la falla de un disco detuvo el servicio.
9. I. El servidor confió en un valor que controla el usuario, y el pedido registrado ya no coincide con el precio real. Nunca dejes que el cliente fije un precio.
10. C. Datos personales de otros clientes fueron visibles para usuarios que no tenían autorización para verlos.

Puntuación: acertar ocho o más significa que ya sabes clasificar incidentes. Si fallaste varios del grupo de integridad, vuelve a leer la sección de hashes. Algunos incidentes encajan en dos propiedades, así que acepta una respuesta razonada que elija otra propiedad principal si explicas por qué.

#Errores comunes

• Tratar la tríada como un ranking. Qué propiedad importa más depende del sistema. Decídelo por activo.
• Suponer que el cifrado lo resuelve todo. El cifrado protege los datos de quien no tiene la clave. No hace nada contra una cuenta que ya está autorizada a leer los datos.
• Confundir hashes con cifrado. Un hash muestra que algo cambió. No oculta el contenido, y el hash de un valor corto y fácil de adivinar puede revertirse probando posibilidades.
• Confiar en una copia de seguridad que nunca probaste. Muchos planes de recuperación fallan en la primera restauración real.
• Llamar hackeo a cualquier incidente. Muchas caídas graves vienen de una mala configuración, un disco fallido o un borrado equivocado. La tríada te ayuda a verlos también como problemas de disponibilidad o de integridad.
• Olvidar que un hash publicado necesita una fuente confiable. La comprobación es tan fuerte como el lugar de donde sacaste la referencia.

#Cómo seguir avanzando

Lee completas las secciones introductorias de NIST SP 800-12 Rev. 1 y las definiciones de impacto de la FIPS 199. Usan las palabras que acabas de aprender, y eso hará más fácil leer los documentos formales.

Después, lee ¿Qué es una vulnerabilidad? para ver cómo una debilidad se convierte en la pérdida de una de estas tres propiedades. Para entender la mecánica del cifrado y de los hashes, lee ¿Qué es la criptografía?.

Para practicar sin tocar sistemas de terceros, toma algunos archivos tuyos, registra sus hashes, cambia un carácter y vuelve a ejecutar la comprobación. Luego cifra una copia con una contraseña desechable, descífrala y prueba una contraseña incorrecta. Borra los archivos de prueba al terminar. El objetivo es ver las propiedades funcionando, no construir un sistema seguro con comandos de shell.

Por último, lee un informe público de incidente y clasifica su evento principal con el mismo método. Pregúntate qué propiedad golpeó primero y, después, qué control habría cambiado el resultado.

#Fuentes

• NIST, An Introduction to Information Security, NIST SP 800-12 Rev. 1, junio de 2017: https://csrc.nist.gov/pubs/sp/800/12/r1/final
• NIST, Standards for Security Categorization of Federal Information and Information Systems, FIPS 199, febrero de 2004: https://csrc.nist.gov/pubs/fips/199/final