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, a partir de hitos concretos, cómo la ciberseguridad pasó de ser la curiosidad de individuos aislados a convertirse en una disciplina profesional organizada
- Diferenciar un incidente causado por un adversario activo de uno causado por un error accidental, y explicar por qué esa distinción determina qué tipo de profesional se necesita en cada caso
- Reconocer los distintos momentos del ciclo de vida de un sistema en que un ingeniero de seguridad interviene
Apertura: el ataque a Keralty
El 27 de noviembre de 2022, empleados de Keralty llegaron a trabajar y encontraron un mensaje inesperado en sus pantallas: todos los archivos de la empresa habían quedado bloqueados, y alguien exigía millones de dólares para liberarlos. Keralty es el grupo empresarial dueño de EPS Sanitas y de varias clínicas y hospitales del país; el grupo criminal Ransomhouse reclamó después la autoría del ataque.
El impacto se sintió mucho más allá de los sistemas de cómputo de la empresa: en los hospitales y clínicas de Sanitas, los médicos dejaron de poder consultar el historial de sus pacientes, las farmacias no podían validar fórmulas médicas y los sistemas de citas quedaron caídos. Durante días, decenas de millones de afiliados en Colombia no pudieron acceder a los servicios de salud que tenían contratados, y la empresa tardó semanas en recuperar su operación normal sin confirmar nunca públicamente si pagó el rescate que le exigieron.
Todavía no conoces ningún concepto técnico de ciberseguridad, y no lo necesitas para la discusión que sigue: basta con que pienses como alguien a quien esta situación le importa directamente.
(Cobertura periodística del caso: El Tiempo, “Keralty: detalles del ataque de ransomware a EPS Sanitas”.)
Panorama histórico de la ciberseguridad
Phreaking: la curiosidad antes del computador personal
Antes de que existieran los computadores personales, ya existía la curiosidad de manipular sistemas por dentro. En los años sesenta, un grupo de personas conocidas como phreakers descubrió que las redes telefónicas de larga distancia de compañías como AT&T podían controlarse con tonos de audio específicos. El caso más conocido es el de John Draper, apodado “Captain Crunch”: descubrió que el silbato de juguete que venía dentro de las cajas del cereal Cap’n Crunch reproducía exactamente el tono de 2600 hercios que las centrales telefónicas usaban internamente para indicar que una línea estaba libre. Soplar ese silbato en el momento correcto del proceso de marcado permitía hacer llamadas de larga distancia sin pagar por ellas. Esa cultura de explorar sistemas hasta encontrar sus puntos ciegos no se quedó en el teléfono: influyó directamente a Steve Wozniak y Steve Jobs, quienes construyeron y vendieron sus propias “cajas azules” para replicar el truco de Draper antes de fundar Apple. El patrón que hoy define a la ciberseguridad ya estaba presente en esa época, aunque todavía no tuviera ese nombre: sistemas diseñados para un uso específico, y personas dispuestas a dedicar tiempo a entender cómo funcionan realmente para hacerles decir o hacer algo distinto.
(Fuentes: John Draper (Wikipedia); Atlas Obscura, “Early Hackers Used Whistles From Cap’n Crunch Cereal Boxes”.)
El gusano Morris y el nacimiento del primer CERT
El 2 de noviembre de 1988, un estudiante de posgrado en Cornell llamado Robert Tappan Morris lanzó a internet un programa que él mismo describió después como un experimento, no un ataque: quería medir qué tan grande era realmente la red, entonces formada casi exclusivamente por universidades y laboratorios militares de investigación en Estados Unidos, muy distinta a la que usas hoy. El programa se autorreplicaba en cada computador que lograba alcanzar, y un error de diseño hizo que se copiara a sí mismo muchas más veces de las que Morris había previsto, así que en cuestión de horas cerca de una décima parte de todos los computadores conectados a internet quedaron inutilizables por la sobrecarga, sin que nadie hubiera robado un solo dato ni planeado causar ese daño. La respuesta a ese accidente sí fue deliberada: un mes después, el Departamento de Defensa de Estados Unidos encargó a la Universidad Carnegie Mellon crear el primer CERT de la historia, un equipo permanente dedicado por primera vez a coordinar la respuesta a este tipo de incidentes antes de que volvieran a ocurrir. Buena parte de la ciberseguridad como profesión organizada, con equipos dedicados y procesos formales, nace de esa respuesta a un error que a nadie se le había ocurrido prevenir.
(Fuentes: Morris worm (Wikipedia); CERT Coordination Center (Wikipedia).)
La comercialización de internet
Durante la década siguiente, internet dejó de ser una red exclusiva de universidades y laboratorios militares para convertirse en un producto que cualquier persona con un computador y un módem podía contratar. Con la masificación llegó también un nuevo tipo de negocio: empresas dedicadas exclusivamente a vender protección contra el software malicioso que empezaba a circular, como McAfee y, más adelante, Symantec con su producto Norton. En Colombia, ese proceso arrancó formalmente el 4 de junio de 1994, cuando la Universidad de los Andes activó el primer enlace comercial de internet del país, sucediendo a RUNCOL, la red universitaria que había conectado a un puñado de instituciones académicas en los años anteriores. La seguridad informática en Colombia es, en ese sentido, tan vieja como el propio internet colombiano: desde el primer momento en que el país tuvo una red abierta al público, tuvo también la necesidad de protegerla.
(Fuente: Revista de Ingeniería, “Desde la academia, Internet para Colombia”
La profesionalización del cibercrimen: el caso Equifax
Para la década de 2000, el perfil del atacante había cambiado. Ya no se trataba solo de individuos curiosos explorando sistemas por diversión o por desafío intelectual: aparecieron organizaciones con roles definidos, objetivos financieros claros y modelos de negocio completos alrededor del robo y la venta de información, un fenómeno que hoy se conoce como cibercrimen como servicio. El caso de Equifax, una de las tres mayores agencias de crédito de Estados Unidos, ilustra la escala que puede alcanzar esa industria. En 2017, Equifax conocía una vulnerabilidad en el software que usaba, tenía disponible la corrección para esa falla y no la instaló durante más de setenta días. En ese lapso, los datos personales de 147 millones de personas (nombres, fechas de nacimiento, números de identificación, información financiera) quedaron expuestos a quien no debía verlos. La compañía terminó pagando un acuerdo de hasta 700 millones de dólares con la Comisión Federal de Comercio de Estados Unidos. El origen técnico de la falla fue menor comparado con la decisión organizacional que la dejó abierta durante más de dos meses.
(Fuente: FTC, “Equifax to Pay $575 Million as Part of Settlement…”.)
Ataques patrocinados por estados: Stuxnet
El cibercrimen organizado no es el único actor que apareció con el tiempo. Los estados también empezaron a usar herramientas digitales como instrumento de política exterior, y el ejemplo que marcó ese cambio fue Stuxnet, descubierto en 2010. Stuxnet era un gusano diseñado específicamente para sabotear las centrifugadoras de enriquecimiento de uranio de la planta iraní de Natanz: alteraba su velocidad de giro hasta destruirlas físicamente, mientras mostraba a los operadores del sistema lecturas de funcionamiento normal en las pantallas de control. Es ampliamente atribuido a una operación de inteligencia estatal, aunque ningún gobierno lo ha reconocido oficialmente. Lo que hizo a Stuxnet distinto de todo lo anterior es que fue la primera vez que un ciberataque causó destrucción física verificable de infraestructura industrial, algo que hasta ese momento ningún ataque puramente digital había logrado.
(Fuentes: Stuxnet (Wikipedia); IEEE Spectrum, “The Real Story of Stuxnet”.)
El ransomware moderno: WannaCry y el eco de Keralty
El tipo de ataque que abrió esta clase, el secuestro de archivos a cambio de un pago, tampoco es nuevo ni exclusivo de Colombia. En mayo de 2017, un programa llamado WannaCry aprovechó una vulnerabilidad de Windows, filtrada de un conjunto de herramientas que había pertenecido a la Agencia de Seguridad Nacional de Estados Unidos, para propagarse solo, sin que ningún usuario tuviera que hacer clic en nada ni abrir ningún archivo. WannaCry encontraba otros equipos vulnerables en la misma red y los infectaba automáticamente, y por eso pudo bloquear los sistemas de hospitales, empresas y entidades gubernamentales de más de 150 países en cuestión de horas. En el Reino Unido, el impacto sobre el sistema de salud pública fue tan severo que varios hospitales tuvieron que cancelar cirugías programadas y redirigir ambulancias a otros centros. El mismo tipo de ataque que paralizó esos hospitales británicos en 2017 llegó a un hospital colombiano cinco años después, cuando le tocó el turno a Keralty. El patrón no es un caso aislado: es una amenaza que el sector salud, por la urgencia con la que depende de sus sistemas, sigue enfrentando de forma recurrente.
(Fuente: National Audit Office, “Investigation: WannaCry cyber attack and the NHS”.)
De la historia a la profesión
Toda esta historia, desde un silbato de juguete hasta un gusano capaz de destruir infraestructura física, tiene un hilo común: aunque un puente o un edificio también puede colapsar por sabotaje o ataque deliberado, hacerlo exige explosivos, acceso físico y un riesgo de exposición altísimo para quien lo intenta. Un sistema de información, en cambio, puede ser atacado de forma remota, barata, repetible y casi anónima, por lo que ese adversario puede intentarlo una y otra vez sin apenas fricción, contra miles de blancos a la vez. Por esa razón la ciberseguridad existe como disciplina de ingeniería propia: el trabajo consiste en diseñar, construir y mantener sistemas que sigan funcionando correctamente incluso cuando alguien está intentando activamente que fallen, y ese adversario nunca deja de intentarlo. No basta con que el sistema funcione hoy: hace falta anticipar cómo podría comprometerse mañana, con métodos que probablemente todavía no se han inventado.
No todo lo que rompe un sistema tiene detrás a alguien con intención de causar daño, y la mitad de los casos que acabas de leer lo demuestran: el gusano Morris fue un accidente, y Stuxnet, casi con certeza, no lo fue. Cuando alguien deja sin instalar, durante meses, la corrección que un fabricante publica al descubrir una falla en su software (lo que en la práctica se llama un parche), esa falla queda ahí esperando a que alguien la note, tal como le pasó a Equifax. Cuando alguien más construye deliberadamente un programa capaz de aprovechar esa misma clase de descuido (una vulnerabilidad, una debilidad conocida en un sistema que nadie corrigió) para causar daño a propósito, eso es lo que le pasó a WannaCry y, después, a Keralty. Esta distinción importa en la práctica porque determina qué tipo de profesional se necesita en cada caso: 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, alguien que vigile en tiempo real y reaccione mientras el ataque ocurre.
Eso es lo que hace un ingeniero de seguridad: alguien que trabaja en esta tensión todos los días, no solo cuando algo sale en las noticias. Y, como vas a explorar en la actividad que sigue, hay más de una forma de ejercer ese trabajo.
Los roles de la ingeniería en ciberseguridad
Los tres titulares que acabas de discutir 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 del Titular A estaba haciendo trabajo de SecOps: reaccionó a algo que ya estaba pasando y lo contuvo 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 dos 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 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 lo 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.
El proyecto del semestre
Hoy viste tres momentos del mismo campo: un incidente real que interrumpió la atención médica de millones de personas, un recorrido histórico donde el mismo tipo de ataque (secuestro de archivos, robo masivo de datos, sabotaje físico) reaparece en momentos y contextos distintos, 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, con usuarios reales y riesgos reales, no un ejercicio académico genérico. El análisis se entrega en tres etapas acumulativas a lo largo del semestre, y el profesor de esta asignatura evalúa únicamente el componente de ciberseguridad de ese proyecto, no los demás componentes del Proyecto Integrador. Lo que se espera en cada entrega no es un reporte extenso generado con inteligencia artificial y lleno de conceptos copiados: se espera que puedas argumentar por qué las vulnerabilidades que identificaste importan, cómo se conectan con lo que estudiaste en clase, y qué decisiones de diseño habrías tomado diferente.
Preguntas de reflexión
-
Elige un servicio digital que uses a diario (tu banco, tu EPS, una red social, la plataforma de la universidad) y busca en su sitio web o en su app si publican algo sobre seguridad de la información: un certificado, una política de privacidad, un aviso de “conexión segura”. Copia textualmente lo que encontraste (o registra que no encontraste nada) y explica, con tus propias palabras, qué te dice eso sobre qué tan en serio se toma la seguridad esa organización específica. Nombra el servicio.
-
Keralty nunca confirmó públicamente si pagó el rescate exigido por los atacantes. Retoma el detalle concreto que discutiste en tu grupo durante la apertura de esta clase sobre a quién afectó el ataque y de qué manera (una cita programada, un historial inaccesible, un procedimiento aplazado) y, usando ese detalle específico, no un argumento general sobre “las empresas” o “el ransomware”, argumenta si Keralty debió pagar o no. Luego formula el argumento más fuerte que alguien con la posición contraria podría construir citando ese mismo detalle en su contra, uno que realmente te obligue a matizar tu postura, no un espantapájaros fácil de derribar.
-
Busca una noticia colombiana o latinoamericana de los últimos 12 meses sobre un incidente de ciberseguridad (ataque, filtración de datos, fraude digital) que no sea Keralty. Incluye el enlace directo a la noticia. En 5 a 6 líneas, resume qué pasó y a qué tipo de rol de los discutidos en clase (SecOps, desarrollo, consultoría o auditoría) le habría correspondido intervenir para prevenirlo o contenerlo, y por qué.
-
Piensa en un sistema físico que no sea digital: el control de acceso de un edificio, la fila de un banco, el proceso de votación en una elección. Describe qué tendría que fallar (técnicamente, humanamente, u organizacionalmente) para que ese sistema sufriera un incidente comparable en gravedad al de Keralty. ¿Quién sería responsable de cada tipo de falla?
-
El gusano Morris de 1988 no fue un ataque intencional: fue, según su propio autor, un experimento que salió mal. Sin embargo, Robert Tappan Morris fue procesado y condenado bajo una ley de delitos informáticos. ¿Te parece justo que la intención no haya sido determinante para el castigo? Argumenta considerando qué pasaría con la seguridad de los sistemas en general si la intención fuera el criterio central para decidir si un incidente se sanciona.
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 |
| Gusano | Programa que se replica y se propaga solo a través de una red, sin intervención humana |
| Ransomware | Programa que cifra o bloquea archivos y exige un pago a cambio de restituir el acceso |
| Vulnerabilidad | Debilidad conocida en un sistema que no ha sido corregida |
| Parche | Corrección que un fabricante publica cuando descubre una falla en su software |
| CERT (Computer Emergency Response Team) | Equipo dedicado a coordinar la respuesta a incidentes de seguridad |
| Adversario activo | Persona u organización que planea y ejecuta deliberadamente acciones para comprometer un sistema |
| Activo digital | Cualquier recurso de información con valor que requiere protección |
Navegación: Inicio | Siguiente: Principios CIAAN →