Modelado de amenazas
Objetivos: Al terminar este tema, podrás…
- Distinguir una amenaza de una vulnerabilidad y de un riesgo, y escribir cada una en la columna que le corresponde
- Aplicar STRIDE parte por parte sobre un sistema descrito, en vez de aplicarlo al sistema entero
- Ubicar un riesgo en una matriz de probabilidad e impacto y sostener por escrito por qué quedó en esa casilla
- Proponer un control y nombrar con precisión lo que ese control deja sin cubrir
- Leer y escribir un árbol de ataque sencillo
- Documentar un análisis para alguien que no es ingeniero
Apertura: la mitad que traes escrita
Llegas a esta clase con media página escrita a mano. En ella decidiste por dónde entró el atacante del caso que investigó tu grupo en la clase 03, o decidiste que las fuentes no alcanzan a sostener ninguna ruta. Con esa media página arranca la metodología de hoy, antes de cualquier otra cosa.
La razón es que una amenaza no se deja describir con un solo dato. Decir “nos puede atacar un ciberdelincuente” no permite diseñar ningún control, porque no dice por dónde. Decir “nos pueden meter un ransomware” tampoco alcanza, porque no dice quién ni por qué escogería nuestro sistema. Lo que sí se puede modelar es el par completo, es decir este actor entrando por esta ruta. La clase 03 te dio el primer elemento, la lectura de esa clase te dio el segundo, y esta sesión empieza juntándolos sobre el tablero antes de tocar ninguna metodología.
Hay un tercer elemento que también viaja contigo y que es el que decide si el par vale algo: la frase de la fuente que sostiene la ruta. Un par actor-ruta sin una frase que lo respalde es una hipótesis, y una hipótesis puede seguir siendo el mejor material disponible, siempre que quede escrito que lo es. Por eso hoy al tablero sube la ruta y sube también la cita, o sube la palabra “sin cita” cuando el grupo revisó su hoja y no la encontró.
Ese tablero no es un ritual de apertura sino el material con el que vas a trabajar el resto de la sesión: dentro de un rato tu grupo va a modelar las amenazas de un sistema concreto, y va a hacerlo desde el atacante que acaba de quedar escrito con tu nombre al lado.
Marco: amenaza, vulnerabilidad y riesgo no son lo mismo
Tienes en el tablero cinco atacantes con su ruta de entrada. Falta lo que van a atacar. Durante el resto de la sesión los cinco grupos van a trabajar sobre el mismo sistema, uno solo, descrito aquí con suficiente detalle para que nadie tenga que inventarse cómo funciona por dentro.
Crédito Bienestar es un sistema ficticio, construido para esta clase. No corresponde a ninguna plataforma real, y ninguna afirmación sobre él debe leerse como información sobre una entidad existente. Se parece, eso sí, al trámite que reconoce cualquier estudiante colombiano que haya solicitado un crédito educativo: llenas un formulario en línea, alguien verifica que eres quien dices ser, alguien más revisa si cumples los requisitos, un funcionario aprueba o rechaza, y si te aprueban el dinero termina moviéndose hacia tu universidad.
El sistema tiene cinco partes, y esto es todo lo que necesitas saber de cada una:
| # | Parte del sistema | Qué hace | Quién la toca |
|---|---|---|---|
| 1 | Formulario de solicitud | Recibe los datos personales y financieros que escribe el estudiante | El estudiante, desde su casa |
| 2 | Verificación de identidad | Le pregunta a una entidad externa si la cédula que escribió el estudiante corresponde a esa persona | Nadie a mano: son dos sistemas hablando entre sí |
| 3 | Base de datos de solicitudes | Guarda cada solicitud, su estado y quién la tocó | El sistema, y los administradores a través del portal |
| 4 | Portal de administración | Es donde un funcionario de la universidad aprueba o rechaza | Funcionarios de la universidad |
| 5 | Envío al banco | Le comunica al banco que debe desembolsar, y cuánto | Nadie a mano: son dos sistemas hablando entre sí |
Fíjate en lo que acaba de pasar: te entregué los activos ya identificados. Un activo es cualquier cosa del sistema que tiene valor suficiente para que valga la pena protegerla, y la lista no son solo los datos: son también los procesos que tienen que seguir funcionando y la confianza que la gente le tiene al servicio, que es lo que el caso A de la lectura muestra con el ejemplo más claro. Identificarlos es el paso 1 de la metodología, en un proyecto real es trabajo tuyo, y hoy viene resuelto porque la parte difícil está en otro lado. La parte difícil empieza cuando tienes que decir qué puede salir mal en cada una de esas cinco cajas, y para eso hace falta separar tres palabras que el lenguaje corriente usa como si fueran la misma.
Una amenaza tiene sujeto, porque es alguien haciendo algo. Una vulnerabilidad no tiene sujeto, porque es una propiedad del sistema, algo que al sistema le falta o algo que hace mal. Un riesgo es lo que resulta de juntar las dos con lo que se pierde si la cosa efectivamente ocurre. La prueba rápida para saber en cuál de las tres columnas va una frase conviene que la tengas a mano durante todo el taller: si puedes ponerle un nombre propio adelante y la frase sigue teniendo sentido, es una amenaza. El desarrollo completo de esa prueba, con los dos errores que más aparecen en los informes, está en la lectura asignada de esta clase.
Con la separación hecha aparece el problema práctico, que es de dónde sale la lista de amenazas de un sistema recién dibujado. Cuando a un equipo se le pide que piense qué puede salir mal, el equipo enumera lo que ya vio alguna vez y se detiene ahí. STRIDE existe para romper ese techo: es una lista cerrada de seis categorías de amenaza que obliga a preguntar seis veces por cada parte del sistema, incluso por las categorías que ese día no se le habrían ocurrido a nadie. Lo propusieron Loren Kohnfelder y Praerit Garg en un documento interno de Microsoft de 1999 titulado The Threats to Our Products, recogido después en el blog de seguridad de Microsoft (https://www.microsoft.com/security/blog/2009/08/27/the-threats-to-our-products/), escrito para revisar la seguridad de los productos de la propia empresa, y hoy es el punto de partida convencional del modelado de amenazas.
| Categoría | Nombre que usamos en clase | Qué hace el atacante | Principio CIAAN que niega |
|---|---|---|---|
| Spoofing | Suplantación | Se hace pasar por un usuario o por un sistema que no es | Autenticación |
| Tampering | Manipulación | Modifica datos sin autorización | Integridad |
| Repudiation | Repudio | Niega haber hecho algo que sí hizo | No repudio |
| Information Disclosure | Divulgación | Expone información a quien no debía verla | Confidencialidad |
| Denial of Service | Denegación de servicio | Impide que el servicio atienda a quien tiene derecho a usarlo | Disponibilidad |
| Elevation of Privilege | Elevación de privilegios | Obtiene permisos que no le corresponden | Autenticación y autorización |
La última fila nombra dos cosas distintas en su última casilla, y conviene separarlas desde ya: autenticar es responder quién eres, mientras que autorizar es responder qué te dejan hacer una vez que ya se sabe quién eres. Los modelos que hay detrás de esa segunda pregunta son la materia de la clase 06.
Esa última columna no es una coincidencia ni un adorno de la tabla: cada categoría de STRIDE es la negación de una de las propiedades que estudiaste en la clase 02. Hoy no la vamos a trabajar todavía, porque al final de la sesión vas a volver sobre tus propias amenazas y a reconstruir esa correspondencia sobre lo que tú mismo escribiste, que es distinto de leerla hecha. Lo que hoy importa más para trabajar es el detalle que la tabla no dice: STRIDE no se le aplica al sistema, se le aplica a cada parte del sistema por separado. Preguntarle a Crédito Bienestar entero si tiene amenazas de suplantación produce un sí que no sirve para nada, mientras que preguntárselo al formulario, a la verificación de identidad y al envío al banco por separado produce tres amenazas distintas que necesitan tres controles distintos.
Cada amenaza que escribas va a necesitar después una ubicación, es decir qué tan probable es que ocurra y cuánto se pierde si ocurre. La herramienta convencional para eso es una matriz:
| Impacto Bajo | Impacto Medio | Impacto Alto | Impacto Crítico | |
|---|---|---|---|---|
| Probabilidad Alta | Medio | Alto | Crítico | Crítico |
| Probabilidad Media | Bajo | Medio | Alto | Crítico |
| Probabilidad Baja | Bajo | Bajo | Medio | Alto |
Lo que la matriz no te da es la razón, y la razón es lo único que se puede discutir después. Dos analistas serios pueden ubicar el mismo riesgo en casillas distintas sin que ninguno de los dos esté equivocado, así que lo que se evalúa hoy no es la casilla sino la frase que la sostiene. Por qué ocurre eso, y por qué no invalida el método, está desarrollado en la lectura asignada de esta clase.
Cinco partes y cinco grupos, así que a cada grupo le toca una. El reparto queda hecho ya, antes de explicar nada más, porque lo primero que tu grupo va a hacer con su parte no es analizarla sino apostar.
Antes de que empiece el taller, tu grupo escribe una sola línea en la esquina de su hoja y la guarda: de la parte del sistema que le tocó, ¿qué es lo peor que podría hacerle el atacante que quedó escrito en el tablero? Una línea, sin metodología y sin discutirla más de un minuto. Al final de la sesión vas a volver sobre esa línea y a compararla con lo que tu grupo terminó escribiendo.
Cierre: el control que sí propones y el riesgo que aceptas
Ningún control deja el riesgo en cero. Lo que queda después de aplicarlo tiene nombre propio, se llama riesgo residual, y no es una confesión de fracaso sino la parte del análisis que un directivo va a leer con más atención, porque es la que le dice con qué va a tener que convivir la organización. Escribirlo es lo que separa aceptar un riesgo de no haberse dado cuenta de que existía. Los tipos de control y el riesgo residual están desarrollados en la lectura asignada de esta clase.
Escribe en cinco líneas qué queda sin cubrir después del control que propuso tu grupo, y qué tendría que pasar para que ese resto dejara de ser aceptable. No hace falta que el control sea malo: todos dejan algo, y lo que se evalúa es que puedas nombrar qué es ese algo y bajo qué condición dejaría de poderse tolerar.
Lo que queda de esta clase está escrito y te espera en dos partes distintas, y conviene que sepas cuál es cuál. Antes de la próxima sesión tienes que haber trabajado la lectura asignada, que desarrolla las cosas que hoy quedaron nombradas y a medias: la prueba del nombre propio con los dos errores que más aparecen en los informes, por qué dos analistas ubican el mismo riesgo en casillas distintas, y los tipos de control con el riesgo residual. Esa lectura incluye además el árbol de ataque que acabas de ver dibujado en el tablero, que es la única herramienta de hoy que no alcanzaste a usar con las manos. Esa misma lectura, si quieres el desarrollo completo de las cinco categorías de STRIDE que hoy solo viste en una fila de tabla, se extiende después en una sección aparte que no tienes que trabajar antes de la próxima clase. Todo lo demás está disponible sin la fecha de la próxima sesión encima. Están los cuatro análisis ya terminados y la sección de cómo se documenta un análisis, que son material de consulta para cuando tengas que escribir uno. Está la tabla de conceptos clave, con los términos de hoy y sus enlaces al glosario, para cuando una palabra se te haya quedado a medias.
Lectura asignada — El modelado de amenazas en profundidad
Amenaza, vulnerabilidad y riesgo
La confusión que más cuesta corregir en este tema se resuelve mirando la gramática de la frase antes que su contenido técnico. Una amenaza tiene sujeto: alguien hace algo. Una vulnerabilidad no tiene sujeto, porque es una propiedad del sistema, algo que al sistema le falta o algo que hace mal. Cuando escribes “la amenaza es que no tenemos contraseñas fuertes” estás describiendo el sistema y creyendo que describes al atacante, y a partir de esa frase no se puede diseñar nada, porque no dice quién aprovecharía esa debilidad ni para conseguir qué. La prueba para saber en qué columna va una frase es corta: si puedes ponerle un nombre propio adelante y la frase sigue teniendo sentido, es una amenaza. “Un exempleado con las credenciales todavía activas entra al portal y aprueba una solicitud” pasa la prueba. “No revocamos las credenciales cuando alguien renuncia” no la pasa, y por eso vive en la otra columna.
El error tiene una versión simétrica que también vas a ver escrita muchas veces, y conviene que reconozcas las dos con sus palabras exactas. La primera es “la amenaza es que no tenemos autenticación en dos pasos”, que es una debilidad puesta en la casilla de la amenaza. La segunda es “la vulnerabilidad es que nos ataque un ransomware”, que es una amenaza puesta en la casilla de la debilidad. Las dos frases suenan razonables en voz alta y las dos vuelven inservible la tabla donde están escritas.
El tercer término junta a los otros dos. Un riesgo es la combinación de una amenaza que existe, una debilidad que la deja pasar y algo concreto que se pierde si la amenaza atraviesa la debilidad. Los tres se escriben en columnas distintas porque los controles atacan columnas distintas, y esa es la consecuencia práctica de toda la distinción: no puedes eliminar la amenaza, porque el atacante existe con independencia de ti; sí puedes cerrar la debilidad, que es donde va la mayor parte del trabajo de ingeniería; y cuando no puedes cerrarla del todo, a veces lo único que queda a tu alcance es reducir lo que se pierde.
Antes de que haya amenazas hay activos, y ahí está el paso que la sesión te entregó resuelto. Identificar activos suena a hacer un inventario, y por eso se hace mal casi siempre. El inventario sale fácil cuando el activo es una cosa que se puede señalar, como la base de datos de solicitudes o el portal donde el funcionario aprueba. Se pone difícil cuando el activo no es una cosa. Que el desembolso llegue a tiempo es un activo, porque si se retrasa un mes hay estudiantes que pierden el semestre, y sin embargo no hay ningún componente que se llame así. Que la gente crea que una alerta significa algo también lo es, y se pierde por completo la primera vez que llegan tres alertas falsas seguidas. La pregunta que separa un inventario de una lista de activos no es qué partes tiene el sistema sino qué pasa si esto deja de estar, y hay respuestas a esa pregunta que no apuntan a ninguna caja del diagrama.
Esta distinción es la que convierte en método lo que hasta ahora eran dos listas separadas. En la clase 03 aprendiste quién ataca y por dónde entra, y en la clase 02 aprendiste qué propiedades se pierden cuando un ataque tiene éxito. Una amenaza completa es exactamente eso, un actor y una ruta juntos, apuntando a una propiedad concreta que se puede perder. Escribir la amenaza sin el actor produce una lista de todo lo malo que podría pasarle a cualquier sistema, que es una lista con la que no se puede decidir nada.
STRIDE, categoría por categoría
STRIDE lo propusieron Loren Kohnfelder y Praerit Garg en un documento interno de Microsoft de 1999, The Threats to Our Products (https://www.microsoft.com/security/blog/2009/08/27/the-threats-to-our-products/), como un método para revisar la seguridad de los productos de la propia empresa. El problema que resolvía no era de conocimiento sino de cobertura: cuando le pides a un equipo que piense qué puede salir mal, el equipo enumera lo que ya vio alguna vez y se detiene ahí, así que la lista termina reflejando la experiencia de los presentes en vez de la superficie del sistema. Una lista cerrada de seis categorías obliga a preguntar seis veces por cada parte, incluso por las categorías que ese día no se le habrían ocurrido a nadie en la sala.
Las seis iniciales son palabras en inglés, y el archivo lo dice porque el acrónimo no se explica solo. En clase vamos a usar los nombres en español: suplantación, manipulación, repudio, divulgación, denegación de servicio y elevación de privilegios. El mnemónico no sobrevive a la traducción y no vale la pena forzarlo; lo que sí hay que recordar es la lista de seis, no su orden.
De las seis, la que ningún estudiante entiende con una glosa de una línea es el repudio, y merece un ejemplo desarrollado. Conviene empezar por notar que el repudio existe desde mucho antes que los computadores. La razón por la que un recibo se firma por duplicado, o por la que una entrega se hace contra sello, no es la comodidad de quien archiva el papel sino que después alguien pueda sostener que la entrega efectivamente ocurrió. Trasladado al portal de administración, imagina que un funcionario aprueba una solicitud que no debía aprobar. Semanas después alguien revisa el caso y pregunta quién la aprobó. Si el sistema no dejó registro de qué cuenta apretó el botón, ni a qué hora, el funcionario puede sostener con toda tranquilidad que él no fue, y nadie tiene con qué contradecirlo. Fíjate en que aquí no hay ningún ataque técnico contra el sistema: el sistema funcionó como estaba escrito. Lo que se atacó fue la posibilidad de sostener después lo que pasó, y esa posibilidad es un requisito de diseño que hay que decidir de antemano, porque no se puede reconstruir hacia atrás.
Aplicar STRIDE parte por parte tiene un nombre que ya conoces. El conjunto de puntos por donde alguien podría intentar entrar a un sistema es su superficie de ataque, el término que definió la clase 03, y aplicar STRIDE consiste justamente en recorrer esa superficie parándose en cada punto y preguntando seis veces. Cuando alguien te diga que ya hizo el modelado de amenazas de un sistema, la pregunta útil no es cuántas amenazas encontró sino en cuántas paradas se detuvo.
STRIDE también tiene límites, y conocerlos es lo que evita usarlo como si fuera todo el método. No dice nada sobre quién es el atacante, así que por sí solo produce la lista de todo lo que podría pasarle a esa parte, sin distinguir lo que alguien realmente intentaría de lo que nadie se molestaría en hacer. No dice nada sobre probabilidad, así que no ordena la lista que produce. Y cubre mal lo que ocurre cuando el eslabón que falla es una persona y no una parte del sistema, porque las seis categorías están escritas pensando en componentes. Esas tres carencias son la razón por la que la sesión de hoy trabajó con atacantes concretos traídos del tablero en vez de con STRIDE a secas.
Probabilidad e impacto
Ubicar un riesgo en la matriz exige estimar una probabilidad, y casi siempre hay que hacerlo sin datos históricos, que es la situación normal en un sistema que todavía no existe. La salida no es inventarse un porcentaje. Se estima comparando: la pregunta operativa no es cuál es la probabilidad de esto, sino si esto es más o menos probable que aquello otro que el equipo ya clasificó. Una matriz llena por comparación es defendible aunque ninguna de sus casillas tenga un número detrás, y una matriz llena con porcentajes inventados no lo es, aunque se vea más técnica.
Por la misma razón conviene desconfiar de la fórmula “riesgo igual a probabilidad por impacto”. No hay ninguna multiplicación real ahí, porque ninguno de los dos factores es un número: son juicios ordenados de menor a mayor. La fórmula es una metáfora aritmética útil para recordar que las dos dimensiones importan a la vez, y tratarla como una cuenta produce la ilusión de precisión que después nadie puede defender cuando alguien pregunta de dónde salió el resultado.
Hay un caso que rompe la matriz y que vale la pena tener presente: probabilidad muy baja, impacto catastrófico. La matriz manda esa combinación a una casilla intermedia, y la organización que la trata como intermedia es la que un día aparece en las noticias. El ataque a IFX Networks con el que abrió la clase 03 es exactamente ese escenario: la caída simultánea de decenas de entidades por un único proveedor es el tipo de evento que cualquier matriz archiva como poco probable hasta el día en que ocurre. Cuando la casilla intermedia contiene algo de lo que la organización no se puede recuperar, la casilla está mintiendo y hay que decirlo por escrito al lado.
Cuando termines de ubicar tus riesgos vas a encontrarte con un resultado incómodo, y no es señal de que hayas hecho algo mal: la mitad de la lista queda en la casilla alta. La matriz tiene doce casillas y los riesgos que uno se molesta en escribir tienden a agruparse arriba a la derecha, así que ordenar por casilla deja de discriminar justo cuando hace falta. Ahí la pregunta deja de ser cuál es más grave, porque la matriz ya dijo que son igual de graves, y pasa a ser cuál de ellos le abre la puerta a los otros: si uno de los riesgos altos es el que hace posibles a dos más, se atiende ese primero aunque los tres compartan casilla, y el orden de la lista deja de depender de la casilla para depender de cómo se encadenan los riesgos entre sí. Esa relación de encadenamiento es la que hace visible el árbol de ataque, que es la herramienta de la sección siguiente, y es lo que una matriz por sí sola no puede mostrar, porque la matriz mira cada riesgo por separado. La columna “Prioridad” del caso B, más abajo en esta clase, no es un dato nuevo ni un cálculo aparte: es la casilla de la matriz escrita con otro nombre, y por eso una fila con probabilidad baja e impacto alto aparece ahí como prioridad media.
Queda entonces la pregunta que más incomoda al principio: por qué dos analistas serios ponen el mismo riesgo en casillas distintas sin que ninguno esté equivocado. La respuesta es que cada uno está usando un supuesto distinto sobre el atacante o sobre la organización, y esos supuestos casi nunca se escriben. Uno supone que el atacante persiste durante meses y el otro que se rinde al primer obstáculo; uno supone que la organización detecta la intrusión en horas y el otro en semanas. En la sesión de hoy lo viviste en carne propia cuando dos grupos ubicaron riesgos parecidos en casillas distintas. Eso no invalida el método: es lo que el método hace visible. Un análisis de riesgos es un argumento, y un argumento sin sus supuestos escritos no se puede discutir ni corregir.
Controles, tipos y riesgo residual
Los controles se clasifican por el momento en que actúan. Un control preventivo intenta que la amenaza no llegue a materializarse, como exigir un segundo factor antes de aprobar una operación. Un control detectivo no impide nada, pero deja constancia de que algo pasó, como el registro de qué cuenta aprobó cada solicitud. Un control correctivo actúa cuando el daño ya ocurrió y sirve para volver a un estado bueno, como una copia de respaldo que se puede restaurar.
Un sistema serio necesita los tres, y el argumento es concreto. El control preventivo falla en silencio: el día que alguien lo evade, el sistema sigue funcionando con normalidad y nadie se entera. Sin control detectivo esa evasión puede durar meses, y sin control correctivo el día que por fin se descubre no hay a dónde volver. Cuando veas un análisis con cinco controles preventivos y ninguno de los otros dos tipos, lo que tienes delante no es un sistema muy protegido sino un sistema en el que nadie ha pensado qué pasa cuando la protección falla.
Hay una comparación que casi nunca aparece en los informes de estudiantes y que es la primera que hace cualquiera que tenga que aprobar el presupuesto: un control puede costar más que el riesgo que mitiga. Ese costo no es solo plata: es también el tiempo de la gente que tendría que operar el control todos los días, y la funcionalidad que el usuario pierde a cambio. Proponer controles sin esa comparación es un error frecuente y caro, y es lo que convierte una recomendación en una lista de deseos.
Lo que queda después de aplicar el control es el riesgo residual. Toda la sección anterior lleva a esto: como ningún control lleva el riesgo a cero, el análisis termina siempre con algo que la organización decide tolerar. Escribirlo tiene tres efectos. Hace explícito con qué se va a convivir, obliga a que alguien con autoridad lo firme, y deja constancia de la fecha en que se decidió. Aceptar un riesgo por escrito y no haberse dado cuenta de que existía son dos situaciones muy distintas, y la diferencia se nota el día en que el riesgo se materializa y alguien pregunta quién sabía.
Dos de los controles que vas a querer nombrar pertenecen a clases posteriores, y puedes nombrarlos sin saber todavía cómo funcionan por dentro. El cifrado de datos y la firma digital son el mecanismo con el que se sostienen la confidencialidad y la integridad, y su funcionamiento lo vas a ver en la clase 08. Restringir quién puede hacer qué según su rol es un control de acceso, y los modelos que hay detrás son la materia de la clase 06. Escribirlos hoy en tu tabla de controles es correcto; explicar cómo funcionan es trabajo de esas clases.
El árbol de ataque
STRIDE te da amenazas sueltas, y un atacante real no ejecuta amenazas sueltas: recorre una ruta. El árbol de ataque es la herramienta que hace visible esa ruta, y resuelve un problema que STRIDE no resuelve, que es entender cómo se encadenan varias amenazas pequeñas para producir una grande. El momento de sacarlo es cuando el análisis STRIDE ya produjo la lista y hay que decidir cuál de las amenazas de esa lista es la puerta de las otras.
La estructura es simple. En la raíz va el objetivo del atacante, escrito como algo que él quiere conseguir y no como algo que a ti te falta. Debajo van las maneras de conseguirlo, y esas maneras son de dos tipos. Hay nodos que son alternativas, donde basta con que se cumpla uno de ellos, y hay nodos que son requisitos, donde hacen falta todos para que la rama funcione. Con esos dos tipos de nodo alcanza para el nivel de este curso; los árboles profesionales agregan costos y probabilidades por rama, y eso es material de semestres posteriores.
El procedimiento cabe en tres reglas. Se empieza por la raíz, y la raíz se escribe desde el atacante y no desde el sistema. Se baja preguntando una sola cosa en cada nivel, de cuántas maneras se consigue lo que dice el nodo de arriba, y cada respuesta distinta es un nodo nuevo. Se para en el tercer nivel, cuando cada hoja ya es algo que el atacante o bien puede hacer con lo que tiene o bien no puede: un cuarto nivel en este curso produce detalle sin producir ninguna decisión nueva.
El error que arruina un árbol de ataque se comete en la primera línea, y por eso conviene mirarla dos veces antes de seguir bajando. Si escribes en la raíz “la base de datos de solicitudes no tiene control de acceso”, lo que vas a poder colgar debajo es una lista de cosas que le faltan al sistema, y una lista no se ramifica: cada renglón queda solo, sin nada que lo una a los otros. Si en cambio escribes “conseguir que el sistema apruebe una solicitud que debía rechazarse”, lo que cuelga debajo son maneras distintas de llegar al mismo sitio, y ahí sí aparece el ramaje, porque unas maneras necesitan varias cosas a la vez y otras necesitan una sola. La diferencia entre las dos primeras líneas es la diferencia entre un inventario y una ruta, y el árbol solo funciona cuando lo que hay arriba es una ruta.
Este es un árbol trabajado sobre el mismo sistema de la sesión, para que lo leas reconociendo el terreno:
- Raíz: conseguir que Crédito Bienestar apruebe una solicitud que debía rechazarse.
- Alternativa 1: suplantar a un estudiante que sí califica. Requiere las dos cosas a la vez: conseguir los datos personales de esa persona, y que la verificación de identidad acepte esos datos sin ningún control adicional.
- Alternativa 2: alterar los datos financieros después de que el funcionario los revisó. Requiere las dos cosas: permiso para modificar los datos guardados, y no solo para consultarlos, y que el portal no vuelva a mostrar los datos en el momento de firmar la aprobación.
- Alternativa 3: conseguir las credenciales de un funcionario del portal de administración.
- Alternativa 4: convencer al funcionario de que apruebe, sin tocar el sistema en ningún momento.
La cuarta rama es la más interesante de las cuatro, porque es la que deja ver el límite de STRIDE del que se hablaba arriba. Ahí no hay ninguna parte del sistema comprometida ni ninguna de las seis categorías vulnerada: el sistema hace exactamente lo que debe hacer cuando un funcionario autorizado aprueba una solicitud. Lo que falló está en otro lado, y ese lado tiene su propia sesión en la clase 12.
Ese árbol es el mismo que quedó dibujado en el tablero al final del debrief, y la conexión con la ficha de tu grupo es directa: las tres amenazas que escribiste son tres hojas, y la raíz es la frase que el profesor escribió arriba. Una ficha llena no es un árbol todavía, porque le falta la línea que une esas tres hojas con lo que el atacante quiere conseguir, y esa línea es lo único que hay que agregar.
Para comprobar que lo estás leyendo bien, vuelve al árbol de arriba con una pregunta: de las cinco partes de Crédito Bienestar, ¿cuál tendría que fallar primero y cuál después para que la alternativa 1 funcione completa? Escribir el orden es lo que distingue una lista de rutas de una lista de deseos.
Compara ahora ese árbol con este otro, escrito sobre el mismo sistema y mal hecho a propósito:
- Raíz: la base de datos de solicitudes no tiene control de acceso.
- Cualquiera puede leer los datos.
- Cualquiera puede modificar los datos.
- No queda registro de quién los tocó.
Los tres renglones son ciertos y ninguno está mal escrito, pero fíjate en que ninguno depende de otro y en que ninguno se puede combinar con otro para llegar más lejos. Eso no es un árbol sino una lista de carencias con sangría, y es lo que produce siempre una raíz escrita desde el sistema.
Lectura disponible — Profundización en STRIDE
Repudio ya tuvo su desarrollo completo más arriba, porque es la categoría que ninguna glosa de una línea alcanza a explicar. Las otras cinco merecen el mismo trato, y aquí lo tienen.
La suplantación es la más fácil de imaginar y por eso la que más se subestima. Alguien llena el formulario de solicitud con el nombre y el número de cédula de un estudiante real, obtenidos de una filtración distinta a Crédito Bienestar, y la verificación de identidad no tiene ninguna forma de saber que quien está tecleando no es esa persona: el sistema solo confirma que la cédula corresponde a alguien, no que corresponde a quien la está usando en ese momento. La confusión frecuente es tratar esto como un problema de confidencialidad, porque involucra datos robados. No lo es: la confidencialidad se rompió en la filtración original, en otro sistema, y lo que se rompe aquí es la autenticación, que es la propiedad que se niega cuando alguien se hace pasar por otro.
La manipulación ataca la integridad, y su ejemplo más incómodo no involucra a ningún atacante externo. Un funcionario aprueba una solicitud por el monto correcto en el portal de administración, y horas después alguien con acceso directo a la base de datos de solicitudes cambia esa cifra antes de que el sistema la envíe al banco. El funcionario aprobó lo correcto, el registro de aprobación sigue diciendo lo correcto, y sin embargo el banco desembolsa otra cosa. Lo que falla no es el paso de aprobación sino la garantía de que nada toca el dato entre que se aprueba y que se usa.
La divulgación es la que más rápido se confunde con manipulación, porque las dos involucran la misma base de datos, y conviene distinguirlas por lo que el atacante consigue. Si un error de configuración deja la base de datos de solicitudes accesible sin autenticación, cualquiera con el enlace puede leer el ingreso familiar y la dirección de cada solicitante sin cambiar ni un solo dato. El daño no está en que la información sea falsa después, está en que dejó de ser privada, aunque cada cifra siga siendo exactamente la que el estudiante escribió.
La denegación de servicio necesita un sujeto para contar como amenaza, y ese es justamente el punto donde más se confunde con una simple falla técnica. Que el formulario se caiga solo un día de tráfico alto es una vulnerabilidad de capacidad, no una amenaza: no hay nadie detrás. La amenaza aparece cuando alguien satura a propósito el formulario de solicitud con miles de envíos automáticos justo antes del cierre del plazo, para que los estudiantes reales no alcancen a enviar la suya a tiempo. El sistema afectado es el mismo en los dos casos. Lo que cambia es si hay una intención detrás, y esa intención es la que decide en qué columna se escribe.
La elevación de privilegios es la que exige mirar el portal de administración con más cuidado de lo que parece a primera vista. Un funcionario de la universidad con permiso solo para consultar el estado de las solicitudes encuentra que el botón de aprobar también le funciona a él, porque el portal revisa la sesión pero no revisa el rol antes de ejecutar la acción de aprobación. Nadie le dio ese permiso, y sin embargo lo tiene. Esta categoría suele confundirse con la suplantación, y la diferencia es precisa: en la suplantación alguien entra siendo otra persona, en la elevación de privilegios alguien entra siendo quien de verdad es, pero termina pudiendo hacer más de lo que su identidad real debería permitirle.
Lectura disponible — Cómo se documenta un análisis
Documentar el análisis
Un análisis que no se puede leer no sirve, y muchos análisis de estudiantes fallan en la misma parte: enumeran amenazas sin dejar rastro de por qué. Esto es un riesgo documentado completo, con las cuatro piezas que tú vas a tener que escribir:
Amenaza. Un exempleado de la universidad, cuya cuenta del portal de administración no fue desactivada cuando renunció, entra al portal y aprueba una solicitud a nombre de un tercero.
Debilidad que la habilita. El procedimiento de salida de personal no incluye la revocación de las cuentas del portal, y el portal no expira las sesiones inactivas.
Consecuencia concreta. El banco desembolsa un crédito que la universidad no aprobó, la universidad tiene que responder por ese dinero, y la persona a cuyo nombre se aprobó queda registrada como deudora de un crédito que nunca solicitó.
Por qué quedó en esa casilla. Probabilidad media, porque la rotación de personal administrativo es alta y el procedimiento de salida existe pero no cubre este sistema. Impacto crítico, porque el dinero ya salió y porque el daño le cae a una persona que no participó en nada.
Media página escrita así enseña más y se defiende mejor que una tabla de veinte filas donde cada casilla dice “alto”.
El resumen ejecutivo merece un párrafo aparte, porque es la sección que peor se escribe. Su destinatario no es un ingeniero, y esa sola frase cambia todo lo demás: nada de nombres de categorías en inglés, la consecuencia antes que el mecanismo, y una recomendación redactada de forma que se pueda aprobar o rechazar sin pedir una traducción. Si quien lo lee tiene que preguntarle a alguien qué significa lo que acaba de leer, el resumen no cumplió su función, por correcto que sea el análisis que hay detrás.
El resto de la documentación de un análisis profesional sigue este esqueleto, y ahora cada apartado tiene sentido porque sabes lo que va adentro:
- Resumen ejecutivo. Qué sistema se analizó, los riesgos más graves y las recomendaciones prioritarias, escritos para quien decide y no para quien implementa.
- Inventario de activos. Los activos con su clasificación de sensibilidad, quién responde por cada uno y qué propiedades de CIAAN hay que sostener en cada uno.
- Modelo de amenazas. Las partes del sistema y cómo se conectan, los puntos más expuestos, los actores maliciosos considerados (los que estudiaste en la clase 03) y el análisis STRIDE parte por parte.
- Evaluación de riesgos. La matriz con probabilidad e impacto, la priorización que sale de ella, y los riesgos residuales que se aceptan.
- Controles propuestos. Un control por cada riesgo prioritario, con su justificación, su costo estimado y lo que deja sin mitigar.
Este esqueleto de cinco apartados es la forma convencional de documentar un análisis de seguridad en la industria, y es también la estructura que este curso pide para los informes de seguridad que se entregan durante el semestre.
El ingeniero de seguridad en un proyecto
Cuando se construye un sistema, el ingeniero de seguridad participa desde las primeras etapas, y no como revisor al final. La razón cabe en una comparación que puedes hacer tú mismo. Cambiar quién puede aprobar una solicitud cuando el sistema todavía está dibujado en un papel cuesta borrar una flecha y volverla a trazar. Cambiar eso mismo cuando ya hay dos años de solicitudes aprobadas guardadas obliga además a decidir qué se hace con todo lo que se aprobó con la regla vieja, quién revisa esos casos, y qué se le dice a la gente afectada. El trabajo técnico es parecido en los dos momentos; lo que crece es todo lo demás.
Hay una segunda razón, menos evidente, y es que un modelo de amenazas tiene fecha de vencimiento, aunque la fecha no está en el calendario sino en el sistema. El modelo describe unas partes, unas conexiones entre ellas y unos atacantes que tendrían interés en esas partes, así que deja de ser cierto el día en que alguna de las tres cosas cambia. El caso fácil de ver es la integración con un proveedor nuevo, que agrega una conexión que nadie analizó y que además mete en el análisis a un tercero cuya seguridad no controlas. El caso que casi nadie ve es el del dinero: el día en que la organización empieza a administrar recursos de un programa del Estado, el sistema no cambió en nada, pero sí cambió quién tiene razones para mirarlo, y con eso cambia la mitad del modelo aunque el diagrama siga siendo el mismo. Ninguno de los dos cambios se anuncia como un cambio de seguridad, y esa es la razón por la que un modelo se vuelve obsoleto sin que nadie lo note; lo que se hace en la práctica es dejar escrito en el procedimiento de la organización qué tipo de cambio obliga a volver sobre el documento.
Lectura disponible — Cuatro análisis ya terminados
Lo que sigue son cuatro análisis terminados, de sistemas ficticios, construidos para esta clase. Ninguno corresponde a una organización real y ninguna afirmación sobre ellos debe leerse como información sobre una entidad existente.
Están puestos aquí, después del taller y no antes, y el orden de lectura importa más de lo que parece. Un análisis ya resuelto sirve para contrastar el que acabas de hacer, y sustituye al que no hiciste, así que el orden es lo que decide cuál de las dos cosas termina ocurriendo.
Léelos con tres preguntas en la mano, y no con la sensación general de estar comparando. Primera: en el caso A hay un control que no actúa sobre el atacante sino sobre lo que se pierde. Encuéntralo y di si tu ficha tenía alguno de ese tipo. Segunda: el caso B es el único que llega hasta la priorización, y una de sus cinco filas es la que otro analista movería. Di cuál es y qué supuesto sobre el atacante tendría que cambiar para moverla. Tercera: el caso D no está escrito como tabla de amenazas sino como tabla de decisiones, y ninguna de sus tres filas se resuelve con un control técnico. Escoge una de las tres, toma partido por la columna A o por la columna B, y escribe qué pierde quien escoge lo que tú escogiste.
Caso A: sistema de alertas de emergencias
Un sistema ficticio parecido a las alertas por temporada de lluvias que ya te llegan al celular. Recibe información de sensores y de servicios meteorológicos, y la envía como notificaciones a los ciudadanos de una zona. Sus activos principales son los datos de ubicación de los ciudadanos, el contenido de las alertas, el sistema de envío y la confianza pública en que una alerta significa algo.
| Parte del sistema | Categoría STRIDE | Riesgo específico | Impacto |
|---|---|---|---|
| Recepción de datos de sensores | Suplantación | Alguien envía alertas falsas haciéndose pasar por un sensor oficial | Crítico, por el pánico que produce |
| Envío de notificaciones | Denegación de servicio | El sistema se cae justo durante una emergencia real | Crítico, porque hay vidas de por medio |
| Base de datos de usuarios | Divulgación | Se filtran las ubicaciones de los ciudadanos | Alto, por privacidad |
| Contenido de las alertas | Manipulación | Alguien modifica una alerta para cambiar la zona afectada | Crítico |
| Panel de administración | Elevación de privilegios | Un operador sin autorización envía alertas | Crítico |
Los controles que propone el análisis son verificar la identidad de las fuentes antes de aceptar una alerta, firmar digitalmente las alertas para que se note si fueron modificadas, tener un sistema de respaldo que funcione si el principal falla, guardar la mínima cantidad posible de datos de ubicación, y limitar el acceso al panel con verificación en dos pasos. Fíjate en que el cuarto no es un control sobre el atacante sino sobre lo que se pierde: si el dato no está guardado, no se puede filtrar.
Caso B: plataforma de transporte público
Un sistema ficticio que optimiza rutas de buses con información de GPS y patrones de uso, con una aplicación para pasajeros, otra para conductores y un panel de control para la empresa. Se parece a las aplicaciones con las que uno consulta desde el paradero cuánto falta para que llegue el bus en los sistemas de transporte masivo de ciudades como Bogotá, Medellín o Cali, o a las que usan alcaldías más pequeñas para organizar sus rutas urbanas. Este análisis está presentado ya priorizado, que es un paso más adelante que el caso A.
| Riesgo | Probabilidad | Impacto | Prioridad | Control |
|---|---|---|---|---|
| Rastreo de usuarios por terceros | Media | Alto | Alta | Minimizar los datos guardados, no conservar historial innecesario |
| Manipulación de rutas | Baja | Alto | Media | Verificar los cambios de ruta y registrar quién los hizo |
| Fraude en pagos | Alta | Medio | Alta | Verificación de identidad para transacciones, alertas de actividad inusual |
| Suplantación de conductor | Media | Alto | Alta | Verificación de identidad del conductor al iniciar sesión |
| Sistema caído en hora pico | Media | Alto | Alta | Sistemas de respaldo y capacidad extra para momentos de alta demanda |
La fila que vale la pena discutir es la segunda: es la única con prioridad media, y lo es porque su probabilidad se estimó como baja. Esa estimación es un juicio, no un dato, y es exactamente el tipo de casilla que otro analista podría mover.
Caso C: sistema de salud para monitoreo remoto
Un sistema ficticio que conecta pacientes con profesionales de la salud, y que se parece a las consultas médicas a distancia que quizá ya hayas visto ofrecer por aplicación. Los pacientes usan dispositivos como tensiómetros y glucómetros que envían lecturas automáticamente, y los médicos ven el historial y hacen recomendaciones. Este dominio tiene cuatro particularidades que cambian el análisis: los datos de salud tienen protección legal reforzada en Colombia, materia que trabajarás en la clase 09; los dispositivos médicos conectados suelen tener capacidades de seguridad limitadas; los usuarios no son expertos en tecnología; y una falla puede tener consecuencias sobre la vida de una persona. Lo que ocurre cuando un sistema de salud deja de estar disponible lo viste en el ataque con el que abrió la clase 01.
| Riesgo | Consecuencia | Control |
|---|---|---|
| Modificación de dosis recomendadas | Daño físico o muerte | Verificación médica obligatoria de cada recomendación, límites automáticos por fuera de los cuales el sistema no acepta un valor |
| Filtración del historial médico | Discriminación laboral o de aseguramiento, daño a la reputación del paciente | Cifrar la información médica y limitar quién puede consultarla |
| Dispositivo médico comprometido | Lecturas falsas y diagnósticos incorrectos | Verificar la identidad de cada dispositivo y vigilar lecturas inusuales |
| Acceso no autorizado a la cuenta del paciente | Violación de privacidad médica | Autenticación en dos pasos y alerta al paciente cuando alguien accede |
El control de la primera fila es el que conviene mirar dos veces, porque son en realidad dos controles de naturaleza distinta puestos en la misma casilla. Pedir que un médico confirme cada recomendación pone a una persona en el camino y funciona mientras esa persona lea de verdad lo que confirma. El límite automático, en cambio, no depende de que nadie lea nada: el sistema rechaza un valor imposible aunque el médico esté cansado a las tres de la mañana. Cuando un control depende de la atención de alguien y hay otro que no, conviene escribir cuál de los dos es el que de verdad sostiene el riesgo.
Caso D: sistema de videovigilancia urbana
Una red ficticia de cámaras con análisis de video para seguridad pública, que detecta incidentes y alerta a las autoridades. Se parece a las cámaras que administra la alcaldía de cualquier ciudad grande del país, y también a las del conjunto residencial donde uno vive. Este caso no está presentado como tabla de amenazas sino como tabla de decisiones, porque su dificultad principal no es técnica.
| Decisión | Opción A, más seguridad | Opción B, más privacidad |
|---|---|---|
| Reconocimiento facial | Activado para identificar sospechosos | Desactivado o con rostros anonimizados |
| Retención de video | 90 días para investigaciones | 24 a 48 horas como máximo |
| Acceso en tiempo real | Cualquier oficial autorizado | Solo bajo orden judicial |
Los riesgos propios de este dominio no se parecen a los de los otros tres casos: uso del sistema para vigilancia masiva no justificada, manipulación de las grabaciones para incriminar a alguien, acceso de actores maliciosos con fines de chantaje, y sesgo del algoritmo de reconocimiento contra determinados grupos de población. Ninguno de esos cuatro se resuelve con un control técnico, y la discusión de fondo sobre dónde queda el límite es materia de la clase 09.
Lo que hace difícil esta tabla es que cada fila empeora un riesgo mientras mejora otro, y no hay ninguna columna que sea la respuesta segura. Escoger la opción A en retención de video ayuda a reconstruir lo que pasó cuando alguien manipuló una grabación, y al mismo tiempo mantiene disponibles durante tres meses las imágenes que servirían para chantajear a alguien. Por eso el análisis de un sistema así no termina en una casilla de la matriz sino en una decisión escrita con su justificación al lado, que es lo que permite que alguien la revise después.
Conceptos clave
| Término | Definición |
|---|---|
| Activo | Recurso con valor que requiere protección; no solo datos y componentes, sino también procesos que deben seguir funcionando y la confianza que la gente le tiene al servicio |
| Amenaza | Alguien haciendo algo contra el sistema; se escribe con sujeto, y sin sujeto no es una amenaza |
| Vulnerabilidad | Debilidad explotable en un sistema; es una propiedad del sistema y no tiene sujeto |
| Riesgo | La combinación de una amenaza que existe, una debilidad que la deja pasar y algo concreto que se pierde si ocurre |
| STRIDE | Modelo de categorización de amenazas (Spoofing, Tampering, Repudiation, Information Disclosure, DoS, Elevation of Privilege) |
| Superficie de ataque | Conjunto de puntos donde un atacante puede intentar acceder |
| Matriz de riesgo | Tabla que cruza probabilidad e impacto para ordenar los riesgos por prioridad; su valor está en la razón escrita de cada casilla, no en la casilla |
| Priorización | El orden en que se atienden los riesgos; cuando varios comparten casilla, lo decide cuál de ellos hace posibles a los otros |
| Árbol de ataque | Representación de las rutas que un atacante puede recorrer para lograr un objetivo, con nodos que son alternativas y nodos que son requisitos |
| Control preventivo, detectivo y correctivo | Los tres momentos en que puede actuar un control: antes de que la amenaza se materialice, mientras ocurre o después del daño |
| Riesgo residual | Riesgo que permanece después de aplicar controles, y que alguien con autoridad debe aceptar por escrito |
Navegación: ← Anterior | Inicio | Siguiente: Seguridad en aplicaciones →