4.1 Cimientos y cultura de la seguridad

Panorama y motivación

La seguridad no es una funcionalidad que se engarce al final del proceso, ni la responsabilidad exclusiva de un equipo especializado ajeno a la ingeniería. En una organización grande, la seguridad es una propiedad de cómo se diseña, se construye, se opera y se goberna el sistema en su conjunto. Cuando miles de ingenieros publican código en cientos de servicios, es el eslabón más débil el que determina hasta dónde puede llegar el daño de un incidente. Un único bucket de almacenamiento mal configurado, una dependencia sin parchear o una cuenta de servicio con privilegios excesivos pueden exponer millones de registros. Los cimientos y la cultura son lo que impide que eso ocurra a gran escala.

Para las empresas, las consecuencias son financieras y reputacionales: costos de una brecha, multas regulatorias, pérdida de clientes y devaluación del activo. Para el sector público, se extienden a la seguridad nacional, la confianza ciudadana y la continuidad de los servicios esenciales. Ambos contextos comparten una verdad incómoda: no se puede imponer la seguridad únicamente mediante controles y puntos de verificación. Debe ser internalizada por las personas que ejecutan el trabajo. Una cultura en la que los ingenieros comprenden las amenazas, sienten propiedad sobre lo que construyen y son reconocidos por plantear inquietudes produce resultados muy superiores a una que depende de un equipo de seguridad sobrecargado que actúa como portero en la línea de meta.

Este capítulo establece los modelos mentales y las prácticas culturales que sustentan cada uno de los demás capítulos de seguridad de esta guía. Aborda cómo hacer de la seguridad responsabilidad de todos, el modelado de amenazas, el ciclo de vida de desarrollo seguro, los principios arquitectónicos fundamentales como la defensa en profundidad y la confianza cero, y cómo priorizar el trabajo de seguridad según el riesgo real, no el miedo ni la moda.

Véase también: los capítulos 4.2 (seguridad de aplicaciones), 4.3 (seguridad de infraestructura y nube), 4.4 (operaciones de seguridad) y 4.6 (cumplimiento y gobierno) se sustentan en estos cimientos.

Principios fundamentales

La seguridad es responsabilidad de todos. Cada ingeniero, gestor de producto y operador es dueño de la seguridad de lo que construye. El equipo de seguridad habilita, asesora y audita; no puede (ni debe) asumir el trabajo por sí solo.
Asumir la brecha. Diseñen como si los atacantes ya estuvieran dentro. Minimicen lo que un componente comprometido puede alcanzar.
Defensa en profundidad. Ningún control aislado es suficiente. Apilen controles independientes de modo que la falla de uno no implique la falla de todos.
Menor privilegio. Otorguen el acceso mínimo necesario, durante el tiempo mínimo imprescindible, y revíquenlo automáticamente cuando ya no se requiera.
Desplazamiento a la izquierda. Detecten y corrijan los problemas lo antes posible, cuando resultan más baratos de resolver.
Priorización basada en el riesgo. Inviertan esfuerzo donde la combinación de probabilidad y impacto sea mayor, guiados por la tríada CIA (confidencialidad, integridad y disponibilidad), no por lo que apareció en las noticias esa semana.
Aprendizaje sin culpas. Tratemos los incidentes y los casi incidentes como oportunidades de aprendizaje, no como motivos para castigar.

Recomendaciones

Establecer un programa de defensores de seguridad

Integren un defensor de seguridad designado en cada equipo de ingeniería. Los defensores no son especialistas de tiempo completo en seguridad. Son ingenieros con formación adicional y una línea directa hacia el equipo central de seguridad. Revisan diseños, clasifican hallazgos, responden a las preguntas de sus compañeros y llevan el contexto de seguridad a las reuniones de planificación. Esto escala la expertise en seguridad en toda la organización sin tener que contratar un especialista para cada equipo, y genera confianza, porque el consejo llega de un par que conoce de verdad la base de código.

Bríndenles a los defensores un apoyo real: un foro periódico para compartir lo aprendido, presupuesto para formación y congresos, reconocimiento en las evaluaciones de desempeño y tiempo reservado en sus compromisos de entrega. Un programa de defensores que existe solo sobre el papel no produce nada.

Practicar el modelado de amenazas con regularidad

El modelado de amenazas es el hábito disciplinado de preguntarse «¿qué puede salir mal?» antes de construir. Háganlo para nuevos servicios, funcionalidades mayores y cualquier cambio en los límites de confianza. Manténganlo lo suficientemente ágil para que realmente se lleve a cabo con frecuencia.

STRIDE es una lista de verificación práctica mapeada a propiedades de seguridad: Suplantación de identidad (autenticación), Manipulación (integridad), Repudio (no repudio), Revelación de información (confidencialidad), Denegación de servicio (disponibilidad) y Elección de privilegios (autorización). Recorran cada flujo de datos y pregunten cómo se aplica cada categoría.
PASTA (Proceso de Simulación de Ataques y Análisis de Amenazas) es un método más riguroso, centrado en el riesgo, de siete etapas que vincula las amenazas técnicas con el impacto empresarial; úsese en sistemas de alto valor.
Árboles de ataque descomponen un objetivo («robar datos de clientes») en los pasos ramificados que un atacante emprendería, lo que ayuda a identificar y recortar rutas de explotación.

Mantengan los modelos de amenaza como documentos vivos junto al código y revísenlos cada vez que cambie la arquitectura.

Construir un ciclo de vida de desarrollo seguro

Tejan la seguridad en cada fase en lugar de tratarla como una verificación final:

Requisitos: capturen los requisitos de seguridad y privacidad junto a los funcionales.
Diseño: modelen las amenazas y revisen los límites de confianza.
Implementación: impongan estándares de codificación segura, revisión de código y detección de secretos en el control de versión.
Pruebas: ejecuten SAST (análisis estático de seguridad de aplicaciones), DAST (análisis dinámico de seguridad de aplicaciones) y escaneo de dependencias en la tubería (véase el capítulo 4.4).
Liberación: verifiquen la procedencia, firmen los artefactos y comprueben la configuración.
Operación: monitoreen, parcheen y respondan.

La intención del desplazamiento a la izquierda no es acumular toda la tarea en las etapas previas y abrumar a los ingenieros. Se trata de detectar los tipos de defecto que resultan infinitamente más caros de corregir después.

Adoptar los principios de arquitectura de confianza cero

La seguridad perimetral tradicional asume que todo lo que está dentro de la red es digno de confianza. Esa suposición se desploma en el instante en que un atacante consigue una posición. La confianza cero reemplaza la confianza implícita de la red por una verificación explícita y continua: autenticar y autorizar cada solicitud en función de la identidad, el estado del dispositivo y el contexto, sin importar de dónde provenga en la red. Combínenla con una identidad robusta, autorización de menor privilegio, microsegmentación y cifrado en todas partes. La confianza cero es un camino, no un producto, así que abórdenla paso a paso.

Priorizar por riesgo según la tríada CIA

Enmarquen todo activo y todo control en torno a la Confidencialidad, la Integridad y la Disponibilidad. No todos los datos requieren el mismo nivel de protección: una página de marketing pública y una base de datos con registros de salud tienen necesidades de confidencialidad radicalmente distintas. Clasifiquen sus activos, estimen la probabilidad y el impacto de una violación, y dirijan el esfuerzo de seguridad (siempre escaso) a las combinaciones de mayor riesgo. Documenten sus decisiones de riesgo para que otros puedan revisarlas y defenderlas más adelante.

Compromisos: ventajas e inconvenientes

Enfoque	Ventajas	Inconvenientes
Un equipo central de seguridad asume toda la responsabilidad	Profundidad de conocimiento, estándares homogéneos	Cuello de botella, desmotivación de los ingenieros, no escala
Seguridad distribuida (defensores)	Escala, fomenta el sentido de propiedad, retroalimentación más rápida	Exige inversión, nivel desigual de competencia, requiere coordinación
Modelado de amenazas extenso y previo para todo	Rigoroso, detecta fallos de diseño	Ralentiza la entrega, puede convertirse en un trámite burocrático
Modelado de amenaza ligero y dirigido por el riesgo	Rápido, enfocado en lo esencial	Puede pasar por alto amenazas en sistemas «de bajo riesgo»
Puntos de control estrictos que bloquean liberaciones	Impone el cumplimiento	Genera fricción, incentiva atajos

La tensión central es entre velocidad y garantía. Si se inclinan demasiado hacia los puntos de control y el control centralizado, crean una fricción que los ingenieros sortean, alimentando la TI sombra y el resentimiento. Si se inclinan demasiado hacia la autonomía sin soporte, obtienen una seguridad inconsistente y sin auditoría. La respuesta sostenible es una cultura sólida con guardarrails habilitadores: automatizado donde se pueda, humano donde se requiera juicio, y siempre explicado en lugar de simplemente impuesto.

Preguntas para debatir con su equipo

¿Qué sistemas merecen un modelado de amenazas extenso y quién decide la categoría? En un parque de sistemas amplio no se puede ejecutar un análisis PASTA de siete etapas en cada servicio, por lo que se necesita una regla explícita sobre cuándo basta un recorrido STRIDE de 30 minutos y cuándo un sistema de alto valor merece un modelado profundo guiado por el impacto empresarial. Ancre la decisión en su clasificación CIA: los sistemas que albergan datos regulados, flujos de pago o lógica de autenticación se ubican en la cima, y una página de marketing pública no. En el ámbito empresarial y gubernamental, un auditor exigirá que justifiquen por qué un sistema dado se modeló de la forma en que se modeló, así que redacten los criterios de categorización y nombren al responsable que los aplica. Lleven a la reunión su clasificación de activos actual y una lista de servicios sin modelo de amenazas, porque la distancia entre ambos es su riesgo real. Si no pueden acordar el umbral, terminarán modelando todo a la ligera o nada en profundidad, y ambas salidas los dejan en desventaja.
Cuando un defensor de seguridad y un plazo de entrega entran en colisión, ¿quién puede realmente frenar la liberación? Un programa de defensores solo cambia los resultados si el defensor tiene autoridad real, no solo formación adicional y buenas intenciones. Decidan de antemano si un defensor puede bloquear una liberación, si escala al equipo central de seguridad de aplicaciones y qué nivel de gravedad justifica detener la entrega frente a dejar el hallazgo en seguimiento. Esto importa más bajo presión, cuando un gestor de producto quiere eximir un defecto de diseño la semana antes del lanzamiento, que es justo cuando los defectos sin resolver resultan más caros de corregir. Traigan un ejemplo reciente en que una preocupación de seguridad se topó con un plazo y tracen quién decidió y cómo, porque esa historia revela su verdadero canal de escalado. Si la respuesta honesta es que la entrega siempre gana, sus defensores son decorativos y conviene corregir los incentivos antes de añadir más.
¿Qué cambia en concreto el principio de «asumir la brecha» en su próxima reunión de diseño? El principio es fácil de aplaudir y difícil de operar, así que anclen compromisos concretos: qué límites de confianza van a reforzar, dónde van a incorporar microsegmentación y cómo van a reducir lo que un único servicio comprometido puede alcanzar. Para un equipo grande, el beneficio es la reducción del alcance del impacto: que un atacante que se instale en un servicio no pueda pivotar hacia el almacén de datos que hay detrás. En entornos empresariales y gubernamentales, esto también condiciona sus decisiones sobre menor privilegio y credenciales de corta duración, que son baratas de diseñar y costosas de implementar a posteriori. Traigan un diagrama de un servicio real y pregunten qué haría un atacante tras tomar el control de la capa web, y comprométanse a dos cambios de contención este trimestre. Un acuerdo vago de que las brechas ocurren no vale nada si no mueve un permiso, una regla de red o un ciclo de vida de credencial.
¿Cómo sabrá que su cultura de seguridad realmente mejora, y cuál métrica defendería ante la junta directiva? Las tasas de finalización de formación y los conteos de tickets son fáciles de recopilar y casi inútiles, porque miden actividad y no reducción de riesgo, y en una organización grande se ahoga en ellos. Elijan métricas de resultado sobre las que realmente aposten presupuesto: tiempo mediano para resolver hallazgos de alta gravedad, proporción de servicios con un modelo de amenazas actualizado, fracción de incidentes detectados antes de producción y tasa de casi incidentes reportados espontáneamente, que debería crecer a medida que aumenta la confianza y no decrecer. La consideración contraria es que toda buena métrica puede manipularse, así que acompañen cada una con una métrica compensatoria y revisen la tendencia, no la instantánea. Traigan su panel actual y pregunten qué números cambiarían si la seguridad se deteriorara de verdad; los que no cambiarían son adorno. En entornos empresariales y gubernamentales, un regulador o un comité de auditoría pedirá evidencia de que los controles funcionan, así que elijan métricas que puedan defender bajo escrutinio, no solo las que se ven de verde.
¿Qué ocurre realmente la próxima vez que un ingeniero reporta un error, y su proceso es genuinamente sin culpas o solo lo es en la presentación? El aprendizaje sin culpas es el principio más profestado y menos vivido, porque el primer incidente serio pone a prueba si la dirección lo cree de verdad. Decidan de antemano cómo separan la responsabilidad de corregir un problema del castigo por haberlo causado, y quién lidera la revisión posterior al incidente para que se concentre en sistemas rotos y no en individuos nombrados. La tensión es real: las partes interesadas quieren a alguien responsable, pero castigar a quien reporta garantiza que el siguiente error se mantenga oculto hasta que se convierta en una brecha. Traigan sus dos últimas revisiones de incidentes y comprueben si culparon a una persona o a un control, y si el ingeniero que alzó la voz fue reconocido o quedó silenciado. En el sector público y los entornos regulados, las normas de divulgación obligatoria de brechas elevan aún más la posta, porque una cultura que oculta los errores también pasará por alto los plazos de notificación que conllevan sanciones legales.
¿Quién asume la fricción de sus herramientas de desplazamiento a la izquierda y están comprándolas, construyéndolas o ahogándose con ellas? El análisis estático y dinámico automatizado, el escaneo de dependencias y la detección de secretos son la columna vertebral de un ciclo de vida de desarrollo seguro, pero una tubería que inunda a los ingenieros con falsos positivos los enseña a ignorar la salida de seguridad, lo cual es peor que no escanear. Decidan quién ajusta las herramientas, quién clasifica los hallazgos y si adquieren una plataforma integrada o ensamblan analizadores de código abierto que luego tienen que mantener. Las consideraciones en tensión son cobertura frente a ruido y control frente a costo: un analizador barato que alerta sin fundamento quema la confianza que un programa de defensores tardó años en construir. Traigan su tasa actual de falsos positivos, el tiempo medio que los ingenieros esperan en una verificación bloqueante y la lista de equipos que han desactivado en silencio una verificación. En grandes empresas y en el sector público, añadan el ángulo de la adquisición y la proliferación de herramientas, porque diez equipos que compran su propio analizador generan una cobertura inconsistente que ningún auditor puede conciliar.

Perspectiva por sector

Startup. Sin equipo de seguridad y con poco capital, la cultura es el único control asequible. Hagan del modelado de amenazas de 30 minutos en pizarra un hábito antes de cualquier funcionalidad que toque la autenticación o los pagos, preguntando qué puede salir mal y quién lo desearía. Activen el menor privilegio y la autenticación multifactores en todas partes porque no cuestan nada, y mantengan un canal sin culpas donde cualquiera pueda plantear una inquietud sin miedo al reproche. Omitan procesos pesados y herramientas complejas; los ingenieros fundadores no pueden sostenerlos, y la disciplina que construyan ahora es la que permitirá que los compradores empresariales les confíen su inversión más adelante.

PyME. No cuentan con un especialista de seguridad dedicado y el presupuesto es ajustado, así que apoyen en los valores predeterminados seguros de las herramientas que ya adquieren en lugar de montar su propia tubería. Prefieran plataformas gestionadas que impongan la autenticación multifactores, los parches y el menor privilegio por sí mismas, y traten la seguridad como una cuestión de higiene de datos: sepan qué datos sensibles poseen y quién puede acceder a ellos. Cuando deban elegir entre construir o comprar, compren, porque un control gestionado que se mantiene actualizado supera a uno a medida que se deja obsoleto.

Empresa. A escala de cientos de servicios y miles de ingenieros, el desafío es la consistencia y el gobierno en muchos equipos. Ejecuten un programa de defensores de seguridad, estandaricen los niveles de modelado de amenazas vinculados a la clasificación CIA y ofrezcan plantillas de camino pavimentado y verificaciones automatizadas en la tubería para que cada equipo herede buenos valores por defecto. Trazen métricas de remediación y cobertura contra líneas base, y mantengan un rastro de auditoría que demuestre por qué cada sistema se modeló y controló de la manera en que se hizo.

Sector público. Las normas de contratación, las obligaciones de transparencia y la rendición de cuentas ante la ciudadanía condicionan cada decisión. Los principios de confianza cero y las credenciales de corta duración suelen estar mandatados por política ejecutiva, y se debe poder mostrar a un auditor una justificación documentada y basada en el riesgo sobre dónde se destinó el presupuesto de endurecimiento. Prioricen los sistemas que albergan los registros ciudadanos más sensibles, publiquen las salvaguardas donde el público tiene derecho a saber, y exijan a los proveedores que declaren sus limitaciones en lugar de aceptar cajas negras opacas.

Ejemplos

Startup. Una startup de diez personas no tiene equipo de seguridad ni presupuesto para uno, así que los dos ingenieros fundadores convierten el modelado de amenazas de 30 minutos en pizarra en un hábito previo a cualquier funcionalidad que afecte la autenticación o los pagos, preguntando qué puede salir mal y quién lo desearía. Adoptan unos cuantos hábitos fundamentales que no cuestan nada: menor privilegio en cada rol de la nube, autenticación multifactores en cada cuenta y un canal sin culpas donde cualquiera pueda plantear una inquietud sin temor al reproche. Cuando más adelante levantan una ronda de financiación y los compradores empresariales preguntan cómo manejan la seguridad, esa cultura temprana les permite responder con honestidad en lugar de improvisar una.

Empresa. Un banco global con 6 000 ingenieros ejecuta un programa de defensores de seguridad con un defensor formado por cuadrilla. Los defensores asisten a un gremio mensual, completan formación trimestral y lideran el modelado de amenazas para cada nuevo servicio con STRIDE. El equipo central de seguridad de aplicaciones mantiene plantillas de camino pavimentado y verificaciones automatizadas en la tubería. En dos años, el tiempo mediano para resolver hallazgos de alta gravedad bajó de 45 a 9 días, y el modelado de amenazas en fase de diseño detectó un defecto de autorización en una API de pagos antes de que llegara a producción, evitando un incidente que probablemente habría sido reportable.

Sector público. Una agencia tributaria nacional que moderniza sistemas heredados adopta los principios de confianza cero mandatados por política ejecutiva. Cada llamada entre servicios internos se autentica con credenciales de corta duración y se autoriza por solicitud; los segmentos de red ya no otorgan confianza. La agencia modela las amenazas de cada servicio orientado al ciudadano mediante árboles de ataque anclados en «exfiltrar registros de contribuyentes» y «alterar una declaración». La priorización basada en el riesgo, alineada con los niveles de impacto CIA, concentra el presupuesto de endurecimiento en los sistemas que albergan los registros más sensibles.

Justificación económica: motivaciones, retorno y costo total

El costo de construir una cultura de seguridad es real: tiempo de los defensores, formación, herramientas y el leve frenado que supone modelar amenazas y realizar revisiones. Pero ese costo es insignilfante frente al de no hacerlo. La brecha de datos mayor promedio se cuenta en millones una vez que se suman la investigación, la notificación, la remediación, las multas regulatorias, la exposición legal y los negocios perdidos. Las brechas en el sector público añaden la disrupción de la misión y la erosión de la confianza pública que ninguna factura captura del todo.

El retorno de la inversión en seguridad proviene de tres fuentes: incidentes evitados (la brecha que nunca ocurre), costo de remediación reducido (los defectos corregidos en diseño cuestan una fracción de los corregidos en producción) y entrega más rápida (los caminos pavimentados y las verificaciones automatizadas permiten a los equipos publicar con confianza en lugar de esperar una revisión manual). Al presentar el caso a la dirección, enmarquen la seguridad como gestión de riesgo con una etiqueta de precio, no como un bien abstracto. Muestren la pérdida esperada (probabilidad por impacto) de los riesgos más relevantes, el costo de reducirlas y el riesgo que persiste. Los ejecutivos financian la reducción de riesgo que pueden medir.

Antipatrones y trampas

Teatro de seguridad. Controles que impresionan visualmente pero no reducen ningún riesgo real, adoptados para satisfacer una auditoría y no para proteger nada.
El equipo de seguridad como puerta al final. Descubrir defectos de diseño la semana antes del lanzamiento, cuando son más caros de corregir y más propensos a ser perdonados.
Cultura de la culpa. Castigar al ingeniero que reporta un error garantiza que el siguiente se mantenga oculto.
Modelado de amenazas como casilla de verificación. Rellenar una plantilla que nadie lee, produciendo documentos ajenos a la arquitectura real.
Controles uniformes para todo. Aplicar el mismo proceso pesado a un sitio web público y a un sistema de pagos, desperdiciando esfuerzo y sembrando resentimiento.
Priorización guiada por el miedo. Persiguer la vulnerabilidad que está en boca de todos en lugar de la que realmente amenaza sus activos.
Defensores solo en el papel. Nombrar defensores sin darles tiempo, formación ni autoridad.

Modelo de madurez

Nivel 1: Iniciar. La seguridad es reactiva y centralizada. Las revisiones ocurren tarde, si es que ocurren, y no existe modelado de amenazas. Los incidentes generan correctivos a posteriori. Los ingenieros perciben la seguridad como el problema de otro, y no hay estándar compartido.

Nivel 2: Desarrollar. Existe un equipo de seguridad que define estándares, pero la práctica es inconsistente entre equipos. Algunos proyectos grandes tienen modelado de amenazas y otros ninguno. Se ofrece formación básica. La seguridad aún se percibe como una verificación, y el desplazamiento a la izquierda es aspiracional más que real.

Nivel 3: Estandarizar. Los defensores de seguridad están integrados en cada equipo. El modelado de amenazas es rutina para nuevos servicios, estratificado según la clasificación CIA, y el ciclo de vida de desarrollo seguro está documentado y se ejecuta en toda la organización. La priorización basada en el riesgo guía el trabajo, los estándares de codificación segura y las verificaciones en la tubería son el camino pavimentado por defecto, y las revisiones de incidentes sin culpas son la norma.

Nivel 4: Gestionar. Los resultados en seguridad se miden y se controlan contra líneas base. La organización traza el tiempo mediano para resolver hallazgos de alta gravedad, la cobertura de modelos de amenazas, la proporción de incidentes detectados antes de producción y las tasas de reporte de casi incidentes, desglosados por equipo. La autoridad del defensor para frenar una liberación está definida y se ejercita de hecho. Las decisiones de riesgo se cuantifican como probabilidad por impacto, se registran y se revisan con periodicidad, de modo que las brechas de control surgen como datos y no como sorpresas.

Nivel 5: Orquestar. La seguridad es genuinamente responsabilidad de todos y está integrada con la entrega, el riesgo y la planificación empresarial. El modelado de amenazas y el diseño seguro son hábitos ligeros, y los principios de confianza cero están en gran medida realizados. Las métricas impulsan la mejora continua, la organización aprende de los casi incidentes entre equipos, y los controles se adaptan automáticamente conforme cambian el panorama de amenazas y la arquitectura.

Ideas para la reflexión

¿Cómo se mide si una cultura de seguridad realmente mejora, más allá de contar finalizaciones de formación?
¿Dónde está el límite adecuado entre lo que manejan los defensores y lo que asume el equipo central?
¿Cómo se mantiene el modelado de amenazas valioso sin que se convierta en un trámite burocrático?
¿Es realista una arquitectura de confianza cero total para su parque heredado, y si no, cuál es el subconjunto pragmático?
¿Cómo debe priorizarse el trabajo de seguridad frente a la entrega de funcionalidades cuando ambos compiten por los mismos ingenieros?
¿Qué incentivos cambian de verdad el comportamiento del ingeniero hacia la propiedad sobre la seguridad?

Ideas clave

La seguridad es una propiedad cultural de las organizaciones grandes, no una tarea delegada a un solo equipo.
Los defensores de seguridad escalan la competencia y el sentido de propiedad en toda la ingeniería.
El modelado de amenazas (STRIDE, PASTA, árboles de ataque) expone los defectos de diseño de forma temprana y económica.
Un ciclo de vida de desarrollo seguro y la mentalidad de desplazamiento a la izquierda captan los defectos cuando cuestan menos.
La defensa en profundidad, el menor privilegio y la confianza cero son los principios arquitectónicos fundamentales.
La tríada CIA y la priorización basada en el riesgo dirigen el esfuerzo escaso a donde realmente importa.
El costo de construir una cultura de seguridad es mucho menor que el de las brechas que previene.

Referencias y lectura adicional

Adam Shostack, Threat Modelling: Designing for Security
Ross Anderson, Security Engineering: A Guide to Building Dependable Distributed Systems
Michael Howard y Steve Lipner, The Security Development Lifecycle
Betsy Beyer et al. (Google), Building Secure and Reliable Systems
National Institute of Standards and Technology, SP 800-207: Zero Trust Architecture
National Institute of Standards and Technology, Secure Software Development Framework (SSDF), SP 800-218
OWASP, guías de Threat Modelling y Security Champions