Modelización de amenazas

Introducción

Lo que quiero saber es cómo llegas a saberlo.

Richard Feynman, físico estadounidense

En esta introducción, explicaremos los fundamentos del modelado de amenazas. También cubriremos los principios de seguridad más cruciales que necesitas conocer como base para evaluar la seguridad de los sistemas que estás analizando.

Los fundamentos del modelado de amenazas

Empecemos por ver a vista de pájaro qué es el modelado de amenazas, por qué es útil y cómo encaja en el ciclo de vida del desarrollo y en el plan general de seguridad.

¿Qué es el modelado de amenazas?

El modelado de amenazas es el proceso de analizar un sistema para buscar puntos débiles que procedan de elecciones de diseño menos deseables. El objetivo de la actividad es identificar estos puntos débiles antes de que se incorporen al sistema (como resultado de la implementación), para que puedas tomar medidas correctivas lo antes posible. La actividad de modelado de amenazas es un ejercicio conceptual que pretende ayudarte a comprender qué características del diseño de un sistema deben modificarse para reducir el riesgo del sistema a un nivel aceptable para sus propietarios, usuarios y operadores.

Al realizar el modelado de amenazas, consideras un sistema como una colección de sus componentes y sus interacciones con el mundo exterior al sistema (como otros sistemas con los que interactúa) y los actores que pueden realizar acciones en estos sistemas. Luego intentas imaginar cómo pueden fallar o hacerse fallar estos componentes e interacciones. A partir de este proceso, identificarás amenazas para el sistema, que a su vez darán lugar a cambios y modificaciones en el sistema. El resultado es un sistema que puede resistir las amenazas que imaginaste.

Pero dejémoslo claro desde el principio: el modelado de amenazas es una actividad cíclica. Comienza con un objetivo claro, continúa con análisis y acciones, y luego se repite. No es una bala de plata: por sí sola no resuelve todos tus problemas de seguridad. Tampoco es una herramienta de pulsar un botón, como un escáner que apuntas a tu sitio web o a tu repositorio de código y que genera una lista de elementos que hay que marcar. El modelado de amenazas es un proceso lógico e intelectual que será más eficaz si implicas a la mayoría, si no a todo, tu equipo. Generará debate y creará claridad en tu diseño y ejecución. Todo esto requiere trabajo y una cierta cantidad de conocimientos especializados.

La primera regla del modelado de amenazas podría ser la vieja máxima basura dentro, basura fuera (GIGO).¹ Si incorporas el modelado de amenazas a las herramientas de tu equipo y consigues que todos participen de forma positiva, cosecharás sus muchos beneficios, pero si te adentras en él a medias, sin una comprensión completa de sus puntos fuertes y sus defectos, o como un elemento de cumplimiento para "marcar la casilla", sólo lo verás como un sumidero de tiempo. Una vez que encuentres una metodología que funcione para ti y tu equipo y pongas el esfuerzo necesario para que funcione, tu postura general de seguridad crecerá sustancialmente.

Por qué necesitas un modelo de amenazas

Necesitas el modelado de amenazas porque facilitará y mejorará tu trabajo a largo plazo. Dará lugar a arquitecturas más limpias, límites de confianza bien definidos (aún no sabes qué son y por qué son importantes, ¡pero pronto lo sabrás!), pruebas de seguridad centradas y mejor documentación. Y, sobre todo, inculcará en ti y en tu equipo el superpoder de la mentalidad de seguridad de forma organizada y orquestada, lo que conducirá a mejores normas y directrices de seguridad en todo tu esfuerzo de desarrollo.

Por muy importantes que sean todos esos beneficios secundarios, no son lo más importante. Comprender lo que podría ir mal en tu sistema y lo que puedes hacer al respecto aumentará tu confianza en lo que entregas, dejándote libre para concentrarte en otras facetas del sistema. Y eso es lo que realmente está detrás de la necesidad demodelar las amenazas.

También es importante señalar por qué no necesitas el modelado de amenazas. No va a resolver por sí solo todos tus problemas de seguridad; tampoco va a transformar a tu equipo en expertos en seguridad inmediatamente. Y, sobre todo, no lo necesitas para cumplir la normativa. Un ejercicio vacío que sólo pretende poner la marca de verificación en la lista de cumplimiento te llevará a más frustración que saber que no tienes cubierto ese requisito específico.

Obstáculos

El problema con los programadores es que nunca se sabe lo que hace un programador hasta que es demasiado tarde.

Seymour R. Cray, creador de la línea Cray de superordenadores

Esta máxima sigue siendo válida hoy en día. Dale a un desarrollador una especificación o un conjunto de requisitos razonablemente bien documentados, y apártate, y pueden ocurrir muchas cosas interesantes.

Sinceramente, sabemos que los equipos de desarrollo pueden ser personas estresadas que trabajan con grandes exigencias y grandes responsabilidades. Tenéis que lidiar con un panorama casi constantemente cambiante de aprender, llegar a ser competentes y luego olvidar subdisciplinas enteras. Es injusto presionarte por "no saber alguna cosa de seguridad que es realmente básica e importante". Considera que toda la industria de contenidos de formación se centra sobre todo en la consecución de objetivos orientados al negocio, como el cumplimiento y la consecución de objetivos de formación y otras métricas variadas. Hay un gran margen de mejora en la entrega real de contenidos eficaces y útiles que los equipos de desarrollo puedan traducir en conocimiento y uso práctico.

Una de las tareas de los profesionales de la seguridad es fomentar la educación en seguridad de las comunidades de desarrollo. Esto incluye cómo implantar sistemas seguros y cómo evaluar la seguridad del código y los sistemas, a posteriori. Puede parecer más fácil confiar en un costoso conjunto de herramientas para complementar (y, en gran medida, ocultar a la vista) la experiencia en seguridad de la organización. El reto es que los conocimientos incorporados a las herramientas a menudo se ocultan al usuario; los equipos de desarrollo se beneficiarían enormemente si los métodos de detección fueran transparentes para ellos. He aquí algunos ejemplos:

• La formación por ordenador (CBT) es el azote de todo nuevo trabajador. ¿Conjuntos de 45 minutos de voces aburridas leyendo diapositivas de aspecto cansino, en los tipos de letra estándar de siempre, con las mismas fotos e imágenes de archivo? Y lo que es peor, ¿las inocuas preguntas tipo test "resuelve por exclusión", que no enseñan nada?

• Confianza excesiva en escáneres y analizadores de código estático "bala de plata" que prometen utilizar inteligencia artificial, aprendizaje automático, análisis de manchas, árboles de ataque y los Poderes de Grayskull, pero que no producen sistemáticamente los mismos resultados, o dan más falsos positivos que respuestas útiles reales. O las herramientas de análisis esperan que exista todo el sistema antes de poder ejecutar un análisis, por no mencionar que introducen largos tiempos en el proceso de compilación que son un anatema para los valores de integración continua/desarrollo continuo (CI/CD).

• Servicios de consultoría en los que, previa solicitud, un profesional de la seguridad se abalanza sobre ti, ejecuta tareas de corrección (o "formación dirigida") y desaparece (a esto lo llamamos consultoría de gaviota; se abalanzan sobre ti, se cagan encima y se van volando), dejando que el equipo se ocupe de las consecuencias. Confiar en un consultor de seguridad "justo a tiempo" conlleva importantes desventajas: no tienen ningún interés personal en el resultado de sus acciones, son externos al equipo (si no a la empresa), aportan un sesgo personal, y hacen "magia", dejando al equipo con la sensación de que ha ocurrido algo, pero sin una idea de lo que ha sucedido. El culto a la carga² ya que el equipo intenta reproducir constantemente el subconjunto de resultados que dejó el consultor.

Los profesionales de la seguridad también hemos creado un falso sentido de las expectativas de los desarrolladores dentro de las organizaciones:

• Una organización puede comprar su camino hacia una postura de seguridad fuerte. Si invierte suficiente dinero en herramientas, resolverá todos sus problemas de seguridad.

• Treinta minutos de formación obligatoria al trimestre son suficientes para que la organización supere la auditoría. Estos 30 minutos deberían ser suficientes para que los equipos de desarrollo aprendan lo que se espera de ellos. Dado que los equipos de desarrollo tienen acceso a contenidos de formación de primera categoría, las costosas herramientas que utilizan sólo "mirarán por encima de sus hombros" y validarán que, efectivamente, han hecho su trabajo de forma perfectamente segura.

Últimamente (desde mediados de 2019) la industria de la seguridad se ha visto consumida por la idea de desplazarse hacia la izquierda. Imagina un flujo de trabajo que lees de izquierda a derecha. El inicio del flujo de trabajo está a la izquierda. Cuando decimos "desplazarse a la izquierda", queremos decir que queremos que los procesos de seguridad se desplacen lo más "a la izquierda" posible, al principio del flujo de trabajo de desarrollo (de cualquier metodología de desarrollo que se utilice). Esto permite que los sucesos de seguridad ocurran y se traten lo antes posible. Una actividad como el modelado de amenazas, que está estrechamente asociada al diseño, debe producirse lo antes posible en la vida de un sistema. Y, si no ocurrió entonces, debería ocurrir ahora.

Nota

No suscribimos el fenómeno del "giro a la izquierda", sino que preferimos empezar por la izquierda utilizando metodologías que comiencen por el diseño, o antes por los requisitos, como base de la seguridad de un sistema.

Con los cambios en el proceso que dan lugar a un ciclo de desarrollo menos lineal "de izquierda a derecha", desplazarse a la izquierda puede no ser capaz de abordar todas las necesidades de seguridad de un sistema. En su lugar, la comunidad de seguridad tendrá que desplazarse aún más a la izquierda, a la vida de los desarrolladores y diseñadores como individuos, antes de que se esté considerando un sistema. Ahí tendremos que centrarnos en formar a los equipos de desarrollo para que tomen decisiones seguras, y aporten capacidades con ellas, para evitar amenazas a un nivel mucho más fundamental.

Luego está la implementación, en la que supuestamente la seguridad se desplaza hacia la izquierda gracias a los esfuerzos colectivos de formación de la industria, y se expresa semántica y lógicamente mediante código seguro. Pero si la formación no ha cumplido las expectativas prometidas, ¿de qué posibles medidas correctoras se dispone para corregir los supuestos fallidos?

Veamos otro ángulo del problema y luego conectemos las piezas en una respuesta coherente a este desvarío (¡una invitación a una cruzada!). Algunos hablan de "un lugar en la mesa" cuando discuten la estrategia de seguridad. Los equipos de seguridad y los ejecutivos quieren que las "partes interesadas" ocupen "un lugar" para la seguridad en la "discusión en curso". Esto les permite justificar su necesidad de hacerse con ese trozo del pastel de los recursos. Pero hay otro recurso importante que no se reconoce tanto, porque está ofuscado por la "formación exhaustiva" y las "herramientas milagrosas". Y ese recurso es el tiempo y la concentración del desarrollador.

Pensemos en un desarrollador web. Infinidad de memes reflejan el hecho de que si hoy un desarrollador web aprende todo lo que pueda sobre la pila LAMP³ antes de desayunar, ese conocimiento se vuelve inútil justo después de comer porque toda la industria se habrá pasado a la pila MEAN.⁴ Y la pila MEAN será sustituida dos grandes cafés con leche más tarde por otra cosa nueva y brillante hasta que volvamos de nuevo a la versión nueva y mejorada (¡y totalmente incompatible con versiones anteriores!) de donde acabamos de empezar. Cada una de estas nuevas pilas conlleva un nuevo conjunto de retos de seguridad y de modismos y mecanismos relacionados con la seguridad que deben comprenderse e incorporarse para proteger eficazmente el sistema que están desarrollando. Y, por supuesto, cada pila requiere un contrato de seguridad distinto que el desarrollador web debe aprender y dominar rápidamente.

Pero el sitio web no puede estar inactivo, y se supone que su administración tiene lugar al mismo tiempo que el desarrollador está aprendiendo su nueva herramienta dejuguete. ¿Cómo es posible que la seguridad espere compartir el mismo pastel (es decir, el tiempo y la atención del programador) y recibir algo más que un trozo?

Y aquí es donde empieza la cruzada, como nos dice Richard Feynman: "Enseña principios, no fórmulas". En este libro, nos centraremos en los principios para ayudarte a comprender y pensar qué es para ti el modelado de amenazas, cómo puede ayudarte en tu caso concreto y cuál es la mejor forma de aplicarlo a tu proyecto y a tu equipo.

Modelado de amenazas en el ciclo de vida de desarrollo del sistema

El modelado de amenazas es una actividad que se realiza durante el ciclo de vida de desarrollo del sistema y que es fundamental para la seguridad del mismo. Si el modelado de amenazas no se realiza de alguna manera, es probable que se introduzcan fallos de seguridad a través de elecciones de diseño que posiblemente se exploten con facilidad, y que sin duda serán difíciles (y costosas⁵) de solucionar posteriormente. En consonancia con el principio de seguridad de "incorporar, no atornillar", el modelado de amenazas no debe considerarse un hito de cumplimiento; existen consecuencias en el mundo real por no realizar esta actividad cuando más importa.

Hoy en día, la mayoría de las empresas de éxito no ejecutan los proyectos como lo hacían hace un par de años. Por ejemplo, paradigmas de desarrollo como la informática sin servidor⁶ o algunas de las últimas tendencias y herramientas en CI/CD,⁷ han tenido un profundo impacto en la forma en que los equipos de desarrollo diseñan, implementan y despliegan los sistemas actuales.

Debido a la demanda del mercado y a la carrera por ser el primero, hoy en día rara vez tienes la oportunidad de sentarte antes del desarrollo de un sistema y ver un diseño totalmente desarrollado. Los equipos de producto se basan en versiones de "producto viable mínimo" para presentar sus nuevas ideas al público y empezar a crear una marca y un grupo de seguidores. Luego se basan en versiones incrementales para añadir funcionalidad y hacer cambios a medida que surgen problemas. Esta práctica hace que los cambios significativos en el diseño se produzcan más tarde en el ciclo de desarrollo.

Los sistemas modernos tienen una complejidad nunca vista. Puedes utilizar muchos componentes, bibliotecas y marcos de trabajo de terceros (que pueden ser de código abierto o cerrado) para construir tu nuevo software, pero los componentes están muchas veces mal documentados, mal comprendidos y mal asegurados. Para crear sistemas "sencillos", dependes de intrincadas capas de software, servicios y capacidades. De nuevo, utilizando las Implementaciones sin servidor como ejemplo, decir "no me importa el entorno, las bibliotecas, las máquinas o la red, sólo me importan mis funciones" es miope. ¿Cuánta maquinaria se oculta tras la cortina? ¿Cuánto control tienes sobre lo que ocurre "bajo" tus funciones? ¿Cómo afectan estas cosas a la seguridad general de tu sistema? ¿Cómo validas que estás utilizando las funciones y reglas de acceso más adecuadas?

Para responder a esas preguntas de forma fiable y obtener resultados inmediatos, puedes tener la tentación de recurrir a un experto externo en seguridad. Pero la experiencia en seguridad puede variar, y contratar expertos puede resultar caro. Algunos expertos se centran en tecnologías o áreas específicas, y el enfoque de otros es amplio pero superficial. Por supuesto, esto no describe en absoluto a todos los consultores, y seremos los primeros en dar fe de haber tenido algunas experiencias estupendas con consultores de modelado de amenazas. Sin embargo, puedes ver que existe un gran incentivo para desarrollar conocimientos internos sobre el modelado de amenazas e intentar adaptarlo en la medida de lo posible a la metodología de desarrollo de tu equipo.

Desarrollar sistemas seguros

Independientemente de la metodología de desarrollo que utilices, la forma en que se desarrolla tu sistema debe pasar por unas fases muy concretas (ver Figura I-1).

• Inicio de la idea

• Diseño

• Aplicación

• Prueba

• Implementación

Figura I-1. Bucle de desarrollo y actividades de seguridad relacionadas

En la metodología en cascada, por ejemplo, estas fases se suceden de forma natural. Ten en cuenta que la documentación desempeña un papel continuo: debe producirse en paralelo con las demás fases para ser realmente eficaz. Al utilizar esta metodología, es fácil ver que un modelo de amenazas proporciona el mayor beneficio en el momento del diseño.

Ésta es una afirmación que verás muchas veces en este libro. Vinculamos meticulosamente el modelado de amenazas con el diseño. ¿Por qué?

Un concepto muy citado⁸ indica que el coste de resolver un problema aumenta significativamente cuanto más cerca está de la implementación o después de ella. Esto es bastante obvio para las personas familiarizadas con la fabricación y comercialización de software; es mucho más barato aplicar soluciones a un sistema en desarrollo que al que ya está implantado en miles o, en algunos casos extremos, millones de lugares.⁹ No tienes que lidiar con la responsabilidad de que algunos usuarios no apliquen un parche, ni con los posibles fallos de compatibilidad con versiones anteriores introducidos al parchear un sistema. No tienes que lidiar con usuarios que, por una razón u otra, no pueden seguir adelante con el parche. Y no tienes que incurrir en el coste de soportar un proceso de actualización largo y a veces inestable.

Así pues, el modelado de amenazas, por su naturaleza, examina un diseño e intenta identificar fallos de seguridad. Por ejemplo, si tu análisis muestra que un determinado modo de acceso utiliza una contraseña codificada, se identifica como un hallazgo que hay que abordar. Si un hallazgo de no se aborda, probablemente estés ante un problema que se explotará más adelante en la vida del sistema. Esto también se conoce como vulnerabilidad, que tiene una probabilidad de explotación y un coste asociado si se explota. También es posible que no identifiques un problema, o que no determines correctamente algo que puede ser explotado. La perfección y la exhaustividad no son objetivos de este ejercicio.

Nota

El objetivo clave del modelado de amenazas es identificar los fallos para que se conviertan en hallazgos (problemas que puedes abordar) y no en vulnerabilidades (problemas que pueden explotarse). Entonces puedes aplicar mitigaciones que reduzcan tanto la probabilidad de explotación como el coste de ser explotado (es decir, el daño, o impacto).

Una vez que identificas un hallazgo, te mueves para mitigarlo, o rectificarlo. Para ello, aplica los controles adecuados; por ejemplo, puedes crear una contraseña dinámica, definida por el usuario, en lugar de una codificada. O, si el caso lo justifica, puedes realizar varias pruebas con esa contraseña para garantizar su seguridad. O puedes dejar que el usuario decida la política de contraseñas. O podrías cambiar totalmente tu enfoque y eliminar por completo el fallo suprimiendo el uso de contraseñas y ofreciendo en su lugar soporte para WebAuthn¹⁰ en su lugar. En algunos casos, puede que simplemente asumas el riesgo y decidas que, para laforma en que se va a implementar el sistema, podría estar bien utilizar una contraseña codificada. (Sugerencia: no lo es. En serio. Piénsalo.) A veces tienes que determinar que un riesgo es aceptable. En esos casos, tienes que documentar el hallazgo, identificar y describir las razones para no abordarlo, y hacer que forme parte de tu modelo de amenazas.

Es importante destacar (y volveremos sobre ello a lo largo del libro) que el modelado de amenazas es un proceso evolutivo. Es posible que no encuentres todos los fallos de tu sistema la primera vez que lo analices. Por ejemplo, tal vez no disponías de los recursos adecuados o de las partes interesadas correctas para examinar el sistema. Pero tener un modelo inicial de amenazas es mucho mejor que no tener ningún modelo de amenazas. Y la siguiente iteración, cuando se actualice el modelo de amenazas, será mejor, identificará otros fallos y conllevará un mayor nivel de seguridad de que no se han encontrado fallos. Tú y tu equipo adquiriréis la experiencia y la confianza que os llevarán a considerar ataques y vectores nuevos y más complejos o sutiles, y tu sistema mejorará constantemente.

No más cascadas

Avancemos hacia los enfoques Agile y CI/CD más modernos.

Como se trata de formas más rápidas de desarrollar e implementar software, puede que te resulte imposible pararlo todo, iniciar una sesión de diseño adecuada y acordar lo que tiene que ocurrir. A veces tu diseño evoluciona con los requisitos de los clientes, y otras veces tu diseño surge del desarrollo en curso de tu sistema. En estas situaciones, puede ser difícil predecir el diseño general del sistema completo (o incluso saber qué es el sistema completo), y es posible que no puedas hacer modificaciones de diseño de gran alcance de antemano.

Muchas propuestas de diseño describen cómo realizar el modelado de amenazas en estas circunstancias: desde la propuesta de Microsoft de "sprints de seguridad" hasta la aplicación del modelado de amenazas a unidades de sistema más pequeñas, de forma iterativa, en cada sprint. Y, por desgracia, se ha afirmado que el modelado de amenazas "reduce la velocidad" de un equipo ágil. ¿Es mejor reducir la velocidad de un equipo Ágil o la de un equipo de hackers que intentan acceder a tus datos? Por ahora, lo importante es reconocer el problema; más adelante apuntaremos posibles soluciones.

Una vez que abordes la seguridad en el proceso de diseño, verás cómo la seguridad influye en todas las demás fases del desarrollo. Esto te ayudará a reconocer cómo el modelado de amenazas puede tener un impacto aún mayor en la postura general de seguridad del sistema, que es una medida colectiva de:

• El estado actual de la seguridad en el sistema

• Vectores de ataque, o puntos de intrusión, u oportunidades para cambiar el comportamiento del sistema, disponibles para que un actor los explore y explote (también conocido como lasuperficie de ataque)

• Las vulnerabilidades y debilidades existentes en el sistema (también conocidas como deuda de seguridad) y el riesgo combinado para el sistema y/o la empresa resultante de estos factores

Aplicación y pruebas

Es difícil no considerar la implementación y las pruebas como el aspecto más importante de la seguridad en el desarrollo. Al fin y al cabo, los problemas de seguridad provienen (¡en su mayoría!) de problemas o errores cometidos al poner en marcha las líneas de código. Algunos de los problemas de seguridad más infames -¿Heartbleed, alguien?- y la mayoría de los problemas de desbordamiento del búfer no se derivan de un mal diseño, sino de líneas de código que no hacían lo que se suponía que debían hacer, o lo hacían de forma inesperada.

Cuando observas las clases de vulnerabilidades (por ejemplo, los desbordamientos de búfer y los problemas de inyección), es fácil ver cómo un desarrollador puede introducirlas inadvertidamente. Es fácil cortar y pegar una estrofa utilizada anteriormente, o caer en la creencia de "¿quién podría hacer eso?" al considerar una mala entrada. O el desarrollador puede simplemente introducir errores por ignorancia, falta de tiempo u otros factores, sin tener en cuenta la seguridad.

Muchas herramientas existentes identifican vulnerabilidades en el código escrito realizando un análisis estático. Algunas herramientas lo hacen analizando el código fuente; otras lo hacen ejecutando el código a través de simulaciones de entrada e identificando los malos resultados (esta técnica se conoce como fuzzing). El aprendizaje automático ha surgido recientemente como otra alternativa para identificar "código malo".

Pero, ¿influye el modelado de amenazas en estas cuestiones relacionadas con el código? Eso depende. Si observas un sistema en su conjunto y decides que eres capaz de eliminar por completo toda una clase de vulnerabilidades abordando el fallo raíz, entonces tienes la oportunidad, en el momento del diseño, de abordar los problemas relacionados con el código. Google lo hizo con el cross-site scripting (y otras clases de vulnerabilidades) instituyendo bibliotecas y patrones que deben utilizarse en todos los productos que se ocupan del problema.¹¹ Por desgracia, las decisiones tomadas para abordar algunos tipos de problemas pueden cortar cualquier vía para abordar otros problemas. Por ejemplo, supongamos que estás trabajando en un sistema con requisitos primarios de alto rendimiento y alta fiabilidad. Puede que elijas utilizar un lenguaje que ofrezca un control directo de la memoria y menos sobrecarga de ejecución, como C, en lugar de lenguajes como Go o Java, que ofrecen mejores capacidades de gestión de la memoria. En este caso, es posible que tengas opciones limitadas para influir en la amplitud de los posibles problemas de seguridad que deben abordarse cambiando la pila tecnológica. Esto significa que tienes que utilizar herramientas en tiempo de desarrollo y en tiempo de pruebas para vigilar el resultado.

Documentación e Implementación

A medida que se desarrollan los sistemas, los equipos responsables de ellos pueden pasar por un proceso de autodesarrollo. El conocimiento tribal, o conocimiento institucional, existe cuando un conjunto de individuos llega a aprender o comprender algo y conserva ese conocimiento sin documentarlo. Sin embargo, a medida que los miembros del equipo cambian con el tiempo, con individuos que abandonan el equipo y otros nuevos que se incorporan, este conocimiento tribal puede perderse.

Por suerte, un modelo de amenazas bien documentado es un gran vehículo para proporcionar a los nuevos miembros del equipo estos conocimientos formales y propios. Muchos puntos de datos oscuros, justificaciones y procesos generales de pensamiento (por ejemplo, "¿Por qué lo habéis hecho así aquí?") son muy adecuados para ser capturados como documentación en un modelo de amenazas. Cualquier decisión tomada para superar las limitaciones, y sus consiguientes repercusiones en la seguridad, también son buenas candidatas para la documentación. Lo mismo ocurre con la implementación: un modelo de amenazas es un buen lugar para hacer referencia a un inventario de componentes de terceros, cómo se mantienen actualizados, los esfuerzos necesarios para reforzarlos y las suposiciones realizadas al configurarlos. Algo tan sencillo como un inventario de puertos de red y sus protocolos explica no sólo la forma en que fluyen los datos en el sistema, sino también las decisiones de implementación relativas a la autenticación de hosts, la configuración de cortafuegos, etc. Todo este tipo de información encaja bien en un modelo de amenazas, y si tienes que responder a auditorías de cumplimiento y auditorías de terceros, localizar y proporcionar los detalles pertinentes resulta mucho más fácil.

Principios esenciales de seguridad

Nota

El resto de esta Introducción ofrece una breve visión general de los conceptos y la terminología fundamentales de la seguridad, con los que es fundamental que tanto los equipos de desarrollo como los profesionales de la seguridad estén al menos familiarizados. Si deseas obtener más información sobre cualquiera de estos principios, consulta las numerosas y excelentes referencias que ofrecemos a lo largo de este capítulo y del libro.

Familiarizarse con estos principios y terminología es clave como base para un aprendizaje adicional, como individuo o como equipo, aprendiendo a medida que avanzas en tus viajes de seguridad.

Conceptos básicos y terminología

La Figura I-2 destaca conceptos cruciales en la seguridad de los sistemas. Comprender estas relaciones y la nomenclatura de la seguridad es clave para entender por qué el modelado de amenazas es de vital importancia para el diseño de un sistema seguro.

Figura I-2. Relaciones de la terminología de seguridad

Un sistema contiene activos: la funcionalidad de la que dependen sus usuarios y los datos aceptados, almacenados, manipulados o transmitidos por el sistema. La funcionalidad del sistema puede contener defectos, que también se conocen como debilidades. Si estas debilidades son explotables, es decir, si son vulnerables a influencias externas, se conocen como vulnerabilidades, y su explotación puede poner en riesgo de exposición las operaciones y los datos del sistema. Un actor (un individuo o un proceso externo al sistema) puede tener intenciones maliciosas e intentar explotar una vulnerabilidad, si se dan las condiciones para hacerlo posible; algunos atacantes hábiles son capaces de alterar las condiciones para crear oportunidades de intentar la explotación. Un actor crea un evento de amenaza en este caso, y a través de este evento amenaza al sistema con un efecto concreto (como robar datos o hacer que la funcionalidad se comporte mal).

La combinación de funcionalidad y datos crea valor en el sistema, y un adversario que cause una amenaza anula ese valor, lo que constituye la base del riesgo. El riesgo se compensa mediante controles, que abarcan las capacidades funcionales de un sistema, así como los comportamientos operativos y organizativos de los equipos que diseñan y construyen el sistema, y se modifica mediante probabilidades: las expectativas de un atacante que desee causar daño y la probabilidad de que tenga éxito si intenta hacerlo.

Cada concepto y término requiere una explicación adicional para tener sentido:

Debilidad

Una debilidad es un defecto subyacente que modifica el comportamiento o la funcionalidad (dando lugar a un comportamiento incorrecto) o permite un acceso no verificado o incorrecto a los datos. Las debilidades en el diseño del sistema son el resultado de no seguir las buenas prácticas, o normas, o convenciones, y provocan algún efecto indeseable en el sistema. Por suerte para los modeladores de amenazas (y los equipos de desarrollo), una iniciativa de la comunidad -laEnumeración de DebilidadesComunes(CWE)- ha creado una taxonomía abierta de debilidades de seguridad a la que se puede hacer referencia cuando se investiga el diseño del sistema en busca de problemas.

Explotabilidad

La explotabilidad es una medida de la facilidad con la que un atacante puede hacer uso de un punto débil para causar daño. Dicho de otro modo, la explotabilidad es la cantidad de exposición que tiene el punto débil a la influencia externa.¹²

Vulnerabilidad

Cuando un punto débil es explotable (la explotabilidad fuera del contexto de autorización local es distinta de cero), se conoce como vulnerabilidad. Las vulnerabilidades proporcionan un medio para que un adversario con intenciones maliciosas cause algún tipo de daño a un sistema. Las vulnerabilidades que existen en un sistema pero que no han sido descubiertas previamente se conocen como vulnerabilidades de día cero. Las de día cero no son ni más ni menos peligrosas que otras vulnerabilidades de naturaleza similar, pero son especiales porque es probable que no se hayan resuelto y, por tanto, el potencial de explotación puede ser elevado. Al igual que con las debilidades, los esfuerzos de la comunidad han creado una taxonomía de vulnerabilidades, codificada en la base de datos CVE.

Gravedad

Los puntos débiles provocan un impacto en un sistema y sus activos (funcionalidad y/o datos); el potencial de daño y el "radio de explosión" de un problema de este tipo se describen como la gravedad del defecto. Para aquellos cuya profesión principal sea o haya sido cualquier campo de la ingeniería, la gravedad puede ser un término familiar. Las vulnerabilidades -debilidades explotables- son, por definición, al menos tan graves como el defecto subyacente, y lo más frecuente es que la gravedad de un defecto aumente porque está abierto a ser explotado. Los métodos para calcular la gravedad se describen en "Calcular la gravedad o el riesgo".

Nota

Por desgracia, el proceso de determinar la gravedad de un punto débil no siempre es tan sencillo. Si la capacidad de aprovechar el defecto para causar un impacto no se reconoce en el momento del descubrimiento de la debilidad, ¿cuál es la gravedad del problema? ¿Qué ocurre si más tarde se determina que el defecto está expuesto, o peor aún, queda expuesto como resultado de un cambio en el diseño o la implementación del sistema? Son preguntas difíciles de responder. Tocaremos este tema más adelante, cuando introduzcamos los conceptos de riesgo.

Impacto

Si se explota una debilidad o vulnerabilidad, se producirá algún tipo de impacto en el sistema,como romper la funcionalidad o exponer datos. Cuando califiques la gravedad de un problema, querrás evaluar el nivel de impacto como medida de la pérdida potencial de funcionalidad y/o datos como resultado de una explotación exitosa.

Actor

Al describir un sistema, un actor es cualquier individuo asociado al sistema, como un usuario o un atacante. Un actor con intenciones maliciosas, interno o externo a la organización, que crea o utiliza el sistema, se denomina a veces adversario.

Amenaza

Una amenaza es el resultado de una probabilidad no nula de que un atacante se aproveche de una vulnerabilidad para afectar negativamente al sistema de una forma determinada (comúnmente formulada en términos de "amenaza de..." o "amenaza de...").

Evento de amenaza

Cuando un adversario intenta (con éxito o sin éxito) explotar una vulnerabilidad con un objetivo o resultado previsto, esto se conoce como evento de amenaza.

Pérdida

A efectos de este libro y del tema del modelado de amenazas, se produce una pérdida cuando uno (o varios) impactos afectan a la funcionalidad y/o a los datos como consecuencia de que un adversario provoque un evento de amenaza:

• El actor es capaz de subvertir la confidencialidad de los datos de un sistema para revelar información sensible o privada.

• El actor puede modificar la interfaz a la funcionalidad, cambiar el comportamiento de la funcionalidad o cambiar el contenido o la procedencia de los datos.

• El actor puede impedir que entidades autorizadas accedan a funcionalidades o datos, temporal o permanentemente.

  La pérdida se describe en términos de un bien o una cantidad de valor.

Riesgo

El riesgo combina el valor del objetivo potencialmente explotado con la probabilidad de que se produzca un impacto. El valor es relativo para el propietario del sistema o de la información, así como para el atacante. Debes utilizar el riesgo para informar de la prioridad de un problema, y para decidir si debes abordarlo. Las vulnerabilidades graves que son fáciles de explotar, y las que provocan daños significativos por pérdidas, deben tener una prioridad alta para mitigarlas.

Cálculo de la gravedad o el riesgo

La gravedad (la cantidad de daño que puede causar la explotación con éxito de una vulnerabilidad), y el riesgo (la combinación de la probabilidad de inicio de un suceso de amenaza y la probabilidad de éxito para generar un impacto negativo como resultado de la explotación) pueden determinarse mediante fórmulas. Las fórmulas no son perfectas, pero su uso proporciona coherencia. Hoy en día existen muchos métodos para determinar la gravedad o el riesgo, y algunas metodologías de modelado de amenazas utilizan métodos alternativos de puntuación del riesgo (no descritos en este libro). Aquí se presenta una muestra de tres métodos populares de uso general (uno para medir la gravedad y dos para el riesgo).

CVSS (gravedad)

El Sistema Común de Puntuación de Vulnerabilidades (CVSS) está ahora en la versión 3.1, y es un producto del Foro de Equipos de Respuesta a Incidentes y Seguridad (FIRST).

El CVSS es un método para establecer un valor de 0,0 a 10,0, que permite identificar los componentes de gravedad. El cálculo de se basa en la probabilidad de que se explote con éxito una vulnerabilidad, y en una medida del impacto potencial (o daño). En la calculadora se establecen ocho métricas, o valores, para obtener una calificación de gravedad, como se muestra en la Figura I-3.

Figura I-3. Métricas, vector y puntuación del Sistema Común de Puntuación de Vulnerabilidades

La probabilidad de éxito se mide en función de métricas específicas a las que se asigna una puntuación numérica. El resultado es un valor conocido como la subpuntuación de explotabilidad. El impacto se mide de forma similar (con métricas diferentes) y se conoce como subpuntuación de impacto. Sumadas, las dos subpuntuaciones dan como resultado una puntuación base global.

Consejo

Recuerda que el CVSS no mide el riesgo, sino la gravedad. El CVSS puede indicarte la probabilidad de que un atacante consiga explotar la vulnerabilidad de un sistema afectado, y la cantidad de daño que puede causar. Pero no puede indicar cuándo o si un atacante intentará explotar la vulnerabilidad. Tampoco puede decirte cuánto vale el recurso afectado ni lo caro que será solucionar la vulnerabilidad. Es la probabilidad de que se inicie un ataque, el valor del sistema o funcionalidad y el coste de mitigarlo lo que impulsa el cálculo del riesgo. Basarse en la gravedad bruta es una buena forma de comunicar información sobre un defecto, pero es una forma muy imperfecta de gestionar el riesgo.

DREAD (riesgo)

DREAD es un método más antiguo¹³ pero de importancia fundamental, método para comprender el riesgo de los problemas de seguridad. DREAD es el socio de la metodología de modelado de amenazas STRIDE; STRIDE se analiza en profundidad en el Capítulo 3.

DREAD es el acrónimo de:

Daños

Si un adversario realizara un ataque, ¿cuánta destrucción podría causar?

Reproducibilidad

¿Es un ataque potencial fácilmente reproducible (en método y efecto)?

Explotabilidad

¿Es fácil llevar a cabo un ataque con éxito?

Usuarios afectados

¿Qué porcentaje de la población usuaria podría verse afectado?

Descubribilidad

Si el adversario no conoce ya el potencial de un ataque, ¿cuál es la probabilidad de que pueda descubrirlo?

DREAD es un proceso para documentar las características de un posible ataque contra un sistema (a través de un vector por parte de un adversario) y obtener un valor que pueda compararse con otros valores similares para otros escenarios de ataque y/o vectores de amenaza. La puntuación de riesgo para cualquier escenario de ataque dado (combinación de una vulnerabilidad de seguridad y un adversario) se calcula considerando las características de la explotación de una vulnerabilidad por un atacante y asignándoles una puntuación en cada dimensión (es decir, D, R, E, A, D), para problemas de impacto bajo, medio y alto, respectivamente.

El total de las puntuaciones de cada dimensión determina el valor de riesgo global. Por ejemplo, un problema de seguridad arbitrario en un sistema concreto puede tener puntuaciones de [D = 3, R = 1, E = 1, A = 3, D = 2] para un valor de riesgo total de 10. Para que tenga sentido, este valor de riesgo puede compararse con otros riesgos identificados contra este sistema concreto; sin embargo, es menos útil intentar comparar este valor con valores de otros sistemas.

Método FAIR de cuantificación del riesgo (riesgo)

El método de Análisis Factorial del Riesgo de la Información (FAIR) está ganando popularidad entre los tipos ejecutivos porque ofrece el nivel adecuado de granularidad con más especificidad para permitir una toma de decisiones más eficaz. FAIR está publicado por el Open Group y se incluye en la norma ISO/IEC 27005:2018.

DREAD es un ejemplo de cálculo cualitativo del riesgo. FAIR es una norma internacional para el modelado cuantitativo del riesgo y para comprender el impacto de las amenazas sobre los activos, utilizando medidas de valor (costes monetarios duros y blandos) y probabilidad de realización (sucesos, o eventos de amenaza) de una amenaza por parte de un actor. Utiliza estos valores cuantitativos para describir a tus directivos y líderes empresariales el impacto financiero para la empresa de los riesgos identificados en tus sistemas, y compáralos con el coste de defenderse contra los sucesos de amenaza. Las prácticas adecuadas de gestión de riesgos sugieren que el coste de la defensa no debe superar el valor del activo, o la pérdida potencial de un activo. Esto también se conoce como el paradigma del candado de 50 $ por un bolígrafo de 5 $.

Advertencia

FAIR es minucioso y preciso, pero también complejo, y requiere conocimientos especializados para realizar los cálculos y simulaciones correctamente. No es algo que quieras hacer en directo en una sesión de revisión de modelado de amenazas, ni algo que quieras enarbolar sobre tus expertos en materia de seguridad (SME), si los tienes. Los expertos en seguridad tienen experiencia en encontrar puntos débiles y amenazas, no en modelar valoraciones de impacto financiero. Contratar a personas con conocimientos de métodos computacionales y modelización financiera, o encontrar una herramienta que haga los cálculos difíciles por ti, es un mejor curso de acción si piensas adoptar FAIR.

Propiedades principales

Tres propiedades fundamentales -confidencialidad, integridad y disponibilidad- forman la base sobre la que se construyen todas las demás cosas en seguridad. Cuando alguien quiere saber si algo es seguro, estas propiedades y si están intactas determinan una respuesta. Estas propiedades sustentan un objetivo clave: la fiabilidad. Además, la cuarta y quinta propiedades (privacidad y seguridad), están relacionadas con las tres primeras pero tienen enfoques ligeramente diferentes.

Confidencialidad

Un sistema sólo tiene la propiedad de la confidencialidad si garantiza el acceso a los datos que le confía exclusivamente a quienes tienen los derechos adecuados, en función de su necesidad de conocer la información protegida. Un sistema que no tenga una barrera que impida el acceso no autorizado no salvaguarda la confidencialidad.¹⁴

Integridad

Existe integridad cuando puede verificarse la autenticidad de los datos o las operaciones y los datos o la funcionalidad no han sido modificados o convertidos en no auténticos mediante una actividad no autorizada.¹⁵

Disponibilidad

Disponibilidad significa que los actores autorizados pueden acceder a las funciones y/o datos del sistema siempre que tengan la necesidad o el deseo de hacerlo. En determinadas circunstancias, los datos o las operaciones de un sistema pueden no estar disponibles como resultado de un contrato o acuerdo entre los usuarios y los operadores del sistema (como que un sitio web esté inactivo por mantenimiento periódico); si el sistema no está disponible debido a una acción maliciosa de un adversario, la disponibilidad se habrá visto comprometida.¹⁶

Privacidad

Mientras que la confidencialidad se refiere al acceso controlado a la información privada compartida con otros, la privacidad se refiere al derecho a que esa información no quede expuesta a terceros no autorizados. Muchas veces, cuando la gente habla de confidencialidad, en realidad espera privacidad, pero aunque los términos suelen utilizarse indistintamente, no son el mismo concepto. Se podría argumentar que la confidencialidad es un requisito previo de la privacidad. Por ejemplo, si un sistema no puede garantizar la confidencialidad de los datos que almacena, ese sistema nunca podrá proporcionar privacidad a sus usuarios.

Seguridad

La seguridad es "la ausencia de riesgos inaceptables de lesiones físicas o de daños para la salud de las personas, ya sea directamente, o indirectamente como consecuencia de daños a la propiedad o al Medio Ambiente".¹⁷ Naturalmente, para que algo cumpla los requisitos de seguridad, tiene que funcionar de forma predecible. Esto significa que, como mínimo, debe mantener las propiedades de seguridad de integridad y disponibilidad.

Controles fundamentales

Los siguientes controles, o comportamientos y capacidades funcionales, apoyan el desarrollo de sistemas altamente seguros.

Identificación

A los actores de un sistema se les debe asignar un identificador único significativo para el sistema. Los identificadores también deben ser significativos para los individuos o procesos que consumirán la identidad (por ejemplo, el subsistema de autenticación; la autenticación se describe a continuación).

Un actor es cualquier cosa en un sistema (incluidos los usuarios humanos, las cuentas del sistema y los procesos) que tiene influencia sobre el sistema y sus funciones, o que desea acceder a los datos del sistema. Para apoyar muchos objetivos de seguridad, a un actor se le debe conceder una identidad antes de que pueda operar en ese sistema. Esta identidad debe ir acompañada de información que permita a un sistema identificar positivamente al actor o, en otras palabras, que permita al actor mostrar una prueba de identidad al sistema. En algunos sistemas públicos, también se identifica a los actores o usuarios anónimos, lo que indica que su identidad concreta no es importante, pero sigue estando representada en el sistema.

Consejo

Invitado es una identidad aceptable en muchos sistemas como cuenta compartida. Pueden existir otras cuentas compartidas, aunque el uso de cuentas compartidas debe considerarse cuidadosamente, ya que carecen de la capacidad de rastrear y controlar el comportamiento de los actores de forma individual.

Autenticación

Los actores con identidad necesitan demostrar su identidad al sistema. La identidad suele probarse mediante el uso de una credencial (como una contraseña o un token de seguridad).

Todos los actores que deseen utilizar el sistema deben poder proporcionar satisfactoriamente una prueba de su identidad para que el sistema de destino pueda verificar que se está comunicando con el actor correcto. La autenticación es un requisito previo para las capacidades de seguridad adicionales.

Autorización

Una vez que se ha autenticado a un actor -es decir, se ha demostrado satisfactoriamente su identidad-, se le pueden conceder privilegios dentro del sistema para realizar operaciones o acceder a funcionalidades o datos. La autorización es contextual y puede ser, aunque no es obligatorio, de naturaleza transitiva, bidireccional o recíproca.

Con la autenticación llega la capacidad de que un sistema, basándose en la prueba de identificación ofrecida por un actor, especifique los derechos de ese actor. Por ejemplo, una vez que un usuario se ha autentificado en un sistema y se le permite realizar operaciones en una base de datos, el acceso a esa base de datos se concede basándose únicamente en los derechos del actor. El acceso suele concederse en términos de operaciones primitivas como read, write, o execute. Los esquemas de control de acceso que rigen el comportamiento de un actor dentro de un sistema incluyen los siguientes:

Control de acceso obligatorio (MAC)

El sistema limita las autorizaciones de los actores.

Control de acceso discrecional (CAD)

Los actores pueden definir privilegios para las operaciones.

Control de acceso basado en roles (RBAC)

Los actores se agrupan por "roles" significativos, y donde los roles definen las asignaciones de privilegios.

Control de acceso basado en capacidades

Un subsistema de autorización asigna derechos mediante fichas que los actores deben solicitar (y recibir) para realizar operaciones.

Consejo

Las cuentas de invitado no suelen autenticarse (no hay identidad que demostrar), pero estas cuentas de pueden autorizarse explícitamente con un nivel mínimo de capacidad.

Registro

Cuando un actor (humano o proceso) realiza una operación del sistema, como ejecutar una función o acceder a almacenes de datos, debe registrarse un registro de ese evento. Esto favorece la trazabilidad. La trazabilidad es importante cuando se intenta depurar un sistema; cuando los eventos registrados se consideran relevantes para la seguridad, la trazabilidad también respalda la capacidad de realizar tareas críticas como la detección y prevención de intrusiones, el análisis forense y la recogida de pruebas (en el caso de que un actor malicioso se inmiscuya en un sistema).

Auditoría

El registro crea registros; los registros de auditoría están bien definidos (en formato y contenido), ordenados en el tiempo, y suelen ser resistentes a la manipulación (o al menos evidentes). La capacidad de "mirar atrás en el tiempo" y comprender el orden en que ocurrieron los hechos, quién realizó qué operaciones y cuándo, y opcionalmente determinar si las operaciones fueron correctas y autorizadas, es fundamental para las operaciones de seguridad y las actividades de respuesta a incidentes.

Patrones básicos de diseño para sistemas seguros

Cuando diseñes un sistema, debes tener en cuenta ciertos principios y metodologías de seguridad. Puede que no todos los principios se apliquen a tu sistema. Pero es importante que los tengas en cuenta para asegurarte de que son válidos si se te aplican.

En 1975 se publicó un artículo fundamental de Jerome Saltzer y Michael Schroeder, "La protección de la información en los sistemas informáticos".¹⁸ . Aunque han cambiado muchas cosas desde su publicación, los principios básicos siguen siendo aplicables. Algunos de los fundamentos que tratamos en este libro se basan en los principios expuestos por Saltzer y Schroeder. También queremos mostrarte cómo algunos de esos principios se han hecho relevantes de formas distintas a las previstas originalmente.

Confianza cero

Un enfoque habitual del diseño de sistemas, y del cumplimiento de la seguridad, es "confiar, pero verificar", o confianza cero, que consiste en asumir el mejor resultado para una operación (como que un dispositivo se una a una red, o que un cliente llame a una API) y luego realizar una verificación de la relación de confianza de forma secundaria. En un entorno de confianza cero, el sistema ignora (o nunca establece) ninguna relación de confianza previa y, en su lugar, verifica todo antes de decidir establecer una relación de confianza (que puede ser temporal).¹⁹

También conocido como mediación completa, este concepto parece asombrosamente sencillo sobre el papel: garantizar que los derechos de acceso a una operación se comprueban cada vez que se accede a un objeto, y que los derechos para esa operación de acceso se comprueban de antemano. En otras palabras, debes verificar que un actor tiene los derechos adecuados para acceder a un objeto cada vez que se solicita ese acceso.

Nota

John Kindervag creó el concepto de confianza cero en 2010,²⁰ y se ha aplicado comúnmente a los debates sobre la arquitectura del perímetro de la red. Los autores decidieron importar el concepto a los principios de seguridad, y creen que también se aplica sin modificaciones a las decisiones de seguridad que deben producirse a nivel de aplicación.

Diseño por contrato

El diseño por contrato está relacionado con la confianza cero, y supone que siempre que un cliente llama a un servidor, la entrada procedente de ese cliente tendrá un determinado formato fijo y no se desviará de ese contrato.

Es similar al paradigma de la cerradura y la llave. Tu cerradura sólo acepta la llave correcta y no confía en nada más. En "Securing the Tangled Web" (Proteger la Web enmarañada)²¹ Christoph Kern explica cómo Google ha reducido significativamente la cantidad de fallos de cross-site scripting (XSS) en las aplicaciones mediante el uso de una biblioteca de llamadas a API inherentemente seguras: el diseño por contrato. El diseño por contrato aborda la confianza cero garantizando que cada interacción siga un protocolo fijo.

Menor privilegio

Este principio significa que una operación debe ejecutarse utilizando sólo el nivel de privilegio más restrictivoque aún permita que la operación tenga éxito. En otras palabras, en todas las capas y en todos los mecanismos, asegúrate de que tu diseño constriñe al operador al nivel mínimo de acceso necesario para realizar una operación individual, y nada más.

Si no se respetan los mínimos privilegios, una vulnerabilidad en una aplicación podría ofrecer acceso completo al sistema operativo subyacente, y con ello todas las consecuencias de que un usuario privilegiado tenga acceso sin restricciones a tu sistema y a tus activos. Este principio se aplica a todo sistema que mantenga un contexto de autorización (por ejemplo, un sistema operativo, una aplicación, bases de datos, etc.).

Defensa en profundidad

La defensa en profundidad utiliza un enfoque multifacético y por capas para defender un sistema y sus activos.

Cuando pienses en la defensa de tu sistema, piensa en las cosas que quieres proteger -los activos- y en cómo podría intentar acceder a ellas un atacante. Considera qué controles podrías establecer para limitar o impedir el acceso de un adversario (pero permitir el acceso de un actor debidamente autorizado). Podrías considerar capas paralelas o superpuestas de controles para ralentizar al atacante; alternativamente, podrías considerar implementar características que confundan o disuadan activamente a un adversario.

Algunos ejemplos de defensa en profundidad aplicada a los sistemas informáticos son los siguientes:

• Defender un puesto de trabajo específico con cerraduras, guardias, cámaras y dispositivos de ventilación

• Introduciendo un host bastión (o cortafuegos) entre el sistema y la Internet pública, y luego un agente de punto final en el propio sistema

• Utilizar la autenticación multifactor para complementar un sistema de contraseñas para la autenticación, con un retardo de tiempo que aumenta exponencialmente entre intentos fallidos

• Implementación de un honeypot y una capa de base de datos falsa con funciones de validación de autenticación limitadas intencionadamente por prioridad

Cualquier factor adicional que actúe como un "obstáculo en el camino" y haga que un ataque sea más costoso en términos de complejidad, dinero y/o tiempo es una capa exitosa en tu defensa en profundidad. Esta forma de evaluar las medidas de defensa en profundidad está relacionada con la gestión de riesgos de : defensa en profundidad no siempre significa defensa a toda costa. Se produce un acto de equilibrio entre decidir cuánto gastar para asegurar los activos frente al valor percibido de esos activos, lo que entra en el ámbito de la gestión de riesgos.

Simplificar las cosas

Mantener las cosas sencillas consiste en evitar la sobreingeniería de tu sistema. Con la complejidad viene el mayor potencial de inestabilidad, retos en el mantenimiento y otros aspectos del funcionamiento del sistema, y un potencial de controles de seguridad ineficaces.²²

También hay que tener cuidado para evitar la simplificación excesiva (como omitir o pasar por alto detalles importantes). A menudo esto ocurre en la validación de entradas, ya que suponemos (correctamente o no) que un generador de datos ascendente siempre proporcionará datos válidos y seguros, y evitamos (incorrectamente) nuestra propia validación de entradas en un esfuerzo por simplificar las cosas. Para un debate más extenso sobre estas expectativas, véase el trabajo de Brook S. E. Schoenfield sobre los contratos de seguridad.²³ Al fin y al cabo, un diseño limpio y sencillo, en lugar de uno sobredimensionado, a menudo proporcionará ventajas de seguridad con el tiempo, y debe dársele preferencia.

Sin salsa secreta

No confíes en la oscuridad como medio de seguridad. El diseño de tu sistema debe ser resistente a los ataques aunque se conozcan y publiquen todos y cada uno de los detalles de su implementación. Fíjate, esto no significa que tengas que publicarlo,²⁴ y los datos sobre los que opera la implementación deben permanecer protegidos; sólo significa que debes suponer que se conoce cada detalle, y no confiar en que ninguno de ellos se mantenga en secreto como forma de proteger tus activos. Si pretendes proteger un activo, utiliza el control correcto: cifrado o hashing; ¡no esperes que un actor no identifique o descubra tus secretos!

Separación de privilegios

También conocido como separación de funciones, este principio significa segregar el acceso a la funcionalidad o a los datos dentro de tu sistema, de modo que un actor no posea todos los derechos. Entre los conceptos relacionados se incluye el de creador/comprobador, en el que un usuario (o proceso) puede solicitar que se produzca una operación y establecer los parámetros, pero se requiere que otro usuario o proceso autorice que la operación se lleve a cabo. Esto significa que una sola entidad no puede realizar actividades maliciosas sin impedimentos o sin la oportunidad de supervisión, y eleva el listón para que se produzcan acciones nefastas.

Considera el factor humano

Se ha dicho que los usuarios humanos son el eslabón más débil de cualquier sistema ,²⁵ por lo que el concepto de aceptabilidad psicológica debe ser una restricción básica del diseño. Los usuarios que se sientan frustrados por las fuertes medidas de seguridad intentarán inevitablemente encontrar formas de eludirlas.

Al desarrollar un sistema seguro, es crucial decidir cuánta seguridad será aceptable para el usuario. Hay una razón por la que tenemos la autenticación de dos factores y no la de dieciséis. Pon demasiados obstáculos entre un usuario y el sistema, y se producirá una de estas situaciones:

• El usuario deja de utilizar el sistema.

• El usuario encuentra soluciones para eludir las medidas de seguridad.

• El poder deja de apoyar la decisión de seguridad porque perjudica la productividad.

Registro eficaz

La seguridad no consiste sólo en evitar que ocurran cosas malas, sino también en ser consciente de que algo ha ocurrido y, en la medida de lo posible, de qué ha ocurrido. La capacidad de ver lo que ha pasado viene de poder registrar eficazmente los sucesos.

Pero, ¿en qué consiste un registro eficaz? Desde el punto de vista de la seguridad, un analista de seguridad debe ser capaz de responder a tres preguntas:

• ¿Quién realizó una acción concreta para que se registrara un suceso?

• ¿Cuándo se realizó la acción o se registró el acontecimiento?

• ¿A qué funcionalidad o datos accedió el proceso o el usuario?

El no repudio, que está estrechamente relacionado con la integridad, significa tener un conjunto de transacciones que indiquen quién hizo qué, y que el registro de cada transacción mantenga la integridad como propiedad. Con este concepto, es imposible que un actor afirme que no realizó una acción concreta.

Advertencia

Tan importante como saber qué registrar y cómo protegerlo es saber qué no registrar. En particular:

• La información personal identificable (IPI) nunca debe registrarse en texto plano, para proteger la privacidad de los datos de los usuarios.

• El contenido sensible que forma parte de las llamadas a la API o a funciones nunca debe registrarse.

• Las versiones en texto claro del contenido encriptado tampoco deben registrarse.

• Los secretos criptográficos, como la contraseña de un sistema o una clave utilizada para descifrar datos, no deben registrarse.

Utilizar el sentido común es importante aquí, pero ten en cuenta que evitar que estos registros de se integren en el código es una batalla continua contra las necesidades del desarrollo (principalmente la depuración). Es importante dejar claro a los equipos de desarrollo que es inaceptable tener interruptores en el código que controlen si el contenido sensible debe registrarse con fines de depuración. El código desplegable y listo para la producción no debe contener funciones de registro de información sensible.

Falla seguro

Cuando un sistema se encuentra con una condición de error, este principio significa no revelar demasiada información a un adversario potencial (como en registros o mensajes de error de usuario) y no conceder simplemente el acceso de forma incorrecta, como cuando el fallo está en el subsistema de autenticación.

Pero es importante entender que hay una diferencia significativa entre el fallo seguro y el fallo a prueba de fallos. Fallar manteniendo la seguridad puede contradecir la condición de fallar con seguridad, y habrá que conciliarlo en el diseño del sistema. Cuál de las dos es la adecuada en una situación determinada, por supuesto, depende de las particularidades de la situación. A fin de cuentas, fallar con seguridad significa que si un componente o la lógica del sistema falla, el resultado sigue siendo seguro.

Integrar, no atornillar

La seguridad, la privacidad y la protección deben ser propiedades fundamentales del sistema, y cualquier característica de seguridad debe incluirse en el sistema desde el principio .²⁶

La seguridad, al igual que la privacidad o la seguridad, no debe considerarse una ocurrencia tardía ni depender única o principalmente de la presencia de componentes externos del sistema. Un buen ejemplo de este patrón es la implementación de comunicaciones seguras; el sistema debe soportarlo de forma nativa, es decir, debe estar diseñado para soportar Transport Layer Security (TLS) o un método similar para preservar la confidencialidad de los datos en tránsito. Confiar en que el usuario instale sistemas de hardware especializados para habilitar la seguridad de las comunicaciones de extremo a extremo significa que, si el usuario no lo hace, las comunicaciones quedarán desprotegidas y potencialmente accesibles a actores malintencionados. No des por sentado que los usuarios actuarán en tu nombre cuando se trate de la seguridad de tu sistema.

Resumen

Después de leer esta Introducción, deberías tener todos los conocimientos básicos que necesitas para sacar el máximo partido a los capítulos que siguen: los fundamentos del modelado de amenazas y cómo encaja en el ciclo de vida de desarrollo del sistema, y todos los conceptos, terminología y principios de seguridad más importantes que son fundamentales para comprender la seguridad de tu sistema. Cuando realices el modelado de amenazas, buscarás estos principios de seguridad en el diseño de tu sistema para asegurarte de que está debidamente protegido frente a intrusiones o compromisos.

En el Capítulo 1 analizamos cómo construir representaciones abstractas del diseño de un sistema para identificar problemas de seguridad o privacidad. En capítulos posteriores, presentaremos metodologías específicas de modelado de amenazas que se basan en los conceptos de esta Introducción y en las técnicas de modelado del Capítulo 1 para realizar evaluaciones completas de amenazas a la seguridad utilizando la actividad de modelado de amenazas.

¡Bienvenido a bordo del tren de la seguridad!

¹ Esta frase está acreditada a Wilf Hey y al especialista del ejército William D. Mellin.

² "Un culto de carga es un sistema de creencias milenarista en el que los adeptos practican rituales que creen que harán que una sociedad tecnológicamente más avanzada entregue bienes". Wikipedia, consultado el 24/10/2020.

³ La pila LAMP está formada por el conjunto de sistema operativo Linux, servidor web Apache, base de datos MySQL y lenguaje de programación PHP.

⁴ La pila MEAN está formada por MongoDB, Express.js, Angular.js y Node.js.

⁵ Arvinder Saini, "¿Cuánto cuesta corregir los errores en cada fase del SDLC?", Software Integrity Blog, Sinopsis, enero de 2017, https://oreil.ly/NVuSf; Sanket, "Exponential Cost of Fixing Bugs", DeepSource, enero de 2019, https://oreil.ly/ZrLvg.

⁶ "¿Qué es la informática sin servidor?", Cloudflare, consultado en noviembre de 2020, https://oreil.ly/7L4AJ.

⁷ Isaac Sacolick, "¿Qué es CI/CD? Integración continua y entrega continua explicadas", InfoWorld, enero de 2020, https://oreil.ly/tDc-X.

⁸ Barry Boehm, Economía de la ingeniería de software (Prentice Hall, 1981).

⁹ Kayla Matthews, "¿Cuánto cuestan a la economía los hackeos de la IO?", IoT Para Todos, octubre de 2018, https://oreil.ly/EyT6e.

¹⁰ "¿Qué es WebAuthn?", Yubico, https://oreil.ly/xmmL9.

¹¹ Christoph Kern, "Preventing Security Bugs through Software Design", USENIX, agosto de 2015, https://oreil.ly/rcKL_.

¹² "Externo" es relativo cuando se utiliza aquí, y es específico de lo que se conoce como contexto de autorización; por ejemplo, el sistema operativo, la aplicación, las bases de datos, etc.

¹³ Algunos dicen que la DREAD ha dejado de ser útil; véase Irene Michlin, "Threat Prioritisation: DREAD Is Dead, Baby?", Grupo NCC, marzo de 2016, https://oreil.ly/SJnsR.

¹⁴ NIST 800-53 Revisión 4, "Controles de seguridad y privacidad para sistemas de información y organizaciones federales": B-5.

¹⁵ NIST 800-53 Revisión 4, "Controles de seguridad y privacidad para sistemas de información y organizaciones federales": B-12.

¹⁶ NIST 800-160 vol 1, "Ingeniería de seguridad de sistemas: Consideraciones para un enfoque multidisciplinar en la ingeniería de sistemas seguros dignos de confianza": 166.

¹⁷ "Seguridad funcional e IEC 61508", Comisión Electrotécnica Internacional, https://oreil.ly/SUC-E.

¹⁸ J. Saltzer y M. Schroeder, "La protección de la información en los sistemas informáticos", Departamento de Informática de la Universidad de Virginia, https://oreil.ly/MSJim.

¹⁹ "Arquitectura de Confianza Cero", Centro Nacional de Excelencia en Ciberseguridad, https://oreil.ly/P4EJs.

²⁰ Brook S. E. Schoenfield, experto en modelización de amenazas y prolífico autor, nos recuerda que la idea de "observar la desconfianza mutua" ya fue planteada por Microsoft en 2003-04, pero lamentablemente no hemos podido localizar una referencia. ¡Confiamos en Brook!

²¹ Christoph Kern, "Securing the Tangled Web", acmqueue, agosto de 2014, https://oreil.ly/ZHVrI.

²² Eric Bonabeau, "Comprender y gestionar el riesgo de complejidad", MIT Sloan Management Review, julio de 2007, https://oreil.ly/CfHAc.

²³ Brook S. E. Schoenfield, Secretos de un arquitecto de ciberseguridad (Boca Ratón, FL: CRC Press, 2019).

²⁴ Excepto cuando se utilizan licencias copyleft y proyectos de código abierto, claro.

²⁵ "Los humanos son el eslabón más débil de la cadena de seguridad de la información", Kratikal Tech Pvt Ltd, febrero de 2018, https://oreil.ly/INf8d.

²⁶ Algunas características o funcionalidades de seguridad pueden tener efectos negativos en la usabilidad, por lo que puede ser aceptable desactivar algunas capacidades de seguridad por defecto si los usuarios pueden activarlas al implementar el sistema.