Qué es la ciberseguridad
Objetivos: Al terminar este tema, podrás…
- Explicar qué hace distinta a la ciberseguridad de otras disciplinas de ingeniería
- Describir los tres principios del triángulo CIA a partir de consecuencias concretas, no de definiciones
- Identificar los trade-offs entre los tres principios y argumentar cuál pesa más en un contexto dado
- Reconocer los distintos momentos del ciclo de vida de un sistema en que un ingeniero de seguridad interviene
Los tres pilares: el Triángulo CIA
Lo que acabas de analizar, más que un caso de noticias, es el punto de partida de lo que estudiarás durante todo este semestre.
Cuando los grupos analizaron el caso Keralty, cada uno describió un tipo diferente de pérdida. El Grupo 1 habló de control sobre quién puede ver su información y qué puede hacer con ella. El Grupo 2 habló de si puede ejercer su trabajo en el momento en que se necesita. El Grupo 3 preguntó si la información que volvió es la misma que estaba antes. En el campo de la ciberseguridad, estos tres tipos de pérdida tienen nombre. Juntos forman el marco más fundamental de la disciplina: el Triángulo CIA.
Confidencialidad
La confidencialidad es la propiedad de que la información solo sea accesible para quienes tienen autorización para verla. Cuando un historial clínico es consultado por alguien que no debería tener acceso a él (un extorsionador, un competidor, un empleado sin autorización) la confidencialidad se ha violado.
La violación de confidencialidad no siempre tiene efectos inmediatos visibles. Una filtración de datos puede pasar meses sin que nadie lo note. Pero sus consecuencias son reales: pérdida de privacidad de personas concretas, daño a la reputación de organizaciones, ventajas para adversarios que ahora saben cosas que no deberían saber. En el caso de datos médicos, las consecuencias pueden incluir discriminación, extorsión o simplemente la violación de algo que las personas consideran íntimamente suyo.
Como ingeniero de ciberseguridad, proteger la confidencialidad implica decidir quién puede acceder a qué información, en qué condiciones, y asegurarte de que esas decisiones se cumplan técnicamente, no solo en papel.
Question
Un médico de urgencias argumenta que la confidencialidad de los historiales médicos no debería aplicarse cuando el paciente llegó inconsciente: en esa situación cualquier profesional de salud debería poder acceder a cualquier historial sin restricciones. ¿Esa posición es razonable? Describe una situación concreta donde estés de acuerdo con ella y una donde definitivamente no lo estés.
Integridad
La integridad es la propiedad de que la información no haya sido modificada de manera no autorizada. No se trata solo de que alguien la vea sin permiso: también se trata de que alguien la cambie sin que nadie se dé cuenta.
Este es, quizás, el principio más silencioso de los tres. Una violación de confidencialidad a veces se detecta porque los datos aparecen publicados en algún lugar. Una violación de disponibilidad es obvia: el sistema no funciona. Pero una violación de integridad puede permanecer invisible durante meses: el historial clínico al que le falta una alergia registrada, el registro de auditoría con entradas borradas, el saldo bancario modificado en centavos que nadie revisa.
Lo que hace la integridad particularmente difícil de proteger es que su violación no interrumpe el funcionamiento del sistema. Los médicos de Keralty pudieron haber seguido usando sus plataformas sin saber que algún historial había sido alterado; las alarmas no suenan cuando un dato cambia silenciosamente. Un sistema que ha perdido su integridad puede parecer completamente funcional mientras entrega información incorrecta.
Por eso, proteger la integridad no consiste solo en evitar que los datos sean modificados: consiste también en diseñar sistemas que puedan detectar cuándo algo cambió, y demostrar de manera confiable qué cambió, cuándo y quién lo hizo. Esta capacidad de registrar, verificar y auditar el estado de los datos es lo que convierte la pregunta del Grupo 3 en una pregunta de ingeniería real: si el sistema no fue diseñado para responderla desde el principio, no hay forma de responderla después de un incidente.
Disponibilidad
La disponibilidad es la propiedad de que los sistemas y la información estén accesibles cuando los usuarios autorizados los necesiten. El médico de urgencias que no puede ver el historial del paciente inconsciente no está sufriendo un problema de confidencialidad ni de integridad, sino un problema de disponibilidad.
Lo que hace la disponibilidad particularmente crítica es su relación con el tiempo. Un sistema de inscripción de materias que falla el último día del período de inscripciones no es igual a uno que falla en enero, cuando no hay nada que hacer. Un servicio de salud que no funciona durante una emergencia médica tiene consecuencias que van más allá del inconveniente. La disponibilidad no se evalúa en promedio, sino en el peor momento posible.
Una forma de entender qué tan crítica es la disponibilidad de un sistema es preguntarse cuánto tiempo puede ese sistema estar caído antes de que haya consecuencias irreversibles para alguien. La respuesta varía enormemente. Una red social puede permitirse horas de interrupción; un servicio de pagos en tiempo real, minutos; una plataforma de atención médica de emergencias, segundos. Detrás de esa pregunta hay contratos, obligaciones legales y, en muchos casos, vidas humanas. Cuando los sistemas de Keralty estuvieron caídos durante días, ese indicador de baja disponibilidad reflejaba además el incumplimiento de una promesa que la empresa tenía con decenas de millones de personas que dependían de ese servicio para su atención médica.
Los trade-offs del triángulo
Hasta aquí, CIA parece simple: maximiza los tres principios y el sistema es seguro. En la práctica, no funciona así. Los tres principios entran en tensión constantemente, y parte central de tu trabajo como ingeniero será tomar decisiones razonadas sobre cuál pesa más en cada contexto.
Piénsalo con el mismo sistema de Keralty. Un sistema de historiales médicos con confidencialidad absoluta (donde solo el médico tratante puede acceder al historial de su paciente) protege la privacidad de manera efectiva. Pero si ese médico está de vacaciones y llega el paciente inconsciente a urgencias, la disponibilidad colapsa exactamente cuando más importa. Si fue la decisión correcta de diseño depende de lo que se priorizó y por qué.
O piénsalo al revés: un sistema que maximiza disponibilidad (donde cualquier médico puede ver cualquier historial en cualquier momento sin pasos adicionales de verificación) facilita la atención de emergencias. Pero sacrifica la confidencialidad de millones de personas.
Reconocer estos trade-offs y documentar las decisiones que tomaste sobre ellos es parte central del análisis de seguridad que harás este semestre. No se trata de encontrar la respuesta perfecta; se trata de tomar decisiones informadas y ser capaz de argumentarlas.
Question
¿Existe algún tipo de sistema donde los tres principios CIA sean igualmente críticos y ninguno pueda sacrificarse para fortalecer los otros? Propón un ejemplo concreto y defiéndelo. Si crees que eso es imposible en la práctica, explica por qué siempre termina cediendo uno primero.
El triángulo deja además una pregunta sin responder: si alguien sí tenía permiso para modificar tu historia clínica, ¿cómo se demuestra después quién lo hizo y que esa persona no pueda negarlo? Esa pregunta tiene nombre propio en la disciplina, y la siguiente sección te lo adelanta.
Más allá del triángulo: el modelo CIAAN
Ya adelantaste una de esas preguntas en el bloque anterior. El triángulo CIA captura bien tres tipos de pérdida, pero en la práctica emergen dos preguntas adicionales que CIA no responde: ¿cómo verificamos que quien accede a un sistema es realmente quien dice ser? ¿Y cómo demostramos, de forma irrefutable, quién realizó una acción concreta y cuándo? Las preguntas que hicieron los Grupos 4 y 5 en la apertura apuntaban exactamente ahí. Esas preguntas corresponden a dos principios adicionales que la Clase 03 desarrolla con profundidad. Por ahora, la siguiente tabla nombra el marco completo:
| Principio | Pregunta que responde |
|---|---|
| Confidencialidad | ¿Quién puede ver esta información? |
| Integridad | ¿Puedo confiar en que los datos son correctos? |
| Autenticación | ¿Es esta entidad realmente quien dice ser? |
| Disponibilidad | ¿Está el sistema accesible cuando se necesita? |
| No repudio | ¿Puedo probar quién realizó una acción y cuándo? |
El campo de la ingeniería en ciberseguridad
Cuando una aplicación de transporte falla y los usuarios no pueden pedir un carro, nadie habla de un “ataque”. Fue un error de software, un servidor caído, una red sobrecargada. Pero cuando los sistemas de Keralty dejaron de funcionar en noviembre de 2022, fue diferente: alguien tomó una decisión deliberada de causar ese daño.
La ciberseguridad es la disciplina de ingeniería que existe precisamente porque los sistemas digitales tienen adversarios activos, no solo errores accidentales. A diferencia de un puente, que puede colapsar por mala ingeniería estructural pero nunca porque alguien coordine y planee su colapso, un sistema de información sí puede tener a alguien detrás planeando exactamente eso. El trabajo del ingeniero de ciberseguridad es diseñar, construir y mantener sistemas que funcionen correctamente incluso cuando alguien está intentando activamente que fallen.
Esto hace que la ciberseguridad sea distinta de otras ramas de la ingeniería: el escenario adversarial nunca termina. No es suficiente con que el sistema funcione hoy: hay que anticipar cómo podría ser comprometido mañana, con métodos que quizás aún no se han inventado. Esta es la tensión que define la disciplina, y la que hace que el trabajo de un ingeniero de seguridad nunca sea idéntico al de ayer.
No todo lo que rompe un sistema tiene detrás a alguien con intención de causar daño. A veces el problema es un descuido: alguien deja sin instalar, durante meses, una actualización de seguridad (lo que en la práctica se llama un parche, la corrección que el fabricante publica cuando descubre una falla), y esa falla queda ahí, esperando a que alguien la note. Otras veces sí hay intención: alguien construye deliberadamente un programa capaz de aprovechar esa misma clase de descuido, es decir, una vulnerabilidad, una debilidad conocida en un sistema que nadie corrigió, para causar daño a propósito. Esta distinción entre el error accidental y el adversario activo importa porque determina qué tipo de profesional se necesita: contra el descuido, hace falta alguien que revise y audite, que se asegure de que los parches se instalen a tiempo; contra la intención maliciosa, hace falta alguien que vigile en tiempo real y reaccione mientras ocurre. Quién es exactamente ese adversario activo, qué lo motiva y por qué ataca a unos sistemas y no a otros, es la pregunta que abre la próxima clase.
Los tres titulares describen el mismo campo desde tres momentos distintos del ciclo de vida de un sistema:
En operaciones (SecOps): El ingeniero monitorea sistemas en funcionamiento, detecta comportamientos anómalos y responde cuando algo sale mal. Su trabajo ocurre mientras el sistema está activo y siendo usado por personas reales. El equipo que detectó el ataque en el Titular A estaba haciendo trabajo de SecOps: reaccionaron a algo que ya estaba pasando y lo contuvieron a tiempo. En la práctica, ese trabajo incluye revisar registros de actividad buscando patrones que no deberían estar ahí, configurar y ajustar reglas de detección, y responder cuando una alerta se activa a las 2 de la mañana. A diferencia de otros roles, el trabajo de SecOps no termina cuando el sistema “queda listo”: el sistema siempre está corriendo, y alguien siempre debe estar mirando.
En desarrollo: La seguridad que no se diseña desde el principio es la más difícil de agregar después. El ingeniero de desarrollo seguro define requisitos de seguridad antes de que el sistema exista, revisa decisiones de arquitectura y configuración, y hace que los errores (como el del Titular B) no lleguen a afectar a usuarios reales. Ese error no ocurrió el día que fue detectado: ocurrió el día en que alguien tomó una decisión de configuración sin que nadie la cuestionara. El ingeniero de desarrollo seguro es quien debería haber estado ahí para hacer esa pregunta.
En consultoría: El consultor evalúa la seguridad de sistemas que ya existen, desde afuera de la organización que los opera. El Titular C describe exactamente ese rol. Con el tiempo, los equipos internos pierden perspectiva sobre su propio sistema: lo conocen tan bien que ya no notan lo que asumieron que estaba seguro pero no está. El consultor llega con una mirada externa, hace preguntas incómodas, prueba si las defensas declaradas realmente funcionan, y produce un reporte que identifica lo que el equipo interno dejó de ver. Su independencia es lo que hace posible ese trabajo.
Question
De los tres roles (desarrollo, operaciones, consultoría), ¿en cuál crees que el ingeniero de seguridad tiene mayor impacto en el resultado final de un sistema? ¿Por qué ese y no los otros dos? Formula el argumento más fuerte que alguien que defienda un rol diferente podría hacerte.
Casos de estudio: cuando los principios fallan
Gran parte de los incidentes de seguridad más graves pueden rastrearse hasta fallas de diseño: decisiones que se tomaron mal o que nunca se tomaron. Los siguientes casos ilustran cada principio del triángulo CIA con situaciones documentadas.
Caso 1: WannaCry (2017) — Disponibilidad
En mayo de 2017, un programa malicioso llamado WannaCry bloqueó los sistemas de hospitales, empresas y entidades gubernamentales en más de 150 países. El ataque fue posible porque los sistemas afectados no habían instalado una actualización de seguridad que llevaba meses disponible: WannaCry encontró la puerta abierta porque nadie la había cerrado.
Lo que hizo a WannaCry especialmente destructivo no fue solo que bloqueara datos, sino la manera en que se propagó. El programa no requería que ningún usuario hiciera clic en un enlace ni abriera un archivo: encontraba otros equipos vulnerables en la misma red y los infectaba automáticamente, sin intervención humana. Un programa que se replica y se propaga solo a través de una red, sin intervención humana, se conoce como gusano; y un programa que, una vez dentro, cifra o bloquea archivos y exige un pago a cambio de restituir el acceso se conoce como ransomware. WannaCry era ambas cosas a la vez, lo cual explica su alcance: es también, en esencia, lo que le ocurrió a Keralty en el caso que abrió esta clase, aunque ahí todavía no se usara el nombre técnico. Una organización con cientos de equipos sin actualizar podía perderlos todos en cuestión de horas a partir de un único punto de entrada, transformando lo que podría haber sido un incidente localizado en una interrupción masiva y simultánea.
Las consecuencias fueron concretas: hospitales del sistema de salud público del Reino Unido tuvieron que cancelar cirugías y redirigir ambulancias porque sus sistemas no respondían. Los datos no fueron robados. Simplemente se volvieron inaccesibles en el momento en que se necesitaban.
Principio comprometido: Disponibilidad. La falla: ausencia de un proceso sistemático que asegurara la aplicación oportuna de actualizaciones de seguridad, y de copias de respaldo que permitieran recuperar la operación sin pagar.
(Caso real documentado por el National Cyber Security Centre del Reino Unido y por Microsoft en sus reportes de 2017. Investigación oficial completa: National Audit Office, “Investigation: WannaCry cyber attack and the NHS”.)
Caso 2: Equifax (2017) — Confidencialidad
En 2017, Equifax (una de las tres mayores agencias de crédito de Estados Unidos) sufrió una filtración que expuso los datos personales de 147 millones de personas: nombres, fechas de nacimiento, números de identificación, información de tarjetas de crédito.
El origen fue una vulnerabilidad conocida en el software que usaban. Equifax sabía de esa vulnerabilidad. La corrección estaba disponible. Nunca la instalaron.
Las 147 millones de personas afectadas no sufrieron un impacto inmediato visible. La gravedad apareció después: con nombres completos, fechas de nacimiento, números de identificación y datos financieros, los atacantes podían abrir cuentas bancarias a nombre de las víctimas, solicitar créditos o realizar compras antes de que la persona afectada supiera que algo había ocurrido. Este tipo de fraude de identidad puede tardar meses en detectarse y, una vez detectado, años en resolverse legalmente. La confidencialidad comprometida no siempre produce consecuencias inmediatas; a veces su impacto real llega mucho después y dura mucho más.
Principio comprometido: Confidencialidad. La falla: ausencia de un proceso que asegurara la aplicación oportuna de correcciones de seguridad, combinada con almacenamiento de datos sensibles sin las protecciones adecuadas.
(Caso real documentado por la Comisión Federal de Comercio de Estados Unidos, FTC v. Equifax. Comunicado oficial del acuerdo: FTC, “Equifax to Pay $575 Million as Part of Settlement…”.)
Caso 3: Keralty/Sanitas (2022) — Los tres principios
Ya comparaste en grupo dos incidentes que afectaron, cada uno, un solo principio del triángulo por una causa distinta. El caso con el que abrió esta clase compromete los tres principios a la vez, y esa simultaneidad es justamente lo que explica por qué resultó tan difícil de resolver.
El 27 de noviembre de 2022, el grupo criminal Ransomhouse anunció que había comprometido los sistemas de Keralty. El ataque no fue instantáneo: los atacantes habían estado dentro de la red durante un período antes de ejecutar el daño visible. El momento en que las pantallas mostraron el mensaje de rescate no fue el inicio del ataque, sino el momento en que decidieron hacerlo visible.
- Confidencialidad: Los atacantes afirmaron haber obtenido datos de pacientes. La posibilidad de que historiales médicos de millones de personas fueran accedidos representa una violación potencial de máxima gravedad.
- Integridad: Cuando el sistema volvió a funcionar, médicos y administradores enfrentaron una pregunta legítima: ¿los datos que ven ahora son los mismos que estaban antes del ataque, o fueron modificados?
- Disponibilidad: El impacto más visible: los servicios de salud interrumpidos durante días para decenas de millones de afiliados.
Lo que hace este caso relevante para un ingeniero en formación no son los detalles técnicos del ataque. Son las preguntas que dejó abiertas: ¿cómo se diseña un sistema de salud de tal manera que un ataque así no interrumpa la atención durante días? ¿Cómo se protege la confidencialidad de millones de historiales sin convertir esa protección en un obstáculo para el trabajo médico de emergencias? ¿Qué garantías permiten a un médico confiar en los datos que ve cuando el sistema vuelve? Estas son preguntas de ingeniería.
(Cobertura periodística del caso: El Tiempo, “Keralty: detalles del ataque de ransomware a EPS Sanitas”.)
El proyecto del semestre
Hoy viste tres momentos del mismo problema: un incidente real con los tres principios comprometidos a la vez, dos incidentes distintos que rompieron cada uno un solo principio por razones distintas, y tres roles de ingeniería que existen precisamente porque ese problema nunca se resuelve del todo. Esa es la lente con la que vas a mirar, desde la próxima entrega, el proyecto que estás construyendo este semestre.
A lo largo de este curso aplicarás los conceptos de cada clase a un análisis de seguridad de un proyecto real de software. No será un ejercicio académico genérico: será un sistema real, con usuarios reales, con riesgos reales; tu tarea será razonar sobre esos riesgos como lo haría un ingeniero de seguridad.
Cada bloque del curso te dará herramientas nuevas para profundizar ese análisis. Al final del semestre habrás completado tres entregas acumulativas. Lo que se espera no es un reporte extenso generado con IA lleno de conceptos copiados: se espera que puedas argumentar por qué las vulnerabilidades que identificaste importan, cómo se conectan con los principios que estudiaste, y qué decisiones de diseño habrías tomado diferente.
Preguntas de reflexión
-
Un hospital implementa el siguiente sistema de auditoría: cada acceso a un historial médico queda registrado automáticamente con el identificador del profesional, la fecha y la hora de la consulta. El sistema puede mostrar quién abrió cada historial y cuándo, pero no detecta si el contenido fue modificado después de ser accedido. Evalúa este diseño: ¿cuál de los principios CIA protege efectivamente y cuál deja sin cubrir? Si tuvieras que defender ante la dirección del hospital que este es un diseño aceptable para su contexto específico, ¿qué argumentarías? Formula también el contraargumento más fuerte que un auditor de seguridad externo le haría a esa defensa.
-
Busca en un medio de comunicación colombiano o latinoamericano una noticia publicada en los últimos 12 meses sobre un incidente de ciberseguridad, filtración de datos o ataque a un sistema. Pega el titular y el enlace. Identifica: (a) cuál principio CIA fue el más comprometido en ese incidente, y (b) cuál fue la decisión de diseño o proceso que, según la noticia, permitió que ocurriera. Si la noticia no da suficiente información para responder (b), explica qué información adicional necesitarías para saberlo.
-
El modelo CIA fue diseñado para sistemas de información digital. Elige un sistema físico de uso cotidiano en Colombia (por ejemplo: el control de acceso a un edificio universitario, el sistema de semáforos de una ciudad o una red de acueducto municipal). Aplica los tres principios al sistema que elegiste: ¿cuál se traslada con más claridad al mundo físico? ¿Cuál resulta más difícil o más contraintuitivo de aplicar? ¿Por qué?
-
El texto señala que “los atacantes habían estado dentro de la red durante un período antes de ejecutar el daño visible” en el caso Keralty, una organización que maneja historiales médicos de decenas de millones de afiliados. Identifica una decisión de diseño relacionada específicamente con la capacidad de detectar actividad dentro de la red antes de que cause daño visible (no con impedir la entrada ni con restaurar el servicio) que, de haber sido diferente, habría reducido el impacto sobre la confidencialidad o la integridad. Explica por qué esa decisión habría tenido ese efecto citando el detalle del caso que lo justifica, y por qué la escala de datos médicos que maneja Keralty (no la de una empresa pequeña con pocos usuarios) hace que esa misma decisión sea más difícil o más costosa de implementar de lo que parece a primera vista.
Conceptos clave
| Término | Definición |
|---|---|
| Ciberseguridad | Disciplina de ingeniería dedicada a proteger sistemas, redes y datos frente a accesos, modificaciones o interrupciones no autorizadas, incluyendo adversarios activos |
| Confidencialidad | Propiedad de que la información solo sea accesible para entidades autorizadas |
| Integridad | Propiedad de que la información no sea modificada de manera no autorizada |
| Disponibilidad | Propiedad de que los sistemas estén accesibles cuando los usuarios autorizados los requieran |
| Activo digital | Cualquier recurso de información con valor que requiere protección |
| Control de seguridad | Medida técnica, administrativa u operacional que mitiga un riesgo |
Navegación: Inicio | Siguiente: Actores y amenazas →