Cybersecurity Threats Pages ESP

Machine Translated by Google
amenazas de ciberseguridad,
Tendencias de malware y
Estrategias
Segunda edicion
Descubra estrategias de mitigación de riesgos para amenazas modernas

para su organización
tim lluvias
BIRMINGHAM—MUMBAI
Amenazas de ciberseguridad, tendencias de malware y estrategias

Segunda edicion
Copyright © 2023 Packt Publishing
Reservados todos los derechos. Ninguna parte de este libro puede reproducirse, almacenarse en un sistema de recuperación o transmitirse
de ninguna forma ni por ningún medio sin el permiso previo por escrito del editor, excepto en el caso de citas breves incrustadas en artículos
críticos o reseñas.
Se ha hecho todo lo posible en la preparación de este libro para garantizar la exactitud de la información presentada. Sin embargo, la
información contenida en este libro se vende sin garantía, ya sea expresa o implícita. Ni el autor, ni Packt Publishing ni sus comerciantes y
distribuidores serán responsables de los daños causados o presuntamente causados directa o indirectamente por este libro.
Packt Publishing se ha esforzado por proporcionar información de marcas registradas sobre todas las empresas y productos mencionados
en este libro mediante el uso apropiado de capitales. Sin embargo, Packt Publishing no puede garantizar la exactitud de esta información.
Gerente sénior de productos editoriales: Aaron Tanna
Editor de Adquisiciones – Peer Reviews: Gaurav Gavas
Editor del proyecto: Meenakshi Vijay
Editor de desarrollo de contenido: Liam Thomas Draper
Editor de textos: Safis Editing

Editor técnico: Aneri Patel
Corrector: Safis Editing
Indexador: Sejal Dsilva
Diseñador de la presentación: Rajesh Shirsath
Ejecutivo de marketing de relaciones con desarrolladores: Meghal Patel
Primera publicación: mayo de 2020
Segunda edición: enero de 2023
Referencia de producción: 1170123
Publicado por Packt Publishing Ltd.
Lugar de librea
Calle librea 35
Birmingham
B3 2PB, Reino Unido.
ISBN 9781804613672
www.packt.com
Prefacio
Ser un líder de seguridad en la actualidad es un poco como ponerse las máscaras de comedia y tragedia que se
ven en los cines. Algunos incidentes que surgen en los escritorios de los líderes de seguridad son comedias de
errores completamente evitables. Otras son tragedias que están completamente fuera del control de las empresas
víctimas, y no hay más remedio que reaccionar ante tales cosas. Me vienen a la mente las vulnerabilidades sin
parches y los problemas de seguridad de la cadena de suministro. Hay dos cosas, una que es muy prevenible con
los procesos o la tecnología correctos, y la otra en la que no tiene más remedio que responder a los efectos
posteriores. Con el volumen de ataques de productos básicos que golpean las infraestructuras cada segundo, los
CISO tienen poco o ningún margen de error. Sabiendo que no existe algo 100 % seguro, un programa de seguridad
debe abordar los riesgos más probables y de mayor impacto.
Con eso en mente, es fundamental encontrar la fuente más importante de vulnerabilidad y protegerse contra ella
repetidamente. Como CISO que ha llevado a cabo operaciones de seguridad para cuatro marcas importantes,
cada empresa tendrá desafíos únicos que influirán en su capacidad de respuesta, como su cultura, las limitaciones
de la industria o simplemente la resistencia al cambio. El trabajo del liderazgo en seguridad es luchar a través de
estas áreas de resistencia para lograr resultados alineados que logren la misión principal de mantener a la
empresa, los clientes y los empleados a salvo de un incidente cibernético.
Hay muchas herramientas a disposición de los líderes para hacer frente a estos desafíos. Descubrí que mi mejor
fuente de conocimiento es conectarme con compañeros que han pasado por los desafíos y problemas que he
enfrentado. El conocimiento táctil de una mesa redonda es inigualable en mi experiencia de lo que puede obtener
de cualquier sesión de conferencia o sala de capacitación. Esa es una de las razones por las que estoy tan
emocionado de ver las amenazas de ciberseguridad, las tendencias de malware y las estrategias revisadas por
Tim Rains. Tim ha estado en la mesa en más de este tipo de discusión que nadie.
Conozco a Tim Rains desde hace más de 12 años. La única persona que conoce tantos CISO como yo es Tim.
La carrera de Tim ha sido impulsada por escuchar problemas complejos de los líderes y centrarlos en soluciones
racionales. Tim ha tenido la ventaja de sentarse en mesas redondas con algunos de los mejores líderes en
seguridad de la industria. Combinando eso con posiciones de liderazgo en algunas de las compañías Fortune 500
más grandes, tiene una perspectiva única e informada. he tenido el placer de
ser parte de muchas de estas mesas redondas mientras mis compañeros luchan con algunos de los problemas
más desafiantes de la industria. En varios casos, no hay buenas respuestas y es una situación de mejor esfuerzo
debido a las limitaciones en la tecnología o las fuerzas de la industria.
Tim ha proporcionado algunas de sus mejores lecciones en este libro. Aporta todos sus años de conocimiento
de la industria e investigación en profundidad sobre temas que preocupan a los líderes de seguridad. Los CISO
necesitan ayuda para alinear su intención operativa con los objetivos estratégicos. Comenzar con un buen
conjunto de fundamentos es fundamental para tener un enfoque sólido y confiable para las amenazas
cibernéticas. Como se describe en el libro, los fundamentos son atacados continuamente por los sospechosos
habituales: sistemas sin parches, configuraciones incorrectas, ingeniería social, amenazas internas y contraseñas
débiles. Mi experiencia me ha enseñado que estos desafíos trascienden las industrias, los presupuestos y el
talento organizacional. Los CISO deben preguntarse qué partes de sus programas abordan estos desafíos
básicos y qué tan efectivos son esos programas. A partir de ahí, los CISO deben conectar los puntos de cómo
esos programas fundamentales respaldan las iniciativas estratégicas más importantes. Ninguna solución mágica
o servicio de consulta puede hacerlo por usted. Es dedicar tiempo a comprender los datos de apoyo y conectarse
con los líderes de su empresa. Tim brinda una excelente guía para acceder a los datos y hacerlos relevantes
para todos los líderes.
Este es un libro importante y oportuno sobre cómo los líderes pueden manejar la comedia y la tragedia de la
ciberseguridad. Lo que es crucial para los líderes es tener un enfoque definible para comprender su riesgo,
conocer las deficiencias de seguridad más comunes y comprender las estrategias para mitigar los impactos. Las
amenazas de seguridad cibernética, las tendencias de malware y las estrategias le brindarán las medidas de
seguridad que un CISO, CTO, CIO o líder senior en una organización necesitarán para comenzar. Para los
novatos en el lenguaje de la seguridad cibernética, en cada capítulo encontrará información sobre lo que importa
cuando se trata de proteger a su empresa, y esos veteranos experimentados verán un marco para probar teorías
sobre cómo abordar las amenazas. Las fuerzas en juego se multiplican para los líderes a medida que el malware
se duplica año tras año, los problemas regulatorios requieren mayores restricciones y crece la facilidad de los
ataques automatizados. Los líderes deben hacerse preguntas serias, como ¿conozco las amenazas que enfrenta mi organización?
¿Tengo respuestas apropiadas a esas amenazas? ¿ Existe un enfoque para mantenerse informado sobre las
tendencias impactantes de la industria? ¿Tengo una estrategia de ciberseguridad que se alinea con mi perfil de riesgo?
Si no conoce las respuestas a estas preguntas, este libro lo ayudará a comenzar el camino hacia la confianza en
sus futuras respuestas.
Timothy Youngblood, CISSP

Colaboradores
Sobre el Autor
Tim Rains es un ejecutivo, estratega, asesor y autor de ciberseguridad reconocido internacionalmente. Ha
ocupado los roles de asesor de seguridad cibernética más importantes tanto en Microsoft como en Amazon
Web Services. Tim tiene experiencia en múltiples disciplinas comerciales y de seguridad cibernética, incluida
la respuesta a incidentes, comunicaciones de crisis, gestión de vulnerabilidades, inteligencia de amenazas,
entre otras. Tim es actualmente vicepresidente de confianza y riesgo cibernético en TMobile. Tim es el
autor del popular libro Cybersecurity Threats, Malware Trends, and Strategies, publicado por Packt Publishing.
Quisiera agradecer a mi esposa, Brenda, por animarme a escribir una segunda edición de este libro y por su ayuda
y paciencia. Gracias Karen Scarfone por ser nuestra extraordinaria revisora técnica. También me gustaría
agradecer a Liam Draper, nuestro editor de desarrollo, ya todo el equipo de Packt Publishing por hacer realidad este libro.
Sobre el revisor
Karen Scarfone es la consultora principal de Ciberseguridad de Scarfone. Desarrolla publicaciones
de seguridad cibernética para agencias federales y otras organizaciones. Anteriormente fue
científica informática sénior en el Instituto Nacional de Estándares y Tecnología (NIST). Desde
2003, Karen es coautora de más de 100 publicaciones del NIST sobre una amplia variedad de
temas de ciberseguridad. Además , es coautora o colaboradora de 18 libros y ha publicado más
de 200 artículos sobre temas de ciberseguridad. Karen tiene maestrías en informática y redacción técnica.
Gracias a mi esposo, John, por todo.

Únete a nuestra comunidad en Discord

Únase al espacio Discord de nuestra comunidad para debatir con el autor y otros lectores:
https://packt.link/SecNet
Tabla de contenido
Prefacio xi
Capítulo 1 Introducción 1
Diferentes tipos de CISO: “The CISO Spectrum” 3
Cómo las organizaciones se ven comprometidas inicialmente y los fundamentos de ciberseguridad 6
Vulnerabilidades sin parchear • 6
Configuraciones erróneas de seguridad • 10
Credenciales débiles, filtradas y robadas • 11
Ingeniería social • 14
Amenazas internas • 15
Centrarse en los fundamentos de la ciberseguridad dieciséis
Comprender la diferencia entre las motivaciones y las tácticas de los atacantes 17
Resumen 20
Referencias 20
Capítulo 2: Qué saber sobre la inteligencia de amenazas 23
¿Qué es la inteligencia de amenazas?

24
¿De dónde provienen los datos de CTI? 24
Uso de inteligencia de amenazas 27
La clave para utilizar la inteligencia de amenazas • 31
Intercambio de inteligencia sobre amenazas 32
Protocolos para compartir CTI • 33

yo Tabla de contenido
Protocolo de Semáforo • 33
STIX y TAXII • 35
Razones para no compartir CTI • 37
Cómo identificar inteligencia creíble sobre ciberamenazas 38
Fuentes de datos • 38
Períodos de tiempo • 39
Reconocer la exageración • 40
Predicciones sobre el futuro • 41
Motivos de los vendedores • 41
Resumen .............................................................................................................................................................................................................................................................................................................................42
Referencias .............................................................................................................................................................................................................................................................................................................43
Capítulo 3: Uso de tendencias de vulnerabilidad para reducir riesgos y costos 45
Introducción .............................................................................................................................................................................................................................................................................................................46
Introducción a la gestión de vulnerabilidades 47
Fuentes de datos de divulgación de vulnerabilidades 57
Tendencias de divulgación de vulnerabilidades de la industria 58
Tendencias de vulnerabilidad de proveedores y productos • 68
Reducción de riesgos y costos: medición de la mejora de proveedores y productos • 71
Tendencias de vulnerabilidades de Microsoft • 74
Tendencias de vulnerabilidades de Oracle • 78
Tendencias de vulnerabilidades de Google • 79
Tendencias de vulnerabilidades de Debian • 82
Tendencias de vulnerabilidad de Apple • 83
Resumen de tendencias de vulnerabilidad de proveedores • 85
Tendencias de vulnerabilidad del sistema operativo • 88
Tendencias de vulnerabilidades de Google Android • 89
Tendencias de vulnerabilidad de Apple iOS • 91
Resumen del sistema operativo móvil • 93
Tendencias de vulnerabilidades de Microsoft Windows 10 • 93
Tendencias de vulnerabilidad de Apple macOS • 95

Tabla de contenido iii
Resumen del sistema operativo de escritorio • 97
Tendencias de vulnerabilidades de Ubuntu Linux • 98
Tendencias de vulnerabilidades del kernel de Linux • 99
Tendencias de vulnerabilidad de Microsoft Windows Server 2016 • 101
Resumen del sistema operativo del servidor • 102
Tendencias de las vulnerabilidades de los navegadores web • 103
Tendencias de vulnerabilidades de Apple Safari • 103
Tendencias de vulnerabilidades de Google Chrome • 104
Resumen del navegador web • 105
Resumen del marco de mejora de vulnerabilidades • 106

Guía de gestión de vulnerabilidades 108
Resumen 112
Referencias 113
Capítulo 4: La evolución del malware 119
Introducción 121
¿Por qué hay tanto malware en Windows en comparación con otras plataformas? 123
Fuentes de datos 125
La herramienta de eliminación de software malicioso • 125
Herramientas antimalware en tiempo real • 126
Fuentes de datos que no son de seguridad • 128
Acerca del software malicioso 129
Cómo se propagan las infecciones de malware • 130
troyanos • 131
Software potencialmente no deseado • 131
Exploits y kits de exploits • 133

Gusanos • 134
software de rescate • 137
Virus • 138
Modificadores del navegador • 139
Medición de la prevalencia del malware • 139

IV Tabla de contenido
Análisis global de infecciones de malware de Windows
Análisis regional de infecciones de malware de Windows 144
El panorama de las amenazas en Oriente Medio y África del Norte • 148
Boleta de calificaciones regional de 10 años para el Medio Oriente y África del Norte • 148
El panorama de amenazas en la Unión Europea y Europa del Este • 151
Informe regional de 10 años para la Unión Europea • 152
Boleta de calificaciones regional de 10 años para ubicaciones seleccionadas de Europa del Este • 155
El panorama de amenazas en ubicaciones seleccionadas de Asia y Oceanía • 156
Informe regional de 10 años para Asia y Oceanía • 158
El panorama de amenazas en ubicaciones seleccionadas en las Américas • 160
Boleta de calificaciones regional de 10 años para las Américas • 161
Conclusiones del análisis regional de infección de malware de Windows • 163
¿Qué significa todo esto para los CISO y los equipos de seguridad empresarial? • 164
Evolución global del malware 166
Conclusiones de la evolución global del malware • 172
La evolución del ransomware 173
Mecanismos de entrega • 177
Mecanismos de ejecución • 178
Métodos de pago del rescate • 179
Demandas de rescate y comunicaciones • 180
modelo de negocio • 181
El gran debate: ¿realmente valen la pena las soluciones antimalware? 183
Resumen .............................................................................................................................................................................................................................................................................................................................................
185
Referencias 186
Capítulo 5: Amenazas basadas en Internet 193
Introducción 193
Un ataque típico 194
Ataques de phishing 196
Mitigar el phishing • 203
Ataques de descargas no autorizadas 205

Tabla de contenido v
Mitigación de los ataques de descargas ocultas 208
Sitios de alojamiento de malware 209
Mitigación de la distribución de malware • 211
Compromiso posterior: botnets y ataques DDoS 212
Resumen 215
Referencias 216
Capítulo 6: Los roles que juegan los gobiernos en la ciberseguridad 221
La búsqueda de la felicidad 223
Los gobiernos como participantes en el mercado de la ciberseguridad 226
Los gobiernos como organismos de normalización 228
Los gobiernos como ejecutores 232
Reguladores • 232
Cumplimiento de la ley • 235
Los gobiernos como defensores 237
Seguridad ciudadana • 238
Seguridad nacional • 239
Militar • 241
Resumen 245
Referencias 245
Capítulo 7: Acceso del gobierno a los datos 249
Comprender el acceso del gobierno a los datos 252
El escenario de la inteligencia de señales • 252
El escenario del acceso ilegal del gobierno a los datos • 253
El escenario del acceso legal del gobierno a los datos • 254
Acceso legal del gobierno a los datos 255
La Ley CLOUD y la Ley PATRIOTA • 262
Gestión del riesgo de acceso gubernamental a los datos • 268
El volumen de solicitudes de aplicación de la ley • 272
La probabilidad de que las fuerzas del orden de EE. UU. accedan a los datos en la nube • 275
vi Tabla de contenido
El RGPD, FISA Sección 702 y Schrems II • 284

La probabilidad de que la inteligencia estadounidense acceda a los datos en la nube • 287
Mitigar el acceso del gobierno a los datos 293
Establecimiento y comprensión del alcance • 293
Establecer objetivos realistas • 294
Planificación de controles de protección de datos • 295
Conclusión 300
Resumen 301
Referencias 303
Capítulo 8: Ingredientes para una estrategia de ciberseguridad exitosa 309
¿Qué es una estrategia de ciberseguridad? 309
Otros ingredientes para una estrategia exitosa 314
Alineación de objetivos de negocio • 314
Visión, misión e imperativos de la ciberseguridad • 315

Alto ejecutivo y apoyo a la junta • 316
Comprender el apetito por el riesgo • 318
Visión realista de las capacidades actuales de ciberseguridad y el talento técnico • 319
Programa de cumplimiento y alineación del marco de control • 320
Una relación efectiva entre ciberseguridad y TI • 322

Cultura de seguridad • 324
Resumen .............................................................................................................................................................................................................................................................................................................................325
Referencias 326
Capítulo 9: Estrategias de ciberseguridad 327
Introducción 327
Medición de la eficacia de las estrategias de ciberseguridad 330
Estrategias de ciberseguridad 335
Estrategia de Protección y Recuperación 336
Puntaje CFSS • 339
Resumen de la estrategia Proteger y recuperar • 341

Tabla de contenido viii
Estrategia de protección de terminales 341
Resumen de la estrategia de protección de endpoints • 346
Control físico y habilitaciones de seguridad como estrategia de seguridad 347
Resumen de la estrategia de control físico y autorizaciones de seguridad • 354
El cumplimiento como estrategia de seguridad 355
Resumen de cumplimiento como estrategia de seguridad • 358
Estrategia centrada en la aplicación 359
Resumen de la estrategia centrada en la aplicación • 361
Estrategia centrada en la identidad 362
Resumen de la estrategia centrada en la identidad • 365
Estrategia centrada en datos 366
Resumen de la estrategia centrada en datos • 373
Estrategia centrada en el ataque 374
Resumen de la estrategia centrada en el ataque • 378
Confianza cero 379
Resumen de estrategias de ciberseguridad 386
DevOps y DevSecOps 388
Resumen ............................................................................................................................................................................................................................................................................................................................................. 391
Referencias 391
Capítulo 10: Implementación de la estrategia 395
Introducción 395
¿Qué es una cadena de eliminación de intrusos? 397

viii Tabla de contenido
Modernizando la Kill Chain 400
Mapeo de los sospechosos habituales de ciberseguridad • 401
Actualización de la matriz • 402

¿Cadena de eliminación de intrusos o ATT&CK? • 404
Primeros pasos 405
Madurez de las capacidades actuales de ciberseguridad • 406
Omnipresencia de las capacidades actuales de ciberseguridad • 407

¿Quién consume los datos? • 408
Renovaciones de licencias de ciberseguridad • 409
Implementación de esta estrategia 410
Racionalización de la matriz: brechas, inversiones insuficientes y inversiones excesivas • 412
Identificación de lagunas • 412
Identificación de áreas de inversión insuficiente • 413
Identificación de áreas de sobreinversión • 413
Planificación de su implementación • 414
Diseño de conjuntos de control 416
Fase de ataque – Reconocimiento I • 417
Controles de ejemplo para Reconnaissance I • 420
Perspectivas de ATT&CK • 421
Fase de ataque – Entrega • 422
Ejemplos de controles para Entrega • 425
Fase de ataque – Explotación • 427
Ejemplos de controles para Explotación • 429
Fase de ataque – Instalación • 432
Ejemplos de controles para la instalación • 434
Fase de Ataque – Mando y Control (C2) • 443
Ejemplos de controles para C2 • 445

Tabla de contenido ix
Fase de ataque – Reconocimiento II • 448
Controles de ejemplo para Reconnaissance II • 450
Fase de Ataque – Acciones sobre Objetivos • 453
Ejemplos de controles para acciones sobre objetivos • 454
Conclusión 458
Resumen ............................................................................................................................................................................................................................................................................................................................................. 459
Referencias 460
Capítulo 11: Medición del desempeño y la eficacia 463
Introducción 463
Uso de datos de gestión de vulnerabilidades 465
Activos administrados versus activos totales • 466
Vulnerabilidades conocidas sin parchear • 469
Vulnerabilidades sin parchear por gravedad • 471
Vulnerabilidades por tipo de producto • 472
Medición del rendimiento y la eficacia de una estrategia centrada en el ataque 474
Realización de reconstrucciones de intrusión • 475
Uso de los resultados de la reconstrucción de intrusiones • 484
Identificación de controles cojos • 485
Aprendiendo del fracaso • 487
Identificación de proveedores útiles • 487
Informando evaluaciones internas • 489
Emulaciones adversarias que aprovechan ATT&CK • 489
Resumen 491
Referencias 492
Capítulo 12: Enfoques modernos de seguridad y cumplimiento 495
Introducción 496
¿En qué se diferencia la computación en la nube? 497

X Tabla de contenido
Proveedores de servicios en la nube frente a proveedores de servicios gestionados • 499
Migración a la nube • 500

Cuestionarios de evaluación de ciberseguridad • 501
Cambios en el juego de seguridad y cumplimiento 502
El poder de las API • 503

Las ventajas de la automatización • 509
Mitigación de amenazas internas e ingeniería social • 509
Mitigación de vulnerabilidades sin parches • 512
Mitigación de errores de configuración de seguridad • 514
Mitigación de credenciales débiles, filtradas y robadas • 515
Cambios en el juego de la seguridad y el cumplimiento: resumen • 516
Uso de estrategias de ciberseguridad en la nube 516
Uso de la estrategia Protect and Recover en la nube • 517

El cumplimiento como estrategia de Ciberseguridad en la nube • 518
Uso de la estrategia centrada en ataques en la nube • 520
DevOps: un enfoque moderno de la seguridad en la nube • 522

Recuperación ante desastres en la nube • 526
Cifrado y gestión de claves 528
Conclusión 532
Resumen 533
Referencias 534
Otros libros que puede disfrutar 541
Índice 545
Prefacio
Imagina que estás en un submarino sumergido cientos de pies debajo de la superficie rodeado de agua oscura y
helada. El casco del submarino está bajo una inmensa presión constante desde todas las direcciones. Un solo
error en el diseño, construcción u operación del submarino significa un desastre para él y toda su tripulación.
Esto es análogo al desafío al que se enfrentan hoy en día los directores de seguridad de la información (CISO) y
sus equipos. Sus organizaciones están rodeadas en Internet por maldad que constantemente busca formas de
penetrar y comprometer sus infraestructuras de TI. Las personas en sus organizaciones reciben ola tras ola de
ataques de ingeniería social diseñados para engañarlos para que tomen decisiones de poca confianza que
socavarán los controles que han implementado sus equipos de seguridad. Los espectros del ransomware y las
violaciones de datos continúan acechando a los CISO, los directores de información (CIO) y los directores de
tecnología (CTO) de las organizaciones más sofisticadas del mundo.
Después de realizar cientos de investigaciones de respuesta a incidentes para los clientes

empresariales de Microsoft , publicar miles de páginas de información sobre amenazas y ayudar a
algunos de los clientes más grandes de Amazon Web Services (AWS) , he tenido la oportunidad de
aprender y asesorar literalmente a miles de empresas y organizaciones del sector público en casi
todos los países del mundo. Escribí este libro para compartir algunas de las ideas y lecciones que
aprendí durante este viaje extraordinario.
Los puntos de vista y las opiniones expresadas en este libro son mis propias opiniones personales y no las de mis
empleadores actuales o anteriores.
xi Prefacio
para quien es este libro

Los directores de seguridad de la información (CISO) y los aspirantes a CISO, los directores de seguridad (CSO),
los directores de tecnología (CTO), los directores de información (CIO), los profesionales de ciberseguridad, los
profesionales de cumplimiento y auditoría, la alta dirección de TI con responsabilidades de ciberseguridad, los
consultores y vendedores de servicios profesionales de ciberseguridad de los proveedores, los aficionados a la
informática interesados en la ciberseguridad y los estudiantes universitarios que aspiran a convertirse en
profesionales de la ciberseguridad se beneficiarán de la lectura de este libro.
Los lectores deben tener conocimientos básicos de tecnología de la información (TI), con cierta percepción de los desafíos
de TI en entornos de TI empresariales complejos y de gran escala. El conocimiento intermedio de las redes (redes TCP/
IP) y los principios de desarrollo de software, la experiencia en gestión de personas y los conocimientos sobre cómo
operan las organizaciones a escala empresarial en general, y el conocimiento de los conceptos básicos de ciberseguridad
también serían útiles.
Lo que cubre este libro

El Capítulo 1, Introducción, analiza las formas más comunes en que los entornos de TI empresariales se ven
comprometidos inicialmente y cómo mitigarlos. Esto lo preparará para evaluar las estrategias de seguridad
cibernética que están diseñadas para mitigar los intentos de intrusión (que se tratan en capítulos posteriores).
El Capítulo 2, Qué saber sobre la inteligencia de amenazas, explica qué es la inteligencia de amenazas, cómo
diferenciar la buena inteligencia de la mala y cómo la utilizan los equipos de ciberseguridad empresarial.
El Capítulo 3, Uso de tendencias de vulnerabilidades para reducir riesgos y costos, cubre qué son las vulnerabilidades de
seguridad, cómo se califican y las tendencias de divulgación de la industria a largo plazo entre los principales proveedores,
sistemas operativos y navegadores. Este capítulo también proporciona consejos y trucos para ejecutar un programa de
administración de vulnerabilidades empresariales y cómo se puede integrar la inteligencia de amenazas (tratada en el
Capítulo 2, Lo que debe saber sobre la inteligencia de amenazas) .
El Capítulo 4, La evolución del malware, proporciona una perspectiva única basada en datos de cómo ha evolucionado el
malware en todo el mundo durante los últimos 10 años o más. Esto lo ayudará a comprender los tipos de amenazas de
malware que enfrenta y qué amenazas de malware son más y menos frecuentes.
Prefacio XIII
Este capítulo también proporciona una inmersión profunda en la evolución del ransomware, la amenaza más temida para
los equipos de seguridad.
El Capítulo 5, Amenazas basadas en Internet, examina algunas de las formas en que los atacantes han estado usando
Internet y cómo estos métodos han evolucionado con el tiempo. Se examinan varios tipos de amenazas, incluidos los
ataques de phishing, los ataques de descarga oculta, los sitios de alojamiento de malware y los ataques de denegación de
servicio distribuido (DDoS).
El Capítulo 6, Los roles que juegan los gobiernos en la ciberseguridad, explica que muchos CISO confían en los gobiernos
para ayudarlos a lograr sus objetivos al establecer y regular los estándares de seguridad de la industria, mientras que otros
ven a los gobiernos como una fuente de inteligencia y orientación sobre amenazas, mientras que otros CISO ven a los
gobiernos como amenazas para sus organizaciones. ¿Qué papel juegan realmente los gobiernos en la ciberseguridad?
Este capítulo explora esta pregunta y lo ayuda a decidir si tratar a los gobiernos como amenazas.
Capítulo 7, Acceso gubernamental a los datos, muchos CISO y equipos de seguridad ven a los gobiernos como
amenazas para los datos de sus organizaciones. Esto es especialmente cierto en el caso de organizaciones
con sede fuera de los Estados Unidos. ¿Por qué es esto y qué saben ellos que tú no? Este capítulo examinará
la amenaza del acceso del gobierno a los datos y cómo mitigarla.
El Capítulo 8, Ingredientes para una estrategia de seguridad cibernética exitosa, analiza el desarrollo de una estrategia de
seguridad cibernética, que es necesaria, pero no una garantía de éxito en sí misma. Hay varios otros ingredientes que son
necesarios para un programa de ciberseguridad exitoso. Este capítulo describe cada uno de estos ingredientes en detalle.
Esto le dará la mejor oportunidad de éxito para su propia estrategia de ciberseguridad.
El Capítulo 9, Estrategias de ciberseguridad, evalúa críticamente las principales estrategias de

ciberseguridad que se han empleado en la industria durante los últimos 20 años, incluida Zero Trust. Este
capítulo le muestra cómo evaluar la eficacia de las estrategias de ciberseguridad.
El Capítulo 10, Implementación de la estrategia, proporciona un ejemplo de cómo implementar una de las mejores
estrategias de ciberseguridad. Este capítulo ilustra cómo se puede implementar una estrategia centrada en el ataque que
aprovecha la cadena de destrucción de intrusos y MITRE ATT&CK®.
El Capítulo 11, Medición del rendimiento y la eficacia, examina uno de los desafíos que siempre han
tenido los CISO y los equipos de seguridad: cómo medir la eficacia de sus programas de ciberseguridad.
Es difícil probar que algo malo no sucedió gracias al trabajo del equipo de seguridad cibernética; este capítulo brinda
orientación sobre cómo medir el desempeño y la efectividad de las estrategias de seguridad cibernética.
xiv Prefacio
El Capítulo 12, Enfoques modernos de la seguridad y el cumplimiento, proporciona información sobre cómo la nube es el gran
amplificador de talento en ciberseguridad. Este capítulo describe cómo se pueden aprovechar las interfaces de programación de
aplicaciones (API) y la automatización para respaldar una ciberseguridad altamente efectiva.
estrategia.
Para aprovechar al máximo este libro

• Ya comprenderá los conceptos básicos de TI y tendrá algo de experiencia en el uso, implementación y operación de sistemas y
aplicaciones de TI.
• Poseer algún conocimiento de los conceptos básicos de ciberseguridad hará que este libro sea más fácil
leer.
• La experiencia en la gestión de equipos empresariales de TI, cumplimiento y/o seguridad cibernética será útil, pero no es
estrictamente necesaria.
• Atraerá la curiosidad y el deseo de aprender sobre los aspectos clave de la ciberseguridad que los CISO y los CSO de las
grandes organizaciones manejan en el transcurso de su trabajo.
Descarga las imágenes a color

También proporcionamos un archivo PDF que tiene imágenes en color de las capturas de pantalla/diagramas utilizados en este libro.
Puede descargarlo aquí: https://packt.link/INq4w.
Convenciones utilizadas
Hay una serie de convenciones de texto utilizadas a lo largo de este libro.
CodeInText: indica palabras de código en texto, nombres de tablas de bases de datos, nombres de carpetas, nombres de archivos,
extensiones de archivos, nombres de rutas, direcciones URL ficticias, entrada de usuario y identificadores de Twitter. Por ejemplo:
“Los atacantes podrían registrarse y usar nombres de dominio en este ccTLD para atrapar a los usuarios de navegadores web que escriben
.om en lugar de .com”.
Cualquier fragmento de código se escribe de la siguiente manera:
función vacía ( índice int, valor int )

{
charbuf [4];
buf[índice] = valor;
}
Prefacio XV
Negrita: indica un nuevo término, una palabra importante o palabras que ve en la pantalla. Por ejemplo,
las palabras en los menús o cuadros de diálogo aparecen en el texto de esta manera. Por ejemplo:
"DevOps generalmente incluye conceptos como pruebas continuas, integración continua (CI), entrega
continua (CD), implementación continua y monitoreo continuo del rendimiento".
Las advertencias o notas importantes aparecen así.
Los consejos y trucos aparecen así.
Ponerse en contacto
Los comentarios de nuestros lectores es siempre bienvenido.
Comentarios generales: envíe un correo electrónico a feedback@packtpub.com y mencione el título del libro en el asunto de
su mensaje. Si tiene preguntas sobre cualquier aspecto de este libro, envíenos un correo electrónico a question@
packtpub.com.
Errata: Aunque hemos tomado todas las precauciones para garantizar la precisión de nuestro contenido, los errores ocurren.
Si ha encontrado un error en este libro, le agradeceríamos que nos lo informara.
Visite http://www.packtpub.com/submiterrata, haga clic en Enviar errata y complete el formulario.
Piratería: si encuentra copias ilegales de nuestros trabajos en cualquier forma en Internet, le agradeceríamos que nos
proporcionara la dirección de la ubicación o el nombre del sitio web. Póngase en contacto con nosotros en
copyright@packtpub.com con un enlace al material.
Si está interesado en convertirse en autor: si hay un tema en el que tiene experiencia y

está interesado en escribir o contribuir a un libro, visite
http://autores.packtpub.com.
xvi Prefacio
Comparte tus pensamientos

Una vez que haya leído Amenazas de ciberseguridad, tendencias y estrategias de malware, segunda edición, ¡ nos
encantaría escuchar sus opiniones! Haga clic aquí para ir directamente a la página de reseñas de Amazon de este
libro y compartir sus comentarios.
Su revisión es importante para nosotros y para la comunidad tecnológica y nos ayudará a asegurarnos de que
ofrecemos contenido de excelente calidad.
Descargue una copia gratuita en PDF de este libro

¡Gracias por comprar este libro!
¿Le gusta leer sobre la marcha pero no puede llevar sus libros impresos a todas partes?
¿La compra de su libro electrónico no es compatible con el dispositivo de su elección?
No se preocupe, ahora con cada libro de Packt obtiene una versión en PDF sin DRM de ese libro sin costo alguno.
Lea en cualquier lugar, en cualquier lugar, en cualquier dispositivo. Busque, copie y pegue el código de sus libros técnicos
favoritos directamente en su aplicación.
Las ventajas no terminan ahí, puede obtener acceso exclusivo a descuentos, boletines y excelente contenido gratuito en su
bandeja de entrada todos los días.
Siga estos sencillos pasos para obtener los beneficios:
1. Escanea el código QR o visita el siguiente enlace
https://packt.link/freeebook/9781804613672
2. Envía tu comprobante de compra
3. ¡Eso es todo! Le enviaremos su PDF gratuito y otros beneficios a su correo electrónico directamente
1
Introducción
Después de asesorar a miles de organizaciones del sector público y comercial en todo el mundo mientras
trabajaba como asesor de seguridad en Microsoft y luego en Amazon Web Services (AWS), llegué a la conclusión
de que la mayoría de las organizaciones no tienen una estrategia de ciberseguridad que sus ejecutivos de
seguridad o equipos de seguridad puedan articular. De hecho, pensando en todos los informes de seguridad que
brindé y las reuniones que tuve con ejecutivos y sus equipos durante las últimas dos décadas, recuerdo haber
conocido menos de 10 organizaciones que tenían una estrategia de ciberseguridad escrita que los directores de
seguridad de la información (CISO) podían describir y que los miembros del equipo de seguridad podían repetir.
En lugar de hablar sobre dominios de seguridad cibernética como la gestión de riesgos y la gestión de identidad y
acceso, me encontré asesorando a los CISO sobre estrategias de seguridad cibernética casi exclusivamente.
Esto no es sorprendente dado que hay muchas fuentes de información sobre todos los dominios de seguridad
cibernética descritos en varios marcos y certificaciones de la industria, pero la estrategia generalmente no se encuentra entre ellos.
Dado esto, decidí escribir un libro sobre estrategias de ciberseguridad para CISO, directores de información
(CIO), directores de tecnología (CTO), aspirantes a ejecutivos de ciberseguridad, equipos de ciberseguridad y
profesionales de tecnología de la información (TI) que tienen importantes responsabilidades de ciberseguridad.
Packt publicó Cybersecurity Threats, Malware Trends, and Strategies (Rains) en mayo de 2020. La respuesta al
libro en la industria fue muy positiva; Las estrategias de ciberseguridad continúan generando un interés
abrumador. Esta es una segunda edición actualizada de ese libro.
¿Por qué el tema de las estrategias de ciberseguridad despierta tanto interés? La ciberseguridad nunca ha sido
más importante para las empresas comerciales y las organizaciones del sector público. A medida que el mundo
se vuelve cada vez más dependiente de la tecnología e Internet, los actores de amenazas han florecido.
2 Introducción
Las economías del mundo dependen literalmente de la tecnología que opera constantemente, sin interrupciones.
Ninguna industria o geografía es inmune a los ciberataques.
En 2021, se estimó que la industria de la ciberseguridad global estaba valorada en alrededor de $ 140 mil millones.
Combine eso con una Tasa de Crecimiento Anual Compuesto (CAGR) estimada del 12% al 15% y esto da como
resultado un tamaño estimado del mercado de la industria de alrededor de $ 375 mil millones antes del final de esta década.
Cada vez más proveedores de seguridad cibernética se unen al coro para utilizar el espectro del "panorama de
amenazas en constante cambio" para comercializar y vender sus productos a organizaciones ansiosas y, a
veces, borrachas en todas las industrias. Lo que comenzó como un concepto relativamente simple de usar
computadoras para tomar decisiones comerciales más rápidas y potencialmente mejores ha llevado a una
proliferación de tecnologías, regulaciones y estándares que requieren un conjunto cada vez mayor de personas,
procesos y tecnologías para protegerlos.
Por ejemplo, cuando comencé a trabajar en Microsoft a finales de los 90, tenían pocos o ningún ingreso material
por el desarrollo y la venta de productos de ciberseguridad. En 2021, los ingresos del negocio de ciberseguridad
de Microsoft superaron los 10.000 millones de dólares (Jakkal, 2021). En 2016, pude guiar a los clientes a través
del modelo de referencia de seguridad relativamente grande y complicado de Microsoft en una sola diapositiva
de PowerPoint. Durante los siguientes cinco años, esto se convirtió en lo que ahora llaman " Arquitecturas de
referencia de ciberseguridad de Microsoft", que incluye no menos de nueve modelos de referencia diferentes
(Microsoft Corporation, 2021).
Cuando comencé a trabajar en AWS en 2017, tenían alrededor de 40 servicios en la nube en su cartera.
Cuando dejé AWS casi cuatro años y medio después, ofrecían más de 300 servicios en la nube y tenían una
cartera creciente de servicios de seguridad. Además de la introducción de nuevos servicios, los servicios
existentes se mejoraron constantemente y se amplió su funcionalidad. Muchos equipos de TI que se tomaron el
tiempo para evaluar los servicios de AWS antes de adoptarlos tendrían que volver a evaluarlos anualmente para
asegurarse de que aún los entendieran por completo.
Combine el crecimiento de solo estos dos proveedores con el crecimiento de otros proveedores importantes de
TI y nube (Oracle, IBM, Google, etc.) que las empresas también suelen aprovechar, y miles de proveedores de
seguridad cibernética que compiten por su negocio, y tiene muchas opciones , complejidad, ruido,
y confusión
Por supuesto, el telón de fondo de toda esta proliferación tecnológica, el crecimiento de la industria y la
complejidad es el constante redoble de los ataques de ciberseguridad exitosos. Las nuevas tecnologías también
han permitido a los atacantes aumentar la velocidad y el impacto de sus ataques. Las nuevas formas de realizar
grandes transacciones financieras internacionales han permitido a los atacantes crear modelos comerciales
sofisticados basados en la extorsión y el ransomware operado por humanos.
Capítulo 1 3
Si se saltó la lectura del prefacio de este libro (la analogía del submarino), léalo, ya que captura el entorno
presurizado en el que operan todas las empresas hoy en día.
Posteriormente, muchas de las organizaciones a las que asesoré a menudo hacían preguntas muy básicas.
¿Qué capacidades de ciberseguridad son más importantes? ¿Qué hacemos primero? ¿Cómo prioriza los
requisitos y las capacidades? ¿Qué están haciendo otras organizaciones en nuestra industria? ¿Tiene
inteligencia de amenazas de otras organizaciones en nuestra industria? ¿ Hay algún algoritmo que nos ayude
a determinar las prioridades correctas? Después de tener miles de estas discusiones y leer entre líneas, lo
que realmente me preguntaban era sobre una estrategia de ciberseguridad. La pregunta fundamental que me
hacían era: ¿ qué estrategia de seguridad cibernética o combinación de estrategias será más efectiva para
nuestra organización dada la industria en la que estamos, las ubicaciones donde hacemos negocios, nuestros
requisitos de cumplimiento normativo y el apetito por el riesgo que tiene nuestro negocio?
Escribí este libro con esta pregunta en mente; Espero que contenga algunas ideas que lo ayuden a responder
esta pregunta para su organización. Mencioné que escribí este libro para CISO, aspirantes a CISO y otros
profesionales que trabajan con CISO. ¿ Sabías que existen diferentes tipos de CISO? Si usted mismo es un
CISO, un miembro del equipo de seguridad que apoya a un CISO, un vendedor que intenta venderle a un
CISO o un miembro de una junta directiva a la que informa un CISO, comprender el tipo de CISO con el que
está trabajando puede ayudar a que la comunicación con ellos sea mucho más predecible, eficiente y quizás
incluso agradable.
Diferentes tipos de CISO: “The CISO Spectrum”

Después de pasar tanto tiempo con CISO durante las últimas dos décadas, puedo decirle con confianza que
existen diferentes tipos de CISO. Los diferentes tipos de CISO pueden tener diferentes enfoques de la
ciberseguridad que dictan, o al menos influyen fuertemente, en el enfoque de sus programas de seguridad.
Llamo a esta lista de tipos de CISO el "CISO Spectrum". Esta lista no es exhaustiva; simplemente contiene
los tipos de CISO que he encontrado en los últimos 20 años de mi carrera:
• Tipo 1: El Director de TI con responsabilidad en ciberseguridad. Eran quizás los más técnicos de todos
los tipos de CISO que encontré, por lo general tenían más experiencia en TI que en ciberseguridad.
Sabían todo sobre la infraestructura de TI que respaldaban y eran miembros confiables del equipo
de liderazgo de TI. Se les asignó ciberseguridad como parte de su función laboral. Tenían la aptitud
y el deseo de aprender sobre seguridad y cumplimiento, a veces simplemente por un sentido de
autopreservación. Su zona de confort eran los sistemas de TI, y estaban interesados en obtener
información y ayuda con la ciberseguridad.
4 Introducción
• Tipo 2: El Respondedor de Incidentes. Algunos de los CISO que conocí se convirtieron en CISO porque eran la persona a
quien acudir para responder a los incidentes de su organización. Se convirtieron en expertos en respuesta a incidentes
y remediación. Sus organizaciones confían en ellos durante las crisis y los buscan para ayudar a la organización a evitar
situaciones de crisis en el futuro. Solían ser expertos en inteligencia de amenazas y se centraban en dificultar el éxito
de los atacantes utilizando sus conocimientos técnicos. Tenían un profundo conocimiento de los sistemas de TI, ya que
normalmente participaban en su creación y administración al principio de su carrera.
• Tipo 3: El Experto en Cumplimiento o Auditoría. Estas personas tendían a centrarse en conjuntos de control que ayudaron a
cumplir con los estándares regulados y de la industria. Su experiencia en la gestión de programas de cumplimiento o
auditoría les dio una gran experiencia en la gestión de grandes conjuntos de control en entornos de TI grandes y
complejos que debían cumplir con múltiples estándares, como PCI, CMMC, NIST SP 80053, ISO 27000, etc. Prefieren
discutir los conjuntos de control y los desafíos de cumplimiento que las amenazas o los actores de amenazas.
• Tipo 4: El experto en políticas. Conocí dos tipos diferentes de CISO que confían en su fuerte
Antecedentes de la política:
• Expertos en políticas de Gobernanza, Riesgo y Cumplimiento (GRC) : estos CISO generalmente tenían mucha
experiencia en la redacción y aplicación de políticas relacionadas con GRC. Para hacer las cosas, se basaron
en las políticas de la misma manera que la policía se basa en las leyes.
• Expertos en políticas públicas de ciberseguridad: estos CISO generalmente no eran expertos en TI ni expertos en
ciberseguridad empresarial. Más bien, tendían a ser abogados con una profunda experiencia en políticas
públicas y privacidad. Tenían experiencia con las políticas nacionales de ciberseguridad, es decir, las políticas
de ciberseguridad que implementan los gobiernos nacionales o federales para proteger a los ciudadanos y
las organizaciones del sector público y privado.

dentro de sus fronteras.
• Tipo 5: El Estratega. Estos CISO tendían a centrarse en alinear los recursos en torno a los marcos. Para hacer esto,
requerían cierta experiencia en seguridad cibernética junto con cierta perspicacia empresarial. Muchas de estas
personas tenían experiencia en al menos un par de dominios de ciberseguridad diferentes, como Respuesta a incidentes
y Gestión de riesgos. Siempre estaban en busca de tecnologías o procesos que les ayudaran a abordar las brechas
conocidas en sus capacidades y mejorar la efectividad de sus estrategias.
• Tipo 6: El Experto en Riesgos. En mi experiencia, este tipo de CISO era más raro que el resto. Su área de especialización
era el riesgo. Abordaron la seguridad cibernética como un actuario utilizando cálculos de riesgo cuantitativos para
determinar áreas de inversión para su programa de seguridad cibernética.

Capítulo 1 5
Si no recuerdo mal, conocí a este tipo de CISO casi exclusivamente cuando asesoraba a compañías de seguros.
Siempre parecían informar al Director de Riesgos (CRO).
• Tipo 7: El Asesor de Ciberseguridad. Estos CISO se veían a sí mismos como asesores de los negocios que
apoyaban. Por lo general, su posición era que en realidad no eran "dueños" de nada , sino el negocio.
Aconsejaron a la empresa que hiciera inversiones en seguridad cibernética, pero no necesariamente diseñaron
y operaron las capacidades de seguridad cibernética ellos mismos, sino que lo haría el equipo de TI. Este tipo
de CISO generalmente pudo evitar el conflicto que naturalmente ocurre cuando hay tensión entre la libertad que
el negocio quiere y el control.
necesaria para defender los activos de la empresa. Muchos CISO de este tipo no creían que su función fuera
proporcionar supervisión, sino solo asesoramiento.
• Tipo 8: El Ejecutivo de Negocios de Confianza. Estos CISO no eran expertos en ciberseguridad y, a veces, tampoco
eran expertos en TI. Eran ejecutivos que habían demostrado su valía para el liderazgo empresarial al administrar
diferentes partes del negocio o proyectos o iniciativas particularmente difíciles o importantes. El liderazgo
confiaba en ellos debido a su historial de éxito en la empresa. Dado que habían demostrado que podían manejar
tareas desafiantes, se les dio seguridad cibernética para administrar. Estas empresas creían que estos CISO
tendrían éxito dada su capacidad de liderazgo y gestión, y que la experiencia en ciberseguridad no era un
requisito previo para el éxito. Muchos de los CISO que conocí en esta categoría
eran abogados.
Ese es el espectro CISO. Los tipos de CISO que analicé probablemente describen el 90 % de los miles de CISO que he
conocido. No veo a ninguno de ellos como mejor que los demás; simplemente tienen diferentes antecedentes y enfoques
de la ciberseguridad. Sin embargo, con frecuencia, los factores dentro de las organizaciones a las que apoyan los CISO
dictan el enfoque de ciberseguridad que adoptan, independientemente de sus antecedentes o preferencias personales.
Muchos CISO que conocí estaban frustrados porque querían ser un tipo específico de CISO mientras que sus
organizaciones exigían un tipo diferente. Demostrando una vez más que, incluso en la cima de una disciplina empresarial,
no siempre se puede obtener lo que se desea.
Aprendí a identificar el tipo de CISO que estaba asesorando lo más rápido posible para que la conversación fuera más
significativa para ambos. Por ejemplo, si un CISO estuviera realmente interesado en analizar cómo funciona un nuevo
exploit, sería una conversación corta y molesta tratar de analizar la gestión de riesgos con él. Por esta razón, muchos de
los equipos de ventas a los que apoyé en Microsoft y AWS se sintieron intimidados por los CISO de sus cuentas. Una vez
que aprendieron sobre CISO Spectrum, les resultó más fácil comprender a los CISO que apoyaban y conectarlos con las
personas y los recursos que realmente podrían abordar las cosas que más les interesaban.
6 Introducción
En la mayoría de los casos, esto ganaría cierta confianza con los CISO porque los vendedores se percibieron como útiles y no solo
interesados en las transacciones de ventas. Reconocer el tipo de CISO que apoya puede ayudarlo a convertirse en un asesor de
confianza para ellos.
A continuación, examinemos cómo los entornos de TI empresariales se ven comprometidos en primer lugar. Esto es clave para
comprender, desarrollar y evaluar la eficacia de las estrategias de ciberseguridad para los entornos de TI empresariales.
Cómo las organizaciones se ven comprometidas inicialmente y

los fundamentos de la ciberseguridad
La base de una estrategia de seguridad cibernética efectiva es lo que yo llamo los “fundamentos de seguridad cibernética ”. Se
requiere una base sólida para una estrategia exitosa. Los fundamentos de la ciberseguridad se basan en décadas de inteligencia de
amenazas que analizo en detalle más adelante en este libro. Después de realizar cientos de investigaciones de respuesta a incidentes
y estudiar la inteligencia de amenazas de Microsoft y otros proveedores durante más de una década, puedo decirle con confianza
que solo hay cinco formas en que las organizaciones se ven comprometidas inicialmente . Después del compromiso inicial, hay
muchas, muchas tácticas, técnicas y procedimientos (TTP) que los atacantes pueden usar para moverse lateralmente, robar
credenciales, comprometer la infraestructura, permanecer persistentes, obtener acceso ilícito a la información, destruir datos e
infraestructura, etc. Algunos de estos han existido durante décadas y otros son más nuevos y novedosos.
Las cinco formas en que las organizaciones se ven comprometidas inicialmente son lo que yo llamo la "seguridad cibernética".
Sospechosos de siempre":
1. Vulnerabilidades sin parchear
2. Configuraciones incorrectas de seguridad
3. Credenciales débiles, filtradas y robadas
4. Ingeniería social
5. Amenazas internas
Los fundamentos de la ciberseguridad son parte de una estrategia que se enfoca en mitigar los sospechosos habituales de la
ciberseguridad. Veamos cada uno de estos con más detalle, comenzando con la explotación de vulnerabilidades sin parchear.
Vulnerabilidades sin parchear

Una vulnerabilidad es una falla en el diseño del software o hardware y/o el código de programación subyacente que permite a un
atacante hacer que el sistema afectado haga algo que no estaba previsto.
Capítulo 1 7
Las vulnerabilidades más graves permiten a los atacantes tomar el control total del sistema afectado, ejecutando código
arbitrario de su elección. Las vulnerabilidades menos graves hacen que los sistemas divulguen datos de formas no
previstas o nieguen el servicio a usuarios legítimos. En el Capítulo 3, Uso de las tendencias de vulnerabilidad para
reducir el riesgo y los costos, ofrezco una inmersión profunda en la gestión de vulnerabilidades y algunas de las
tendencias clave de divulgación de vulnerabilidades en los últimos 20 años. Guardaré esa discusión en profundidad
para ese capítulo, pero proporcionaré más contexto aquí.
Los atacantes han estado utilizando vulnerabilidades para comprometer sistemas a gran escala desde al menos los días
de Code Red y Nimda en 2001. En 2003, SQL Slammer y Blaster interrumpieron con éxito Internet y comprometieron
cientos de miles de sistemas en todo el mundo al explotar vulnerabilidades sin parches en los sistemas operativos
Microsoft Windows. En los años posteriores a estos ataques, una industria artesanal desarrolló un esfuerzo continuo
para ayudar a las organizaciones empresariales, aquellas con los entornos más complejos, a inventariar sus sistemas
de TI, identificar vulnerabilidades en ellos, implementar mitigaciones para vulnerabilidades y parchearlas. A finales de
2022, se habían revelado más de 192 000 vulnerabilidades en productos de software y hardware de todo el sector,
registradas en la Base de datos nacional de vulnerabilidades (National Vulnerability Database, nd). Como leerá en un
capítulo posterior, la cantidad de vulnerabilidades reveladas en la industria aumentó un 128 % entre 2016 y 2017,
alcanzando niveles nunca antes vistos. La cantidad de divulgaciones de vulnerabilidades ha aumentado año tras año,
todos los años desde entonces, alcanzando más de 25,000 divulgaciones en 2022.
Una economía ha evolucionado en torno a la oferta y la demanda de vulnerabilidades y exploits, con una lista variada
de participantes que incluye proveedores, atacantes, defensores, diversas entidades comerciales , gobiernos y otros.
La cantidad de participantes en esta economía y su relativa sofisticación dificulta que las organizaciones se protejan de
la explotación de vulnerabilidades en sus entornos de TI al presionar los riesgos asociados. El uso de vulnerabilidades
sin parches es un pilar de los conjuntos de herramientas de los atacantes.
Las organizaciones que son altamente eficientes y competentes en la gestión de vulnerabilidades hacen que sea mucho
más difícil para los atacantes atacarlas con éxito. Un programa de gestión de vulnerabilidades bien ejecutado es un
componente fundamental y un requisito crítico de una estrategia de ciberseguridad eficaz.
Sin él, los esfuerzos de seguridad cibernética de las organizaciones fracasarán independientemente de las otras
inversiones que realicen. Este punto es lo suficientemente importante como para reiterarlo. Las vulnerabilidades sin
parches en los sistemas operativos y los componentes de la plataforma subyacente en los que se basan las capacidades
avanzadas de ciberseguridad permiten a los atacantes socavar por completo la eficacia de estas inversiones.
El hecho de no abordar de manera eficiente las divulgaciones de vulnerabilidades en curso en la "base informática
confiable" en la que se basan sus sistemas hace que no sea confiable.

8 Introducción
Un inventario preciso de todos los activos de TI es fundamental para un programa de gestión de vulnerabilidades. Las
organizaciones que no pueden realizar inventarios precisos y oportunos de todos sus activos de TI, escanear todos los activos de
TI en busca de vulnerabilidades y mitigar y/o parchear esas vulnerabilidades de manera eficiente, no deberían molestarse en hacer
otras inversiones hasta que esto se resuelva . Si su organización entra en esta categoría, vuelva a leer la sección del Prefacio de
este libro y recuerde la analogía del submarino que presenté. Si el CISO y los administradores del programa de administración de
vulnerabilidades confían en el grupo de TI de su organización u otros socios internos para proporcionar inventarios de activos de
TI, esos inventarios deben estar completos, no solo los inventarios de los sistemas que desean cumplir.
Los activos que no aparecen en los inventarios no se escanearán ni repararán y se convertirán en el eslabón débil de la cadena
de seguridad que intenta crear. Muy a menudo, esto está en contradicción con los objetivos de tiempo de actividad con los que se
miden las organizaciones de TI, porque parchear las vulnerabilidades aumenta la cantidad de reinicios del sistema y, en
consecuencia, reduce el tiempo de actividad incluso si todo va bien.
Mi consejo en escenarios donde los inventarios de activos son proporcionados por partes distintas al propio programa de gestión
de vulnerabilidades es confiar pero verificar. Dedique el esfuerzo y el presupuesto adicionales para comparar continuamente los
inventarios de activos con la realidad. Esto incluye los entornos de prueba y desarrollo oficiales y no oficiales que han sido
responsables de tantas infracciones en la industria a lo largo de los años. Shadow IT y las cuentas en la nube no oficiales también
entran en esta categoría.
Si las fuentes de los inventarios de activos resisten este requisito o no proporcionan inventarios precisos y oportunos , esto
representa el tipo de riesgo del que se debe informar a la junta directiva. Proporcionarles una vista del porcentaje estimado del
inventario total de activos actualmente no gestionado por su programa de gestión de vulnerabilidades debería dar como resultado
que las fuentes de inventarios de activos vuelvan a priorizar su trabajo y la interrupción de un statu quo peligroso.
Sugerencia: Los productos Cloud Access Security Brokers (CASB) y Attack Surface Management pueden
ayudar a identificar activos desconocidos y no autorizados. Hoy en día, la mayoría de las herramientas de
gestión de superficie de ataque se centran en activos externos (relacionados con Internet), pero la industria
está preparada para incluir activos internos en el alcance de las herramientas que se ofrecen.
Hablaré sobre la gestión de vulnerabilidades con más detalle en el Capítulo 3, Uso de tendencias de vulnerabilidad para reducir
riesgos y costos. También hablaré sobre la gestión de vulnerabilidades en el Capítulo 13, Enfoques modernos de seguridad y
cumplimiento, sobre computación en la nube y contenedores. La nube puede hacer que los métodos anticuados de inventariar,
escanear y aplicar parches a las vulnerabilidades de seguridad queden obsoletos.

Capítulo 1 9
Por supuesto, un desafío con el enfoque que acabo de describir son los entornos que han adoptado las políticas de Traiga su
propio dispositivo (BYOD) que permiten a los trabajadores de la información usar sus dispositivos personales.
dispositivos móviles para acceder y procesar datos empresariales. La pregunta subyacente es si los equipos de administración
de vulnerabilidades empresariales deben inventariar y administrar los dispositivos personales.
Este debate es una de las razones por las que muchos profesionales de la seguridad llamaron originalmente a BYOD "Traiga su
propio desastre". Diferentes organizaciones adoptan diferentes enfoques al responder a esta pregunta.
Algunas organizaciones brindan a los empleados dispositivos móviles de propiedad corporativa y completamente administrados,
mientras que otras requieren dispositivos personales para inscribirse en los programas de administración de dispositivos móviles
empresariales. También he visto un modelo de gestión más pasivo, donde los usuarios deben tener un PIN de acceso en sus
dispositivos y no se les permite conectarse a las redes de sus empleadores si la última versión del sistema operativo móvil no
está instalada en sus dispositivos. Algunas organizaciones utilizan tecnologías de Control de acceso a la red (NAC) o Protección
de acceso a la red (NAP) para ayudar a hacer cumplir las políticas relacionadas con el estado de los sistemas que se conectan
a su red. Algunos proveedores han hecho de este modelo la piedra angular de las arquitecturas “Zero Trust” que ofrecen a sus
clientes. No confiarán en los terminales a menos que se haya verificado que su estado cumple con las políticas de seguridad de
dispositivos móviles de la organización. Por lo general, esto incluye ejecutar la última versión del sistema operativo, recibir
parches para las vulnerabilidades conocidas, incluidas las vulnerabilidades más recientes, y tener instaladas firmas antimalware
actualizadas. Estas características hacen que los puntos finales sean más confiables porque cumplen con los estándares
mínimos de seguridad, lo que reduce la probabilidad de que se vean comprometidos y puedan permitir que los atacantes
ingresen a la red corporativa. Si un punto final no cumple con estos estándares mínimos, las solicitudes de conexión remota se
rechazan hasta que cumpla con la política.
y tiene un "certificado de salud limpio".
Minimizar la cantidad de sistemas sin parches que pueden conectarse a las redes empresariales es una buena práctica, pero
puede ser difícil de lograr según las culturas corporativas y las políticas de dispositivos móviles. Por ejemplo, ¿quién quiere
esperar a que se instalen las actualizaciones de seguridad y reiniciar su sistema cuando simplemente intentaba obtener acceso
a un documento en la red corporativa antes de su vuelo? Muchos "guerreros de la carretera" tienden a evitar conectarse a sus
redes corporativas por este motivo, lo que conduce a una seguridad de punto final peor, no mejor. La recopilación de datos que
ayuden a los equipos de seguridad a comprender el riesgo que los dispositivos móviles representan para sus entornos es muy
útil para un enfoque racionalizado basado en el riesgo.
A continuación, consideraremos las configuraciones incorrectas de seguridad. Al igual que las vulnerabilidades sin parches, las
configuraciones erróneas de seguridad pueden permitir que los atacantes realicen una variedad de acciones en un sistema,
incluida la interrupción de su funcionamiento, el robo de información, la reducción de la configuración de seguridad, la
desactivación de funciones de seguridad, la toma del control y su uso para atacar otros sistemas.
10 Introducción
Configuraciones incorrectas de seguridad

Las configuraciones incorrectas de seguridad pueden estar presentes en un sistema como una configuración predeterminada, como
una clave o contraseña preestablecida que es la misma en todos los sistemas fabricados por un proveedor. Las configuraciones
incorrectas de seguridad también se pueden introducir gradualmente a medida que la configuración de un sistema cambia
gradualmente a medida que se administra con el tiempo. Después de realizar cientos de investigaciones de respuesta a incidentes
mientras estaba en el equipo de respuesta a incidentes orientado al cliente en Microsoft, puedo decirles que un porcentaje significativo
de sistemas se ve comprometido inicialmente debido a configuraciones incorrectas de seguridad.
Esto es especialmente cierto en el caso de los sistemas orientados a Internet, como servidores web, firewalls y otros sistemas que
se encuentran en las zonas desmilitarizadas (DMZ) empresariales . Una vez que una configuración incorrecta permite que un atacante
controle un sistema en una DMZ o lo use para enviar comandos autenticados en nombre del atacante (como un ataque de falsificación
de solicitud del lado del servidor), el atacante aspira a usar el sistema para obtener acceso a otros sistemas en la DMZ y, en última
instancia, obtener acceso a los sistemas dentro del firewall interno de la organización. Este ha sido un patrón común en los libros de
jugadas de los atacantes durante 20 años o más.
Las configuraciones incorrectas de seguridad también han afectado a los dispositivos de punto final, como PC, teléfonos inteligentes
y dispositivos de Internet de las cosas (IoT) . Las infraestructuras a las que se conectan estos puntos finales, como los puntos de
acceso inalámbrico, también son objeto de sondeos frecuentes por parte de los atacantes en busca de errores de configuración comunes.
Las configuraciones incorrectas de seguridad también han sido un problema en los sistemas de control industrial (ICS). Por ejemplo,
un escenario con ICS que ha quemado a los equipos de seguridad en el pasado es "volver al último estado conocido", que puede
anular los cambios de configuración de seguridad más recientes a favor de configuraciones anteriores menos seguras. Las
credenciales codificadas y las configuraciones predeterminadas vulnerables han perseguido durante mucho tiempo a los fabricantes
de todo tipo de software y hardware en toda la industria.
Un programa de gestión de vulnerabilidades bien ejecutado normalmente incluye la identificación de configuraciones erróneas de
seguridad como parte de su alcance. Muchos de los mismos escáneres de vulnerabilidades y herramientas que se utilizan para
identificar y parchear las vulnerabilidades de seguridad también son capaces de identificar configuraciones erróneas de seguridad y
brindar orientación sobre cómo abordarlas. Algunos escáneres de vulnerabilidades pueden determinar si las configuraciones de los
sistemas cumplen con los estándares de la industria, como Center for Internet Security
(CIS) Benchmarks (Center for Internet Security, nd) o los propios estándares de seguridad internos de una organización. Una vez
más, las organizaciones deben renunciar a grandes inversiones en capacidades avanzadas de ciberseguridad si aún no son muy
competentes en la identificación y mitigación de configuraciones erróneas de seguridad en su entorno. No tiene sentido gastar mucho
dinero y esfuerzo buscando la Amenaza Persistente Avanzada (APT) en un entorno si los atacantes pueden usar listas de contraseñas
codificadas con décadas de antigüedad , que están disponibles en Internet, para comprometer con éxito y moverse por el entorno.
Incluso si los CISO encontraran tales atacantes en su entorno de TI, serían impotentes para exorcizarlos con configuraciones
erróneas de seguridad comunes no administradas presentes.

Capítulo 1 11
Algunas de las brechas más grandes de la historia fueron el resultado de un compromiso inicial a través de una
combinación de vulnerabilidades sin parches y configuraciones incorrectas de seguridad. Ambos pueden gestionarse a
través de un programa de gestión de vulnerabilidades bien ejecutado.
Esta es una disciplina no opcional en cualquier estrategia de seguridad cibernética, que debe ser financiada en
consecuencia. No lo olvides, es más fácil administrar cosas que puedes medir; Los inventarios de activos de TI completos,
precisos y oportunos son fundamentales para los programas de gestión de vulnerabilidades. Confíe pero verifique los
inventarios de activos, siempre. Vale la pena tener en cuenta que la nube ofrece varias ventajas sobre el antiguo mundo
de TI en las instalaciones. Discutiré esto en detalle en el Capítulo 13, Enfoques modernos para la seguridad y el
cumplimiento, en este libro.
Las configuraciones incorrectas de seguridad pueden estar presentes de forma predeterminada con el nuevo hardware y
software o pueden aparecer con el tiempo. Otra amenaza constante que requiere atención constante es la de las
credenciales comprometidas. Las organizaciones deben trabajar constante y proactivamente para mitigar este vector de amenazas.
Credenciales débiles, filtradas y robadas

Los entornos de TI comprometidos debido a credenciales débiles, filtradas o robadas son comunes. Hay varias formas en
que las credenciales se filtran y roban, incluida la ingeniería social como el phishing, el malware que registra las pulsaciones
de teclas o roba las credenciales de los sistemas operativos y navegadores, y los sistemas comprometidos que guardan
en caché, almacenan o procesan las credenciales. A veces, los desarrolladores ponen proyectos en sitios de código
compartido disponibles públicamente, pero olvidan que su código contiene secretos como claves y contraseñas. Los
entornos de prueba y desarrollo antiguos que se abandonan pero aún se ejecutan finalmente otorgarán credenciales a los
atacantes después de no haber sido parcheados con el tiempo.
A lo largo de los años, se han descubierto en Internet listas masivas de credenciales robadas y filtradas.
Además de estas listas, la disponibilidad de clústeres de computación de alto rendimiento (HPC) y
Las herramientas de descifrado de contraseñas basadas en GPU han hecho que las contraseñas, por sí mismas, sean
ineficaces para proteger los recursos y las cuentas. Una vez que las contraseñas se han filtrado o robado, pueden
aprovecharse potencialmente para el acceso no autorizado a los sistemas, en ataques de "reutilización" y para escalar
privilegios. La utilidad de las contraseñas por sí solas para proteger los recursos de la empresa pasó hace mucho tiempo.
Posteriormente, el uso de la autenticación multifactor (MFA) es un requisito tanto para las empresas como para los consumidores.
El uso de MFA puede mitigar las credenciales robadas y filtradas en muchos escenarios, pero no en todos. Al usar MFA,
incluso si los atacantes poseen un nombre de usuario y una contraseña válidos para una cuenta, no obtendrán acceso a
la cuenta si los atacantes no poseen también el otro factor requerido para la autenticación. Otros factores que se pueden
usar para la autenticación incluyen certificados digitales, contraseñas de un solo uso y PIN generados en hardware
dedicado o una aplicación de teléfono inteligente, una llamada a un teléfono fijo o móvil registrado previamente, y más.
12 Introducción
MFA no es una bala de plata para contraseñas débiles, filtradas o robadas, pero es muy útil en muchos escenarios . Ha
habido algunos ataques exitosos en algunos métodos MFA. Por ejemplo, ataques de intercambio de SIM para interceptar
códigos PIN enviados a teléfonos móviles registrados previamente a través de SMS. Otra limitación real de MFA es que no
es omnipresente en los entornos de TI empresariales. Es menos probable que las organizaciones con décadas de
aplicaciones heredadas que usan métodos de autenticación y autorización anticuados mitiguen completamente el riesgo
con MFA. Incluso si los últimos sistemas y servicios basados en la nube requieren MFA, es probable que haya más
aplicaciones heredadas que no puedan utilizarlo fácilmente.
Aquí me viene a la mente una imagen de un iceberg. Varios CISO con los que he hablado han experimentado esta
limitación de primera mano durante las pruebas de penetración que expusieron las limitaciones de MFA en sus entornos .
Aún así, MFA debe adoptarse ampliamente, ya que mitiga con éxito muchos escenarios de ataque en los que están
involucradas contraseñas débiles, filtradas y robadas. Debe ser un requisito para los nuevos sistemas que se adopten y los
riesgos que plantean los sistemas antiguos sin él deben considerarse cuidadosamente y mitigarse cuando sea posible. Hay
varios proveedores que se especializan en tales mitigaciones.
Cuando un entorno empresarial local se ve comprometido inicialmente, los atacantes usan credenciales filtradas o robadas
para realizar un reconocimiento y buscar otras credenciales que se hayan almacenado en caché o en el entorno. Están
especialmente atentos a las credenciales de administrador que podrían darles acceso ilimitado a los recursos en el entorno
comprometido.
Por lo general, segundos después del compromiso inicial, los atacantes intentan acceder al servicio de directorio de
cuentas de usuario de la organización víctima, como Microsoft Active Directory (AD), para volcar todas las credenciales en
el directorio. Cuantas más credenciales puedan usar para moverse y permanecer persistentes, más difícil será expulsarlos
del entorno; pueden persistir indefinidamente. Los atacantes intentarán robar las bases de datos de las cuentas de los
usuarios. Si los atacantes obtienen con éxito todas las credenciales del servicio de directorio de su víctima, entonces la
recuperación es realmente una aspiración.
Una vez que los atacantes han robado las credenciales cifradas, la más débil de estas credenciales se puede descifrar en
ataques fuera de línea en cuestión de horas. Las contraseñas más largas, poco comunes y realmente complejas se
descifrarán en último lugar. Ha habido intensos debates durante décadas sobre la eficacia de las contraseñas frente a las
frases de contraseña, así como sobre las longitudes de caracteres adecuadas, los juegos de caracteres, las políticas de
bloqueo de contraseñas, las políticas de caducidad de contraseñas y similares. La orientación para las contraseñas ha
cambiado a lo largo de los años a medida que han cambiado las amenazas y los riesgos y se han puesto a disposición
nuevos datos. Algunas de las personas con las que trabajé en el equipo de Protección de identidad de Microsoft publicaron
una guía de contraseñas basada en los datos de 10 millones de ataques de credenciales por día que ven en los sistemas
de identidad de sus empresas y consumidores. Se recomienda leer la guía de contraseñas de Microsoft (Hicock, 2016).
Capítulo 1 13
Cuando se filtran o roban las credenciales de una organización, los atacantes no tardan mucho en ejecutarlas a través
de secuencias de comandos que intentan iniciar sesión en instituciones financieras, sitios de comercio electrónico,
sitios de redes sociales y otros sitios con la esperanza de que las credenciales se reutilicen en alguna parte.
Reutilizar contraseñas entre cuentas es una práctica terrible. En pocas palabras, las credenciales que brindan acceso
a más de una cuenta tienen un ROI más alto para los atacantes que aquellas que no lo hacen. Conjuntos de
credenciales comprometidas que pueden proporcionar acceso a recursos e información corporativos, así como redes
sociales que también pueden servir como una rica fuente de información y posibles víctimas.
son valiosos.
El uso de contraseñas únicas para cada cuenta y el uso de MFA en todas partes puede mitigar este riesgo. Si tiene
demasiadas cuentas a las que asignar contraseñas únicas, utilice una bóveda de contraseñas para facilitarle la vida.
Existen numerosos productos comercialmente disponibles para consumidores y empresas.
La identidad siempre ha sido la parte más difícil de la ciberseguridad. El gobierno y la gestión de la identidad merecen
su propio libro. Ofrezco una lista muy incompleta de recomendaciones para ayudar a manejar la
riesgo de credenciales débiles, filtradas y robadas:
• MFA puede ser muy efectivo: utilícelo donde pueda. Microsoft publicó una excelente publicación de blog sobre la
efectividad de MFA llamada Your Pa$$word Doesn't Matter (Weinert, 2019), que se recomienda leer.
• Debe saber si su organización está filtrando credenciales y qué antigüedad tienen esas credenciales filtradas. El
uso de un servicio que recopila credenciales filtradas y robadas y busca las credenciales de su organización
que se venden e intercambian en línea puede darle un poco de tranquilidad de que no se está perdiendo algo
obvio. Tener una idea de la antigüedad de estas credenciales puede ayudar a decidir si es necesario
restablecer la contraseña y la cantidad de personas potencialmente afectadas.
• Las soluciones de administración de acceso privilegiado pueden detectar passthehash, passtheticket y
Ataques Golden Ticket, así como el movimiento lateral y reconocimiento de los atacantes en su
infraestructura:
• Muchas de estas soluciones también ofrecen almacenamiento de contraseñas, intermediación de
credenciales y análisis especializado. Algunas de estas soluciones pueden ser ruidosas y propensas
a falsos positivos, pero aun así, pueden ayudarlo a administrar y detectar problemas débiles, filtrados y
credenciales robadas.
14 Introducción
• En entornos basados en la nube, los controles de gestión de acceso e identidad (IAM) son los controles más
potentes que tiene. Aprovechar todo el poder que ofrecen los controles de IAM puede ayudarlo a proteger y
detectar amenazas a los recursos en la nube. Pero esta es un área de conjunto de control que puede convertirse
rápidamente en un desastre inmanejable. La planificación extra cuidadosa de la estrategia de IAM de su
organización generará enormes beneficios en materia de seguridad.
Discutiré la identidad un poco más en el Capítulo 9, Estrategias de ciberseguridad, de este libro.
Un aspecto importante de la protección de las credenciales implica educar a los trabajadores de la información para que
sean conscientes de los ataques de ingeniería social en los que los atacantes pueden intentar robar las credenciales a
través de métodos como el phishing. Sin embargo, esta no es la única forma en que se utiliza la ingeniería social para
comprometer los sistemas. Cubriré la ingeniería social con un poco más de detalle a continuación.
Ingeniería social
De los sospechosos habituales de ciberseguridad, la ingeniería social es el método más utilizado. En pocas palabras, la
ingeniería social está engañando a los usuarios para que tomen malas decisiones de confianza. Los ejemplos de
decisiones de poca confianza incluyen la reducción de la postura de seguridad de un sistema al cambiar su configuración
sin comprender los posibles resultados de hacerlo o, sin saberlo, instalar malware en un sistema.
Los atacantes confían en la ingenuidad de sus víctimas en los ataques de ingeniería social.
El volumen de los ataques de ingeniería social es mucho más grande que otros tipos de ataques.
Por ejemplo, el volumen de ataques de phishing por correo electrónico que Microsoft informó para julio de 2019
fue del 0,85 % de los más de 470 000 millones de mensajes de correo electrónico que fluyeron a través de Office
365 ese mes (Microsoft Corporation, sin fecha). Son 4 mil millones de correos electrónicos de phishing que se
basaron en ingeniería social detectados en un solo mes. Del mismo modo, los troyanos, una categoría de malware
que se basa en la ingeniería social para tener éxito, ha sido la categoría de malware más frecuente en el mundo
de forma continua durante muchos años. Discutiré esta categoría de malware y muchas otras en detalle en el
Capítulo 4, La evolución del malware.
Dado el volumen masivo de ataques de ingeniería social y su historial de éxito, mitigar estos ataques realmente no es
opcional para las empresas. Un componente fundamental de una estrategia de ciberseguridad empresarial es una
estrategia de mitigación de los ataques de ingeniería social. Dicho de otra manera, no incluir los ataques de ingeniería
social en su estrategia de ciberseguridad significaría ignorar la forma principal en que las organizaciones se ven
comprometidas inicialmente por volumen.
Los ataques de ingeniería social suelen ser perpetrados por atacantes externos a las organizaciones, para lo cual los
usuarios deben estar preparados a través de la educación y capacitación adecuadas. Otra amenaza desafiante de la que
defenderse es una desde adentro.

Capítulo 1 15
La última ruta potencial de compromiso, que discutiremos a continuación, es la de la amenaza interna.
Amenazas internas
Cuando hablo de las amenazas internas con los CISO y los equipos de seguridad, me resulta útil dividirlas en tres
categorías diferentes, enumeradas aquí de la más probable a la menos probable:
1. Usuarios y administradores que cometen errores o toman malas decisiones de confianza que conducen a malos
resultados de seguridad.
2. El lobo solitario con información privilegiada o un grupo muy pequeño de personas que usan su acceso privilegiado
para robar información o afectar negativamente la confidencialidad, integridad o disponibilidad de la tecnología
de la información y/o los datos de la organización.
3. La conspiración de masas, donde múltiples personas con información privilegiada trabajan juntas para superar la
separación de funciones que distribuye el alcance del control de seguridad. Descubrí que las empresas suelen
mencionar esta categoría en las discusiones sobre los riesgos en el entorno del proveedor de servicios administrados.
mentos y la nube.
Mitigar las amenazas internas es un aspecto importante de la ciberseguridad y es algo que debería ser fundamental para
cualquier estrategia empresarial. Hacer cumplir la separación significativa de funciones y adoptar el principio de privilegio
mínimo son útiles, al igual que la automatización, el monitoreo y la auditoría.
Me convertí en un gran admirador de la tecnología engañosa después de ver cómo se puede usar para mitigar las
amenazas internas. Hay algunos enfoques diferentes para la tecnología de engaño, pero el concepto básico es presentar
a los atacantes un sistema, potencialmente con vulnerabilidades conocidas públicamente o configuraciones erróneas de
seguridad comunes que, cuando interactúan, alertan a los defensores de la presencia de atacantes.
Este enfoque puede ayudar a alertar a los defensores sobre la presencia de atacantes externos y amenazas internas.
Escuché que algunos profesionales de la seguridad se refieren a él como un "canario en la mina de carbón" para los
entornos de TI . Implementar tecnología de engaño con la menor cantidad de personas involucradas posible y mantener la
confidencialidad del programa puede ser útil para exponer al menos dos de las tres categorías de amenazas internas que
he descrito. Sin embargo, es importante ser transparente con las personas adecuadas en la organización, para que haya
una supervisión y visibilidad adecuadas.
Sugerencia: la revelación de un programa clandestino de amenazas internas es una de las maneras más fáciles de crear
una desconfianza duradera dentro de una organización. Revelar la existencia del programa solo cuando necesita la ayuda
de otras personas puede generar problemas de confianza. Establecer un comité directivo del programa de amenazas
internas compuesto por representantes sénior de la oficina del CISO (OCISO), los departamentos Legal, de Recursos
Humanos, Fraude y TI lo ayudará a evitar o minimizar los problemas más adelante si el programa identifica amenazas maliciosas.
información privilegiada y la acción está justificada.
dieciséis Introducción
Un comité directivo que establezca los estatutos y el alcance del programa y apruebe sus libros de jugadas puede
ayudar a evitar alienar a sus socios y permitirle administrar el programa de manera más efectiva.
Esas son las cinco formas en que las organizaciones se ven comprometidas inicialmente. Defenderse de estos cinco
vectores de ataque es fundamental para una ciberseguridad eficaz.
Centrarse en los fundamentos de la ciberseguridad

Para lograr un programa de ciberseguridad exitoso, las organizaciones deben ser muy buenas en la mitigación
continua de los cinco sospechosos habituales de ciberseguridad. Esta competencia constituye la base de una sólida
estrategia de ciberseguridad. Otras inversiones relacionadas con la seguridad cibernética tendrán potencialmente
rendimientos decrecientes si la base de la estrategia no es sólida.
Después de que un atacante utiliza una o más de estas cinco formas para comprometer inicialmente a una
organización, entonces podría emplear una plétora de TTP novedosos y avanzados. Las organizaciones que se
enfocan en los fundamentos de la ciberseguridad hacen que sea mucho más difícil para los atacantes tener éxito; es
decir, al centrarse en el 85 % interior de la curva de campana por debajo de la cual se encuentran los fundamentos
de la ciberseguridad, en lugar de las actividades en el 7,5 % externo en cualquier extremo de la curva, los equipos
de seguridad tendrán mucho más éxito. Desafortunadamente, el atractivo de cazar amenazas persistentes avanzadas
puede restar recursos al trabajo menos sexy pero crítico en el medio de la curva.
Figura 1.1: Una curva de campana que ilustra que la mayoría de los equipos de seguridad deberían dedicar su tiempo a
los fundamentos de la ciberseguridad
Si realmente solo hay cinco formas en que las organizaciones se ven comprometidas inicialmente, ¿por qué parece
haber tanta confusión en la industria sobre las prioridades adecuadas para los programas de ciberseguridad? Creo
que hay un montón de factores que contribuyen a la confusión. Una de las razones de la confusión es la forma en
que los ataques, los incidentes de seguridad y las filtraciones de datos se han informado en los medios de
comunicación populares, a veces confundiendo las tácticas de los atacantes con sus motivaciones.
Capítulo 1 17
Esto puede llevar a las organizaciones a tomar decisiones de priorización de seguridad incorrectas.
Comprender la diferencia entre las motivaciones y las

tácticas de los atacantes
Una de las razones por las que descubrí que tantas organizaciones carecen de enfoque y competencia en torno a los
fundamentos de la seguridad cibernética es la forma en que se informaron las violaciones de big data en las noticias.
la ultima decada. Historias que afirman que un ataque fue el "ataque más avanzado visto hasta la fecha" o el
el trabajo de “un estado nación” parece ser común. Pero cuando observa más de cerca estos ataques, la organización
víctima siempre se vio inicialmente comprometida por atacantes que usaban uno o más de los sospechosos habituales
de ciberseguridad que describí en este capítulo.
Hay atacantes que operan abiertamente porque no creen que sus actividades ilícitas tengan consecuencias, según su
ubicación, jurisdicción legal o quién patrocina su trabajo. Esto solía ser la excepción a la regla de que ofuscarán sus
verdaderas afiliaciones e identidades.
Sin embargo, ha habido una proliferación de grupos de amenazas de estados nacionales y algunos proveedores de
inteligencia de amenazas ahora están rastreando muchos de esos grupos (más de 30 grupos) que identifican como
estados nacionales de buena fe.
Atribuir un ataque a un individuo o grupo puede ser extremadamente difícil. Esto se debe a que Internet se basa en un
conjunto de protocolos que se desarrollaron hace más de 40 años. Los ingenieros que desarrollaron estos protocolos
inmensamente escalables y sofisticados nunca imaginaron un mundo futuro donde toda una industria de más de 100 mil
millones de dólares al año estaría basada en los descubrimientos de nuevas vulnerabilidades de seguridad, investigación
de malware, protección de ingeniería social y la proliferación de organizaciones criminales sofisticadas y actores de
estadosnación. El conjunto de protocolos TCP/IP (versión 4), la base de Internet, nunca se diseñó para ayudar a los
investigadores a realizar la atribución de los ataques cibernéticos que aprovechan las vastas redes de sistemas
distribuidos comprometidos en todo el mundo. Comparar fragmentos de código de dos muestras de malware para
determinar si los mismos atacantes desarrollaron ambos no es una forma confiable de realizar la atribución, especialmente
cuando los atacantes saben que esta es una técnica común. Encontrar el "paciente cero", donde comenzó el compromiso,
en entornos grandes que han estado comprometidos durante meses o años, utilizando datos de sistemas comprometidos,
no se puede hacer con total confianza.
Sin embargo, los atacantes que han adoptado el modelo comercial moderno de ransomware han facilitado la atribución
con mucha más confianza. Básicamente, se identifican a sí mismos, o al menos a su afiliación con pandillas de
ransomware, cuando exigen un rescate de sus víctimas. Tener una designación de pandilla de ransomware conocida
puede ayudar a infundir miedo en la mente de las víctimas, especialmente cuando la pandilla tiene un historial de ataques
exitosos.
18 Introducción
Las víctimas los toman en serio cuando tienen un historial de cumplimiento de sus promesas, tanto buenas como malas.
La atribución es relativamente fácil cuando una pandilla conocida de ransomware publica una publicación en un blog de
la Dark Web de la misma manera que lo han hecho en el pasado, publicando algunos de los datos de sus últimas víctimas.
Demuestra que tienen posesión de datos robados y exigen uno o más rescates de la víctima. Examino algunas de las
formas en que ha evolucionado el ransomware en el Capítulo 4, La evolución del malware.
Cuando los equipos de seguridad encuentran indicadores de compromiso (IOC, por sus siglas en inglés) que coinciden
con precisión con los "caídas de ratas " de un actor de amenazas conocido, es difícil no concluir que el actor de amenazas
asociado está involucrado en un ataque. Hablo de los IOC con más detalle en el Capítulo 2, Qué saber sobre la inteligencia
de amenazas. Pero sigo pensando que es importante tener en cuenta que incluso si pudiera identificar a un atacante y
capturarlo, es probable que nunca le diga sus verdaderas motivaciones; los delincuentes rara vez lo hacen. Esto es
especialmente cierto en el caso del crimen organizado y los estados nacionales: se quedará con muchas suposiciones
sobre sus motivaciones. Hablo de los gobiernos y la gran cantidad de motivaciones que tienen en el Capítulo 6, Los roles
que juegan los gobiernos en la ciberseguridad.
En el caso del ransomware, parecería que la motivación es bastante sencilla: obtener ganancias.
Sin embargo, la investigación de amenazas de Microsoft sugiere que los atacantes usaron ransomware "falso" contra
objetivos del gobierno de Ucrania durante la invasión rusa en 2022. La motivación de estos ataques de ransomware
"falsos" no fue el lucro; fue realmente la destrucción de los activos ucranianos. Microsoft informó: "MSTIC evalúa que el
malware, que está diseñado para parecerse a un ransomware pero que carece de un mecanismo de recuperación de
rescate, tiene la intención de ser destructivo y está diseñado para dejar inoperables los dispositivos específicos en lugar
de obtener un rescate" (Microsoft Corporation, 15 de enero de 2022). Aparentemente, el malware de limpieza se disfrazó
de ransomware. La diferencia es que este malware de limpieza no fue diseñado para cifrar datos de una manera reversible
mediante una clave de descifrado; en cambio, los datos se destruyen. Esta no fue la primera vez, ni será la última vez
que los atacantes intentan ocultar sus motivaciones.
Aún así, muchos profesionales de la ciberseguridad utilizan este tipo de datos para suponer las motivaciones, afiliaciones
e identidades de los atacantes . Las motivaciones del atacante pueden incluir:
• Notoriedad: el atacante quiere demostrar que es más inteligente que las grandes empresas de alta tecnología.
y sus víctimas.
• Beneficio: como analizo en el Capítulo 4, La evolución del malware, después de los exitosos ataques globales
de gusanos en 2003, el malware comenzó a evolucionar para respaldar un motivo de lucro que continúa hasta
el día de hoy.
• Espionaje económico: por ejemplo, supuestas actividades de grupos en China para robar propiedad intelectual
valiosa de las naciones occidentales para dar a sus propias industrias una ventaja competitiva y económica.
Capítulo 1 19
• Espionaje militar: Una motivación tan antigua como los propios gobiernos, donde los gobiernos quieren conocer las
capacidades militares de sus adversarios y aliados.
• Hacktivismo: Ataques a organizaciones e instituciones basados en desacuerdos sobre
cuestiones políticas o filosóficas.
• Objetivos de política exterior: los gobiernos ejecutan operaciones sofisticadas de influencia cibernética usando
manipulación cultural y tácticas de guerra de información, amplificando narrativas falsas para influir y manipular a las
poblaciones objetivo. Los ejemplos incluyen influir en las elecciones y bajar la moral de las poblaciones civiles
enemigas durante la guerra.
• Muchos otros: vea cualquier película de James Bond en la que el Ejecutivo especial para contrainteligencia, terrorismo,
venganza y extorsión (SPECTRE) sea parte de la trama y

ver algunas motivaciones creativas.
Creo que es justo decir que la mayoría de las organizaciones no entenderán realmente cuál es la motivación de un atacante.
Si las motivaciones de los atacantes no están claras, ¿cómo se supone que los CISO saben qué es una respuesta proporcional?
¿Quién debe ayudar a la organización víctima con la respuesta al ataque: las autoridades locales, el ejército o una coalición
internacional?
Aún así, he hablado con organizaciones cuyas estrategias de ciberseguridad dependen en gran medida de la atribución.
Después de realizar cientos de investigaciones de respuesta a incidentes para los clientes de Microsoft y publicar inteligencia
de amenazas durante casi una década, creo que la suposición de que la atribución oportuna se puede hacer con confianza es
demasiado optimista. Ciertamente, los avances que los proveedores de inteligencia de amenazas y los fabricantes de
herramientas de seguridad cibernética han logrado en los últimos años han nivelado un poco más el campo de juego. Los
equipos de seguridad armados con el conocimiento de los TTP de los atacantes, catálogos de IOC y automatización mejorada
de detección y respuesta, pueden defenderse contra los actores de amenazas conocidos de manera mucho más efectiva y
eficiente que nunca. Tan exitosas y prometedoras como son estas nuevas capacidades, e incluso cuando los atacantes
identifican sus afiliaciones con demandas de rescate y publicaciones de blogs de fuga de datos, los ataques continúan sin cesar
y, posiblemente, los atacantes nunca han tenido más éxito.
Afortunadamente, comprender quiénes son los atacantes no es un requisito previo para el éxito de una estrategia de
ciberseguridad. Independientemente de quién patrocine su trabajo o cuán sofisticados sean los atacantes, todos utilizan los
sospechosos habituales de ciberseguridad para el compromiso inicial: "las herramientas utilizadas por los estados nacionales
para comprometer las redes de las víctimas son con mayor frecuencia las mismas herramientas utilizadas por otros actores malintencionados".
(Microsoft Corporation, octubre de 2021). Creo que podemos, con un 99,9 % de certeza, predecir las tácticas que utilizarán los
atacantes cuando intenten comprometer inicialmente un entorno de TI empresarial. Esto es en lo que las organizaciones
deberían invertir: los fundamentos de la ciberseguridad para mitigar los sospechosos habituales de la ciberseguridad.
20 Introducción
Una gran y próspera industria de Threat Intelligence ha surgido del deseo insaciable de atribución, TTP e IOC.
En el próximo capítulo, profundizaremos en la inteligencia de amenazas. Aprenderá qué es la inteligencia de
amenazas, cómo distinguir la buena inteligencia de la mala y cómo la usan los equipos de ciberseguridad
empresarial. Esto lo ayudará a prepararse para evaluar las estrategias de seguridad cibernética diseñadas para
mitigar los intentos de intrusión, que se analizan en capítulos posteriores de este libro.
Resumen
El contexto que proporcioné en este capítulo será útil para los lectores a lo largo del resto de este libro.
En este capítulo, introduje los fundamentos de la ciberseguridad y los sospechosos habituales de la
ciberseguridad; Me referiré sin descanso a estos conceptos a lo largo del resto de este libro.
Las organizaciones que son muy competentes en la gestión de los fundamentos de la ciberseguridad hacen que
sea mucho más difícil para los atacantes tener éxito. Se requiere una base sólida, centrada en los fundamentos,
para una estrategia exitosa.
No confunda las motivaciones de un atacante con sus tácticas. Dado que la atribución precisa de los ataques
puede ser difícil o imposible de lograr, es poco probable que la mayoría de las organizaciones puedan determinar
quién las está atacando y cuáles son realmente las motivaciones de los atacantes. Ya sea que el atacante sea
un proveedor de malware comercial o un estado nacional, las formas en que intentarán comprometer inicialmente
los entornos de TI de sus víctimas se limitan a los sospechosos habituales de ciberseguridad. Ser muy
competente en los fundamentos de la ciberseguridad hace que sea mucho más difícil para los atacantes, ya sea
un estado nación que intenta robar propiedad intelectual o un extorsionista que usa ransomware.
Referencias
• Lluvias, T. (2020). Amenazas de seguridad cibernética, tendencias de malware y estrategias. Publicación de paquetes.
Obtenido de https://www.packtpub.com/product/cybersecuritythreatsmalware
tendenciasyestrategias/9781800206014.
• Jakkal, V. (2021). “Microsoft supera los $10 mil millones en ingresos del negocio de seguridad, más del 40
por ciento de crecimiento año tras año”. Microsoft.com. Obtenido de https://www.
microsoft.com/security/blog/2021/01/27/microsoftsupera10billonesen
seguridadnegocioingresosmásdel40porcientoañotrasañocrecimiento/.
• Microsoft. (2021). “Arquitecturas de referencia de ciberseguridad de Microsoft”. Microsoft Corporation .

Obtenido de https://docs.microsoft.com/enus/security/cybersecumrity
arquitectura de referencia/mcra.
Capítulo 1 21
• Khalid Kark, Taryn Aguas (26 de julio de 2016). “El nuevo CISO: Liderando la organización de seguridad
estratégica”, Deloitte Review número 19. Obtenido de https://www2.deloitte.com/
us/es/insights/deloittereview/issue19/cisonextgenerationstrategic
seguridadorganización.html.
• Base de Datos Nacional de Vulnerabilidad. (Dakota del Norte). Obtenido de https://nvd.nist.gov/vuln.
• Centro de Seguridad en Internet. (Dakota del Norte). Obtenido de https://www.cisecurity.org/cis

puntos de referencia/.
• Hicock, R. (2016). “Guía de contraseñas de Microsoft”. Corporación Microsoft. Obtenido de: https://
www.microsoft.com/enus/research/wpcontent/uploads/2016/06/
Microsoft_Password_Guidance1.pdf.
• Weinert, A. (9 de julio de 2019). “Tu Pa$$palabra no importa”. Corporación Microsoft. Obtenido de https://
techcommunity.microsoft.com/t5/azureactivedirectoryidentity/
tupapalabranoimporta/bap/73198.
• Corporación Microsoft. (Dakota del Norte). “Informe de Defensa Digital de Microsoft”. Corporación Microsoft.
Obtenido de https://www.microsoft.com/securityinsights/Phishing.
• Corporación Microsoft. (15 de enero de 2022). “Malware destructivo dirigido a organizaciones ucranianas”.
Corporación Microsoft. Obtenido de https://www.microsoft.
com/security/blog/2022/01/15/destructivemalwaretargetingukrainian
organizaciones/.
• Corporación Microsoft. (Octubre 2021). “Informe de Defensa Digital de Microsoft Octubre 2021”.
Corporación Microsoft. Obtenido de https://query.prod.cms.rt.microsoft.com/
cms/api/am/binary/RWMFIi.

2
Qué saber sobre la amenaza
Inteligencia
Lo admito, soy un fanático de los datos de inteligencia de amenazas. Realmente disfruto estudiando inteligencia de amenazas. Me ayuda a
comprender las tácticas y técnicas que están de moda entre los atacantes y cómo está evolucionando el panorama de amenazas. Uno de los
mejores trabajos que tuve en Microsoft fue trabajar como Director de Computación digna de confianza. En este cargo, fui editor ejecutivo y
colaborador del Informe de inteligencia de seguridad de Microsoft, al que llamamos "el SIR". Durante los 8 o 9 años que ayudé a producir el
SIR, publicamos más de 20 volúmenes y ediciones especiales de este informe, que abarcan miles de páginas. Di literalmente miles de
informes de inteligencia de amenazas para clientes de todo el mundo, así como entrevistas con la prensa y analistas. Puedo decirle por
experiencia que las entrevistas en televisión en vivo frente a millones de personas, discutiendo la inteligencia de amenazas, ¡son angustiosas!
(Noticias de la BBC, 2013).
Construir y publicar el SIR fue mucho trabajo , pero muy gratificante. En este puesto, tuve la
oportunidad de trabajar con tanta gente inteligente en el Centro de respuestas de seguridad de Microsoft.
(MSRC), el Centro de protección contra malware de Microsoft (MMPC), la Unidad de delitos digitales de Microsoft
(DCU), el equipo de ciclo de vida de desarrollo de seguridad (SDL) , Microsoft IT y muchos otros. Hacer este trabajo me dio una profunda
apreciación del valor de una buena inteligencia de amenazas y algunas de las formas en que se produce. Microsoft ha seguido invirtiendo en
inteligencia de amenazas y ahora tienen un centro dedicado a ello llamado Microsoft Threat Intelligence Center (MSTIC), en el que trabajan
algunos de mis antiguos colegas.
Proporciono una inmersión profunda en los datos del SIR en el Capítulo 4, La evolución del malware. También ofrezco una inmersión profunda
en las vulnerabilidades de seguridad en el Capítulo 3, Uso de tendencias de vulnerabilidad para reducir el riesgo y
Costos.
24 Lo que debe saber sobre la inteligencia de amenazas
Pero antes de llegar a estos datos, permítame brindarle un contexto útil para ayudarlo a consumir los datos en esos
capítulos y otra inteligencia de amenazas que encuentre en su carrera.
¿Qué es la inteligencia de amenazas?

Threat Intelligence (TI) a veces se denomina Cyber Threat Intelligence (CTI) para dejar en claro que la inteligencia
se centra en las amenazas de ciberseguridad en lugar de otros tipos de amenazas.
El concepto es antiguo: cuanto más sepa sobre sus enemigos y cómo planean y ejecutan sus ataques, más
preparado podrá estar para esos ataques.
En pocas palabras, CTI proporciona a las organizaciones datos e información sobre cómo los atacantes han estado
aprovechando los sospechosos habituales de ciberseguridad, qué han estado haciendo en los entornos de TI
después del compromiso inicial y, a veces, la atribución de los ataques a actores de amenazas específicos. Las
amenazas también pueden incluir varias categorías de malware, explotación de vulnerabilidades, ataques basados
en web, ataques de denegación de servicio distribuido (DDoS) , ataques de ingeniería social y otros. Por supuesto,
como escribí en el Capítulo 1, Introducción, también existe un gran interés en la información sobre los propios
atacantes: quiénes son, dónde se encuentran, si son patrocinados por el estado o una organización criminal
independiente, y los detalles sobre su modus operandi de sus ataques anteriores. Toda una industria ha crecido en
torno a la demanda de atribución e información sobre los actores de amenazas.
¿De dónde provienen los datos de CTI?

Los proveedores de CTI recopilan y analizan datos de fuentes de datos. Hay muchas fuentes potenciales de datos
que los proveedores de CTI pueden usar. Por ejemplo, los datos sobre amenazas de malware pueden provenir de
productos y servicios antimalware que se ejecutan en terminales, redes, servidores de correo electrónico,
navegadores web, servicios en la nube, honeypots, etc. Los datos sobre credenciales débiles, filtradas y robadas
pueden provenir no solo de proveedores de identidad como Microsoft Azure Active Directory, las ofertas de identidad
de Google y Okta, sino también del monitoreo de foros ilícitos donde se compran y venden dichas credenciales .
Los datos sobre los ataques de ingeniería social pueden provenir de los servicios de phishing y filtrado de spam,
así como de los servicios de redes sociales.
También hay Open Source Threat Intelligence (OSINT) que aprovecha las fuentes de datos disponibles públicamente,
como las redes sociales, las noticias, los documentos judiciales y los registros de arrestos, la información divulgada
por los atacantes sobre sus víctimas, la actividad en foros ilícitos y muchos otros. OSINT puede ayudar a los
defensores en al menos un par de formas. Primero, puede ayudar a notificarle que su entorno de TI se ha visto
comprometido. Observar a los atacantes que ofrecen sus datos a la venta o hablan sobre el acceso ilícito a su red
pueden ser indicadores principales de una brecha que no ha sido detectada. Otra forma en que muchas
organizaciones usan OSINT es para investigar a los atacantes y las tácticas que usan.
Capitulo 2 25
Por supuesto, los atacantes pueden usar OSINT para investigar y realizar un reconocimiento de sus objetivos
potenciales. Hay una gran cantidad de herramientas para ayudar a encontrar OSINT, incluidas Maltego, Shodan,
theHarvester y muchas otras.
Los proveedores de CTI pueden usar fuentes de datos que poseen y operan, datos de CTI obtenidos de terceros y
fuentes de datos OSINT. Por ejemplo, los proveedores de antimalware que operan sus propios laboratorios de
investigación y respuesta recolectan malware para su análisis y operan varias ofertas de antimalware. Sus clientes
aceptan enviar muestras de malware que encuentran, y los productos y servicios de los proveedores generan datos
de detecciones, bloqueos de instalación y desinfecciones en el curso de la operación. Todos estos datos se pueden
recopilar, agregar y analizar para proporcionar al proveedor información sobre cómo funcionan sus productos y
servicios y orientar las actividades e inversiones futuras de investigación y respuesta.
Muchos proveedores también publican informes de inteligencia de amenazas y brindan CTI a sus clientes a través
de portales web y correos electrónicos, pero también lo integran en API, productos y servicios. Ejemplos de
proveedores que hacen esto incluyen CrowdStrike, Google, Mandiant, McAfee, Microsoft, Recorded Future, Sophos,
Symantec y muchos otros. Hacen esto para compartir su CTI y ayudar a las organizaciones a comprender lo que
está sucediendo en el panorama de amenazas. Pero también lo hacen para generar nuevos negocios al demostrar
la amplitud y profundidad de su CTI. A muchos proveedores les gusta afirmar que brindan una mejor visibilidad que
sus competidores y, por lo tanto, una mejor protección contra las amenazas. Aquí es donde la escala puede ser un
diferenciador.
Cuando trabajaba en Microsoft, algunos proveedores de antimalware hacían afirmaciones como esta. Sin embargo,
cientos de millones de usuarios de Windows en todo el mundo acordaron compartir datos de amenazas con
Microsoft. Agregue capas de datos de navegadores web, el motor de búsqueda de Internet Bing, la suite de
productividad más popular del mundo y productos y servicios de identidad empresarial, y el CTI generado es
impresionante. Este alcance masivo permitió a Microsoft desarrollar una excelente comprensión del panorama
global de amenazas y compartirlo con sus clientes a través del SIR, blogs, documentos técnicos, productos, servicios
y API. Demuestro el alcance de dichas fuentes de datos, en detalle, en el Capítulo 4, La evolución del malware.
Algunos proveedores de CTI se diferencian no necesariamente por la escala, sino por la calidad de sus datos y
análisis. Son capaces de correlacionar los datos que tienen con industrias específicas y con clientes específicos
dentro de esas industrias y proporcionar información más procesable que las tendencias globales anonimizadas de
alto nivel que normalmente permiten.
Por ejemplo, si soy un CISO de una organización en la industria de la salud, es probable que esté interesado en CTI
de un proveedor que realmente comprenda mi industria y sus desafíos únicos y tenga datos sobre los atacantes y sus
ataques en la industria de la salud, y en las ubicaciones geográficas en las que mi organización hace negocios . Esta
combinación me ayudará a comprender las amenazas que afectan específicamente a mi industria y prepararme mejor
para ellas en un contexto de atención médica que potencialmente incluye una regulación estricta, un gran enfoque en
la privacidad del paciente, requisitos costosos de certificación de equipos y riesgo para la vida humana. Siempre
busco información sobre lo que están haciendo otras organizaciones similares a la mía para proteger, detectar y
responder a estas amenazas. Esta información informará algunos de mis esfuerzos y hará que sea más fácil convencer
a la empresa a la que apoyo para que proporcione el presupuesto y los recursos que necesito.
Algunos proveedores de CTI promocionan sus habilidades para realizar atribuciones y su conocimiento de los
atacantes del estadonación . Han acuñado nombres a veces divertidos, pero siempre intrigantes para estos grupos de ataque.
Los ejemplos incluyen Lazarus Group, Sandworm Team, PHOSPHORUS y muchos otros. Puede ser muy interesante
obtener una idea de cómo operan los atacantes bien financiados. No pasa mucho tiempo antes de que otros atacantes
intenten imitar las tácticas y técnicas que usan los profesionales una vez que se revelan a través de CTI. De esta
manera, los actores de amenazas del estadonación han estado reduciendo la barrera de entrada para los delincuentes
durante décadas. Sin embargo, en mi experiencia asesorando a muchas organizaciones a lo largo de los años, la
amenaza de los actores del estadonación puede sesgar el enfoque que toman los equipos de seguridad de una
manera que no es útil. Centrarse en los actores de amenazas que potencialmente tienen recursos ilimitados (los
gobiernos pueden imprimir dinero) puede distraer a los CISO y los equipos de seguridad de centrarse en los
fundamentos de la ciberseguridad. Después de todo, no importa cuán bien financiados estén los atacantes, utilizarán
uno o más de los sospechosos habituales de ciberseguridad para comprometer inicialmente el entorno de TI de su
objetivo, al igual que los delincuentes comunes. Los CISO deben preguntarse: "¿Realmente debemos preocuparnos
por estos actores de amenazas del estadonación ahora o tenemos desafíos más fundamentales que abordar primero?"
Después de todo, volverse excelente en los fundamentos de la ciberseguridad reducirá el ROI para todos los posibles
actores de amenazas que se dirijan a su organización.
No me malinterpreten, he hablado con muchos equipos de seguridad en organizaciones del sector público y del sector
privado donde prestar atención a los actores de amenazas del estadonación no es opcional debido a los propios
estatutos de sus organizaciones o la propiedad intelectual que poseen. Pero incluso en estos casos, centrarse en los
fundamentos de la ciberseguridad puede generar grandes dividendos.

Capitulo 2 27
Uso de inteligencia de amenazas

Los programas de ciberseguridad pueden hacer uso de CTI de varias maneras. Estos son algunos ejemplos (esta lista no es
exhaustiva):
• Los Centros de Operaciones de Seguridad (SOC) son tan buenos como el CTI que tienen
• Informar sobre las investigaciones de los Equipos de Respuesta a Incidentes de Ciberseguridad (CIRT)
• Informar sobre los esfuerzos de los equipos de caza de amenazas, rojo, azul y morado
• Perfilar a los atacantes para estar mejor preparados para ellos
• Informar los programas de protección ejecutiva diseñados para proteger a los ejecutivos y sus familias
• Informar a la gestión de riesgos
Profundicemos un poco más en ese último ejemplo, informemos a la gestión de riesgos. CTI puede informar los riesgos a los que
las organizaciones prestan atención. Recuerde que el riesgo se compone de probabilidad e impacto. CTI puede ayudar a cuantificar
tanto el lado de la probabilidad como el lado del impacto de los cálculos de riesgo. Por ejemplo, supongamos que usted es un CISO
y los líderes empresariales a los que apoya están muy preocupados por el ransomware porque siguen viendo noticias sobre
ataques. CTI puede ayudar a dar una idea de la probabilidad de encontrar ransomware. Discutiré el ransomware en detalle en el
Capítulo 4, La evolución del malware, pero resulta que el ransomware (la categoría de malware) suele ser una de las categorías de
malware menos prevalentes. Hay algunas razones lógicas por las que este es el caso que trataré en el Capítulo 4, La evolución del
malware. Sin embargo, si tuviera que clasificar los riesgos por orden de prioridad basándose únicamente en la probabilidad, el
ransomware probablemente aparecería casi al final de la lista.
Pero una vez que cuantificamos el impacto potencial del ransomware para reflejar que encontrarlo podría ser un evento de extinción
para su empresa, es probable que suba en la clasificación de la lista de riesgos.
Otro uso de CTI es ayudar a los equipos de seguridad a mitigar los riesgos proporcionando detalles sobre amenazas específicas y
cómo operan. Comprender las tácticas, técnicas y procedimientos (TTP) que emplean los atacantes puede proporcionar algunas
ideas concretas sobre cómo pueden mitigarse. NIST define los TTP como,
El comportamiento de un actor. Una táctica es la descripción de más alto nivel de este comportamiento,
mientras que las técnicas brindan una descripción más detallada del comportamiento en el contexto
de una táctica, y los procedimientos una descripción de nivel aún más bajo y altamente detallada en
el contexto de una técnica. (Tejón et al 2016)

Una táctica es la razón por la que el atacante realiza una acción en particular. ¿Por qué deciden tomar una
acción específica? Era un gol táctico. Por ejemplo, una vez que un atacante está dentro de la red de su víctima,
normalmente necesita moverse lateralmente para explorar la red y encontrar datos confidenciales. La táctica en
este ejemplo es el movimiento lateral. Otros ejemplos de tácticas incluyen reconocimiento, persistencia y
exfiltración.
Las técnicas son la forma en que el atacante intenta llevar a cabo la táctica: las acciones específicas que realiza.
Por ejemplo, el atacante necesitaba moverse lateralmente (la táctica) en la red de la víctima, por lo que utilizó
Pass the Hash y cookies de autenticación web robadas (estas son técnicas) para hacer esto.
El uso de esta combinación de tácticas y técnicas permite a los equipos de seguridad adoptar un enfoque
estructurado para la planificación de ataques. Conocer las tácticas y técnicas que utilizan los atacantes permite
a los defensores implementar personas, procesos y tecnologías que detectarán o mitigarán las técnicas cuando
se empleen. En nuestro ejemplo donde se empleó Pass the Hash, podríamos planear mitigar esta técnica
utilizando alguna guía de Microsoft o adquiriendo un producto de seguridad diseñado para detectarlo.
Usar TTP de esta manera puede parecer una tarea desalentadora porque debe haber muchas combinaciones y
permutaciones de tácticas y técnicas del atacante. Un gran recurso para ayudar a los equipos de seguridad es
la base de conocimientos MITRE ATT&CK® (que se encuentra en https://attack.mitre.org/). Esta base de
conocimientos contiene tácticas y técnicas que se han visto en uso durante los ataques. Asigna técnicas a
tácticas y proporciona formas en que cada técnica puede ser potencialmente mitigada y detectada. La
popularidad de este enfoque entre los equipos de seguridad se ha disparado en los últimos años.
Muchos equipos de seguridad también utilizan indicadores de compromiso (IOC) para ayudar a determinar si
sus entornos de TI empresariales se han visto comprometidos. Donde los TTP pueden ayudar a proteger,
detectar y responder a los ataques, los IOC pueden ayudar al compromiso posterior para tratar de determinar
cuándo y cómo ocurrió el compromiso inicial y qué hicieron los atacantes con su acceso ilícito después. Los IOC
se describen de esta manera en la Publicación especial 80053 Revisión 5 del NIST:
Capitulo 2 29
Los indicadores de compromiso (IOC) son artefactos forenses de intrusiones que se identifican
en los sistemas organizacionales a nivel de host o red. Los IOC proporcionan información
valiosa sobre los sistemas que se han visto comprometidos. Los IOC pueden incluir la creación
de valores de clave de registro. Los IOC para el tráfico de red incluyen Universal Resource
Locator o elementos de protocolo que indican servidores de comando y control de código malicioso.
La rápida distribución y adopción de los IOC puede mejorar la seguridad de la información al
reducir el tiempo que los sistemas y las organizaciones son vulnerables al mismo exploit o
ataque. Los indicadores de amenazas, firmas, tácticas, técnicas, procedimientos y otros
indicadores de compromiso pueden estar disponibles a través de cooperativas gubernamentales
y no gubernamentales, incluido el Foro de Respuesta a Incidentes y Equipos de Seguridad, el
Equipo de Preparación para Emergencias Informáticas de los Estados Unidos, el Programa de
Intercambio de Información de Ciberseguridad de la Base Industrial de Defensa y el Centro de Coordinación CERT” .
(Publicación especial NIST 80053 Revisión 5, septiembre de 2020).
Los ejemplos de IOC incluyen tráfico de red inusual (destino, origen o volumen), tráfico de red hacia o desde
nombres de dominio o direcciones IP maliciosos conocidos, volúmenes inusuales de fallas de autenticación, la
presencia de herramientas específicas, archivos o entradas de registro, cuentas no reconocidas agregadas

recientemente y muchos otros. Los equipos forenses y de respuesta a incidentes pueden usar IOC para ayudarlos
a identificar sistemas comprometidos. Para hacer esto, normalmente necesitan hash MD5, SHA1 o SHA256 para
archivos, scripts y herramientas que los atacantes dejan atrás. Los hashes de archivos pueden ayudar a identificar
la presencia de archivos que se usaron potencialmente durante los ataques entre las montañas de archivos legítimos en los sistemas.
Las direcciones IP para servidores de comando y control, ubicaciones de exfiltración de datos y otros recursos
controlados por atacantes también pueden ser útiles para los investigadores mientras revisan los registros de
datos de flujo de red en firewalls, servidores proxy y otros dispositivos en una red.
Figura 2.1: Un ejemplo de IOC con nombres de archivo ficticios, hash y direcciones IP
Aprendí mucho sobre los trucos que les gusta usar a los atacantes cuando trabajé en el software personalizado de Microsoft.
equipo de respuesta a incidentes de cara a er. Creamos herramientas para recopilar datos del sistema en sistemas
Windows en ejecución en vivo que se sospechaba que estaban comprometidos. Compararíamos los datos sobre las
configuraciones del sistema y los estados de ejecución con conjuntos de datos buenos y malos conocidos,
esencialmente buscando IOC. Esto era tanto arte como ciencia porque los atacantes usaban todo tipo de trucos
creativos para tratar de evitar la detección, permanecer persistentes y realizar la extracción de datos.
Capitulo 2 31
Algunos trucos memorables incluyen atacantes que usan direcciones IP en formato Base8 en lugar de Base10 para
eludir las reglas del servidor proxy, aprovechar errores en los navegadores y servidores proxy cuando se usan nombres
de dominio en cirílico, ejecutar procesos usando el mismo nombre que los procesos legítimos del sistema de Windows,
pero desde directorios ligeramente diferentes para evitar la detección, y muchos más. ¡Cosas divertidas!
Los equipos de seguridad pueden aprovechar los TTP y los IOC con una variedad de herramientas, productos y servicios de seguridad.
Los ejemplos incluyen sistemas de administración de eventos e información de seguridad (SIEM) , herramientas de
análisis de comportamiento, herramientas de visualización de datos, servicios de filtrado de correo electrónico, servicios
de filtrado de navegación web, productos de protección de puntos finales, productos de detección y respuesta
extendidas (XDR) , productos de orquestación, automatización y respuesta de seguridad (SOAR) y muchos otros. Hay
una gran cantidad de formas de aprovechar CTI para proteger, detectar y responder a las amenazas modernas.
Los diferentes roles en los equipos de seguridad pueden aprovechar CTI de formas ligeramente diferentes. Por
ejemplo, como mencioné anteriormente, los equipos de respuesta a incidentes cibernéticos (CIRT) usarán IOC cuando
realicen investigaciones de intrusión. Mientras tanto, los analistas de TI utilizan CTI para garantizar que se optimicen
las capacidades de protección y detección. CTI tiene el potencial de informar los esfuerzos de muchos roles diferentes y
partes interesadas.
La clave para usar inteligencia de amenazas

He proporcionado algunos ejemplos de algunas de las formas en que los equipos de seguridad usan CTI.
Independientemente de la forma en que los equipos de seguridad elijan aprovechar CTI, es importante reconocer que,
aunque CTI es un producto ofrecido por muchos proveedores y organizaciones, también es un proceso: un proceso
que se utiliza para recopilar datos, procesarlos, analizarlos y luego compartir los resultados con las partes interesadas
que los necesitan. Por lo general, esto requiere tiempo, presupuesto y recursos para lograrlo. Todavía no he conocido
un equipo de seguridad que tenga recursos ilimitados y no necesite hacer concesiones. La combinación de tantas
fuentes potenciales de CTI, tantos usos y recursos limitados, puede hacer que los equipos de seguridad se ahoguen
en CTI. En muchos casos, el CTI no les sería útil incluso si pudieran consumirlo.
La razón más común que he visto para esto es que los equipos no se tomaron el tiempo para desarrollar un conjunto
de requisitos para su programa CTI. En este contexto, los "requisitos" son declaraciones sobre los problemas
específicos que el programa CTI está tratando de resolver. Estos requisitos ayudan al programa de CTI a racionalizar
el CTI que utilizan vinculando el CTI específico recopilado y analizado con las necesidades específicas de las partes
interesadas del programa. Si alguna fuente de CTI tiene algunos datos interesantes, pero los datos que proporciona
no ayudan a cumplir con un requisito definido por una parte interesada del programa, entonces esa fuente
probablemente no debería aprovecharse.

Este enfoque ayuda al programa CTI a optimizar los recursos con los que cuenta y evita que se ahogue
en CTI.
Figura 2.2: Ejemplo de requisitos de CTI
He visto algunos enfoques diferentes para documentar los requisitos. La figura 2.2 proporciona un ejemplo. Si
su programa CTI no tiene un conjunto de requisitos documentados, recomiendo trabajar con las partes
interesadas del programa para desarrollarlos, ya que son la clave para un enfoque optimizado.
También vale la pena mencionar que la inteligencia artificial (IA) y las capacidades de aprendizaje automático
han madurado mucho en los últimos años. Los servicios que aprovechan estas capacidades pueden procesar
cantidades masivas de CTI muy rápidamente en comparación con los analistas humanos. Esto puede ayudar
a su organización a gestionar grandes volúmenes de CTI de forma continua. Por supuesto, como muchos
aspectos de la informática y la ciberseguridad, el valor derivado aquí es una función del esfuerzo que se pone
en ello.
Intercambio de inteligencia sobre amenazas
Los equipos de seguridad pueden encontrarse en situaciones en las que desean compartir la CTI que poseen
con los equipos de seguridad de otras organizaciones o viceversa. Hay muchos escenarios diferentes donde
esto sucede. Por ejemplo, una empresa matriz quiere que todos los equipos de seguridad de sus filiales
compartan CTI entre sí. Otro ejemplo es un Centro de Análisis e Intercambio de Información (ISAC) específico
de la industria que facilita el intercambio de CTI entre sus organizaciones miembros. Compartir CTI entre
organizaciones en la misma industria podría hacer que sea más difícil para los atacantes victimizar a miembros
individuales, porque todos tienen los TTP que los actores de amenazas usan cuando apuntan a la industria. Por
esta razón, la industria de servicios financieros y la industria de la salud tienen ISAC como ejemplos.
NIST publicó la Publicación especial 800150, Guía para compartir información sobre amenazas cibernéticas,
que proporciona algunas pautas para compartir CTI, así como una buena lista de escenarios en los que compartir
CTI puede ser útil.
Capitulo 2 33
Los beneficios de compartir CTI que citan los autores son numerosos, incluida la conciencia situacional
compartida , una postura de seguridad mejorada, la maduración del conocimiento y una mayor agilidad
defensiva. ( Publicación especial del NIST 800150 Badger et al, octubre de 2016).
Sin embargo, compartir CTI puede ser más complicado de lo que parece. Compartir CTI no está exento de riesgos.
La información confidencial, como la información de identificación personal (PII), se puede rastrear como parte de
una investigación sobre una intrusión. Si su contexto y sensibilidad se pierden y el CTI se comparte sin las medidas
de seguridad adecuadas, podría usarse como un ejemplo de cómo la organización no cumplió con sus obligaciones
de cumplimiento normativo con estándares como PCI DSS, SOX, GDPR y muchos otros. Para las organizaciones
del sector público que poseen información clasificada que requiere autorizaciones de seguridad para acceder, los
programas de intercambio de información pueden estar llenos de desafíos que hacen que compartir información
sea difícil o imposible. Debido a todas las sensibilidades y posibles minas terrestres, muchas organizaciones que
deciden compartir CTI lo hacen de forma anónima. Sin embargo, la CTI que no se atribuye a una fuente creíble
podría no inspirar la confianza necesaria en su calidad entre los equipos de seguridad que la reciben y no se utiliza.
Si su equipo de seguridad está considerando compartir CTI con otras organizaciones, sugiero que aprovechen la
Publicación especial 800150 del NIST para informar sus deliberaciones.
Protocolos de intercambio de CTI

No puedo hablar de compartir CTI sin mencionar al menos algunos de los protocolos para hacerlo. Recuerde que
los protocolos se utilizan para establecer reglas para una comunicación efectiva. Algunos protocolos están
optimizados para la comunicación de persona a persona, mientras que otros están optimizados para la
comunicación de máquina a máquina (automatizada), la comunicación de máquina a persona, etc. Los tres
protocolos que analizaré en esta sección incluyen Traffic Light Protocol (TLP), Structured Threat Information
eXpression (STIX) y Trusted Automated eXchange of Indicator Information (TAXII).
Protocolo de semáforo
El Traffic Light Protocol (TLP) se ha convertido en un protocolo popular para compartir CTI y otros tipos de
información. TLP puede ayudar a comunicar el tratamiento esperado de CTI compartido entre personas.
No creo que esté especialmente optimizado para el intercambio automatizado de CTI entre sistemas: en realidad
es un protocolo para que los humanos lo usen cuando comparten información potencialmente confidencial entre
sí. Por ejemplo, si un equipo de CTI decide compartir algún CTI con otro equipo de CTI o un CIRT por correo
electrónico o en un documento, podría usar TLP.
TLP ayuda a establecer expectativas entre el remitente de la información y el receptor de la información sobre
cómo se debe manejar la información. El remitente es responsable de comunicar estas expectativas al receptor.
El receptor podría optar por ignorar las instrucciones del remitente.
Por lo tanto, la confianza entre las partes que comparten es muy importante. El remitente confía en el receptor
para respetar los límites de intercambio de información especificados por el remitente. Si el remitente no confía
en que el receptor cumpla con sus expectativas, no debe compartir la CTI con el receptor.
Como sugiere su nombre, TLP utiliza una analogía de semáforo para facilitar que las personas comprendan las
expectativas de los remitentes de información y los límites previstos para compartir información. La analogía del
“semáforo ” en este caso tiene cuatro colores: rojo, ámbar, verde y transparente (PRIMERO, sf). Los colores se
utilizan para comunicar diferentes límites de intercambio de información, según lo especificado por el remitente.
La regla que establece el protocolo es que el color se especifique de la siguiente manera, cuando el CTI se
comunique por escrito (en un correo electrónico o documento): TLP:COLOR. “TLP:” va seguido de uno de los
nombres de color en mayúsculas, por ejemplo, TLP:AMBER.
TLP:RED especifica que la información compartida "no es para divulgación, está restringida solo a los
participantes" (FIRST, nd). Red le dice al receptor que la expectativa del remitente es que la información
compartida no se comparta con otras personas. La información se limita solo a las personas con las que el
remitente la compartió directamente y, por lo general, se comunica verbalmente como un paso más para limitar
cómo se puede compartir la información y dificultar la atribución de la información a un remitente en particular,
protegiendo así su privacidad. Los remitentes usan este color cuando quieren limitar el impacto potencial en su
reputación o privacidad y cuando otras partes no pueden actuar de manera efectiva.
la información compartida.
TLP:AMBER especifica “divulgación limitada, restringida a las organizaciones de los participantes” (FIRST, nd).
A los receptores solo se les permite compartir información de TLP:AMBER dentro de su propia organización y con
clientes que necesiten saber. El remitente también puede especificar más restricciones y limitaciones que espera
que respeten los destinatarios.
TLP:GREEN permite “divulgación limitada, restringida a la comunidad” (FIRST, nd). Los remitentes que
especifican TLP:GREEN permiten que los receptores compartan la información con organizaciones dentro
de su comunidad o industria, pero no mediante el uso de canales abiertos al público en general. Los
remitentes no quieren que la información se comparta fuera de la industria o comunidad del receptor. Esto
se usa cuando la información se puede usar para proteger a la comunidad o industria en general.
Por último, usar TLP:CLEAR significa que la "divulgación no está limitada" (FIRST, nd). En otras palabras, no hay
restricciones para compartir la información que se divulga mediante TLP:CLEAR. Los receptores son libres de
compartir esta información tan ampliamente como lo deseen.
Capitulo 2 35
Esto está destinado a ser utilizado cuando compartir información tiene un riesgo mínimo.
La designación TLP debe usarse al compartir CTI por correo electrónico o documentos. La convención dicta que los
correos electrónicos deben tener la designación TLP en la línea de asunto y en la parte superior del correo electrónico,
mientras que la designación debe aparecer en los encabezados y pies de página de los documentos (CISA, sin fecha).
Esto aclara al receptor cuáles son las expectativas del remitente antes de leer el CTI.
Una vez más, el remitente confía en que el receptor respetará la designación de TLP y los límites de uso compartido que
haya especificado.
Si está investigando en Internet sobre amenazas, es probable que encuentre documentos marcados
con TLP:CLEAR. Por ejemplo, tanto la Oficina Federal de Investigaciones (FBI) como la Agencia de
Seguridad de Infraestructura y Ciberseguridad (CISA) publican informes de amenazas para consumo
público con la etiqueta TLP:CLEAR. Si no conocía TLP antes, estas marcas tendrán más sentido para usted ahora.
STIX y TAXII
Ahora que hemos cubierto un protocolo para uso entre humanos, veamos dos protocolos complementarios que permiten
el intercambio automatizado de CTI, la expresión de información de amenazas estructuradas (STIX) y el intercambio
automatizado confiable de información de indicadores (TAXII). El empleo de protocolos que están optimizados para ser
procesados por máquinas puede ayudar a acelerar drásticamente la difusión de CTI a las organizaciones que pueden
beneficiarse de él y ponerlo en funcionamiento, así como a través de diferentes tipos de tecnologías que saben cómo
consumirlo.
OASIS”, “STIX”, “Structured Threat Information eXpression”, “TAXII” e “Trust ed Automated

eXchange of Indicator Information” son marcas comerciales de OASIS, el consorcio de
estándares abiertos donde las especificaciones “STIX”, “Structured Threat Information
eXpression”, “TAXII” e “Trusted Automated Exchange of Indicator Information” son propiedad
y están desarrolladas. "STIX", " Expresión de información de amenazas estructuradas",
"TAXII" e "Intercambio automatizado de información de indicadores de confianza" son obras
con derechos de autor © de OASIS Open. Reservados todos los derechos.
STIX es un lenguaje o esquema estructurado que ayuda a describir las amenazas de forma estándar. El esquema definido
por STIX incluye objetos centrales y metaobjetos que se utilizan para describir amenazas. La especificación para STIX
versión 2.1 es de 313 páginas. (STIXv2.1) No hace falta decir que es muy completo y se puede utilizar para describir una
amplia gama de amenazas. Para darle una idea de cómo se ve STIX, a continuación encontrará un ejemplo de una
campaña descrita usando STIX.

Todos los datos de este ejemplo son aleatorios y ficticios: se proporcionan para que pueda ver un ejemplo de
el formato.
{
"tipo": "campaña",
"spec_version": "2.1",
"id": "campaña—3a3b4a4b16a30fea543e10fa55c3cc2c",
"created_by_ref": "identidad—e552e362722c33f1bb4a7c4455ace3ef",
"creado": "20220709T15:02:00.000Z",
"modificado": "20220709T15:02:00.000Z",
"name": "Ataques de Attacker1 en la industria minorista",
"description": "Campaña de Attacker1 en la industria minorista".
}
Mientras que STIX se usa para describir amenazas de manera estándar, TAXII es un protocolo de capa de aplicación
que se usa para comunicar esa información entre los sistemas que pueden consumirla. TAXII estandariza la forma en
que las computadoras comparten CTI entre sí. Dicho de otra manera, TAXII es un protocolo diseñado para intercambiar
CTI entre el remitente y el (los) receptor(es) y permite el intercambio automatizado de CTI de máquina a máquina a
través de HTTPS. TAXII es compatible con varios modelos de uso compartido, incluidos concentrador y radio, fuente y
suscriptor, y de igual a igual. Para ello, TAXII especifica dos mecanismos: colecciones y canales.
Esto permite que los productores de CTI admitan modelos de comunicación push y pull. Las colecciones son conjuntos
de datos de CTI que los productores de CTI pueden proporcionar a sus clientes cuando se les solicite.
Los canales permiten a los productores de CTI enviar datos a sus clientes, ya sea un solo cliente o muchos clientes.
Este mismo mecanismo también permite a los clientes recibir datos de muchos productores (TAXIIv2.1). La
especificación de la versión 2.1 de TAXII tiene 79 páginas y contiene todos los detalles necesarios para implementar
participantes de cliente y servidor en los modelos de uso compartido de CTI que mencioné anteriormente.
No es necesario que las amenazas descritas con STIX se compartan a través de TAXII; se puede usar cualquier
protocolo para hacer esto, siempre que el remitente y el receptor lo entiendan y lo admitan.
Un beneficio clave de usar STIX y TAXII es la estandarización. Cuando los productores de CTI publican CTI utilizando
un esquema estandarizado como STIX, facilita que las organizaciones lo consuman, incluso cuando utilizan tecnologías
de diferentes proveedores. Si todos usan la misma forma estándar para describir las amenazas en comparación con
los protocolos propietarios, los consumidores de CTI obtienen el beneficio independientemente de los proveedores de
los que adquieran las capacidades de seguridad cibernética. En otras palabras, los proveedores y equipos de seguridad
cibernética pueden enfocarse en la innovación usando CTI, en lugar de dedicar tiempo a idear formas de modelarlo y
compartirlo. Estos protocolos ayudan a escalar el intercambio de CTI a organizaciones y tecnologías de todo el mundo.
Capitulo 2 37
Razones para no compartir CTI

Muchos de los equipos de seguridad con los que he hablado optan por no compartir CTI con otras organizaciones,
incluso cuando tienen buenas relaciones con ellas. Esto puede parecer contradictorio. ¿Por qué un equipo de
seguridad no querría ayudar a otras organizaciones a detectar amenazas que ya han descubierto en
su propio entorno de TI?
Hay al menos un par de buenas razones para este comportamiento. En primer lugar, dependiendo de la exposición,
la divulgación de CTI podría interpretarse como una admisión o incluso un anuncio de que la organización ha
sufrido una violación de datos. Mantener estos asuntos en secreto minimiza los posibles riesgos legales y de
relaciones públicas, o al menos le da a la organización algo de tiempo para completar su investigación, si hay
alguna en curso. Si la organización ha sufrido una infracción, querrá gestionarla en sus propios términos y en su
propio cronograma, si es posible. En tales escenarios, muchas organizaciones simplemente no compartirán CTI
porque podría terminar interrumpiendo sus procesos de respuesta a incidentes y planes de comunicación de crisis,
lo que podría conducir a litigios y demandas colectivas.
Una segunda razón por la que algunos equipos de seguridad optan por no compartir CTI es que no quieren señalar
a los atacantes que saben que su entorno de TI está comprometido. Por ejemplo, cuando encuentran un archivo
sospechoso de ser malware en uno de sus sistemas, en lugar de cargar una copia del mismo en VirusTotal o en su
proveedor de antimalware para su análisis, prefieren hacer su propio análisis a puerta cerrada para no alertar a los
atacantes. Su razonamiento es que una vez que cargan la muestra de malware a un proveedor de antimalware,
ese proveedor desarrollará firmas para detectar, bloquear y limpiar ese malware y distribuir esas firmas a sus
clientes y muestras de malware a otros proveedores de antimalware. El malware también aparecerá en las
enciclopedias de amenazas en línea de los proveedores de antimalware.
Una "práctica recomendada" que utilizan muchos proveedores de malware es escanear el malware que desarrollan
fuera de línea con varios productos antimalware para garantizar que ninguno de ellos detecte el nuevo malware.
Esto les da una medida de confianza de que aún no son detectados en los entornos de TI de sus víctimas. Sin
embargo, si en algún momento ven que los productos antimalware que prueban detectan su malware , sabrán que
una o más de sus víctimas encontraron su malware, lo enviaron a un proveedor de antimalware y probablemente
estén investigando más para determinar el alcance de la intrusión. Esta es una señal para los atacantes de que
sus víctimas ahora pueden detectar una de las herramientas que han estado usando (el malware) y podrían estar
buscándolos en el entorno comprometido. A medida que las firmas de detección del malware se distribuyen a más
y más sistemas en todo el mundo, las posibilidades de detección aumentan drásticamente.
Posteriormente, muchos equipos de seguridad realizan su propia ingeniería inversa de malware interna y no
compartirán CTI con otras organizaciones, ni siquiera con los proveedores de seguridad de los que obtienen
productos y servicios, hasta que crean que no existe un costo de oportunidad para hacerlo. Este enfoque les
brinda la mejor oportunidad de encontrar y exorcizar a los atacantes antes de que decidan realizar acciones
en los objetivos, como implementar ransomware o malware de limpieza destructivo.
Cómo identificar inteligencia creíble sobre ciberamenazas

Le daré una guía sobre cómo identificar una buena CTI frente a la inteligencia de amenazas cuestionable que veo tan
a menudo en la industria actual. Después de publicar uno de los mejores informes de inteligencia de amenazas de la
industria durante la mayor parte de una década (está bien, admito que soy parcial), aprendí algunas cosas en el
camino que compartiré con ustedes aquí. El tema de esta guía es comprender la metodología que utilizan sus
proveedores de inteligencia de amenazas. Si no le dicen cuál es su metodología, entonces no puede confiar en sus
datos, punto. Además, la única forma en que podrá comprender realmente si la inteligencia de amenazas específica
puede ayudar a su organización y de qué manera es comprender sus fuentes de datos, así como la metodología
utilizada para recopilar e informar los datos; sin este contexto, la inteligencia de amenazas puede ser una distracción
y lo contrario de útil.
Fuentes de datos
Siempre comprenda las fuentes de datos de CTI que está utilizando y cómo los proveedores involucrados están
interpretando los datos. Si se desconoce la fuente de los datos o los proveedores no comparten la fuente de los
datos, entonces simplemente no puede confiar en ellos ni en las interpretaciones basadas en ellos. Por ejemplo, un
proveedor afirma que el 85% de todos los sistemas han sido infectados con éxito por una familia particular de malware.
Pero cuando profundiza en la fuente de los datos utilizados para hacer esta afirmación, resulta que el 85% de los
sistemas que usaron el sitio web de limpieza de malware en línea del proveedor estaban infectados con el malware
al que se hace referencia. Tenga en cuenta que "85% de todos los sistemas" es una extrapolación dramática de "85%
de todos los sistemas que usaron su herramienta en línea".
Además, la herramienta en línea solo se ofrece en inglés de EE. UU., lo que significa que es menos probable que los
consumidores que no hablan inglés la usen, incluso si saben que existe. Finalmente, descubre que la herramienta de
detección de antivirus de escritorio del proveedor remite a los usuarios a la herramienta en línea para desinfectarla
cuando encuentra sistemas infectados con la amenaza. El proveedor hace esto para generar conciencia de que su
excelente herramienta en línea está disponible para sus clientes. Esto distorsiona los datos, ya que se sabía que el
100% de los usuarios referidos a la herramienta en línea desde la herramienta antivirus de escritorio estaban
infectados con esa amenaza. No puedo contar cuántas veces he visto acrobacias como esta a lo largo de los años.
Capitulo 2 39
Profundice siempre en las fuentes de datos para comprender qué significan realmente los datos para usted.
Cuanto más familiarizado esté con las fuentes de datos, más fácil le resultará determinar el verdadero valor
de esos datos para su organización. En el Capítulo 4, La evolución del malware, dedico mucho tiempo a
describir las complejidades de las fuentes de datos utilizadas en ese capítulo. Esta es la única manera de
comprender la imagen que brindan los datos, en relación con su organización y los riesgos que le preocupan.
Por ejemplo, si trabaja en una organización del sector público en Japón, ¿qué tan valioso es para usted CTI que se
enfoca en una industria vertical específica en el sector privado en los Estados Unidos? La respuesta es que no lo sabrá
hasta que comprenda las fuentes de datos y lo que podrían significar para su organización.
La especificidad es tu amiga en este contexto. Comprender de dónde y cómo se recopilaron los datos, las limitaciones
de las fuentes de datos y las suposiciones y sesgos subyacentes presentes durante el procesamiento de los datos son
claves para comprender cómo el CTI resultante podría ayudar a su organización. CTI es mucho menos creíble sin el
contexto que te permite entenderlo. Los proveedores de CTI confiables se complacen en brindarle este contexto. Sin
embargo, es posible que no ofrezcan esta información y es posible que deba solicitarla. Proporcionar dicha información
tiende a resaltar las limitaciones de la CTI y las capacidades del proveedor de CTI. Además, descubrí que no todo el
mundo es un conocedor de los puntos más finos de CTI; estar preparado para hacer sus propias preguntas suele ser
la mejor manera de obtener el contexto que necesita para comprender verdaderamente la CTI.
Períodos de tiempo
Al consumir inteligencia de amenazas, es muy importante comprender la escala de tiempo y los períodos de tiempo de
los datos . ¿Se proporcionan los datos y las perspectivas de un período de días, semanas, meses, trimestres o años?
La respuesta a esta pregunta ayudará a proporcionar el contexto necesario para comprender la inteligencia. Los
eventos de unos pocos días tendrán potencialmente un significado muy diferente para su organización que una
tendencia a largo plazo durante un período de años.
Las anomalías generalmente justificarán un tratamiento de riesgo diferente al de los patrones establecidos. Además, las
conclusiones que se pueden sacar de los datos de CTI se pueden modificar drásticamente en función de los períodos
de tiempo que utiliza el proveedor en su informe.
Permítanme proporcionarles un escenario de ejemplo. Supongamos que un proveedor informa sobre cuántas
vulnerabilidades se explotaron en sus productos durante un período determinado. Si los datos se informan en períodos
de tiempo secuenciales regulares, como trimestralmente, la tendencia se ve muy mal ya que se evidencian grandes
aumentos.
Pero en lugar de informar la tendencia utilizando períodos trimestrales secuenciales, la tendencia se ve mucho mejor
cuando se compara el trimestre actual con el mismo trimestre del año pasado; en realidad podría haber una disminución
en la explotación de vulnerabilidades en el trimestre actual en comparación con el mismo trimestre del año pasado.
Esto pone una luz positiva sobre el proveedor, a pesar de un aumento en la explotación de vulnerabilidades en sus
productos trimestre tras trimestre.
Otra posible señal de alerta es cuando ve datos de informes de proveedores que no son para un período de tiempo
normal, como mensual, trimestral o anual. En cambio, usan un período de meses que parece un poco aleatorio. Si el
período de tiempo es irregular o la razón por la que se usa no es obvia, la justificación debe documentarse con el CTI.
Si no es así, pregúntele al proveedor por qué eligió los períodos de tiempo que eligió. A veces, encontrará que los
proveedores usan un período de tiempo específico porque hace que su historia sea más dramática, atrayendo más
atención, si esa es su agenda. Alternativamente, el período seleccionado podría ayudar a restar importancia a las
malas noticias al minimizar los cambios en los datos.
Comprender por qué los datos se informan en escalas de tiempo y períodos específicos le dará una idea de la
credibilidad de los datos, así como de la agenda del proveedor que se los proporciona.
Reconociendo el bombo
Uno de los mayores errores que he visto cometer en las organizaciones al consumir CTI es aceptar las afirmaciones
de sus proveedores sobre el alcance, la aplicabilidad y la relevancia de sus datos. Por ejemplo, un proveedor de CTI
publica datos que afirman que el 100 % de los ataques en un período de tiempo específico involucraron ingeniería
social o explotaron una vulnerabilidad específica. El problema con tales afirmaciones es que nadie en el mundo puede
ver el 100% de todos los ataques, punto.
Tendrían que ser omniscientes para ver todos los ataques que ocurren en todas partes del mundo simultáneamente,
en todos los sistemas operativos y plataformas en la nube, en todos los navegadores y aplicaciones. Del mismo modo,
afirmaciones como que el 60% de todos los ataques fueron perpetrados por un grupo APT específico no son útiles. A
menos que tengan conocimiento del 100 % de los ataques, no pueden hacer afirmaciones creíbles sobre las
características del 60 % de ellos. Una afirmación sobre las características de todos los ataques o un subconjunto que
requiere el conocimiento de todos los ataques, incluso cuando se hace referencia a períodos de tiempo específicos,
ubicaciones específicas y vectores de ataque específicos, simplemente no es posible ni creíble. Una buena prueba de
fuego para CTI es preguntarse, ¿el proveedor tiene que ser omnisciente para hacer esta afirmación? Aquí es donde
comprender las fuentes de datos y los períodos de tiempo lo ayudará a reducir la exageración y obtener cualquier
valor que la inteligencia pueda tener.

Capitulo 2 41
Muchas veces, el proveedor que publica los datos no hace tales afirmaciones directamente en sus informes
de inteligencia de amenazas, pero la forma en que se informa la nueva inteligencia en los titulares se
generaliza o se hace más dramática para llamar la atención. No culpe a los proveedores de CTI por la forma
en que se informan las noticias, ya que esto suele estar fuera de su control. Pero si hacen tales afirmaciones
directamente, reconózcalas y ajuste el contexto en su mente apropiadamente. Durante muchos años, aparecí
en los titulares de todo el mundo hablando y escribiendo sobre amenazas con regularidad, pero siempre
tuvimos mucho cuidado de no pasarnos de la raya a partir de conclusiones respaldadas por los datos. Hacer
afirmaciones más audaces habría requerido omnisciencia y omnipotencia.
Predicciones sobre el futuro

Estoy seguro de que ha visto a algunos proveedores hacer predicciones sobre lo que sucederá en el panorama
de amenazas en el futuro. Un truco que han utilizado algunos proveedores de CTI está nuevamente relacionado
con los períodos de tiempo. Supongamos que estoy publicando un informe de inteligencia de amenazas sobre
el último período de 6 meses que abarca de enero a junio. En el momento en que se recopilan los datos para
este período y se escribe y publica el informe, pueden haber pasado uno o dos meses. Ahora estamos en
septiembre. Si hago una predicción sobre el futuro en este informe, tengo dos meses de datos de julio y agosto
que me dicen lo que ha estado sucediendo desde el final del período del informe.
Si mi predicción se basa en lo que los datos nos dicen que ya sucedió en julio y agosto, los lectores del informe
creerán que en realidad predije el futuro con precisión, lo que refuerza la idea de que sabemos más sobre el
panorama de amenazas que nadie. Comprender cuándo se realizó la predicción en relación con el período de
tiempo en el que se centró lo ayudará a decidir qué tan creíbles son la predicción y los resultados, y qué tan
confiable es el proveedor que hace la predicción. Recuerde, las predicciones sobre el futuro son conjeturas: lo
que sucedió en el pasado no define lo que puede suceder en el futuro.
motivos de los vendedores

La confianza es una combinación de credibilidad y carácter. Puede usar ambos para decidir qué tan confiables
son sus proveedores. La transparencia en torno a las fuentes de datos de CTI, las escalas de tiempo, los
períodos de tiempo y las predicciones sobre el futuro pueden ayudar a los proveedores a demostrar que son
creíbles. Sus motivos comunican algo sobre su carácter. ¿Quieren entablar una relación con su organización
como asesores de confianza o su interés se limita a una transacción financiera? Hay un lugar para ambos tipos
de proveedores al crear un programa de seguridad cibernética, pero saber qué proveedores se incluyen en
cada categoría puede ser útil, especialmente durante las actividades relacionadas con la respuesta a incidentes,
cuando hay presión. Es importante saber en quién puede confiar para obtener ayuda real cuando la necesite.
Esas son algunas de las ideas que puedo ofrecerle a partir de 10 años de publicar informes de inteligencia de
amenazas. Una vez más, lo importante aquí es comprender la metodología y las fuentes de datos de la CTI que
consume; este contexto no es opcional. Un último consejo: no consuma inteligencia de amenazas que no cumpla
con este criterio. Hay demasiado miedo, incertidumbre, duda y complejidad en la industria de TI. Tienes que ser
selectivo con respecto a quién te da consejos.
Espero que hayan disfrutado este capítulo. En los últimos años, la industria de CTI se ha disparado. Encontrar
fuentes confiables de CTI no debería ser un desafío para los programas de ciberseguridad bien financiados. La
CTI se está integrando cada vez más en los productos y servicios de ciberseguridad, lo que significa que proteger,
detectar y responder a las amenazas debería ser más fácil y rápido que nunca. Sin embargo, tengo que
preguntarme si esto es cierto, ¿cómo es que los atacantes tienen más éxito ahora que nunca? Hay muchos
ejemplos históricos que nos enseñan que la inteligencia de amenazas no es suficiente por sí sola para mitigar los
ataques: los defensores deben estar dispuestos a actuar según la inteligencia que tienen y necesitan las
capacidades para hacerlo de manera efectiva. A pesar de la proliferación de CTI, las organizaciones aún necesitan
estrategias de ciberseguridad efectivas para tener éxito. Para desarrollar una estrategia efectiva para su
organización, es útil comprender primero los tipos de amenazas que enfrenta y cómo operan. Este es el tema de
los próximos tres capítulos de este libro.
Resumen
Cyber Threat Intelligence (CTI) proporciona a las organizaciones datos e información sobre posibles amenazas
cibernéticas. Esas amenazas pueden incluir varias categorías de malware, explotación de capacidades de
vulnerabilidades, ataques basados en la web, ataques de denegación de servicio distribuido (DDoS) , ataques de
ingeniería social y otros. Open Source Threat Intelligence (OSINT) aprovecha las fuentes de datos disponibles
públicamente, como las redes sociales, las noticias, los documentos judiciales y los registros de arrestos, la
información divulgada por los atacantes sobre sus víctimas, la actividad en foros ilícitos y muchos otros.
Los programas de ciberseguridad pueden hacer uso de CTI de varias maneras, incluso en los Centros de
operaciones de seguridad (SOC), para informar las investigaciones de los Equipos de respuesta a incidentes de
ciberseguridad (CIRT) , para informar la búsqueda de amenazas, los esfuerzos de los equipos rojo, azul y púrpura,
y muchos otros. Comprender las tácticas, técnicas y procedimientos (TTP) que emplean los atacantes puede
proporcionar algunas ideas concretas sobre cómo pueden mitigarse. Una táctica es la razón por la que el atacante
realiza una acción en particular. Muchos equipos de seguridad también usan indicadores de compromiso (IOC)
para ayudar a determinar si sus entornos de TI empresariales se han visto comprometidos. Donde los TTP pueden
ayudar a proteger, detectar y responder a los ataques, los IOC pueden ayudar al compromiso posterior para tratar
de determinar cuándo y cómo ocurrió el compromiso inicial y qué hicieron los atacantes con su acceso ilícito después.
Capitulo 2 43
El Traffic Light Protocol (TLP) se ha convertido en un protocolo popular para compartir CTI y otros tipos de información.
La analogía del “semáforo” en este caso tiene cuatro colores: rojo, ámbar, verde y transparente.
Los colores se utilizan para comunicar diferentes límites de intercambio de información, según lo especificado por el
remitente.
Este capítulo proporcionó algo de contexto para ayudarlo a comprender el análisis de varias amenazas en los siguientes
tres capítulos: Capítulo 3, Uso de tendencias de vulnerabilidad para reducir riesgos y costos, Capítulo 4, La evolución del
malware y Capítulo 5, Amenazas basadas en Internet.
Referencias
• Noticias de la BBC. (2013). “Microsoft ve un aumento en los ataques de red”. Noticias de la BBC. Obtenido de https://
www.bbc.com/news/av/business22348290.
• Tejón, L.; Johnson, C.; Skorupka, C.; Snyder, J.; Watermire, D. (octubre de 2016). “Publicación especial NIST
800150”. NIST. Obtenido de https://nvlpubs.nist.gov/nistpubs/
Publicaciones especiales/NIST.SP.800150.pdf.
• MITRE ATT&CK® (sin fecha). Obtenido de https://attack.mitre.org/.
• “Publicación Especial NIST 80053 Revisión 5”. (septiembre de 2020). NIST. Obtenido de
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.80053r5.pdf.
• PRIMERO. (Dakota del Norte). Obtenido de https://www.first.org/tlp/.
• CISA. (Dakota del Norte). Obtenido de https://www.cisa.gov/tlp.
• STIX Versión 2.1. (10 de junio de 2021). Estándar OASIS. https://docs.oasisopen.org/cti/
stix/v2.1/os/stixv2.1os.html. Última etapa: https://docs.oasisopen.org/cti/

stix/v2.1/stixv2.1.html.
• TAXII™ Versión 2.1. (10 de junio de 2021). Estándar OASIS. https://docs.oasisopen.org/cti/

taxii/v2.1/os/taxiiv2.1os.html. Última etapa: https://docs.oasisopen.org/cti/
taxii/v2.1/taxiiv2.1.html.

3
Uso de tendencias de vulnerabilidad para
Reduzca el riesgo y los costos
Las vulnerabilidades representan un riesgo y un gasto para todas las organizaciones. Los proveedores que se
toman en serio la reducción tanto del riesgo como de los costos para sus clientes se enfocan en reducir la
cantidad de vulnerabilidades en sus productos y trabajan en formas de hacer que sea difícil y costoso para los
atacantes explotar a sus clientes, lo que reduce el retorno de la inversión de los atacantes. La identificación
de los proveedores y los productos que han tenido éxito en hacer esto puede llevar mucho tiempo y ser difícil.
En este capítulo, le proporcionaré información básica valiosa y un análisis en profundidad de cómo algunos
de los líderes de la industria han manejado las vulnerabilidades en sus productos durante las últimas dos
décadas, centrándose en los sistemas operativos y los navegadores web. Presento un marco de mejora de
vulnerabilidades que puede ayudarlo a identificar proveedores y productos que han estado reduciendo riesgos
y costos para sus clientes. Estos datos y análisis pueden informar la estrategia de gestión de vulnerabilidades
de su organización.
En este capítulo, cubriremos los siguientes temas:
• Una introducción a la gestión de vulnerabilidades
• Introducción de un marco de mejora de la gestión de vulnerabilidades
• Examinar las tendencias de divulgación de vulnerabilidades para proveedores, sistemas operativos y

navegadores web
• Orientación sobre programas de gestión de vulnerabilidades
Empecemos por ver qué es la gestión de vulnerabilidades.

46 Uso de tendencias de vulnerabilidad para reducir riesgos y costos
Introducción
En los últimos 20 años, las organizaciones han enfrentado el desafío de administrar un volumen continuo de nuevas
vulnerabilidades en software y hardware. Los atacantes y el malware intentan constantemente explotar vulnerabilidades
sin parches en los sistemas de todas las industrias y en todas partes del mundo. Las vulnerabilidades son moneda
corriente para muchos grupos interesados, incluidos los investigadores de seguridad, la industria de administración de
vulnerabilidades, los gobiernos, varias organizaciones comerciales y, por supuesto, los atacantes y proveedores de
malware. Estos grupos tienen diferentes motivaciones y objetivos, pero todos valoran las nuevas vulnerabilidades y
algunos están dispuestos a pagar generosamente por ellas. Tuve un asiento de primera fila en la zona cero durante el
período tumultuoso en el que los gusanos y otro malware comenzaron a explotar las vulnerabilidades del software de
Microsoft a gran escala. Después de trabajar en el equipo de soporte de redes empresariales de Microsoft durante
algunos años, me pidieron que ayudara a crear un nuevo equipo de respuesta a incidentes de seguridad orientado al
cliente. Acepté ese trabajo el jueves 23 de enero de 2003. Dos días después, el sábado 25 de enero, SQL Slammer llegó
a Internet, interrumpiendo las redes en todo el mundo. Ese sábado por la mañana, subí a mi auto para ir a la oficina, pero
tuve que detenerme para cargar gasolina. Tanto el cajero automático como los surtidores de la gasolinera estaban
desconectados debido a “problemas de red”. En ese momento, me di cuenta de cuán generalizado y serio era ese
ataque. Luego, un día de agosto de 2003, Blaster interrumpió Internet en mayor medida que SQL Slammer. Luego, en el
transcurso del año siguiente, siguieron las variantes de Blaster, así como MyDoom, Sasser y otros ataques de malware
generalizados.
Resulta que millones de personas estaban dispuestas a hacer doble clic en un archivo adjunto de correo electrónico con
la etiqueta "MyDoom". La mayoría de estos ataques utilizaron vulnerabilidades sin parches en productos de Microsoft para
infectar sistemas y propagarse. Todo esto sucedió antes de que existiera Windows Update, o cualquiera de las
herramientas que están disponibles hoy en día para el mantenimiento del software. Debido a que Microsoft tuvo que
lanzar múltiples actualizaciones de seguridad para abordar las vulnerabilidades subyacentes en los componentes que
usaba Blaster, muchos departamentos de TI comenzaron un patrón de comportamiento a largo plazo, retrasando la
aplicación de parches a los sistemas para evitar parchear los mismos componentes repetidamente y reiniciar los sistemas
repetidamente. La mayoría de los sistemas basados en Windows conectados a Internet tampoco ejecutaban software
antivirus en esos días, y muchos de ellos que lo hacían no tenían instaladas las firmas más recientes. Trabajar en un
equipo de respuesta a incidentes de seguridad orientado al cliente, respaldar las actualizaciones de seguridad y ayudar
a los clientes empresariales con infecciones de malware y piratas informáticos era un trabajo muy difícil en esos días: se necesitaba una piel d
Posteriormente, tuve la oportunidad de aprender mucho sobre malware, vulnerabilidades y exploits.

en este papel.
Más adelante en mi carrera en Microsoft, administré las comunicaciones de marketing para Microsoft Security Response
Center (MSRC), Microsoft Security Development Lifecycle (SDL) y Microsoft Malware Protection Center (MMPC).
Capítulo 3 47
El MSRC es el grupo de Microsoft que administra los informes de vulnerabilidades y los informes de ataques entrantes.
El MMPC es lo que en ese entonces llamaban el laboratorio de investigación y respuesta antivirus de Microsoft.
SDL es una metodología de desarrollo de software que se instituyó en Microsoft en los años que siguieron a estos
devastadores ataques de gusanos. Aprendí mucho sobre vulnerabilidades, exploits, malware y atacantes en los 8 o 9
años que trabajé en esta organización, llamada Trustworthy Computing. A menudo me preguntan si las cosas están
mejor hoy que hace 5 o 10 años. Este capítulo está dedicado a responder a esta pregunta y proporcionar algunas
ideas sobre cómo han cambiado las cosas desde la perspectiva de la gestión de vulnerabilidades. También quiero
brindarle una forma de identificar proveedores y productos que han estado reduciendo el riesgo y los costos para sus
clientes.
Introducción a la gestión de vulnerabilidades

Antes de sumergirnos en las tendencias de divulgación de vulnerabilidades de las últimas dos décadas, permítanme
brindarles una introducción rápida sobre la administración de vulnerabilidades para que sea más fácil comprender los
datos y el análisis que proporciono, y cómo algunos equipos de administración de vulnerabilidades usan dichos datos.
Hay muchas definiciones diferentes de lo que es una vulnerabilidad. Dado que proporciono una gran cantidad de
datos en este capítulo basados en las vulnerabilidades y exposiciones comunes (CVE) de MITRE según lo informado
por las autoridades de numeración de CVE, así es como definen una vulnerabilidad en ese contexto:
Una debilidad en la lógica computacional (p. ej., código) que se encuentra en los componentes de
software y hardware que, cuando se aprovecha, tiene un impacto negativo en la confidencialidad,
la integridad o la disponibilidad. La mitigación de las vulnerabilidades en este contexto normalmente
implica cambios en la codificación, pero también podría incluir cambios en las especificaciones o
incluso desuso de las especificaciones (p. ej., la eliminación de los protocolos o la funcionalidad
afectados en su totalidad)”. (CVE, 2020)
Si se pregunta cómo es realmente una vulnerabilidad, este pequeño fragmento de código es un buen ejemplo, como
explica su autor a continuación. Las vulnerabilidades, como este ejemplo, pueden ser errores obvios identificados por
los desarrolladores que revisan el código, las herramientas de desarrollo que utilizan o las pruebas de seguridad de
aplicaciones estáticas (SAST) y las pruebas de seguridad de aplicaciones dinámicas (DAST). Otras vulnerabilidades
pueden ser muy sutiles y difíciles de encontrar.
función vacía ( índice int, valor int )

{
charbuf [4];
buf[índice] = valor;
}
Supongamos que los argumentos index y value provienen de una llamada a recv() que
lee un paquete de Internet. ¿Es esto un error de seguridad? Diablos, sí. El atacante
controla todo sobre ese pobre y viejo búfer. Incluso con /GS y ASLR en su lugar, esto
sería un error grave y se solucionaría lo antes posible”. (Howard, 9 de mayo de 2021)
Cuando se descubre una vulnerabilidad en un producto de software o hardware lanzado y se informa al

proveedor propietario del producto o servicio vulnerable, en última instancia, se le asigna un identificador
CVE a la vulnerabilidad en algún momento. MITRE Corporation inició un catálogo de todos los CVE,
llamado Lista CVE, en 1999. Se puede acceder a la Lista CVE en https://cve.mitre.org/cve/search_cve_list.html.
La Base de Datos Nacional de Vulnerabilidad (NVD) de EE. UU . fue establecida en 2005 por el Instituto Nacional de
Estándares y Tecnología (NIST). El NVD importa datos de la Lista CVE y le agrega metadatos (incluidas métricas e
información de puntuación) (CVE, 2020). El NVD se puede utilizar para rastrear vulnerabilidades divulgadas públicamente
en todo tipo de productos de software y hardware en toda la industria. El NVD es una base de datos disponible
públicamente a la que se puede acceder en https://
nvd.nist.gov.
La fecha exacta en que se asigna un identificador CVE a una vulnerabilidad depende de muchos factores diferentes, a
los que podría dedicarse un capítulo completo de este libro. De hecho, coescribí un documento técnico de Microsoft
sobre este tema llamado Administración de vulnerabilidades de software en Microsoft, que describía por qué podría
tomar un tiempo relativamente largo publicar actualizaciones de seguridad para los productos de Microsoft. Parece que
este documento ha desaparecido del Centro de descarga de Microsoft con las arenas del tiempo.
Sin embargo, los siguientes son algunos de los factores que explican por qué puede pasar mucho tiempo entre que un
proveedor recibe un informe de una vulnerabilidad y publica una actualización de seguridad para ella:
• Identificación del error: algunos errores solo aparecen en condiciones especiales o en los entornos de TI más
grandes. El proveedor puede tardar un tiempo en reproducir el error y clasificarlo.
Además, la vulnerabilidad informada podría existir en otros productos y servicios que utilicen los mismos
componentes o componentes similares. Todos estos productos y servicios deben repararse simultáneamente
para que el proveedor no produzca inadvertidamente una vulnerabilidad de día cero en su propia línea de
productos. Discutiré las vulnerabilidades de día cero más adelante en este capítulo.
• Identificar todas las variantes: corregir el error informado puede ser sencillo y fácil.
Sin embargo, encontrar todas las variaciones del problema y solucionarlas también es importante, ya que
evitará la necesidad de volver a publicar actualizaciones de seguridad o lanzar múltiples actualizaciones para
abordar las vulnerabilidades en el mismo componente. Esta puede ser la actividad que lleva más tiempo al
corregir vulnerabilidades.
Capítulo 3 49
• Revisiones y pruebas de código: Asegurarse de que el código actualizado solucione realmente la vulnerabilidad y no
introduzca más errores y vulnerabilidades es importante y, a veces, requiere mucho tiempo.
• Pruebas funcionales: esto garantiza que la solución no afecte la funcionalidad del producto ; los clientes no aprecian cuando
esto sucede.
• Pruebas de compatibilidad de aplicaciones: en el caso de un sistema operativo o navegador web, es posible que los
proveedores deban probar miles de aplicaciones, controladores y otros componentes para asegurarse de que no
rompan su ecosistema cuando publiquen la actualización de seguridad. Por ejemplo, la matriz de pruebas de integración
para Windows es enorme e incluye miles de las aplicaciones más comunes que se ejecutan en la plataforma.
• Pruebas de lanzamiento: asegurar que la distribución e instalación de la actualización de seguridad funcione
como se esperaba y no hace que los sistemas no puedan arrancar o sean inestables.
Es importante darse cuenta de que la fecha en que se asigna un identificador CVE a una vulnerabilidad no está necesariamente
relacionada con la fecha en que el proveedor publica una actualización que aborda la vulnerabilidad subyacente; es decir, estas
fechas pueden ser diferentes. El atractivo de la notoriedad que conlleva anunciar el descubrimiento de una nueva vulnerabilidad
importante lleva a algunos investigadores de seguridad a publicar los detalles antes de que los proveedores puedan corregir las
fallas. El mejor escenario típico es cuando la divulgación pública de una vulnerabilidad ocurre en la misma fecha en que el
proveedor publica una actualización de seguridad que aborda la vulnerabilidad. Esto reduce la ventana de oportunidad para que
los atacantes exploten la vulnerabilidad al tiempo que le toma a cada organización probar e implementar la actualización en su
entornos de TI.
Un ejemplo de un identificador CVE es CVE20188653. Como puede ver en el identificador de CVE, el número 8653 se asignó a
la vulnerabilidad con la que estaba asociado en 2018. Cuando buscamos este identificador de CVE en la Lista de CVE, podemos
obtener acceso a información básica que incluye una breve descripción, referencias y la fecha en que se agregó el CVE a la lista.
Aquí está la descripción del CVE:
Existe una vulnerabilidad de ejecución remota de código en la forma en que el motor de secuencias de
comandos maneja los objetos en la memoria en Internet Explorer, también conocida como "vulnerabilidad
de daños en la memoria del motor de secuencias de comandos". Esto afecta a Internet Explorer 9, Internet
Explorer 10 e Internet Explorer 11”. (CVE)

Al buscar el mismo ID de CVE en el NVD, podemos obtener acceso a más detalles sobre la capacidad de
vulnerabilidad con la que está asociado. Los ejemplos incluyen el puntaje de gravedad de la vulnerabilidad, si se
puede acceder a la vulnerabilidad de forma remota y su impacto potencial en la confidencialidad, la integridad y la
disponibilidad.
¿Para qué se utiliza esta información adicional que proporciona el NVD? El riesgo es la combinación de probabilidad
e impacto. En el contexto de las vulnerabilidades, el riesgo es la combinación de la probabilidad de que una
vulnerabilidad pueda explotarse con éxito y el impacto en el sistema si se explota.
Se asigna una puntuación a cada CVE en el NVD que representa este cálculo de riesgo para la vulnerabilidad. El
Sistema de puntuación de vulnerabilidad común (CVSS) se utiliza para estimar el riesgo de cada vulnerabilidad en el
NVD. El Grupo de Interés Especial (SIG) del CVSS del Foro de Equipos de Seguridad y Respuesta a Incidentes
(FIRST ) es el custodio del CVSS con el objetivo de mejorarlo con el tiempo.

Puede encontrar más información sobre este SIG en https://www.first.org/cvss/.
Para calcular el riesgo, el CVSS utiliza "métricas de explotación", como el vector de ataque, la complejidad del ataque,
los privilegios necesarios y la interacción del usuario (FIRST, 2019). Para calcular una estimación del impacto en un
sistema si se explota con éxito una vulnerabilidad, el CVSS utiliza "métricas de impacto", como el impacto esperado
en la confidencialidad, la integridad y la disponibilidad (FIRST, 2019).
Las métricas de explotabilidad y las métricas de impacto se proporcionan en los detalles de NVD en cada CVE.
El CVSS utiliza estos detalles en algunos cálculos matemáticos simples para generar una puntuación base para cada
vulnerabilidad (NIST, sin fecha).
Los profesionales de gestión de vulnerabilidades pueden refinar aún más las puntuaciones base de las vulnerabilidades
mediante el uso de métricas en un grupo de métricas temporales y un grupo ambiental. El grupo de métrica temporal
refleja el hecho de que la puntuación base puede cambiar con el tiempo a medida que se dispone de nueva
información , por ejemplo, cuando el código de prueba de concepto para una vulnerabilidad se pone a disposición del público.
Las métricas ambientales se pueden utilizar para reducir la puntuación de un CVE debido a la existencia de miti
factores de activación o controles en un entorno de TI específico. Por ejemplo, el impacto de una vulnerabilidad podría
atenuarse porque la organización ya había implementado una mitigación para la vulnerabilidad en sus esfuerzos
anteriores para fortalecer su entorno de TI. Todas las tendencias de divulgación de vulnerabilidades que discuto en
este capítulo se basan en las puntuaciones base para CVE.
El CVSS ha evolucionado con el tiempo: se han lanzado algunas versiones diferentes a lo largo del tiempo, como
v2, v3 y v3.1. Las calificaciones de la versión actual, la versión 3.1, se representan en el siguiente diagrama
(FIRST, 2019). Las calculadoras NVD CVSS para CVSS v3 y v3.1 están disponibles para ayudar a las
organizaciones a calcular las puntuaciones de vulnerabilidad utilizando métricas temporales y ambientales (NIST, sin fecha).
Capítulo 3 51
Los puntajes se pueden convertir en calificaciones como bajo, medio, alto y crítico para que sea más fácil de administrar
que usar puntajes numéricos granulares (FIRST, 2019).
Figura 3.1: Descripciones de calificación para rangos de puntajes de CVSS versión 3.1
Las vulnerabilidades con puntajes más altos tienen mayores probabilidades de explotación y/o mayores impactos en los
sistemas cuando se explotan. Dicho de otra manera, cuanto mayor sea la puntuación, mayor será el riesgo. Esta es la
razón por la que muchos equipos de administración de vulnerabilidades usan estos puntajes y clasificaciones para
determinar qué tan rápido probar e implementar actualizaciones de seguridad y/o mitigaciones de vulnerabilidades en
sus entornos, una vez que las vulnerabilidades se han divulgado públicamente.
Otro término importante para entender es la vulnerabilidad de "día cero". Una vulnerabilidad de día cero es una
vulnerabilidad que se ha divulgado públicamente antes de que el proveedor responsable haya publicado una actualización
de seguridad para abordarla. Estas vulnerabilidades son las más valiosas de todas las vulnerabilidades , con atacantes
y gobiernos dispuestos a pagar sumas relativamente altas por ellas (potencialmente un millón de dólares o más por una
explotación funcional).
Un escenario que los equipos de gestión de vulnerabilidades temen es cuando se divulga públicamente una vulnerabilidad
de día cero con clasificación crítica en software o hardware que tienen en su entorno. Esto significa que el riesgo de
explotación podría ser muy alto y que una actualización de seguridad que podría evitar la explotación de la vulnerabilidad
no está disponible públicamente. A veces, en estos escenarios, existen "soluciones alternativas" que se pueden
implementar para ayudar a que la explotación de la vulnerabilidad sea más difícil o imposible. Las soluciones alternativas,
como las configuraciones específicas del sistema que evitan la explotación, generalmente están destinadas a ser
temporales. Después de todo, si lo único que impide la explotación es un ajuste de configuración, ¿qué sucede si ese
ajuste se cambia sin darse cuenta? A menudo, cambiar una opción de configuración como solución alternativa también
desactiva la funcionalidad que estaba disponible anteriormente.
La única forma de abordar la vulnerabilidad con la mayor confianza y el menor impacto es instalar una actualización que
la solucione.
Un escenario aún peor es cuando un proveedor publica una actualización de seguridad para una vulnerabilidad clasificada
crítica y explotable, pero la actualización no corrige la vulnerabilidad por completo. En este escenario, la existencia de la
vulnerabilidad es de conocimiento público, y la actualización de seguridad disponible públicamente que no es 100% efectiva
esencialmente dibuja un mapa de la vulnerabilidad para que los atacantes la usen. Por lo general, en tales escenarios, el
código de explotación para tal vulnerabilidad está disponible públicamente y circula ampliamente en Internet, muy
rápidamente.
Este escenario puede sonar teórico, pero desafortunadamente, ha ocurrido varias veces en las últimas dos décadas. Quizás
el último y mejor ejemplo son las temidas vulnerabilidades "Log4j" (CVE202144228 y CVE202145046). Esta
vulnerabilidad estaba en la omnipresente biblioteca de registro de Java Apache Log4j2. CVE202144228 tiene una
puntuación CVSS de 10 "perfecta", lo que significa que es fácil de explotar y puede hacer que los atacantes tomen el
control total de los sistemas afectados. Es tan fácil de explotar que algunos profesionales de la ciberseguridad lo apodaron
"Log4Shell", una referencia irónica a la capacidad de ejecutar de forma remota cualquier comando en sistemas
comprometidos con esta vulnerabilidad.
El Centro de Coordinación CERT del Instituto de Ingeniería de Software de la Universidad Carnegie Mellon lo describió de
esta manera:
Apache Log4j permite búsquedas JNDI inseguras que podrían permitir que un atacante
remoto no autenticado ejecute código arbitrario con los privilegios de la aplicación Java
vulnerable usando Log4j”. ( Centro de Coordinación CERT del Instituto de Ingeniería
de Software, Universidad Carnegie Mellon 20211215)
Debido a que esta vulnerabilidad estaba en una biblioteca de software muy popular, afectó literalmente a miles de productos
que aprovecharon esa biblioteca en sistemas operativos como Windows, Linux y macOS.
Para muchos equipos de seguridad, la ubicuidad de Log4j y la amplia variedad de lugares en los que podría estar presente
en los entornos de TI empresariales dificultaron su búsqueda y solución. Las organizaciones que tenían prácticas de
gestión de activos inmaduras o inventarios de activos imperfectos (casi todos) se quedaron con una bomba de relojería en
sus manos. Posteriormente, muchos de los clientes a los que asesoré gestionaron la reparación de esta vulnerabilidad de
la misma manera que gestionarían un incidente de ciberseguridad activo. El uso de procesos de respuesta a incidentes en
lugar de sus procesos de gestión de vulnerabilidades permitió a estos equipos considerar la remediación como una
prioridad principal para sus organizaciones y obtener acceso a recursos acordes con esta declaración.
Sin embargo, para empeorar las cosas, se tuvo que lanzar más de una actualización de seguridad para abordar
completamente esta vulnerabilidad calificada como crítica, que ya estaba en uso activo por parte de los atacantes en ese momento.
Capítulo 3 53
CVE202145046 declaró: "Se descubrió que la solución para abordar CVE202144228 en Apache Log4j
2.15.0 estaba incompleta en ciertas configuraciones no predeterminadas" (CVE, 14/12/2021).
Estos factores resultaron en mucho más trabajo para los equipos de ciberseguridad y TI que remediar una
vulnerabilidad típica clasificada como crítica. Este escenario ocurrió en la Navidad de 2021 y se prolongó
durante el nuevo año, lo que obligó a muchos equipos de seguridad a trabajar durante la temporada navideña
para solucionarlo . Todos estos factores conspiraron para agotar a muchos profesionales de ciberseguridad y
TI. Meses después, las versiones vulnerables de Log4j continuaron ganándose el cariño de los equipos de
ciberseguridad y TI de todo el mundo, al continuar "apareciendo" inesperadamente en muchos entornos de TI
empresariales, filtrándose de una variedad de fuentes, como sistemas vulnerables restaurados a partir de
copias de seguridad, activando máquinas virtuales a partir de imágenes sin parches, proveedores que continúan
implementando aplicaciones y dispositivos sin parches, y muchos otros. Esta diversión continuará durante años.
Si está interesado en leer todos los detalles sobre cómo se informaron las vulnerabilidades de Log4j y cómo se
desarrolló la crisis, la recién formada Junta de Revisión de Seguridad Cibernética de los Estados Unidos
investigó y publicó un informe sobre sus hallazgos. Vi al presidente de la junta del Departamento de Seguridad
Nacional y al vicepresidente de Google discutir el informe y sus hallazgos en Black Hat 2022.
Fue interesante escuchar sobre la reacción del gobierno de la República Popular China (RPC)
ante el investigador de seguridad de Alibaba que encontró la vulnerabilidad y la informó inicialmente
a la Apache Software Foundation, en lugar de al Ministerio de Industria y Tecnología de la
Información (MIIT) de la RPC.
Independientemente de una posible sanción contra Alibaba, la Junta señaló elementos preocupantes de las
regulaciones del MIIT que rigen la divulgación de vulnerabilidades de seguridad. El requisito de que los
proveedores de productos de red informen las vulnerabilidades de sus productos al MIIT dentro de los dos
días posteriores al descubrimiento podría dar al gobierno de la República Popular China un conocimiento
temprano de las vulnerabilidades antes de que las soluciones del proveedor estén disponibles para la comunidad.
A la Junta le preocupa que esto le brinde al gobierno de la República Popular China una ventana en la
que explotar las vulnerabilidades antes de que los defensores de la red puedan repararlas. Esta es una
perspectiva inquietante dado el historial conocido del gobierno de la República Popular China de robo de
propiedad intelectual, recopilación de inteligencia, vigilancia de activistas de derechos humanos y
disidentes, y operaciones cibernéticas militares”. (Junta de Revisión de Seguridad Cibernética. 11 de julio de 2022).
¡Esta cita deja al descubierto cuán importantes a nivel mundial y políticamente cargadas pueden llegar a ser las
revelaciones de vulnerabilidades! Discutiré esta tensión en el Capítulo 6, Los roles que juegan los gobiernos en la
ciberseguridad. Si está interesado en leer el informe, puede descargarlo de https://www.cisa.gov/sites/

default/files/publications/CSRBReportonLog4July112022_508.pdf.
Las vulnerabilidades de día cero no son tan raras como podría pensar. Los datos que Microsoft publicó indican que de
las CVE que se sabía que se explotaban en los productos de Microsoft en 2017, la primera vez que se explotaron, el
100 % eran vulnerabilidades de día cero y, en 2018, el 83 % eran vulnerabilidades de día cero (Matt Miller, 2019).
Aquí hay un hecho divertido para ti. Creé un gran ciclo de noticias sensacionales en 2013 cuando acuñé el término "día
cero para siempre" en una publicación de blog que escribí en el blog de seguridad oficial de Microsoft. Me refería a
cualquier vulnerabilidad encontrada en Windows XP después de que finalizara el soporte oficial. En este escenario,
cualquier vulnerabilidad encontrada en Windows XP después del final del soporte sería un día cero para siempre, ya
que Mic rosoft no proporcionaría actualizaciones de seguridad continuas para ello.
Permítanme explicar esto con un poco más de detalle. Los atacantes pueden esperar a que se publiquen nuevas
actualizaciones de seguridad para las versiones actualmente compatibles de Windows, como Windows 11. Luego,
aplican ingeniería inversa a estas actualizaciones para encontrar la vulnerabilidad que aborda cada actualización.
Luego, verifican si esas vulnerabilidades también están presentes en Windows XP. Si lo son y Microsoft no publica
actualizaciones de seguridad para ellos, los atacantes tendrán vulnerabilidades de día cero para Windows XP para
siempre. Hasta el día de hoy, puede buscar el término "día cero para siempre" y encontrar muchos artículos de noticias
que me citan. Me convertí en el chico del cartel del final de la vida de Windows XP debido a ese ciclo de noticias.
A lo largo de los años, he hablado con miles de CISO y administradores de vulnerabilidades sobre las prácticas que
utilizan para administrar las vulnerabilidades de sus organizaciones. Históricamente, los cuatro grupos de pensamiento
más comunes sobre la mejor manera de gestionar las vulnerabilidades en entornos empresariales grandes y complejos
Los entornos son los siguientes:
• Priorizar las vulnerabilidades calificadas como críticas: cuando las actualizaciones o mitigaciones para las
vulnerabilidades calificadas como críticas están disponibles, se prueban y se implementan de inmediato. Las
vulnerabilidades de menor calificación se prueban e implementan durante el mantenimiento de TI programado
regularmente para minimizar los reinicios del sistema y la interrupción del negocio. Estas organizaciones
están mitigando las vulnerabilidades de mayor riesgo lo más rápido posible y están dispuestas a aceptar un
riesgo significativo para evitar interrumpir constantemente sus entornos con implementaciones de
actualizaciones de seguridad.
Capítulo 3 55
• Priorizar las vulnerabilidades de calificación alta y crítica: cuando se divulgan públicamente las capacidades de
vulnerabilidades de calificación alta y crítica, su política dicta que parchearán las capacidades de vulnerabilidades
críticas o implementarán las mitigaciones disponibles dentro de las 24 horas y las vulnerabilidades de calificación
alta dentro de un mes. Las vulnerabilidades con puntajes más bajos se parchearán como parte de su ciclo
regular de mantenimiento de TI para minimizar los reinicios del sistema y la interrupción del negocio.
• Sin priorización , solo parche todo: algunas organizaciones han llegado a la conclusión de que, dado el volumen
continuo y creciente de divulgaciones de vulnerabilidades que se ven obligadas a administrar, el esfuerzo que
realizan para analizar las puntuaciones CVSS y priorizar las actualizaciones no vale la pena. En cambio,
simplemente prueban e implementan todas las actualizaciones esencialmente en el mismo horario. Este
cronograma puede ser mensual, trimestral o, para aquellas organizaciones con apetitos de riesgo inflados,
semestral. Estas organizaciones se enfocan en ser realmente eficientes en la implementación de actualizaciones
de seguridad, independientemente de sus clasificaciones de gravedad.
• Retraso en la implementación: para las organizaciones que son muy sensibles a las interrupciones de TI y que se
han visto afectadas por actualizaciones de seguridad de mala calidad en el pasado, retrasar la implementación
de las actualizaciones de seguridad se ha convertido en una práctica desafortunada. En otras palabras, estas
organizaciones aceptan el riesgo relacionado con todas las vulnerabilidades sin parches conocidas públicamente
en los productos que utilizan durante un período de meses para garantizar que las actualizaciones de seguridad
de sus proveedores no se vuelvan a publicar debido a problemas de calidad. Estas organizaciones han decidido
que el remedio es potencialmente peor que la enfermedad; es decir, la interrupción de las actualizaciones de
seguridad de baja calidad representa un riesgo igual o mayor para ellos que para todos los atacantes potenciales
del mundo. Las organizaciones que se suscriben a esta escuela de pensamiento tienden a agrupar e implementar
meses de actualizaciones. El apetito por el riesgo entre estas organizaciones es alto, por decir lo menos.
Un enfoque más nuevo para administrar vulnerabilidades en entornos de TI de grandes empresas que se enfoca aún más
en priorizar vulnerabilidades específicas para remediar se ha vuelto muy popular entre los equipos de seguridad. Como
escribí en el Capítulo 2, Qué saber sobre Threat Intelligence, Cyber Threat Intelligence (CTI) tiene muchos usos. Uno de
esos usos es informar la prioridad de la remediación de la vulnerabilidad. La mayoría de las organizaciones a las que he
asesorado en los últimos años ahora utilizan CTI para identificar las vulnerabilidades que se utilizan en los ataques activos
en Internet. Ven estas vulnerabilidades como el mayor riesgo porque su explotación no es solo teórica, que es lo que
representa un puntaje CVSS. Dado que alguien ha descubierto cómo explotar una vulnerabilidad, tiene un código de
explotación o una herramienta para hacer esto, y están atacando activamente los sistemas con él, el lado de la
probabilidad de la ecuación del riesgo es tan alto como parece. Posteriormente, priorizan parchear estas vulnerabilidades
antes que todas las demás. Este enfoque brinda a los equipos de remediación más tiempo para abordar las vulnerabilidades
donde no hay CTI que indique que se están explotando activamente.

Podría decirse que las organizaciones que utilizan este enfoque aceptan más riesgos, al menos hasta que se
aborden todas las vulnerabilidades críticas y de alta gravedad en sus activos de TI. Esencialmente, están
apostando por la calidad y la puntualidad de la CTI que utilizan para informar sus prioridades de remediación de vulnerabilidades.
Sin embargo, para las organizaciones que luchan con la gestión y reparación de vulnerabilidades, este enfoque les ayuda a
mantener un alcance manejable para sus esfuerzos de reparación mientras reducen realmente el riesgo. Sin embargo, la
clave es abordar las otras vulnerabilidades críticas y de alta gravedad que no se estaban explotando activamente cuando se
evaluaron inicialmente, en un período de tiempo razonable. Permitir que estas vulnerabilidades permanezcan en el inventario
y se acumulen con el tiempo es una locura.
Recuerde lo que escribí en el Capítulo 2 : nadie es omnisciente y, en consecuencia, nadie puede ver el 100 % de todos los
ataques. Comprender las fuentes de datos y las limitaciones de la CTI utilizada para informar la gestión de vulnerabilidades
es fundamental cuando se utiliza este enfoque.
Aprovechar CTI para priorizar la remediación de vulnerabilidades se ha vuelto tan popular que los principales proveedores de
escáneres de vulnerabilidades ofrecen integraciones de CTI en sus productos de escáneres de vulnerabilidades, y NVD ahora
integra información de explotación en los detalles de cada CVE.
El NVD ha agregado información a sus páginas de detalles de CVE para identificar las
vulnerabilidades que aparecen en el Catálogo de vulnerabilidades conocidas explotadas (KEV) de
CISA. CVE que aparece en el catálogo ahora contendrá una referencia de texto y un hipervínculo al catálogo.
CVE que no aparece en el catálogo no verá ningún cambio. La información sobre las
vulnerabilidades explotadas y los productos afectados también estará disponible para los
desarrolladores cuando NVD publique nuevas API a finales de 2022". (NIST, sin fecha)
Para los no iniciados, estos enfoques y las compensaciones pueden no tener mucho sentido. El principal
problema que crea la implementación de vulnerabilidades, además del gasto, es la interrupción del negocio.
Por ejemplo, históricamente, la mayoría de las actualizaciones para los sistemas operativos Windows requerían reinicios.
Cuando los sistemas se reinician, el tiempo de inactividad incurrido se cuenta contra los objetivos de tiempo de actividad con
los que se comprometen la mayoría de las organizaciones de TI. Reiniciar un solo servidor puede no parecer material, pero el
tiempo que lleva reiniciar cientos o miles de servidores comienza a acumularse. Tenga en cuenta que las organizaciones que
intentan mantener un tiempo de actividad del 99,999 % (5 "9") solo pueden permitirse tener 5 minutos y 15 segundos de
tiempo de inactividad al año. Eso es 26,3 segundos de tiempo de inactividad por mes. Los servidores en los centros de datos
empresariales, especialmente los servidores de bases de datos y almacenamiento, pueden tardar fácilmente más de 5
minutos en reiniciarse cuando están en buen estado. Además, cuando se reinicia un servidor, la vida es como una caja de
bombones; este es un momento ideal para que surjan problemas que requieren solución de problemas, lo que exacerba el tiempo de inactividad.
El peor de los casos es cuando una actualización de seguridad en sí misma causa un problema.
Capítulo 3 57
El tiempo que lleva desinstalar la actualización y reiniciar una vez más, en cientos o miles de sistemas,
dejándolos en un estado vulnerable, también afecta negativamente el tiempo de actividad.
Los sistemas de parches y reinicios pueden ser costosos, especialmente para las organizaciones que realizan
parches supervisados fuera del horario laboral, lo que puede requerir horas extra y salarios de fin de semana.
El concepto de la ventana de mantenimiento convencional ya no es válido, ya que muchas empresas son
globales y operan a través de las fronteras, las 24 horas del día, los 7 días de la semana. Se ha vuelto común
un enfoque reflexivo para el parcheo programado y en capas, manteniendo la mayoría de la infraestructura
disponible mientras se parchea y reinicia una minoría.
Los reinicios son la razón principal por la que muchas organizaciones deciden aceptar cierto riesgo al aplicar
parches trimestrales o semestrales, tanto que el MSRC con el que trabajé de cerca durante más de una década
solía tratar de minimizar la cantidad de actualizaciones de seguridad que requerían reinicios del sistema cada
dos meses. Para hacer esto, cuando sea posible, intentarían lanzar todas las actualizaciones que requerían un
reinicio un mes y luego lanzar las actualizaciones que no requerían reiniciar el mes siguiente. Cuando este plan
funcionó, las organizaciones que aplicaban parches a los sistemas todos los meses podían al menos evitar
reiniciar los sistemas cada dos meses. Pero las actualizaciones "fuera de banda", que eran actualizaciones no
planificadas, parecían estropear estos planes con frecuencia.
Cuando vea la tendencia de las revelaciones de vulnerabilidades a lo largo del tiempo, las compensaciones que
hacen las organizaciones entre el riesgo de explotación y el tiempo de actividad pueden tener más sentido. La
ejecución de servidores en la nube puede cambiar drásticamente esta ecuación. Cubriré esto con más detalle
en el Capítulo 12, Enfoques modernos para la seguridad y el cumplimiento. Hay muchos otros aspectos y
detalles de NVD, CVE y CVSS que no cubrí aquí, pero proporcioné suficiente información básica para que
pueda apreciar las tendencias de divulgación de vulnerabilidades que proporciono a continuación.
La mayor parte del resto de este capítulo está dedicada a datos y análisis con más de 50 gráficos y tablas. Si
no está interesado en ver los datos y el análisis, puede omitirlo e ir directamente a la sección denominada
Resumen del marco de mejora de vulnerabilidades.
Fuentes de datos de divulgación de vulnerabilidades

Antes de profundizar en los datos de divulgación de vulnerabilidades, permítame decirle de dónde provienen los
datos y brindarle algunas advertencias sobre la validez y confiabilidad de los datos. Hay tres fuentes primarias
de datos que utilicé para este capítulo:
• La Lista CVE: https://www.cve.org/
• El NVD: https://nvd.nist.gov/vuln/search
• Detalles de CVE: https://www.cvedetails.com/

La Lista CVE es la fuente autorizada de facto de divulgaciones de vulnerabilidades para la industria.

El NVD importa datos de la Lista CVE y le agrega metadatos (incluidas métricas e información de puntuación) (CVE,
2020). El CVSS se utiliza para calcular las puntuaciones de gravedad de cada CVE importado en el NVD. Sin
embargo, esto no significa que los datos en el CVE o el NVD sean perfectos, ni tampoco lo es el CVSS. Asistí a una
sesión en la conferencia Black Hat USA en 2013 llamada “Comprar en el sesgo: por qué apestan las estadísticas de
vulnerabilidad” (Brian Martin, 2013).
Esta sesión cubrió numerosos sesgos en los datos CVE. Esta charla todavía está disponible en línea y recomiendo
Recomiende verlo para que comprenda algunas de las limitaciones de los datos CVE que analizo en este capítulo.
CVE Details es un gran sitio web que me ahorró mucho tiempo recopilando y analizando
datos CVE. CVE Details hereda las limitaciones de NVD porque utiliza datos de NVD. Es
vale la pena leer cómo funciona CVE Details y sus limitaciones (CVE Details, nd). Dado que los datos y el análisis
que proporciono en este capítulo se basan en los detalles de NVD y CVE, heredan estos
limitaciones y sesgos.
Dado que las dos fuentes principales de datos que utilicé para el análisis en este capítulo tienen limitaciones
establecidas, puedo afirmar con confianza que mi análisis no es del todo preciso ni completo. Además, los datos de
vulnerabilidad cambian con el tiempo ya que el NVD se actualiza constantemente. Mi análisis se basa en una
instantánea de los datos de CVE tomados hace meses que ya no están actualizados ni son precisos. Proporciono
este análisis para ilustrar la tendencia de las revelaciones de vulnerabilidades a lo largo del tiempo, pero no garantizo
estos datos: utilícelos bajo su propio riesgo.
Tendencias de divulgación de vulnerabilidades de la industria

Primero, veamos las divulgaciones de vulnerabilidades cada año desde que se inició la Lista CVE en 1999. Es
interesante notar que puedo encontrar vulnerabilidades con fechas de publicación que se remontan a enero de 1989
(CVE19991471) en el NVD. A las vulnerabilidades publicadas antes de 1999 parece que se les asignaron ID de
CVE que comienzan con "1999" porque fue entonces cuando MITRE recopiló y publicó la primera lista de CVE. Un
boletín archivado publicado por el Laboratorio de Tecnología de la Información (ITL) de la División de Seguridad
Informática del NIST en julio de 2000 proporciona una visión histórica de los primeros días de la NVD. El servicio de
búsqueda CVE original de NIST se llamaba ICAT.
Capítulo 3 59
La División de Seguridad Informática del Laboratorio de Tecnología de la Información del NIST
ha creado un índice de búsqueda que contiene 700 de las vulnerabilidades de seguridad
informática más importantes conocidas públicamente. Este índice, llamado ICAT (pronunciado
eyecat), ayuda al usuario a buscar vulnerabilidades específicas e identificar aquellas
vulnerabilidades que son aplicables a sus organizaciones... La información de vulnerabilidad
indexada por ICAT se refiere a aquellas vulnerabilidades incluidas en un esquema estándar de
nomenclatura de vulnerabilidades llamado CVE (vulnerabilidades y exposiciones comunes)...
Dado que la lista actual de 700 vulnerabilidades es demasiado grande para que los administradores
del sistema la revisen manualmente, creamos ICAT para permitirle buscar vulnerabilidades.
nerabilidades aplicables a los hosts de una organización en particular”. (Mell, Peter. NIST. 2000).
La revisora de este libro, Cybersecurity Threats, Malware Trends, and Strategies, Karen Scarfone, trabajó
en estrecha colaboración con Peter Mell y otros en el NIST para desarrollar NVD como sucesor de ICAT.
El NVD se lanzó a mediados de 2005. Los analistas del NIST realizaron la puntuación CVSS (v1) para todas las
vulnerabilidades ICAT existentes. Luego usaron ese cuerpo de datos de puntuación para informar mejoras para CVSS v2
(Scarfone, Karen. comunicación personal, 4 de septiembre de 2022).
El número total de vulnerabilidades a las que se les asignó un identificador CVE entre 1999 y 2021 superó las 167 000
(Detalles de CVE, sin fecha). Como ilustra la Figura 3.2 , hubo un gran aumento en las divulgaciones en 2017 que no ha
retrocedido a los volúmenes históricamente típicos desde entonces. Revelación de una nueva era en vulnerabilidad
Seguros comenzó en 2017.
Figura 3.2: Vulnerabilidades divulgadas en la industria por año (1999–2021)

Hubo un aumento del 128 % en las divulgaciones entre 2016 y 2017, y un aumento del 157 % entre 2016 y
2018. Dicho de otra manera, en 2016, los equipos de administración de vulnerabilidades administraron un
promedio de 18 nuevas vulnerabilidades por día. Ese número aumentó a 40 vulnerabilidades por día en 2017
y 45 por día en 2018, en promedio. Como ilustra la Figura 3.3 , los equipos de gestión de vulnerabilidades
gestionaron 55 nuevas vulnerabilidades por día en promedio en 2021, un aumento del 206 % con respecto a
los niveles de 2016. En 2022, se revelaron 25.213 vulnerabilidades. Eso fue un promedio de 69 divulgaciones
de vulnerabilidades por día para que los equipos de seguridad las enfrenten.
Muchas de las organizaciones a las que asesoré durante estos años no habían aumentado los niveles de
personal o el presupuesto para sus equipos de gestión de vulnerabilidades y equipos de remediación en
consonancia con estos aumentos. Este es un factor que ayuda a explicar por qué tantas empresas tienen
grandes inventarios de vulnerabilidades sin parchear, lo que aumenta drásticamente el riesgo para ellas.
Por ejemplo, en 2021, si sus equipos de remediación no mantuvieran 55 o más divulgaciones de
vulnerabilidades nuevas todos los días (incluidos fines de semana y días festivos), eso es potencialmente
385 vulnerabilidades por semana, 1,650 por mes, 20,075 en un año, multiplicado por la cantidad de
instancias, sistemas y dispositivos IoT que estas vulnerabilidades impactan en sus propiedades de TI, una
acumulación que necesitan remediar mientras se ocupa simultáneamente de la volumen continuo de nuevas
divulgaciones todos los días, mientras enfrentan un riesgo dramáticamente mayor para su organización. No
es una posición divertida para estar. Para las grandes empresas que no han invertido en el desarrollo de
excelentes capacidades de gestión de vulnerabilidades, esto puede traducirse fácilmente en inventarios de
cientos de miles o millones de vulnerabilidades sin parches que llevan durante meses.
Figura 3.3: Promedio de vulnerabilidades reveladas por día entre 1999 y 2021
Capítulo 3 61
Recuerde que una sola vulnerabilidad sin parchear puede ser toda la oportunidad que los atacantes necesitan para
comprometer inicialmente un entorno de TI empresarial. Hay muchos ejemplos de una sola vulnerabilidad sin
parchear que condujo a violaciones de datos de grandes corporaciones que llegaron a los titulares. Los atacantes
pueden aprovechar las vulnerabilidades sin parches de muchas maneras diferentes, incluido el uso de herramientas
especialmente diseñadas, malware, archivos adjuntos de correo electrónico y ataques de descargas ocultas, entre
otros métodos. Los atacantes también utilizan las vulnerabilidades sin parchear para moverse lateralmente y
obtener acceso a los sistemas después del compromiso. Las vulnerabilidades sin parchear también se utilizan en
los temidos ataques masivos de ransomware . ¿Recuerda el ataque de ransomware "cryptoworm" de WannaCry
que afectó a cientos de miles de sistemas en todo el mundo?
Posteriormente, llevar inventarios masivos de vulnerabilidades sin parchear es como zarpar en un submarino que
sabe que tiene agujeros en el casco. A menudo les preguntaba a los ejecutivos que asesoraba, que eran un poco
arrogantes sobre el estado de la gestión de vulnerabilidades en sus entornos de TI, si pondrían a sus familias y
sus ahorros para la jubilación en un submarino de este tipo y zarparían, conociendo el estado del casco. Hasta la
fecha, no he encontrado un ejecutivo que dijera que haría tal cosa.
Un enfoque basado en el riesgo informado por Cyber Threat Intelligence (CTI) que analicé en el Capítulo 2
y que hace un uso intensivo de la automatización puede ayudar a administrar esta nueva normalidad.
Alternativamente, como le he suplicado a muchas empresas, pasar a entornos informáticos modernos
como la nube puede cambiar drásticamente este cálculo. Compartiré más sobre este enfoque en el Capítulo
12, Enfoques modernos para la seguridad y el cumplimiento.
Quizás se pregunte qué factores contribuyeron a un aumento tan grande en las revelaciones de
vulnerabilidades . El factor principal probablemente fue un cambio realizado en la forma en que los
identificadores CVE se asignan a las vulnerabilidades en la Lista CVE. Durante este tiempo, la CVE ungió
y autorizó lo que ellos llaman "Autoridades de numeración de CVE (CNA)" para asignar identificadores de
CVE a nuevas vulnerabilidades (Common Vulnerabilities and Exposures, sin fecha). Según MITRE, que
gestiona el proceso CVE que llena el NVD con datos:
Los CNA son proveedores de software, proyectos de código abierto, centros de coordinación,
proveedores de servicios de recompensas por errores, servicios alojados y grupos de
investigación autorizados por el programa CVE para asignar ID de CVE a vulnerabilidades y
publicar registros de CVE dentro de sus propios ámbitos de cobertura específicos. Los CNA se
unen al programa de una variedad de sectores comerciales; hay requisitos mínimos, y no hay
tarifa monetaria o contrato para firmar”. (Vulnerabilidades y exposiciones comunes. (nd))
Uso de CVE: MITRE le otorga una licencia de derechos de autor perpetua, mundial, no exclusiva,
gratuita, libre de regalías e irrevocable para reproducir, preparar obras derivadas, exhibir
públicamente, ejecutar públicamente, otorgar sublicencias y distribuir Vulnerabilidades y
exposiciones comunes (CVE®). Cualquier copia que realice para tales fines está autorizada
siempre que reproduzca la designación de derechos de autor de MITRE y esta licencia en dicha
copia.
La llegada de los CNA significa que hay muchas más organizaciones que asignan identificadores CVE después de 2016.
El 1 de enero de 2020, había 110 organizaciones en 21 países que participaban como CNA. Para julio de 2022, la
cantidad de CNA había aumentado a 232 organizaciones en 35 países (Common Vulnerabilities and Exposures, nd).
Eso es un aumento del 111 % en el número de organizaciones que ingresan CVE en el NVD, en menos de dos años.
Los nombres y ubicaciones de los CNA están disponibles en https://www.cve.org/PartnerInformation/ListofPartners.
Claramente, este cambio ha hecho que el proceso de asignación de identificadores CVE sea más eficiente, lo que ha
llevado a un gran aumento en las divulgaciones de vulnerabilidades en 2017 y todos los años desde entonces.
Hay otros factores que han llevado a mayores volúmenes de divulgaciones de vulnerabilidades. Por ejemplo, hay más
personas y organizaciones que investigan vulnerabilidades que nunca y tienen mejores herramientas que en el pasado.
Encontrar nuevas vulnerabilidades es un gran negocio y muchas personas están ansiosas por obtener un pedazo de
ese pastel. Sin embargo, la mayor parte del enfoque se ha centrado en vulnerabilidades críticas y de alta gravedad.
Aquí es donde está el dinero, y muchos investigadores de seguridad solo están interesados en encontrar las
vulnerabilidades más valiosas para maximizar el retorno de sus inversiones en tiempo, experiencia y gastos. Esto deja
la notificación de vulnerabilidades de menor gravedad en gran medida a los propios proveedores. Dicho de otra manera,
los proveedores se involucran en gran medida en el sistema de honor para autoinformar vulnerabilidades de baja
calificación. Es probable que esto haya llevado a la subestimación de las vulnerabilidades de baja calificación.
Después de todo, es más fácil corregir errores de bajo riesgo que probablemente no sean explotables, para la próxima
actualización del producto, que pasar por el proceso de informe de vulnerabilidades y parchearlos individualmente.
Capítulo 3 63
Otro factor en el aumento dramático en las revelaciones de vulnerabilidades es que nuevos tipos de hardware y software
se están uniendo rápidamente al ecosistema informático en forma de dispositivos de Internet de las cosas (IoT) . La gran
fiebre del oro para obtener una participación de mercado significativa en este nuevo espacio de mercado masivo ha
llevado a la industria a cometer los mismos errores que cometieron los fabricantes de software y hardware durante el
último cuarto de siglo.
Hablé con algunos fabricantes sobre los planes de desarrollo de seguridad para sus líneas de productos IoT hace varios
años y era evidente que planeaban hacer muy poco. El desarrollo de dispositivos IoT que carecen de mecanismos de
actualización hace que la industria retroceda en el tiempo cuando las computadoras personales no podían actualizarse
por sí mismas, pero a una escala mucho, mucho mayor. Los consumidores simplemente no están dispuestos a pagar
más por una mejor seguridad y los fabricantes no están dispuestos a invertir tiempo, presupuesto y esfuerzo en aspectos
del desarrollo que no impulsan la demanda. Después de 5 años de volúmenes significativamente mayores de
divulgaciones, que continúan creciendo cada año, esta parece ser la nueva normalidad para la industria, lo que genera
mucho más riesgo y más trabajo para administrar para las empresas. Y con el espectro del ransomware, que podría ser
un evento de extinción para una empresa, la presión sobre los equipos de seguridad nunca ha sido mayor.
La distribución de la gravedad de estos CVE se ilustra en la Figura 3.4 (Detalles de CVE, sin fecha). El período cubierto
aquí es de 1999 a julio de 2022 (los últimos datos disponibles en el momento de escribir este artículo). Hay casi tres
veces más CVE clasificados como de gravedad media (104.223 CVE con puntuaciones CVSS entre 4 y 6,9) que de
gravedad alta (36.894 CVE con puntuaciones CVSS entre 7 y 8,9). La cantidad combinada de vulnerabilidades críticas y
de gravedad alta es poco más de la mitad (55 %) de la cantidad de vulnerabilidades de calificación media. El 31,4% de
todas las vulnerabilidades, 56.872 de 180.979, se califican como críticas o altas. Esta es una disminución del 4,3 % en
las divulgaciones de vulnerabilidades críticas y de alta calificación desde 2019. Los mayores cambios en la distribución
entre 2019 y mediados de 2022 son una disminución del 2,2 % en las vulnerabilidades de alta gravedad y una disminución
del 2 % en las vulnerabilidades de gravedad crítica. El puntaje CVSS promedio ponderado de los CVE que se informan
es 6.5, una disminución de 0.1 en comparación con 2019. ¿Podrían estas disminuciones representar un progreso hacia
la reducción de la gravedad de las vulnerabilidades reveladas en toda la industria?
El tiempo dirá. Tenga en cuenta que, dado que es probable que las vulnerabilidades de gravedad baja no se notifiquen,
el promedio ponderado de todas las vulnerabilidades, incluidas las no informadas, es casi seguro más bajo que el de las
vulnerabilidades informadas.
Para las organizaciones que tienen políticas de administración de vulnerabilidades que dictan la implementación de
emergencia de todas las vulnerabilidades calificadas críticas y la implementación mensual de CVE calificados como altos,
eso es potencialmente cerca de 20 000 implementaciones de emergencia y casi 28 000 implementaciones de parches
mensuales durante un período de 20 años.

Esta es una de las razones por las que algunas organizaciones deciden no priorizar las actualizaciones de seguridad
en función de la gravedad: hay demasiadas vulnerabilidades de gravedad alta y crítica para que administrarlas de
manera diferente a las vulnerabilidades de menor calificación sea un uso efectivo del tiempo. Muchas de estas
organizaciones se enfocan en volverse realmente eficientes al probar e implementar actualizaciones de seguridad
en su entorno para que puedan implementar todas las actualizaciones lo más rápido posible sin interrumpir el
negocio, independientemente de su gravedad.
Figura 3.4: Puntajes CVSS por gravedad (19992022 (enerojulio))
Profundicemos un poco más en las tendencias a largo plazo de las vulnerabilidades críticas y de alta gravedad que
tienen puntajes CVSS de 7 o más. Como mencioné anteriormente, la mayoría de los equipos de seguridad se
enfocan primero en remediar estas vulnerabilidades porque son las de mayor riesgo. Como ilustra la Figura 3.5 ,
aunque la cantidad de vulnerabilidades críticas y de alta gravedad aumentó en 2017 a medida que la cantidad total
de vulnerabilidades aumentó drásticamente, la tendencia ha sido relativamente estable desde entonces (Detalles de
CVE, sin fecha).
Capítulo 3 sesenta y cinco
Figura 3.5: Número total de CVE por año y número total de CVE críticos y de alta gravedad por año
Cuando la cantidad de divulgaciones de vulnerabilidades en la industria aumentó un 128 % entre 2016 y

2017, la cantidad de CVE críticas y de alta calificación no aumentó proporcionalmente, sino que creció
solo un 75 %, lo que significa que la cantidad de vulnerabilidades críticas y de alta gravedad disminuyó
como porcentaje del total. La figura 3.6 ilustra cómo el porcentaje de CVE con una puntuación CVSS de 7
o superior ha ido disminuyendo en relación con el total desde 2016. La figura también nos muestra que la
cantidad de vulnerabilidades críticas y de calificación alta en relación con el total es más baja en los últimos
años que nunca en la historia de NVD. Esta es una noticia positiva porque lo último que necesita la
industria es un volumen cada vez mayor de vulnerabilidades críticas y de alta gravedad con las que lidiar.
Figura 3.6: CVE clasificados como críticos o de alta gravedad como porcentaje del total de todos los CVE, por año
Sin embargo, no abras el champán todavía. El aumento del 75 % antes mencionado entre 2016 y 2017 es evidente
en la Figura 3.7. Cuando se traduce en trabajo potencial para los equipos de gestión de vulnerabilidades y los
equipos de remediación, la Figura 3.7 revela que la cantidad promedio de divulgaciones de vulnerabilidades por
día que tienen puntajes CVSS de 7 o más nunca ha sido mayor. Con un promedio de 11 o 12 nuevos CVE críticos
o de alta calificación divulgados todos los días, los equipos de gestión de vulnerabilidades y los equipos de
remediación necesitan personas, procesos y tecnologías altamente eficientes para mantenerse al día. Si no se
atiende, ese volumen es potencialmente de 77 CVE por semana, 330 CVE por mes y 4015 CVE por año, todos los
cuales tienen la mayor probabilidad de explotación. La cantidad de vulnerabilidades multiplicada por la cantidad
de instancias, sistemas y dispositivos de IoT en los que impactan estas vulnerabilidades significa que el inventario
de vulnerabilidades sin parchear puede crecer mucho, muy rápidamente.
Figura 3.7: Número promedio de vulnerabilidades divulgadas por día que se clasifican como críticas o de
gravedad alta, por año
¿Recuerdas mi historia sobre todos los ataques de gusanos exitosos en 2003? El volumen promedio diario de
divulgaciones de vulnerabilidades críticas y de alta gravedad en ese entonces era solo el 17% de lo que era en 2021.
Cómo han cambiado los tiempos. Afortunadamente, el volumen de divulgaciones de vulnerabilidades no es lo
único que ha cambiado; capacidades para detectar, bloquear, contener y responder a la explotación también tienen.
Usando la gravedad de la vulnerabilidad para priorizar la reparación a corto plazo, los equipos de seguridad
habrían podido reducir el número promedio máximo potencial de nuevas vulnerabilidades para investigar todos los
días de 55,26 a 11,04 en 2021. Eso es potencialmente un 80 % menos de vulnerabilidades para clasificar todos los días.
Capítulo 3 67
Los equipos de seguridad que usan CTI en la explotación activa pueden potencialmente reducir ese número aún más.
Por ejemplo, usemos el Catálogo de Vulnerabilidades Explotadas Conocidas (KEV) de la Agencia de Seguridad de
Infraestructura y Ciberseguridad (CISA ), que está disponible para descargar desde https://www.cisa.
gov/knownexploitedvulnerabilitiescatalog, para determinar cuántos CVE divulgados en 2021 se sabe que se explotan
activamente. Por supuesto, estos datos están sujetos a cambios en cualquier momento sin previo aviso. En el momento
de escribir este artículo, conté 163 CVE divulgados en 2021 que se enumeran en KEV. Sin embargo, 43 de estos se
agregaron al catálogo en 2022, lo que probablemente habría sido demasiado tarde para ayudar a los equipos de
seguridad a clasificar inicialmente las vulnerabilidades divulgadas durante 2021. Eso deja 120 CVE que se divulgaron
en 2021 y se agregaron al Catálogo KEV en 2021. Los equipos de seguridad habrían clasificado, en promedio, 0,33
divulgaciones de vulnerabilidad por día en 2021. Eso es potencialmente un 97 % menos de vulnerabilidades para
clasificar todos los días en lugar de usar la gravedad de la vulnerabilidad para priorizar los esfuerzos. Esta es la razón
por la que el uso de CTI para informar la gestión y corrección de vulnerabilidades es tan popular entre los equipos de
seguridad: en realidad, pueden mantenerse al día con el volumen y reducir el riesgo de manera medible al mismo tiempo.
Como mencioné, en este ejemplo, 43 CVE de 2021 se agregaron a KEV en 2022. ¿Es posible que esos CVE estuvieran
siendo explotados en 2021, pero tomó tiempo para que esto se descubriera y luego se reflejara en el CTI? Esta es la
razón por la cual los equipos de seguridad no pueden simplemente enfocarse exclusivamente en las vulnerabilidades
que se sabe que se explotan activamente, sin aceptar muchos más riesgos en nombre de sus organizaciones. Hay un
tiempo entre el momento en que los atacantes pueden comenzar a explotar una vulnerabilidad, cuando se observa que
lo hacen y cuando se distribuye CTI actualizado que refleja esto. Es posible que nunca se observen algunas
explotaciones.
Hoy en día, muchos equipos de seguridad usan CTI para identificar y remediar los CVE que se están explotando
activamente, lo más rápido posible. Luego, trabajan para cumplir con los acuerdos de nivel de servicio (SLA) que su
organización ha implementado para vulnerabilidades críticas y de alta gravedad. Un SLA de 30 días para vulnerabilidades
de gravedad crítica y un SLA de 60 días para vulnerabilidades de alta gravedad parece ser bastante común entre las
organizaciones que he asesorado. También he visto SLA mucho más agresivos y SLA mucho menos agresivos; en
teoría, estos dependen del apetito por el riesgo de la organización. Sin embargo, he conocido a muy pocos ejecutivos
que realmente entiendan cuánto riesgo representan sus SLA de remediación para sus organizaciones; estos SLA y el
cumplimiento de los mismos suelen depender de la rapidez con la que sus equipos de remediación pueden trabajar en
función de los niveles de recursos objetivo.
Finalmente, esos equipos abordan sus inventarios de vulnerabilidades de menor gravedad para cumplir con los SLA
definidos. Simplemente no parchear las vulnerabilidades de gravedad media y baja es más riesgoso de lo que parece.
Dado que muchos equipos de seguridad se enfocan primero en mitigar las vulnerabilidades críticas y de alta gravedad, los
atacantes han estado usando combinaciones de vulnerabilidades de menor gravedad para comprometer los sistemas durante
muchos años. No abordar tales vulnerabilidades de manera oportuna y permitir que se acumulen grandes inventarios no es
una buena práctica de un programa de gestión de vulnerabilidades bien administrado.
Recuerde, las vulnerabilidades de gravedad crítica y alta combinadas solo comprenden aproximadamente un tercio de todas
las CVE en un año determinado.
Tendencias de vulnerabilidad de proveedores y productos

En este punto, es posible que se pregunte en qué tipo de productos se encuentran estas vulnerabilidades. Al clasificar los 25
productos principales con la mayor cantidad de CVE en sistemas operativos, navegadores web y aplicaciones, la Figura 3.8
ilustra el desglose (Detalles de CVE, consultado en julio de 2022). Los sistemas operativos dominan esta lista, constituyendo
el 90,75 % del total, lo que significa que hay más CVE que afectan a los sistemas operativos que navegadores y aplicaciones
combinados en los 25 productos principales con el

la mayoría de los ECV.
En una gran desviación de los períodos de tiempo pasados, ninguna aplicación llegó a la lista de los 25 principales. Por lo
general, entre el 15 % y el 20 % de esta lista estaría compuesta por aplicaciones como Acrobat, Acrobat Reader y Flash
Player. Como era de esperar, a medida que la cantidad de productos aumenta de 25 a 50, esta distribución comienza a
cambiar rápidamente. Hay 10 aplicaciones (20%) en los 50 productos principales con más CVE. Sospecho que a medida que
aumenta la cantidad de productos incluidos en este análisis, las aplicaciones eventualmente tendrán más CVE que las otras
categorías, aunque solo sea por el hecho de que hay muchas, muchas más aplicaciones que sistemas operativos o
navegadores, a pesar de todo el enfoque que los sistemas operativos han recibido a lo largo de los años. También tenga en
cuenta que el impacto de una vulnerabilidad en una biblioteca de desarrollo popular, como JRE o Microsoft .NET, puede verse
magnificado debido a los millones de aplicaciones que la utilizan.
Hay 3 navegadores web entre los 25 productos principales con la mayor cantidad de CVE, que componen poco menos del 10
% de la lista, y 7 entre los 50 principales, que componen menos del 15 %.

Capítulo 3 69
Figura 3.8: Los 25 productos principales con la mayor cantidad de CVE desglosados por tipo de producto (19992022
(enerojulio))
Los productos específicos en los que se informaron estas vulnerabilidades se ilustran en la siguiente lista
(Detalles de CVE. Consultado en julio de 2022). Esta lista le dará una idea de la cantidad de vulnerabilidades
que tienen muchos productos de software populares y cuánto esfuerzo podrían dedicar los equipos de
administración de vulnerabilidades para administrarlas.
Figura 3.9: Los 25 productos principales con la mayor cantidad de CVE, 19992022 (enerojulio) (Detalles de CVE.
Consultado en julio de 2022)

Los proveedores y las distribuciones de Linux que tenían la mayor cantidad de CVE según la Lista de los 50
proveedores principales de CVE Details (Detalles de CVE, consultado en julio de 2022) se enumeran en la Figura
3.9. Esta lista no debería ser tan sorprendente, ya que algunos proveedores de esta lista también son los
principales proveedores en lo que respecta a la cantidad de productos que han tenido en el mercado durante los
últimos 20 años o más. Cuanto más código escriba, mayor será el potencial de vulnerabilidades, especialmente
en los años anteriores a 2003, cuando se perpetraron los grandes ataques de gusanos (SQL Slammer, Blaster y
similares). Después de 2004, los líderes de la industria como los de esta lista comenzaron a prestar más atención
a las vulnerabilidades de seguridad a raíz de esos ataques. Hablaré más sobre el malware en el Capítulo 4, La
evolución del malware. Además, los proveedores de sistemas operativos y navegadores web han recibido una
cantidad desproporcionada de atención y enfoque en sus productos debido a su ubicuidad. Una nueva
vulnerabilidad crítica o de alta calificación en un sistema operativo o navegador vale mucho más que una vulnerabilidad en una aplicac
Figura 3.10: Los 10 principales proveedores/distribuciones con la mayor cantidad de recuentos de CVE, 19992022 (enerojulio)
( Detalles de CVE. Consultado en julio de 2022)
En 2003, cuando ocurrieron los grandes ataques de gusanos en Microsoft Windows, muchas de las organizaciones
con las que hablé en ese momento creían que solo el software de Microsoft tenía vulnerabilidades y que el
software de otros proveedores era perfecto. Sin embargo, se asignaron miles de CVE cada año antes y después
de 2003 para software de muchos proveedores.
Capítulo 3 71
Dos décadas después, no he hablado recientemente con ningún equipo de seguridad que aún crea en este mito, ya que
están lidiando con vulnerabilidades en todo el software y el hardware. Estos datos no son perfectos y contar el número total
de vulnerabilidades de esta manera no necesariamente nos dice cuáles de estos proveedores y productos han mejorado a
lo largo de los años o si la industria ha mejorado sus prácticas de desarrollo de seguridad en general. Exploremos estos
aspectos más a continuación.
En las próximas secciones de este capítulo, ofrezco un análisis profundo de los cinco principales proveedores con la mayor
cantidad de divulgaciones de vulnerabilidades. Luego verá un análisis similar para dos sistemas operativos móviles, dos
sistemas operativos de escritorio, dos sistemas operativos de servidor y dos navegadores web.
Todos estos números y gráficos le brindarán una idea de cómo algunos de los productos más populares en estas categorías
han tenido tendencia con respecto a los CVE, mostrándole cómo hacer este análisis usted mismo en los productos de
hardware y software que le interesan.
Reducción de riesgos y costos: medición de la mejora de

proveedores y productos
¿Cómo puede reducir el riesgo y los costos asociados con las vulnerabilidades de seguridad? Al utilizar proveedores que
han tenido éxito en la reducción de la cantidad de vulnerabilidades en sus productos, potencialmente está reduciendo el
tiempo, el esfuerzo y los costos relacionados con su programa de administración de vulnerabilidades y los esfuerzos de
remediación. Además, si elige proveedores que también han invertido en reducir el retorno de la inversión de los atacantes
al dificultar o imposibilitar la explotación de vulnerabilidades en sus productos, también estará reduciendo su riesgo y costos.
Ahora le proporcionaré un marco que puede usar para identificar dichos proveedores y productos.
A raíz de los grandes ataques de gusanos en 2003, Microsoft comenzó a desarrollar Microsoft SDL (Microsoft, nd). Microsoft
continúa usando SDL hasta el día de hoy. Dirigí las comunicaciones de marketing para SDL durante varios años, así que
tuve la oportunidad de aprender mucho sobre este enfoque de desarrollo. Los objetivos declarados del SDL son disminuir el
número y la gravedad de las vulnerabilidades.

Habilidades en el software de Microsoft.
El SDL también busca hacer que las vulnerabilidades que se encuentran en el software después del desarrollo sean más
difíciles o imposibles de explotar. Quedó claro que incluso si Microsoft de alguna manera pudiera producir productos libres
de vulnerabilidades, las aplicaciones, los controladores y los componentes de terceros que se ejecutan en Windows o en los
navegadores web aún harían que los sistemas fueran vulnerables. Posteriormente, Microsoft compartió algunas versiones
de SDL y algunas herramientas de SDL con la industria en general de forma gratuita. También incorporó algunos aspectos
de SDL en algunas de sus herramientas de desarrollo disponibles públicamente.

Voy a utilizar los objetivos de SDL como un "marco de mejora de vulnerabilidades" informal para tener una idea de si el
riesgo (probabilidad e impacto) de usar un proveedor o un producto específico

ha aumentado o disminuido con el tiempo. Este marco tiene tres criterios:
• ¿El número total de vulnerabilidades tiene una tendencia al alza o a la baja?

• ¿La gravedad de esas vulnerabilidades está aumentando o disminuyendo?
• ¿La complejidad de acceso de esas vulnerabilidades está aumentando o disminuyendo?
¿Por qué este marco aparentemente simple tiene sentido? Recorrámoslo. ¿El número total de vulnerabilidades tiene una
tendencia al alza o a la baja? Los proveedores deberían trabajar para reducir la cantidad de vulnerabilidades en sus
productos con el tiempo. Una meta a la que aspiran todos los proveedores debe ser tener cero vulnerabilidades en sus
productos. Pero esto no es realista ya que los humanos escriben código y cometen errores que conducen a
vulnerabilidades. Sin embargo, con el tiempo, los proveedores deberían poder mostrar a sus clientes que han encontrado
formas de reducir las vulnerabilidades en sus productos para reducir el riesgo.

para sus clientes.
¿La gravedad de esas vulnerabilidades está aumentando o disminuyendo? Dado que habrá algunas vulnerabilidades de
seguridad en los productos, los proveedores deben trabajar para reducir la gravedad de esas vulnerabilidades.
La reducción de la gravedad de las vulnerabilidades reduce la cantidad de implementaciones de actualizaciones de
seguridad de emergencia que mencioné anteriormente en este capítulo. También brinda a los equipos de administración
de vulnerabilidades más tiempo para probar e implementar vulnerabilidades, lo que reduce las interrupciones en los
negocios que respaldan. Más específicamente, la cantidad de CVE críticos y de alta gravedad debe minimizarse, ya que
representan el mayor riesgo para los sistemas.
¿La complejidad de acceso de esas vulnerabilidades está aumentando o disminuyendo? Una vez más, si hay
capacidades de vulnerabilidad en los productos, hacer que esas vulnerabilidades sean lo más difíciles posible o
imposibles de explotar debería ser algo en lo que los proveedores se centren. La complejidad del acceso o la complejidad
del ataque (dependiendo de la versión de CVSS que se utilice) es una medida de cuán fácil o difícil es explotar una
vulnerabilidad. CVSS v2 proporciona una estimación de la complejidad de acceso como baja, media o alta, mientras que
CVSS v3 utiliza la complejidad de ataque como alta o baja. El concepto es el mismo: cuanto mayor sea la complejidad
del acceso o del ataque, más difícil será para el atacante explotar la vulnerabilidad.
Usando estas medidas, queremos ver a los proveedores haciendo que las vulnerabilidades en sus productos sean
consistentemente difíciles de explotar. Queremos ver la cantidad de CVE de alta complejidad (aquellos con el riesgo
más bajo) que permanecen altos o con tendencia al alza con el tiempo, y las vulnerabilidades de baja complejidad
(aquellas con el riesgo más alto) con tendencia a la baja o cero. Dicho de otra manera, queremos que la proporción de
CVE de alta complejidad aumente hacia el 100% de CVE.

Capítulo 3 73
Para resumir este marco de mejora de vulnerabilidades, voy a medir:
• Recuento de CVE por año
• El número de CVE con calificación crítica y calificación alta por año; estos son CVE con puntajes
de entre 7 y 10
• El número de CVE por año con baja complejidad de acceso o complejidad de ataque
Cuando aplico este marco a los proveedores, que pueden tener cientos o miles de productos, usaré los datos CVE de los
últimos cinco años. Creo que 5 años es un período suficientemente largo para determinar si los esfuerzos de un proveedor
para administrar las vulnerabilidades de sus productos han tenido éxito. Cuando aplico este marco a un producto individual,
como un sistema operativo o un navegador web, usaré los últimos 3 años completos de datos CVE disponibles para que
podamos ver la tendencia más reciente.
Tenga en cuenta que una limitación de este enfoque es que no será útil en los casos en que los proveedores y/o sus
productos sean nuevos y no haya suficientes datos para evaluar. Otra limitación es el “ escenario de fusiones y adquisiciones”
en el que los vendedores adquieren nuevas empresas y sus productos. Por ejemplo , Oracle adquirió numerosas empresas
de tecnología y nuevas tecnologías junto con sus vulnerabilidades, incluidas MySQL y Sun Microsystems. Las adquisiciones
de nuevas tecnologías pueden generar cambios significativos en los números de CVE para los proveedores. Puede llevar
tiempo adquirir proveedores para poner los productos que obtienen en forma para cumplir o superar sus estándares.
Ahora que tenemos un marco para medir si las divulgaciones de vulnerabilidades están mejorando con el tiempo, aplicaré
este marco a años de datos históricos de CVE para algunos proveedores, sistemas operativos y navegadores web
seleccionados para tener una mejor idea del estado del software popular en la industria.
Comenzaremos observando las tendencias de Microsoft, ya que lideran la industria en el número total de CVE a lo largo del
tiempo, como se ilustra en la Figura 3.10.
Permítanme hacer un punto más importante antes de sumergirnos en los datos. Como mencioné anteriormente, he realizado
literalmente miles de informes de inteligencia sobre amenazas en todo el mundo. He dado suficientes sesiones informativas
a suficientes personas para reconocer curiosidades de comportamiento entre las audiencias a las que he informado. Por lo
general, había una o dos personas en cada audiencia que, al ver las tendencias de divulgación de vulnerabilidades, incluso
para los proveedores de los que dijeron que no eran fanáticos, de repente se convirtieron en "apologistas de los proveedores".
El refrán típico era que realmente no podemos ver cómo se desempeñan los proveedores contando CVE a menos que
examinemos productos específicos, o incluso un subconjunto de distribuciones de productos. Después de todo, podrían ser
desarrollados por diferentes equipos de desarrollo, y realmente queremos medir cómo esos equipos de desarrollo específicos
mejoran con el tiempo.

Sin embargo , después de trabajar en Microsoft y Amazon Web Services (AWS) durante muchos años, tengo un
punto de vista diferente. Cada producto y cada distribución son los resultados de las personas, los procesos y las
tecnologías que cada proveedor utiliza para desarrollarlos. Los proveedores que examinaremos en este capítulo
son algunos de los mayores proveedores de software del mundo. Todos tienen Ciclos de vida de desarrollo de
software (SDLC) y Ciclos de vida de desarrollo de seguridad (SDL) de algún tipo que utilizan para cumplir con sus
propios requisitos de productos viables mínimos, al tiempo que mejoran la seguridad y controlan los costos de
desarrollo.
Algunos proveedores más pequeños pueden sufrir de calidad inconsistente en los productos que desarrollan
porque carecen de estas cosas, pero estos grandes proveedores tienen personas, procesos y tecnologías que los
ayudan a cumplir con los requisitos mínimos para enviar sus productos. Esto es lo que estamos midiendo en este
capítulo: la efectividad de su gente, procesos y tecnologías, para desarrollar continuamente productos de mejor
calidad medidos por la cantidad de divulgaciones de seguridad que tenían. Una vez que un producto o distribución
se lanza a sus clientes, los clientes soportan la peor parte del volumen de actualizaciones de seguridad que siguen,
en forma de un riesgo dramáticamente mayor, interrupciones en sus operaciones y gastos asociados.
Cinco años es un período suficientemente largo para medir los cambios en economías nacionales enteras, por lo
que debería ser tiempo suficiente para que cualquiera de estos proveedores con buenos recursos mida su propio
desempeño y corrija el rumbo si así lo desea. Tres años es mucho tiempo para hacer correcciones en el curso del
desempeño de productos individuales, especialmente en una industria donde la agilidad, las integraciones continuas
y las implementaciones continuas son el mantra. Todos se toman en serio la seguridad, así que adoptemos un
enfoque objetivo y cuantitativo para examinar su desempeño. Ahora vamos a sumergirnos en los datos.
Tendencias de vulnerabilidad de Microsoft

Veamos cómo Microsoft ha estado gestionando las vulnerabilidades de sus productos durante los últimos 22 años.
Encabezan la lista de proveedores con la mayor cantidad de CVE, con 8804 entre 1999 y mediados de julio de
2022 (Detalles de CVE, sin fecha). De los 8.804 CVE antes mencionados, 4.118 fueron calificados como críticos o altos.
Eso es el 47% de todos los CVE asignados a Microsoft con puntajes CVSS de 7 o más. La figura 3.11 proporciona una
visión a muy largo plazo del volumen de divulgaciones de vulnerabilidades, así como de aquellas CVE con calificaciones
críticas o de gravedad alta.

Capítulo 3 75
Figura 3.11: El número de CVE y el número de CVE calificados como críticos o altos en productos de
Microsoft por año (1999–2021) (Detalles de CVE, sin fecha)
De esos CVE críticos y de alta gravedad, 1775 CVE tenían baja complejidad de acceso/ataque, o alrededor del 43
% de ellos (Detalles de CVE, sin fecha). Estos representan los CVE de mayor riesgo porque están clasificados con
las mayores severidades junto con baja complejidad (fáciles de explotar). La figura 3.12 ilustra el porcentaje de
todas las vulnerabilidades de Microsoft que se clasificaron como críticas o de gravedad alta. También nos muestra
el porcentaje de CVE de Microsoft que se clasificaron como críticos o de alta gravedad y tenían una complejidad baja.
En 2001, por ejemplo, el 33,72 % de todos los CVE de Microsoft publicados ese año se clasificaron como críticos o de
gravedad alta. De aquellos ECV críticos y de alta severidad, el 100% de ellos fueron de baja complejidad. Esto ayuda a
explicar por qué los ataques masivos de gusanos tuvieron tanto éxito a principios de la década de 2000.
La figura 3.12 también sugiere que poco después de que Microsoft comenzara a centrarse seriamente en SDL en 2004
después de los grandes ataques de gusanos en 2003, el porcentaje de CVE críticos y de alta gravedad con baja complejidad
de acceso se redujo significativamente. Microsoft logró mantener esta medida relativamente baja durante los años de
"Computación confiable", hasta finales de 2014 cuando se cerró el grupo de Computación confiable. (Kovacs, Eduard.
Security Week. 23 de septiembre de 2014). Esto significó que el gobierno corporativo para la seguridad, la privacidad y la
confiabilidad pasó de un modelo centralizado administrado por el grupo de computación confiable de Microsoft a un modelo
descentralizado administrado por equipos de productos individuales. Desde entonces, ha habido aumentos significativos en
el número total de CVE asignados a productos de Microsoft.

Por supuesto, los cambios en el modelo de gobierno de Microsoft no son los únicos factores que contribuyen
potencialmente a este aumento en las revelaciones de vulnerabilidades; como mencioné anteriormente, hay varios.
Figura 3.12: CVE de gravedad alta y crítica, y CVE de gravedad alta y crítica con complejidad
de acceso baja en productos de Microsoft como porcentaje del total (1999–2021)
Centrándose en los 5 años entre el comienzo de 2017 y el final de 2021, la Figura 3.13 ilustra un aumento
del 84 % en CVE asignados a productos de Microsoft (Detalles de CVE, sin fecha). Hubo un total de 3.969
CVE asignados a Microsoft durante estos años. Hubo una disminución del 29 % en las vulnerabilidades
críticas y de alta gravedad después de un período elevado y un aumento del 420 % en los CVE de baja
complejidad de acceso. El lado positivo aquí es la gran disminución de los CVE críticos y de alta gravedad
durante este período, específicamente entre 2020 y 2021, cuando hubo una disminución del 69 %.
Microsoft ha realizado importantes inversiones para dificultar la explotación de vulnerabilidades. Publicaron
datos convincentes sobre la explotabilidad de sus productos que vale la pena ver para obtener una imagen
más completa (Matt Miller, 2019).
Capítulo 3 77
Figura 3.13: Número de CVE, CVE críticos y de alta gravedad, y CVE de baja complejidad de acceso en
productos de Microsoft (2017–2021) (Detalles de CVE, sin fecha)
Como ilustra la Figura 3.14 , entre 2017 y 2021, aumentó la cantidad de vulnerabilidades de baja complejidad,
como porcentaje de todas las vulnerabilidades de Microsoft en cada año, mientras que disminuyó el porcentaje
de vulnerabilidades críticas y de calificación alta. La disminución del 29 % en las vulnerabilidades críticas y de
alta gravedad durante este período es impresionante; Durante una época históricamente alta de divulgaciones
de vulnerabilidades para Microsoft, pudieron mantener los puntajes CVSS para la mayoría de sus CVE por
debajo de 7. En 2021, los rangos de puntaje CVSS con la mayoría de los CVE de Microsoft fueron 4–5 y 6–7.
Figura 3.14: CVE con clasificación de gravedad crítica y alta y CVE de baja complejidad en productos de
Microsoft, como porcentaje del total (20172021)
Los productos que más contribuyeron al recuento general de CVE de Microsoft incluyen Windows 10, Windows
Server 2016, Windows Server 2008, Windows 7, Windows Server 2012, Windows Server 2019 y Windows 8.1
(Detalles de CVE, sin fecha). ¿Notó que falta algo en esa lista de productos? No hubo navegadores web de Microsoft
(Internet Explorer o Microsoft Edge) entre los 20 productos principales con la mayor cantidad de CVE en la industria.
Discutiré las tendencias de divulgación de vulnerabilidades para sistemas operativos y navegadores web más
adelante en este capítulo.
Ahora apliquemos el marco de mejora de vulnerabilidades que presenté anteriormente en este capítulo a los datos
de Microsoft CVE de 2017 a 2021. Las tres medidas del marco son:
• ¿Redujeron el número de CVE durante este período de cinco años? No.
• ¿Redujeron el número de CVE críticos y de alta gravedad? Sí.
• ¿Redujeron el número de CVE con baja complejidad de acceso? No.
Como puede ver, solo lograron uno de los objetivos definidos por el marco. Veamos cómo se desempeñaron otros
proveedores en estas mismas tres medidas.
Tendencias de vulnerabilidad de Oracle

Dado que Oracle ocupa el puesto número 2 en la lista de los 10 principales proveedores con la mayor cantidad de
CVE desde 1999, examinemos sus tendencias de CVE a continuación (Detalles de CVE, sin fecha). Hay CVE en el
NVD para productos de Oracle que se remontan a 1999. La Figura 3.15 ilustra la cantidad de CVE publicadas cada
año para productos de Oracle entre 2017 y 2021, así como la cantidad de CVE con clasificaciones de gravedad
crítica y alta, y la cantidad de CVE con baja complejidad de acceso.
Figura 3.15: Número de CVE, CVE críticos y altos, y CVE de baja complejidad en productos de Oracle
(20172021) (Detalles de CVE, sin fecha)
Capítulo 3 79
Hubo más CVE asignados a Oracle (4.272) durante estos cinco años que los asignados a Microsoft (3.969). Sin
embargo, Oracle tuvo una fracción de la cantidad de CVE críticos y de alta calificación en comparación con Microsoft
durante este período; A Oracle se le asignó 380 frente a los 1354 de Microsoft ( Detalles de CVE, sin fecha).
Después de años de aumentos constantes en la cantidad de CVE cada año a partir de 2014, Oracle parece haber
aplanado esa curva entre 2017 y 2021, como ilustra la Figura 3.15 . Oracle finalizó este período de cinco años con
menos divulgaciones anuales de CVE que cuando comenzó. Sin embargo, hubo un aumento del 26 % en CVE con
baja complejidad de acceso y un aumento del 19 % en CVE críticos y de alta calificación durante este mismo período.
Esto significa que no cumplirán con los criterios establecidos para nuestro marco de mejora de la vulnerabilidad para
este período de cinco años.
La Figura 3.16 nos muestra que Oracle ha mantenido la cantidad de CVE críticas y de alta gravedad, como porcentaje
de todas las vulnerabilidades de Oracle en cada año, relativamente baja y estable.
Figura 3.16: CVE con clasificación de gravedad crítica y alta, y CVE de baja complejidad en productos de
Oracle, como porcentaje del total (20172021)
Según CVE Details, los productos de Oracle que más contribuyeron al número total de CVE durante este período
incluyeron MySQL, JRE y JDK.
Tendencias de vulnerabilidad de Google

El proveedor n.° 3 en la lista de proveedores principales de CVE Details con la mayor cantidad de CVE es Google.
Examinemos sus tendencias CVE. Entre 2017 y 2021, se asignaron 4777 CVE a Google, en comparación con 3969
CVE de Microsoft y 4272 CVE de Oracle (Detalles de CVE, sin fecha). De esos CVE en los productos de Google, 1253
o el 26 % se clasificaron como críticos o de gravedad alta, y 2447 o el 51 % tenían una complejidad de acceso baja.
Las tres medidas se ilustran en la Figura 3.17.
Figura 3.17: Número de CVE, CVE críticos y altos, y CVE de baja complejidad en los productos de Google
(2017–2021) (Detalles de CVE, sin fecha)
Al observar la tendencia en los cinco años entre 2014 y finales de 2018, hubo un aumento del 398 % en los CVE
asignados a los productos de Google. Después de este aumento dramático en los CVE de Google, retrocedieron
ligeramente en 2018 y 2019 antes de alcanzar un nuevo máximo histórico en 2020, y luego retrocedieron
ligeramente en 2021. La cantidad anual de CVE y la cantidad anual de CVE de baja complejidad de acceso
aumentaron entre el inicio y el final del período de cinco años, con un aumento del 20 % en la cantidad de CVE y
un aumento del 132 % en la cantidad de CVE de baja complejidad de acceso . Esto significa que Google no
cumplirá con los criterios establecidos para nuestro marco de mejora de vulnerabilidades para este período de
cinco años. Sin embargo, Google redujo los CVE críticos y de alta gravedad en un 69 % durante este tiempo, un
gran logro. La Figura 3.18 ilustra tanto el aumento de las vulnerabilidades de baja complejidad de acceso como
la disminución de los CVE críticos y de alta gravedad durante el período de cinco años.
Figura 3.18: CVE críticos y de gravedad alta y CVE de baja complejidad en los productos de Google, como
porcentaje del total (20172021)
Capítulo 3 81
Según CVE Details, los productos que contribuyeron con la mayor cantidad de CVE a los totales de Google
incluyeron Android, Chrome y TensorFlow.
Google y Microsoft son feroces competidores, y ambos ofrecen a consumidores y empresas sistemas
operativos, navegadores web y servicios en la nube, entre otros productos. Están bajo presiones competitivas
similares, así como presiones legales y regulatorias, ambos tienen su sede en la costa oeste de los Estados
Unidos y tienen operaciones globales, y compiten por el mismo grupo de talento técnico para su fuerza laboral.
Entonces, quizás se pregunte cómo se comparan cuando se trata de divulgaciones de vulnerabilidades. Las
figuras 3.19 y 3.20 revelan la respuesta a esta pregunta. Hay algunas diferencias, pero es interesante cuán
similares son los puntos de datos CVE de estos titanes tecnológicos al final del período de cinco años.
Figura 3.19: Número de CVE, CVE críticos y altos, y CVE de baja complejidad en productos de Google
y Microsoft (2017–2021) (Detalles de CVE, sin fecha)
La Figura 3.20 ilustra las vulnerabilidades de mayor riesgo tanto de Google como de Microsoft entre 2017 y
2021: aquellas con una gravedad crítica y alta y una complejidad de acceso baja. Parece que Microsoft hizo
un mejor trabajo al administrar estos CVE de alto riesgo en cada uno de los cinco años, especialmente en
2018. Sin embargo, esta diferencia casi desapareció en 2021.
Desafortunadamente, ninguno de estos proveedores cumplió con los criterios de nuestro marco de mejora de
vulnerabilidades durante este período de cinco años.
Figura 3.20: CVE críticos y de alta gravedad, y CVE críticos y de alta gravedad con baja complejidad
de acceso en productos de Google y Microsoft como porcentaje del total (20172021)
Tendencias de vulnerabilidades de Debian

A continuación, examinemos CVE en Debian tal como aparece en el puesto n.° 4 en la lista de los principales
proveedores de detalles de CVE (Detalles de CVE, sin fecha). Entre 2017 y 2021, se asignaron 4814 CVE a
Debian, de los cuales 824 o el 17 % eran críticos o de alta gravedad, y 2324 o el 48 % eran de baja complejidad
de acceso. Tal vez recuerde que hubo 4777 CVE asignados a Google, 3969 asignados a Microsoft y 4272
asignados a Oracle durante el mismo período de tiempo (Detalles de CVE, sin fecha). El número anual de CVE
y el número anual de CVE con baja complejidad de acceso fueron más altos al final del período de cinco años
que al comienzo del mismo. Los CVE experimentaron un aumento del 26 %, mientras que los CVE con baja
complejidad de acceso aumentaron un 14 %. Posteriormente, Debian no cumplirá con los criterios de nuestro
marco de mejora de vulnerabilidades para este período de tiempo.
Capítulo 3 83
Figura 3.21: Número de CVE, CVE críticos y altos, y CVE de baja complejidad en productos
Debian (20172021) (CVE Details, nd)
Tanto la Figura 3.21 como la 3.22 ilustran la misma reducción de CVE críticos y de alta gravedad durante los cinco años
examinados, finalizando el período con un 22% menos que al inicio.
Figura 3.22: CVE críticos y de gravedad alta y CVE de baja complejidad en productos Debian,
como porcentaje del total (20172021)
Debian Linux fue el mayor contribuyente a CVE para Debian durante este período.
Tendencias de vulnerabilidad de Apple

El último proveedor que examinaré es Apple, que está clasificado como el proveedor principal número 5 en la lista de
proveedores principales de CVE Details (Detalles de CVE, sin fecha). A Apple se le asignaron 2404 CVE durante los cinco
años entre 2017 y 2021. Eso es significativamente menos CVE que cualquiera de los otros cuatro proveedores que examiné.
Apple tenía la mitad de los CVE que tenía Debian durante el mismo período. Como ilustra la Figura 3.23 ,
Apple comenzó el período de cinco años con 598 CVE en 2017 y finalizó con 592 en 2021, una disminución
del 1 %. El número de CVE calificados como críticos o altos disminuyó en un 24 % y el número de CVE de
baja complejidad de acceso disminuyó en un 56 %.
Figura 3.23: Número de CVE, CVE críticos y altos, y CVE de baja complejidad en productos Apple (2017–
2021) (Detalles de CVE, sin fecha)
Si bien el porcentaje de CVE de baja complejidad de acceso que finaliza el período en 2021 fue relativamente
alto en Microsoft y Google CVE, con un 65 % y un 60 % respectivamente, Apple solo tenía un 11 %. Esto
se ilustra en la Figura 3.24.
Figura 3.24: CVE críticos y de alta gravedad y CVE de baja complejidad en productos Apple,
como porcentaje del total (20172021)
Capítulo 3 85
Los productos que más contribuyeron al recuento de CVE de Apple incluyeron macOS, iPhone OS, tvOS, Safari y
watchOS (Detalles de CVE, sin fecha).
Como hicimos con los otros cuatro proveedores, apliquemos el marco de mejora de vulnerabilidades a los datos de
Apple CVE de 2017 a 2021. Las tres medidas del marco son:
• ¿Redujeron el número de CVE durante este período de cinco años? Sí.
• ¿Redujeron el número de CVE críticos y de alta gravedad? Sí.
• ¿Redujeron el número de CVE con baja complejidad de acceso? Sí.
¡Felicidades Apple, lo lograste! Cumplió con todos los criterios del marco de mejora de vulnerabilidades . De hecho,
Apple también logró cumplir con los mismos criterios cuando lo apliqué al período de cinco años entre 2014 y 2018, que
analicé en la primera edición de este libro. Fueron el único proveedor entre los cinco principales en lograr esto, también
en ese entonces. Claramente, Apple tiene las personas, los procesos y las tecnologías ajustados para realizar mejoras
continuas y significativas en la seguridad de sus productos. Esto es algo que los otros proveedores no han podido hacer
en los dos períodos de cinco años. He examinado en la primera y segunda ediciones de este libro.
Resumen de tendencias de vulnerabilidad de proveedores
Una nueva era en la divulgación de vulnerabilidades comenzó en 2017, una era de volúmenes históricamente altos.
Todos los proveedores que examinamos en este capítulo vieron aumentos en la cantidad de divulgaciones de
vulnerabilidades en sus productos entre 2016 y 2017. Desde entonces, estos proveedores han tenido problemas para
reducir los volúmenes de CVE a los niveles anteriores a 2017. El volumen de divulgaciones de vulnerabilidades en los
años de los grandes ataques de gusanos del período 20032004 parece extraño en comparación con los volúmenes
que hemos visto en los últimos cinco años.

La figura 3.25 traza los recuentos de CVE para los 5 principales proveedores de 2016 a 2021.
Figura 3.25: Número de CVE en productos de proveedores (2016–2021) (Detalles de CVE, sin fecha)
La Figura 3.26 muestra la tendencia del número de CVE críticos y de alta calificación para cada uno de los cinco
proveedores entre 2017 y 2021. Oracle merece una mención de honor por mantener el número más bajo de CVE críticos y
altos en los cinco años. Debian, Google y Microsoft tuvieron grandes reducciones en las vulnerabilidades críticas y de alta
gravedad durante este período.

Capítulo 3 87
Figura 3.26: Número de CVE críticos y de alta gravedad en productos de proveedores (20172021) (Detalles de CVE,
sin fecha)
La Figura 3.27 muestra el número bruto de CVE, CVE críticos y de alta gravedad, y CVE de baja complejidad
de acceso para cada proveedor. Este gráfico facilita ver los números relativamente bajos de Apple en
comparación con los otros proveedores.
Figura 3.27: Número de CVE, CVE clasificados como críticos y de alta gravedad, y CVE de baja complejidad en
productos de proveedores (2017–2021) (Detalles de CVE, sin fecha)

Finalmente, los resultados generales del marco de mejora de la vulnerabilidad se encuentran en la Figura 3.28.
Figura 3.28: Resultados del marco de mejora de la vulnerabilidad para 2017–2021
En pocas palabras, nuestro marco de mejora de vulnerabilidades mide cómo estos proveedores han
reducido o no el riesgo para sus clientes. Menos CVE, menos CVE severos y menos CVE fáciles de
explotar se traducen en menos complejidad, menos gastos y menos riesgo para las empresas. Apple
entiende esto claramente y es capaz de lograrlo para sus clientes.
Ahora que hemos examinado las tendencias de divulgación de vulnerabilidades para los CVE agregados de los cinco
principales proveedores con la mayor cantidad de CVE, profundicemos un poco más y observemos las tendencias de
divulgación de vulnerabilidades para algunos sistemas operativos y navegadores web populares.
Tendencias de vulnerabilidad del sistema operativo

Los sistemas operativos han llamado mucho la atención de los investigadores de seguridad en las últimas dos décadas. Un
exploit funcional para una vulnerabilidad de día cero en un popular sistema operativo de escritorio o móvil puede tener un
valor potencial de cientos de miles de dólares o más. Veamos las tendencias de divulgación de vulnerabilidades para los
sistemas operativos y analicemos de cerca algunos de los productos que tienen los recuentos de vulnerabilidades más altos.
La figura 3.29 ilustra los sistemas operativos que tenían las vulnerabilidades más exclusivas entre 1999 y julio de 2022, según
CVE Details (CVE Details, nd). La lista contiene sistemas operativos de escritorio, servidor y móviles de una variedad de
proveedores, incluidos Apple, Google, Linux, Microsoft y otros.

Capítulo 3 89
Figura 3.29: Sistemas operativos con las vulnerabilidades más exclusivas por número total de recuentos de
CVE (1999 a 2022 (enerojulio)) (Detalles de CVE, sin fecha)
En esta sección, seleccionaré algunos sistemas operativos (SO) y examinaré sus últimos tres años completos de
medidas de divulgación de vulnerabilidades, como hice con los proveedores en la última sección. Los sistemas
operativos que seleccione se basarán en su popularidad entre los clientes empresariales que he asesorado en el
pasado. Dado que cubrí en gran medida Debian en la sección de proveedores y Debian Linux es casi la única fuente de
CVE para Debian, comencemos con el próximo sistema operativo con la mayor cantidad de CVE, Android.
Tendencias de vulnerabilidad de Google Android

Veamos Android, un sistema operativo móvil fabricado por Google. La fecha de lanzamiento inicial de
Android fue en septiembre de 2008 y las CVE para Android comenzaron a aparecer en 2009. Android
solo tuvo 38 CVE en los 6 años que van de 2009 a 2014 (Detalles de CVE, sin fecha). El volumen de
CVE en Android comenzó a aumentar significativamente en 2016, aumentando un 426 % con respecto
al año anterior. Durante los tres años entre 2019 y 2021, se registraron en promedio 641 CVE para Android por año.
En promedio, hubo 158 CVE por año calificados como críticos o de alta gravedad y 459 CVE con baja
complejidad de acceso. La tendencia de tres años se ilustra en la Figura 3.30.
Durante este tiempo, la cantidad anual de divulgaciones de CVE aumentó en un 16 % y la cantidad anual de
divulgaciones de vulnerabilidades con baja complejidad de acceso aumentó en un 81 %. Las vulnerabilidades
críticas y de alta calificación terminaron el período con un modesto aumento del 6%. Juntos, estos aumentos
significan que Android no cumplirá con los criterios de nuestro marco de mejora de vulnerabilidades para este período de tiempo.
Figura 3.30: La cantidad de CVE, CVE de gravedad crítica y alta y CVE de baja complejidad en
Google Android por año (20192021) (Detalles de CVE, sin fecha)
La Figura 3.30 nos muestra que hubo un gran aumento en las vulnerabilidades de Android que son fáciles de
explotar, entre 2019 y 2020. En los últimos dos años, más del 80 % de todos los CVE de Android tenían una
complejidad de acceso baja. Google ha mantenido estable el nivel de vulnerabilidades críticas y de alta
gravedad en Android durante estos tres años, en casi una cuarta parte de todos los CVE.
Figura 3.31: CVE críticos y de gravedad alta y CVE de baja complejidad en Google Android como
porcentaje de todos los CVE de Google Android durante 20192021
Veamos cómo Google ha gestionado los CVE de mayor riesgo en Android, aquellos con gravedad crítica y
alta que también tienen una complejidad de acceso baja. Durante estos tres años, 385 CVE o el 20 % de todos
los CVE de Android entraron en esta categoría.
Capítulo 3 91
La Figura 3.32 revela que hubo un gran aumento en el porcentaje de CVE en esta categoría entre 2019 y 2020, lo
que resultó en un 93 % de CVE críticos y de alta calificación con baja complejidad de acceso en 2020 y un 87 % en
2021. Este es probablemente el resultado del aumento de CVE de baja complejidad de acceso durante el mismo
período que se ilustra en la Figura 3.31. La conclusión es que el 93 % de las vulnerabilidades más graves de
Android fueron relativamente fáciles de explotar en 2020 y el 87 % en 2021.
Figura 3.32: CVE críticos y de alta gravedad que tienen una complejidad de acceso baja, como porcentaje
de todos los CVE críticos y de alta calificación en Google Android durante 2019–2021
Durante este período de tres años, Android experimentó aumentos en las tres medidas de nuestro marco de mejora
de vulnerabilidades y un aumento en el porcentaje de CVE de mayor riesgo. Quizás se pregunte si estas tendencias
son típicas de los sistemas operativos móviles que son tan populares entre tantas personas en todo el mundo. ¿El
mundo hipercompetitivo de la investigación de vulnerabilidades ejerce presión sobre todos estos proveedores de
sistemas operativos móviles? Para tratar de responder a estas preguntas, comparemos estas tendencias de Android
con otro sistema operativo muy popular, el sistema operativo Apple iPhone, también conocido como iOS.
Tendencias de vulnerabilidad de Apple iOS

Apple comenzó a lanzar iPhone OS en junio de 2007 y luego pasó a llamarse iOS. Solo se asignaron 34 CVE en
los primeros cuatro años después del lanzamiento. Grandes aumentos incrementales en CVE ocurrieron en 2011 y
2015, con aumentos de 315% y 219% respectivamente. iOS tuvo 1052 CVE entre 2019 y 2021.
Eso es un promedio de 351 CVE por año. iOS tuvo 248 CVE críticos y de alta calificación, equivalentes al 24% del
total, y un promedio de 83 CVE por año. Los CVE de baja complejidad de acceso tuvieron un recuento total de 290
en esos tres años, o 97 por año en promedio. Estos CVE representaron el 28 % de todos los CVE de Android
durante este período de tres años.
La Figura 3.33 ilustra la tendencia de los CVE, los CVE críticos y de alta gravedad y los CVE con baja complejidad de
acceso entre 2019 y 2021.
Figura 3.33: Número de CVE, CVE críticos y de alta gravedad y CVE de baja complejidad en Apple
iOS (20192021)
La Figura 3.34 muestra los porcentajes de CVE críticos y de alta calificación como porcentaje de todos los CVE de iOS.
También muestra los porcentajes de CVE de baja complejidad de acceso respecto al total.
Figura 3.34: CVE críticos y de gravedad alta y CVE de baja complejidad en Apple iOS como porcentaje
de todos los CVE de Apple iOS durante 2019–2021
Capítulo 3 93
Resumen del sistema operativo móvil

Entonces, ¿cómo se compara Apple iOS con Android? La figura 3.35 proporciona un resumen. Menos
vulnerabilidades, menos vulnerabilidades graves y menos vulnerabilidades más fáciles de explotar significa menos riesgo y menos
gastos.
Figura 3.35: Comparación de Apple iOS y Google Android 2019–2021
Aunque Apple tuvo un mejor historial con iOS que con Android durante este período, no cumplió con los
criterios de nuestro marco de mejora de vulnerabilidades porque tanto la cantidad anual de CVE como las
CVE de baja gravedad fueron más altas en 2021 que en 2019. Apple redujo la cantidad de CVE críticas y de
alta gravedad durante este tiempo, en un modesto 4 %.
A continuación, veamos un par de sistemas operativos que se ejecutan en plataformas informáticas de escritorio.
Tendencias de vulnerabilidad de Microsoft Windows 10

Windows 10 fue llamado “la versión más segura de Windows” (err… por mí (Ribeiro, nd)).
Windows 10 se lanzó en julio de 2015. En los siete años transcurridos desde su lanzamiento, se han divulgado
2806 vulnerabilidades en este sistema operativo. Para agregar un poco de perspectiva, en los 20 años y 9
meses desde su fecha de lanzamiento, Windows XP ha tenido asignados 685 CVE (Detalles de CVE, sin
fecha). Para que la diferencia sea más fácil de entender, Windows XP reveló 0,15 vulnerabilidades por día,
en promedio, entre la fecha de lanzamiento y la fecha de finalización del soporte. Windows 10 ha tenido 1.1
CVE divulgados por día desde su fecha de lanzamiento. Como mencioné anteriormente, hay muchos factores
que pueden ayudar a explicar esta diferencia, incluida una industria de ciberseguridad hipercompetitiva
masiva que continúa creciendo.
Centrándonos en los últimos tres años para los que tenemos datos de años completos, Windows 10 tenía 1740
CVE, de los cuales el 34 % eran críticos o de alta gravedad y el 68 % tenían una complejidad de acceso baja. Las
cifras brutas para cada una de estas medidas se presentan en la Figura 3.36.
Figura 3.36: El número de CVE, CVE de gravedad crítica y alta y CVE de baja complejidad en
Microsoft Windows 10 (2019–2021) (Detalles de CVE, sin fecha)
Como ilustra la Figura 3.36 , el número de CVE por año fue mayor al final de los tres años que al principio, mientras
que el número de CVE por año con baja complejidad de acceso fue el mismo.
El número de CVE calificados como críticos o de alta gravedad disminuyó un 66 % durante este período, un logro
importante. Esta disminución también se puede ver en la Figura 3.37 , donde el porcentaje de vulnerabilidades
críticas y de gravedad alta en relación con todos los CVE de Windows 10 disminuyó constantemente durante los
tres años, comenzando en 51,56 % en 2019, disminuyendo a 35,44 % en 2020 y finalizando el período con 16,08 %.
Figura 3.37: CVE críticos y de gravedad alta y CVE de baja complejidad en Microsoft Windows 10
como porcentaje de todos los CVE de Microsoft Windows 10 durante 2019–2021
Pero a medida que Microsoft redujo la cantidad de vulnerabilidades más graves en Windows 10, aumentó la
proporción de vulnerabilidades graves que también tenían una complejidad de acceso baja.
Capítulo 3 95
La Figura 3.38 nos muestra que el porcentaje de vulnerabilidades críticas y de alta gravedad que también tenían
baja complejidad de acceso, como porcentaje de todas las vulnerabilidades críticas y de alta gravedad, aumentó
durante el período de tres años. Como resultado, en 2021, el 89 % de todos los CVE críticos y de alta calificación
fueron fáciles de explotar. Tenga en cuenta que es posible reducir el porcentaje de CVE que tienen una gravedad
alta y una complejidad de acceso baja, a medida que disminuye la cantidad de vulnerabilidades de gravedad alta; consulte
este mismo gráfico para macOS.
Figura 3.38: CVE críticos y de alta gravedad que tienen una complejidad de acceso baja, como porcentaje
de todos los CVE críticos y de alta calificación en Microsoft Windows 10 durante 2019–2021
A pesar de esto, Windows 10 estuvo muy cerca de cumplir con nuestros criterios del marco de mejora de vulnerabilidades.
Solo 38 CVE menos en 2021, y Windows 10 probablemente habría cumplido con los criterios. A continuación, veamos
otro sistema operativo de escritorio, pero de un proveedor diferente.
Tendencias de vulnerabilidad de Apple macOS

Ahora examinaré macOS X de Apple. Hay CVE que datan de 2001 para este sistema operativo; se lanzó inicialmente
en marzo de ese año. Hasta la fecha, se han ingresado 3016 CVE en el NVD para macOS (Detalles de CVE, sin fecha).
En promedio, eso es 0.38 CVE por día. Recordará que Windows 10 ha tenido 1,1 CVE por día, en promedio, desde su
lanzamiento.
Entre 2019 y 2021, macOS tuvo 929 divulgaciones de vulnerabilidades, de las cuales el 31 % fueron críticas o
calificadas como altas, y el 35 % tenían una complejidad de acceso baja. Esto se ilustra en la Figura 3.39, donde
el número anual de CVE aumentó en un 7 o 2,3 % durante tres años.
Durante este tiempo, las CVE de baja complejidad se redujeron en un 33,3 % y las capacidades de vulnerabilidades
críticas y de alta severidad se redujeron en un 27 %. macOS no cumplió con los criterios de nuestro marco de mejora
de vulnerabilidades por unos míseros 8 CVE en 3 años. ¡Tan cerca!
Figura 3.39: Número de CVE, CVE de gravedad crítica y alta y CVE de baja complejidad en Apple
macOS por año (20192021)
Esta reducción de vulnerabilidades severas y vulnerabilidades de baja complejidad de acceso también se puede ver
en la Figura 3.40, donde el porcentaje de ambas disminuyó cada año en relación con el número total de
CVE en macOS.
Figura 3.40: CVE críticos y de gravedad alta y CVE de baja complejidad en Apple macOS como
porcentaje de todos los CVE de Apple macOS durante 2019–2021
Capítulo 3 97
Si bien Apple pudo disminuir las vulnerabilidades de alta gravedad en un 27 % entre el inicio y el final del período de tres años,
también logró reducir el porcentaje de CVE que eran críticas y de alta gravedad que también tenían una complejidad de acceso
baja, lo que significa que redujeron la categoría de riesgo más alto de CVE en macOS durante este tiempo, como se refleja en la
Figura 3.41 . ¡Bravo Manzana!
Figura 3.41: CVE críticos y de alta gravedad que tienen una complejidad de acceso baja, como porcentaje de
todos los CVE críticos y de alta calificación en Apple macOS durante 2019–2021
Resumen del sistema operativo de escritorio

Quizás se pregunte cómo se compara Apple macOS con Microsoft Windows 10. La figura 3.42 proporciona un resumen. Menos
vulnerabilidades, menos vulnerabilidades graves y menos vulnerabilidades fáciles de explotar significa menos riesgo y menos
gastos.
Figura 3.42: Comparación de Apple macOS y Microsoft Windows 10 2019–2021
A continuación, examinemos algunos sistemas operativos de servidor que se ejecutan en centros de datos empresariales. Ya he
examinado las CVE de Debian en la sección de proveedores de este capítulo, que se basan en gran medida en las CVE de Debian.
linux Examinemos Ubuntu Linux a continuación.
Tendencias de vulnerabilidades de Ubuntu Linux

¿Sabías que hay cientos de distribuciones de Linux activas? Canonical Ubuntu Linux es uno de los más populares.
Canonical proporciona una página web que se puede utilizar para la investigación de CVE en https://ubuntu.
com/seguridad/cves. Hay CVE con fechas de publicación que se remontan a 2005 para Ubuntu. Entre entonces y el
momento de escribir este artículo, se han asignado 3423 CVE a Ubuntu Linux.
La Figura 3.43 ilustra la tendencia CVE durante los últimos tres años para los cuales tenemos datos de un año completo.
Como muestra la figura, hubo una gran caída (94 %) en los CVE entre 2020 y 2021. Cada vez que veo grandes cambios
en datos como este, sin más contexto, soy muy escéptico sobre la calidad de los datos . Si es preciso, el volumen de
CVE en 2021 es similar al volumen que tenía Ubuntu en 2011 y 2006. Soy escéptico porque es difícil para las empresas
cambiar, en un solo año, las personas, los procesos y las tecnologías que utilizan para desarrollar software tan complejo
como un sistema operativo, de una manera que conduzca a una reducción del 94 % en las divulgaciones de
vulnerabilidades. No he visto a un proveedor de sistemas operativos hacer eso en los 20 años que llevo estudiando las
divulgaciones de vulnerabilidades. Ha habido muchos casos en los que una versión se retira porque llega el final de su
vida útil y los usuarios la abandonan en masa. Esto tiende a cambiar la atención de los equipos de desarrollo y los
investigadores de seguridad hacia las versiones compatibles actualmente. Posteriormente, el volumen de CVE puede
caer rápidamente si finalmente se exorciza el código antiguo que es una fuente perenne de vulnerabilidades. Eso podría
ser lo que sucedió en 2021. Canonical proporciona información sobre el ciclo de vida en https://wiki.ubuntu.com/
Releases. Esta página indica que tres versiones de Ubuntu alcanzaron sus fechas de fin de vida en 2020 y 2021,
incluidas Disco Dingo (versión 19.04), Eoan Ermine (versión 19.10) y Groovy Gorilla (versión 20.10). Además, el número
de CVE a mediados de 2022 está en el mismo estadio (21 CVE) que en 2021. Veremos si estos números superan la
prueba del tiempo y si surge una nueva tendencia de bajo volumen. Para este análisis, asumiré que estos datos son
precisos, ¡porque quiero creer!
Figura 3.43: Número de CVE, CVE críticos y de alta gravedad y CVE de baja complejidad
en Canonical Ubuntu Linux por año (20192021)
Capítulo 3 99
La figura 3.43 indica claramente que Canonical Ubuntu Linux satisface los criterios de nuestro marco de
mejora de vulnerabilidades, una hazaña que ni Apple ni Microsoft lograron durante el mismo período de
tiempo. ¡Bravo Ubuntu!
La Figura 3.44 nos muestra que a medida que la cantidad de CVE se redujo drásticamente en 2021, el porcentaje de edad de esos
CVE con baja complejidad de acceso aumentó al 88 %, y hubo un gran aumento en el porcentaje de vulnerabilidades críticas y de alta
gravedad entre 2020 y 2021. Sin embargo, 25 CVE en 2021 es mucho más fácil de administrar para los equipos de gestión y corrección
de vulnerabilidades que 408 o 477 como se vio en años anteriores.
Figura 3.44: CVE críticos y de alta gravedad y CVE de baja complejidad en Canonical Ubuntu Linux
como porcentaje de todos los CVE de Canonical Ubuntu Linux durante 2019–2021
Debido a que mis datos de Ubuntu son un poco sospechosos, pensé en proporcionar un análisis en otro sistema operativo Linux donde
los datos que tengo parecen un poco más confiables. A continuación, examino las tendencias de CVE para Linux Kernel, un kernel de
sistema operativo de código abierto.
Tendencias de vulnerabilidad del kernel de Linux

En los tres años entre 2019 y 2021, se asignaron 576 CVE a Linux Kernel. De estos CVE, el 25%
eran críticos y de alta gravedad y el 77% eran de baja complejidad de acceso. La Figura 3.45 revela
que las tres medidas en nuestro marco de mejora de la vulnerabilidad se redujeron en este período
de tres años. ¡Felicitaciones Linux Kernel por cumplir con los criterios!
El número de CVE se redujo en un 44 %, las vulnerabilidades más graves se redujeron en un 69 % y las CVE de baja complejidad de acceso se
redujeron en un 40 %.
Figura 3.45: Número de CVE, CVE críticos y de alta gravedad y CVE de baja complejidad en el kernel de
Linux por año (20192021)
La Figura 3.46 nos muestra que aunque los CVE críticos y de alta gravedad como porcentaje del total se
redujeron durante los tres años, el porcentaje de CVE de baja complejidad de acceso aumentó, lo que
significa que, a medida que se reducía el número de CVE cada año, había menos vulnerabilidades graves
pero una mayor proporción de vulnerabilidades fáciles de explotar.
Figura 3.46: CVE críticos y de alta gravedad y CVE de baja complejidad en el kernel de Linux como
porcentaje de todos los CVE del kernel de Linux durante 2019–2021
A continuación, examinemos uno de los sistemas operativos de servidor más populares de Microsoft, Windows Server 2016.
Capítulo 3 101
Tendencias de vulnerabilidad de Microsoft Windows Server 2016

Windows Server 2016 es un sistema operativo de servidor muy popular. Se lanzó a finales de 2016, lo que significa
que, en el momento de escribir este artículo, tenemos más de tres años completos de datos CVE para examinar.
Esto no es cierto para las versiones más recientes de los productos de servidor de Microsoft, como Windows Server 2019 o
Servidor Windows 2022.
Durante 2019 a 2021, Windows Server 2016 tuvo asignados 1739 CVE. De estos, el 34% fueron críticos y de alta
severidad, mientras que el 76% fueron de baja complejidad de acceso. Los números brutos de CVE para cada una
de estas categorías se muestran en la Figura 3.47.
Figura 3.47: Número de CVE, CVE críticos y de alta gravedad y CVE de baja complejidad en
Windows Server 2016 por año (20192021)
Dado que la cantidad anual de CVE aumentó un 13 % y la cantidad de CVE de baja complejidad de acceso aumentó
un 51 % durante estos tres años, Windows Server 2016 no cumple con los criterios de nuestro marco de mejora de
vulnerabilidades. El lado positivo es que Microsoft redujo la cantidad anual de vulnerabilidades críticas y de alta
gravedad en un 63 % durante este período. Este es un logro importante y muy positivo para los clientes de Microsoft.
La figura 3.48 revela que a medida que Microsoft redujo la proporción de las vulnerabilidades más graves en Windows
Server 2016, aumentó la proporción de vulnerabilidades de baja complejidad de acceso. En 2021, según los datos de
CVE Details, el 84% de los CVE en este SO eran de baja complejidad de acceso; esto es significativamente más alto
que el porcentaje en Windows 10 (58%) durante el mismo período, pero en el mismo rango que otros sistemas
operativos de servidor, como Ubuntu y Linux Kernel.

Figura 3.48: CVE críticos y de gravedad alta y CVE de baja complejidad en Microsoft Windows
Server 2016 como porcentaje de todos los CVE de Microsoft Windows Server 2016 durante 2019–2021
Podría escribir un libro completo dedicado a examinar los sistemas operativos de servidor porque hay muchos de ellos;
apenas hemos arañado la superficie aquí. ¡Prometí proporcionar análisis para dos sistemas operativos de servidor y
proporcioné análisis para tres! Usando los ejemplos que proporcioné aquí, creo que les he dado a los lectores que quieren
hacer su propio análisis en otros sistemas operativos de servidor un buen marco. Terminemos nuestro examen de los
sistemas operativos de servidor comparando los tres que vimos.
Resumen del sistema operativo del servidor

La figura 3.49 proporciona un resumen de las métricas clave que examinamos para los sistemas operativos de servidor.
Menos habilidades vulnerables, menos vulnerabilidades graves y menos vulnerabilidades fáciles de explotar significan
menos riesgo y menos gastos.
Figura 3.49: Comparación de Ubuntu Linux, Linux Kernel y Windows Server 2016 20192021
Ahora cambiemos de tema y terminemos esta inmersión profunda en las tendencias de vulnerabilidad examinando dos de
los navegadores web más populares del mundo.

Capítulo 3 103
Tendencias de vulnerabilidad del navegador web

Los navegadores web atraen mucha atención tanto de los investigadores de seguridad como de los atacantes. Esto se
debe a que es difícil vivir sin ellos. Todos usan al menos un navegador en computadoras de escritorio, dispositivos
móviles y en muchos tipos de servidores. Los equipos de desarrollo de sistemas operativos pueden incluir capas de
funciones de seguridad en sus productos, pero los navegadores web tienden a generar amenazas directamente a
través de todos esos firewalls basados en host y otras capas de seguridad. Los navegadores web han sido notoriamente
difíciles de proteger, pero han mejorado a lo largo de los años.
Examinaré dos navegadores web populares en esta sección: Apple Safari y Google Chrome. Todo el mundo tiende a
tener un navegador favorito y algunas personas a las que he informado en el pasado se emocionaron cuando su
navegador favorito tenía más vulnerabilidades de las que creían posibles. Tenga en cuenta que todos estos datos de
CVE son imperfectos y son una instantánea en el tiempo que puede cambiar rápidamente. Por favor, no dejes que
estos datos te pongan de mal humor.
Tendencias de vulnerabilidad de Apple Safari

Apple Safari se introdujo en 2003 y se ejecuta en una variedad de dispositivos, incluidos los que funcionan con Apple
OS, macOS e iOS. Se han asignado 1137 CVE a Safari entre 2003 y finales de 2021. Esto equivale, en promedio, a 60
CVE por año. La Figura 3.50 ilustra la tendencia de tres años para las tres medidas en nuestro marco de mejora de la
vulnerabilidad. Hubo una disminución del 85 % en CVE, una disminución del 84 % en vulnerabilidades graves y una
disminución del 57 % en CVE de baja complejidad de acceso durante este tiempo. Apple lo ha vuelto a hacer: ¡han
cumplido los criterios de nuestro marco de mejora de vulnerabilidades!
Apple Safari por año (2019–2021)
La figura 3.51 revela que Apple fue capaz de mantener porcentajes relativamente bajos de capacidades de
vulnerabilidad severa y CVE de baja complejidad a medida que la cantidad de CVE tendía a la baja durante los tres años.
Figura 3.51: CVE críticos y de alta gravedad y CVE de baja complejidad en Apple Safari como
porcentaje de todos los CVE de Apple Safari durante 2019–2021
¡Felicidades Manzana! A continuación, veamos otro navegador web muy popular, Google Chrome.
Tendencias de vulnerabilidades de Google Chrome

El navegador Google Chrome se lanzó en 2008, primero en Windows y luego en otros sistemas operativos. Hubo
2296 CVE para Chrome entre 2008 y finales de 2021, un promedio de 164 vulnerabilidades por año (Detalles de
CVE, sin fecha). Como se ilustra en la Figura 3.52, las tres medidas en nuestro marco de mejora de vulnerabilidades
disminuyeron entre 2019 y 2021. ¡Guau, felicitaciones a Google!
Google Chrome por año (20192021)
Capítulo 3 105
La Figura 3.53 revela que Google también pudo reducir los porcentajes de CVE graves y de baja complejidad
de acceso, mientras que el número total de CVE se redujo. El volumen de vulnerabilidades críticas y de alta
gravedad y vulnerabilidades de baja complejidad fue tan bajo en 2021 que es difícil no quedar impresionado
con Google Chrome.
Figura 3.53: CVE críticos y de alta gravedad y CVE de baja complejidad en Google Chrome como
porcentaje de todos los CVE de Google Chrome durante 2019–2021
Resumen del navegador web

Es realmente genial y reconfortante ver que los volúmenes de divulgaciones de vulnerabilidades en
navegadores web tan utilizados se administran tan bien.
Apple Safari parece tener la ventaja de que tuvo significativamente menos CVE durante el mismo período que
Google Chrome. Sin embargo, para los equipos de gestión y reparación de vulnerabilidades que se enfocan
en CVE críticos y de alta gravedad, ambos navegadores tuvieron relativamente pocas revelaciones de
vulnerabilidades graves. Tenían una cantidad idéntica de CVE críticos y de alta gravedad que también tenían
una complejidad de acceso baja.
Sé lo que algunos lectores están pensando en este momento: ¿qué pasa con Mozilla Firefox? Los datos de
CVE Details revelan un modesto aumento del 7 % en el número anual de CVE durante el período de tres años.
Esto significa que Firefox no cumpliría con los criterios de nuestro marco de mejora de vulnerabilidades para
este período. Sin embargo, la cantidad anual de CVE críticos y de alta gravedad y CVE de baja complejidad
de acceso se redujo en Firefox durante este tiempo.
Esto es muy positivo. A Firefox se le asignaron 377 CVE durante los tres años.
Figura 3.54: Número de CVE, CVE críticos y de alta gravedad y CVE de baja complejidad en Mozilla Firefox
por año (2019–2021)
Ahora abrí la caja de Pandora. Sé que alguien se pregunta, ¿qué pasa con Microsoft Edge?
Microsoft lanzó su nueva versión de Microsoft Edge basada en el proyecto de código abierto Chromium el 15 de
enero de 2020 (Microsoft, 15 de enero de 2020). En el momento de escribir este artículo, Edge Chromium no tenía
tres años completos de datos CVE. Un análisis tendrá que esperar hasta que tengamos más datos.
La Figura 3.55 proporciona un resumen de las medidas que examinamos para estos navegadores web durante tres
años.
Figura 3.55: Comparación de navegadores web 20192021
Eso concluye mi análisis del navegador web. Esa fue una gran cantidad de datos, déjame resumirla ahora.
Resumen del marco de mejora de vulnerabilidades

Terminemos esta sección sobre tendencias de vulnerabilidades de proveedores y productos con un resumen de
cómo les fue a los proveedores, sistemas operativos y navegadores web que examinamos con respecto a nuestro
marco de mejora de vulnerabilidades.
La figura 3.56 resume el desempeño de cada proveedor, sistema operativo y navegador web que examinamos en
las tres medidas del marco de mejora de vulnerabilidades.
Capítulo 3 107
Figura 3.56: Resumen de si los proveedores, sistemas operativos y navegadores web examinados
en este capítulo cumplieron con los criterios del marco de mejora de vulnerabilidades
Los datos sugieren que la combinación de Safari en macOS durante el período de tiempo que examinamos tenía menos
CVE y menos vulnerabilidades de baja complejidad que otras combinaciones de sistemas operativos que no son de servidor.
macOS no tuvo la menor cantidad de CVE severos de ningún sistema operativo cliente (iOS sí), pero estuvo entre los
sistemas operativos con el conteo más bajo. Según los datos, la combinación de Google Chrome en macOS o iOS también
parece ser una excelente opción para los sistemas cliente. En los servidores, los sistemas operativos basados en Linux que
examinamos habrían ayudado a reducir el riesgo.
Los datos también nos dicen que los proveedores que examinamos se han esforzado por reducir la cantidad de
vulnerabilidades críticas y de alta gravedad en sus productos, incluso cuando el volumen de CVE aumentó para muchos de
ellos. Las organizaciones de TI empresariales deben preferir a aquellos proveedores que demuestren que están dispuestos
y son capaces de lograr un progreso positivo en la reducción del riesgo para sus clientes a lo largo del tiempo. Felicitaciones
a todos los proveedores que descifraron este código y a los que estuvieron cerca. Cada uno de ellos está dando un ejemplo
a seguir para toda la industria.
Permítanme terminar este capítulo brindando una guía general sobre la gestión de vulnerabilidades.
Guía de gestión de vulnerabilidades

Un programa de gestión de vulnerabilidades bien ejecutado es fundamental para todas las organizaciones. Como
ha visto en los datos y análisis de este capítulo, se han revelado muchas vulnerabilidades en toda la industria y los
volúmenes han aumentado, no disminuido. A fines de 2022, había más de 192 000 CVE en NVD. Los atacantes lo
saben y entienden lo difícil que es para las organizaciones mantenerse al día con el volumen y la complejidad de
parchear los diversos productos de hardware y software que tienen en sus entornos. Los defensores tienen que
ser perfectos, mientras que los atacantes solo tienen que ser buenos o afortunados una vez. Permítame ofrecerle
algunas recomendaciones sobre los programas de gestión de vulnerabilidades.
En primer lugar, no puedo exagerar la importancia de la gestión de activos y su función al permitir una gestión
eficaz de vulnerabilidades, respuesta a incidentes y muchos otros aspectos de la gestión de TI. Si una organización
no mantiene un inventario preciso de los activos de TI, es muy difícil, de hecho casi imposible, administrar de
manera efectiva las vulnerabilidades y las configuraciones incorrectas de seguridad. Por ejemplo, supongamos que
un equipo de administración de vulnerabilidades puede escanear un sistema en busca de vulnerabilidades sin
parchear. En este ejemplo, descubren numerosas vulnerabilidades críticas y de alta gravedad sin parches presentes
en el sistema que superan los acuerdos de nivel de servicio de tiempo de remediación. El siguiente paso sería
remediar rápidamente estos hallazgos. ¿A quién debe contactar el equipo de administración de vulnerabilidades o
el equipo de corrección para realizar pruebas de compatibilidad de aplicaciones para las actualizaciones de
seguridad y realizar las actualizaciones en el sistema? Sin un inventario de activos preciso, encontrar al propietario
de ese sistema puede ser una tarea abrumadora en un entorno empresarial grande. El mismo problema surge
durante un incidente de seguridad cibernética activo cuando un sistema se ha visto comprometido, pero no hay un
inventario de activos preciso para encontrar al propietario y obtener otros detalles vitales sobre el sistema que se
está investigando.
A las organizaciones que son realmente buenas en la gestión de los ciclos de vida de sus activos y en el
mantenimiento de inventarios precisos y detallados les resulta mucho más fácil en tales escenarios. Por ejemplo,
imagine que un equipo de administración de vulnerabilidades no tuviera que escanear cientos de miles de sistemas
en busca de la temida vulnerabilidad Log4j durante el período de vacaciones de Navidad. ¿Qué pasaría si, en
cambio, pudieran simplemente consultar su base de datos de gestión de activos y encontrar una lista de activos
con el componente vulnerable? ¿Qué pasaría si la base de datos de administración de activos pudiera proporcionar
el nombre y la información de contacto del propietario de cada sistema donde existe el componente vulnerable?
La remediación podría ser mucho más rápida y con menos drama que escanear cientos de miles de sistemas en
busca del componente vulnerable, mientras se están produciendo ataques activos en Internet y luchando para
tratar de encontrar propietarios de sistemas para comenzar las pruebas y los esfuerzos de remediación.
Capítulo 3 109
Existen algunas integraciones potentes entre los productos de gestión de activos empresariales y muchos
escáneres de vulnerabilidades empresariales que facilitan la gestión de vulnerabilidades y la respuesta a incidentes.
más fácil.
La clave para una gestión de vulnerabilidades eficiente, incluidos los informes de vulnerabilidades, es una
buena gestión de activos. Invertir en la gestión de activos pagará dividendos de muchas maneras en entornos
de grandes empresas. Dicho esto, la gestión de activos no es fácil ni económica para las grandes empresas
que tienen entornos informáticos diversos y complejos. He hablado recientemente con algunos CISO que se
han hecho cargo de la gestión de activos para sus empresas porque es demasiado importante para el éxito
de sus programas de ciberseguridad como para dejar que otros equipos la administren. En mi experiencia
esta es la excepción, no la regla. Sin embargo, puedo ver algo de sabiduría en este enfoque. La gestión de
activos puede ser una gran cantidad de trabajo, especialmente para las organizaciones que recién comienzan
o reanudan ese viaje después de muchos años sin centrarse en la gestión de activos. Pero dado que se
encuentra en la ruta crítica para algunas funciones clave de ciberseguridad, puedo entender por qué algunos
CISO querrían administrarlo ellos mismos. Sin embargo, la gestión de activos puede consumir muchos
recursos y podría consumir recursos en un equipo de ciberseguridad que debería usarse para ciberseguridad
en su lugar. En tales escenarios, se debe mantener un equilibrio cuidadosamente ponderado entre los dos.
Una segunda cosa a tener en cuenta sobre la gestión de vulnerabilidades es que uno de los objetivos de un
programa de gestión de vulnerabilidades es comprender el riesgo que presentan las vulnerabilidades en su
entorno de TI. Esto no es estático o de movimiento lento en grandes entornos de TI. Constantemente se
revelan vulnerabilidades en todo el hardware y software. Debido a esto, los datos sobre las vulnerabilidades
de su entorno pueden volverse obsoletos rápidamente. Las organizaciones con las que me he encontrado
que decidieron implementar actualizaciones de seguridad una vez por trimestre, o cada seis meses, tienen
un apetito inusualmente alto por el riesgo; aunque, paradójicamente, algunas de estas mismas organizaciones
me dicen que no tienen apetito por el riesgo. Siempre es interesante conocer a personas que creen que sus
riesgos de mayor prioridad son sus proveedores, en lugar del grupo de atacantes que buscan activamente
formas de aprovecharse de ellos: atacantes que, si tienen la oportunidad, con gusto encriptarán todos sus
datos y exigirán un rescate por las claves de descifrado.
Cuando me encuentro con una organización con este tipo de política, me pregunto si realmente tienen una
visión del riesgo basada en datos y si la capa más alta de la gerencia realmente comprende el riesgo que
están aceptando en nombre de toda la organización.
¿Saben que en promedio en 2019 se divulgaron 33,4 nuevas vulnerabilidades por día y en 2018 hubo 45,4
divulgaciones por día? Si están parcheando trimestralmente, eso equivale a 4082 vulnerabilidades
potencialmente sin parchear por hasta 90 días en 2018 y 3006 en 2019. Duplica esas cifras para las
organizaciones que parchean semestralmente.
En promedio, más de un tercio de esas vulnerabilidades se califican como críticas o altas. Los atacantes solo requieren una
vulnerabilidad explotable en el sistema correcto para comprometer inicialmente con éxito un entorno. En lugar de evitar
aplicar parches y reiniciar los sistemas para minimizar la interrupción de su negocio, la mayoría de estas organizaciones
deben centrarse en crear programas de gestión de vulnerabilidades muy eficientes con el objetivo de reducir el riesgo en
un período de tiempo más razonable. Los atacantes tienen una gran ventaja en entornos frágiles y sin parches durante
largos períodos.
Para la mayoría de las organizaciones, mi recomendación es que los equipos de administración de vulnerabilidades
analicen todo, todos los días. Lee esa línea de nuevo si es necesario. Recuerde la analogía del submarino que usé en la
sección del prefacio de este libro. Su programa de gestión de vulnerabilidades es una de las formas en que busca defectos
en el casco de su submarino. Escanear todos los activos que tiene en su entorno en busca de vulnerabilidades todos los
días ayudará a identificar grietas e imperfecciones en el casco que, si se explotan, hundirían el barco. Escanear todo todos
los días en busca de vulnerabilidades y configuraciones incorrectas proporciona a la organización datos importantes que
informarán sus decisiones de riesgo.
Recuerde a los sospechosos habituales de ciberseguridad: encontrar y abordar las configuraciones incorrectas de seguridad
es tan importante como las vulnerabilidades. Sin datos actualizados, están gestionando el riesgo de forma desinformada.
Por ejemplo, escanear todo todos los días ayudará a identificar cuándo las vulnerabilidades más graves, como Log4j,
aparecen en un entorno meses o años después de que se pensaba que se remediaba. Escanear todos los días proporciona
a la organización la visibilidad necesaria para identificar y mitigar las vulnerabilidades de riesgo alto y crítico antes de que
se conviertan en un problema.
Tenga en cuenta que no recomiendo parchear todos los días, solo escanear para obtener una instantánea diaria del riesgo.
Los acuerdos de nivel de servicio de tiempo de remediación deben basarse en el apetito de riesgo de la organización.
Recuerde lo que recomendé anteriormente en el capítulo: use CTI para informar las prioridades de remediación. Esto
ayudará a su organización a reducir primero las vulnerabilidades de mayor riesgo y brindará las prioridades prescriptivas
que los equipos de remediación desean con tanta frecuencia. La combinación de CTI y la gestión eficaz de activos puede
simplificar y reducir los costos relacionados con la gestión de vulnerabilidades y los esfuerzos de remediación.
Para las organizaciones que pueden lograrlo, el uso de MITRE ATT&CK® para informar también las prioridades de
remediación de vulnerabilidades puede reducir la cantidad de vulnerabilidades de alta prioridad al tiempo que reduce el
riesgo de explotación. Discuto este marco en detalle en el Capítulo 9, Estrategias de ciberseguridad. Al priorizar el parcheo
de las vulnerabilidades que pueden respaldar las técnicas y los procedimientos que se sabe que utilizan los atacantes, se
hace más difícil para los atacantes tener éxito.
Es importante tener en cuenta que los dispositivos móviles, especialmente los de la variedad BYOD, representan un desafío
importante para los equipos de gestión de vulnerabilidades.

Capítulo 3 111
Los datos sobre las vulnerabilidades de los sistemas operativos móviles proporcionados anteriormente en este capítulo
indican que hay cientos de CVE en los sistemas operativos móviles populares cada año. La mayoría de las organizaciones
simplemente no pueden escanear estos dispositivos en busca de vulnerabilidades de la misma manera que escanean otros
activos. Esta es una de las razones por las que muchos profesionales de la ciberseguridad se refieren a BYOD como "traiga
su propio desastre". En cambio, es más común limitar el acceso de los dispositivos móviles a información confidencial y
activos de alto valor. También es común requerir versiones más nuevas del sistema operativo y niveles mínimos de parches
para poder conectarse a las redes corporativas . Con este fin, la mayoría de las empresas con las que me he reunido a lo
largo de los años aprovechan las soluciones de gestión de dispositivos móviles (MDM) o gestión de aplicaciones móviles (MAM) .
Para algunas organizaciones, escanear todo todos los días requerirá más recursos de los que tienen actualmente. Por
ejemplo, es posible que necesiten más motores de análisis de vulnerabilidades de los que tienen actualmente para analizar
el 100 % de sus activos de TI todos los días. Es posible que también deseen realizar este análisis fuera del horario laboral
para reducir el tráfico de red generado por todo este análisis durante el horario laboral habitual. Esto podría significar que
tienen que escanear todo, todas las noches, durante un número definido de horas. Para lograr esto, necesitarán una cantidad
suficiente de motores de escaneo de vulnerabilidades y personal para administrarlos. Una vez que tienen datos actualizados
sobre el estado del medio ambiente, esos datos se pueden usar para tomar decisiones basadas en el riesgo, por ejemplo,
cuando se deben abordar las vulnerabilidades recién descubiertas y las configuraciones incorrectas. Sin datos actualizados
sobre el estado del medio ambiente, la esperanza jugará un papel continuo y central en la gestión de su vulnerabilidad.
estrategia.
Los datos generados por todo este análisis de vulnerabilidades son oro en polvo para los CISO, especialmente para los
programas de seguridad que son relativamente inmaduros. Proporcionar al Csuite y a la Junta Directiva datos de este
programa puede ayudar a los CISO a obtener los recursos que necesitan y comunicar el progreso que están logrando con
su programa de seguridad. Proporcionar un desglose de la cantidad de activos en el inventario, cuántos de ellos realmente
pueden administrar vulnerabilidades, la cantidad de vulnerabilidades críticas y de alta gravedad presentes, y una estimación
de cuánto tiempo tomará abordar todas estas vulnerabilidades puede ayudar a construir un caso comercial efectivo para una
mayor inversión en el programa de administración de vulnerabilidades. Proporcionar a la alta dirección datos cuantitativos
como este les ayuda a comprender la realidad frente a la opinión. Sin estos datos, puede ser mucho más difícil hacer un caso
de negocios convincente y comunicar el progreso con respecto a los objetivos del programa de seguridad.
Por supuesto, existen enfoques más modernos para la gestión de vulnerabilidades que pueden reducir la cantidad de activos
que los equipos de gestión de vulnerabilidades necesitan escanear todos los días. El uso de enfoques más modernos de
"confianza cero" que verifican que los sistemas estén completamente parcheados antes de que se les permita conectarse a
las redes corporativas es un enfoque popular.

Requerir que los sistemas a los que les faltan actualizaciones de seguridad se corrijan automáticamente antes de que
sean lo suficientemente confiables para conectarse a una red corporativa puede reducir drásticamente la cantidad de
escaneo de vulnerabilidades y parches que deben hacer los equipos de administración y corrección de vulnerabilidades.
Sin embargo, la mayoría de las organizaciones grandes tienen propiedades de TI complejas que se construyeron
durante un período de décadas y que, por lo general, dependen de cantidades significativas de tecnologías heredadas.
Desafortunadamente, no hay atajos para pasar de entornos de TI heredados masivos a arquitecturas Zero Trust
modernas. La mayoría de las organizaciones modernizan partes de sus propiedades de TI a lo largo de los años, sin
poder realmente modernizar todo a la vez. Estos entornos a menudo requieren enfoques heredados, como escanear
todo todos los días, para administrarlos de manera efectiva. La nube puede cambiar los costos y el esfuerzo
relacionados con la gestión de vulnerabilidades de una manera dramáticamente positiva. Hablaré de esto en el
Capítulo 12, Enfoques modernos para la seguridad y el cumplimiento.
Resumen
Con suerte, no lo cegué con demasiada ciencia en este capítulo: ¡había muchos números para digerir! Permítanme
recapitular algunos de los puntos clave de este capítulo.
El riesgo es una combinación de probabilidad e impacto. El sistema de puntuación de vulnerabilidad común

(CVSS) se utiliza para estimar el riesgo de cada vulnerabilidad (CVE) en la base de datos nacional de vulnerabilidades
(NVD). Estos datos disponibles gratuitamente deben usarse para informar su programa de gestión de vulnerabilidades.
El uso de proveedores que han tenido éxito en la reducción de la cantidad de vulnerabilidades en sus productos puede
reducir potencialmente el tiempo, el esfuerzo y los costos relacionados con su programa de administración de
vulnerabilidades. Si elige proveedores que también han invertido en reducir el retorno de la inversión de los atacantes
al hacer que la explotación de vulnerabilidades en sus productos sea difícil o imposible, también estará reduciendo su
riesgo y costos.
De los proveedores examinados en este capítulo, solo Apple cumplió con los criterios de nuestro marco de mejora de
vulnerabilidades al reducir la cantidad de vulnerabilidades en sus productos, reducir la gravedad de las vulnerabilidades
en sus productos y reducir la cantidad de vulnerabilidades de baja complejidad de acceso (aquellas con el mayor
riesgo) durante los 5 años estudiados. Los sistemas operativos que examiné que lograron los objetivos de nuestro
marco de mejora de vulnerabilidades durante un período de 3 años fueron Linux Kernel y Canonical Ubuntu Linux. Los
navegadores web que examiné con el mejor historial de gestión de vulnerabilidades entre 2019 y 2021 incluyeron
Apple Safari y Google Chrome. La forma en que se gestionaron las vulnerabilidades en estos navegadores durante
estos 3 años
redujo el riesgo para sus usuarios.
Capítulo 3 113
Tenga en cuenta que los datos utilizados para estas comparaciones tienen muchos sesgos y no son completos
ni completamente precisos. Pero puede hacer su propia investigación de CVE y usar el marco informal de
mejora de vulnerabilidades que he proporcionado.
Los equipos de administración de vulnerabilidades que escanean todo, todos los días, brindan la mejor visibilidad
para que sus organizaciones administren el riesgo. Los datos de los programas de administración de vulnerabilidades
brindan a los CISO algunos de los datos que necesitan para administrar el rendimiento de sus programas de
seguridad y dirigir futuras inversiones en los programas.
En el próximo capítulo, profundizaremos en los datos de infección de malware de cientos de millones de sistemas
en todo el mundo para examinar cómo ha evolucionado el panorama de amenazas a lo largo de los años.
¿Sabía que los factores socioeconómicos, como el Producto Interno Bruto (PIB), están relacionados con las tasas
regionales de infección de malware? Vamos a ver esto también.
Referencias
• NIST. (Dakota del Norte). Obtenido de la base de datos de vulnerabilidad nacional: https://nvd.nist.gov/vuln
• CVE. (5 de marzo de 2020). Reglas de la autoridad de numeración CVE (CNA). Obtenido de https://
www.cve.org/ResourcesSupport/AllResources/CNARules
• Howard, M. (9 de mayo de 2021). “El mejor consejo de seguridad que puedo dar…”. Obtenido de https://
michaelhowardsecure.blog/2021/05/09/elmejorconsejodeseguridadquepuedodar/.
• CVE. (Dakota del Norte). CVE20188653 Detalle. Obtenido de https://cve.mitre.org/cgibin/
cvename.cgi?name=CVE20188653
• PRIMERO. (junio, 2019). Common Vulnerability Scoring System versión 3.1: Documento de especificación .
Obtenido de https://www.first.org/cvss/specificationdocument
• NIST. (Dakota del Norte). Calculadora del sistema de puntuación de vulnerabilidad común. Obtenido de https://
nvd.nist.gov/vulnmetrics/cvss/v3calculator
• CVE. (11 de diciembre de 2020). Relación CVE y NVD. Obtenido de https://cve.mitre.
org/about/cve_and_nvd_relationship.html
• Mel, Peter. (julio de 2000). Oratorio del Laboratorio de Tecnología de la Información de la División
de Seguridad Informática , Instituto Nacional de Estándares y Tecnología, Boletín ITL. Obtenido de
https://csrc.nist.gov/csrc/media/Publications/Shared/documents/itlbulletin/
itlbul200007.pdf
• Agencia de Seguridad de Infraestructuras y Ciberseguridad (CISA). (Dakota del Norte). Catálogo de

Vulnerabilidades Explotadas Conocidas. Obtenido de https://www.cisa.gov/knownexploited vulnerabilities
catalog
• Junta de Revisión de Seguridad Cibernética. 11 de julio de 2022. Revisión del evento Log4j de diciembre de 2021.
Obtenido de https://www.cisa.gov/sites/default/files/publications/CSRB
ReportonLog4July112022_508.pdf
• Brian Martin, Carolina del Sur (3 de diciembre de 2013). Black Hat USA 2013 Adopción del sesgo: por qué
apestan las estadísticas de vulnerabilidad. Obtenido de YouTube: https://www.youtube.com/
ver?time_continue=20&v=3Sx0uJGRQ4s Detalles de CVE. (Dakota del Norte). ¿Como funciona? Obtenido

de Detalles de CVE: https://www.cvedetails.com/howdoesitwork.php
• Cable trampa. (2020). La Historia de las Vulnerabilidades y Exposiciones Comunes (CVE). Obtenido de https://
www.tripwire.com/stateofsecurity/featured/historycommon
vulnerabilidadesexposicionescve/
• Detalles CVE. (Dakota del Norte). Distribución de puntuación CVSS actual para todas las vulnerabilidades.
Obtenido de Detalles de CVE: https://www.cvedetails.com/index.php
• Vulnerabilidades y exposiciones comunes. (Dakota del Norte). Autoridades de numeración CVE. Obtenido de
Vulnerabilidades y exposiciones comunes: https://www.cve.org/ProgramOrganization/
CNA
• Detalles CVE. (Dakota del Norte). Distribución de puntuación CVSS actual para todas las vulnerabilidades.
Obtenido de Detalles de CVE: https://www.cvedetails.com/index.php
• Detalles CVE. (Consultado en julio de 2022). Top 50 Lista de productos con más CVE. Obtenido de Detalles de
CVE: https://www.cvedetails.com/top50products.php
• Detalles CVE. (Consultado en julio de 2022). Top 50 Lista de proveedores con más CVE. Obtenido de Detalles
de CVE: https://www.cvedetails.com/top50vendors.php
• Microsoft. (Dakota del Norte). Ingeniería de Seguridad. Obtenido de Microsoft: https://www.microsoft.
com/enus/securityengineering/sdl
• Centro de Coordinación CERT del Instituto de Ingeniería de Software, Universidad Carnegie Mellon (15 de
diciembre de 2021). “Apache Log4j permite búsquedas JNDI inseguras, nota de vulnerabilidad VU#930724”.
Obtenido de https://www.kb.cert.org/vuls/id/930724
• CVE. (14/12/2021). “Detalle CVE202145046”. Obtenido de https://cve.mitre.org/
cgibin/cvename.cgi?name=CVE202145046
• NIST. (Dakota del Norte). “Vulnerabilidades conocidas explotadas”. Obtenido de https://nvd.nist.gov/
General/Noticias/cisaexploitcatálogo
• Detalles CVE. (Dakota del Norte). Estadísticas de vulnerabilidad de Microsoft. Obtenido de CVE Detalles: https://
www.cvedetails.com/vendor/26/Microsoft.html
Capítulo 3 115
• Kovacs, Eduardo. Semana de la Seguridad (23 de septiembre de 2014). “Microsoft cierra la unidad informática
digna de confianza”. Obtenido de https://www.securityweek.com/microsoft
apagarlaunidaddecomputacióndeconfianza
• Matt Miller, M. (14 de febrero de 2019). BlueHat IL 2019 – Matt Miller. Obtenido de YouTube:
https://www.youtube.com/watch?v=PjbGojjnBZQ
• Detalles CVE. (Dakota del Norte). Lista de productos de Microsoft. Obtenido de CVE Detalles: https://www.
cvedetails.com/top50products.php
• Detalles CVE. (Dakota del Norte). Top 50 Lista de proveedores con más CVE. Obtenido de CVE Detalles:
https://www.cvedetails.com/top50vendors.php
• Detalles CVE. (Dakota del Norte). Estadísticas de vulnerabilidad de Oracle. Obtenido de CVE Detalles: https://
www.cvedetails.com/vendor/93/Oracle.html
• Detalles CVE. (Dakota del Norte). Detalles de la vulnerabilidad de Google Chrome. Obtenido de CVE Detalles:
https://www.cvedetails.com/product/15031/GoogleChrome.html?vendor_id=122
• Detalles CVE. (Dakota del Norte). Detalles de la vulnerabilidad de Debian. Obtenido de CVE Detalles: https://
www.cvedetails.com/vendor/23/Debian.html
• Detalles CVE. (Dakota del Norte). Detalles de vulnerabilidad de Apple. Obtenido de CVE Detalles: https://www.
cvedetails.com/vendor/49/Apple.html
• Detalles CVE. (Dakota del Norte). Lista de productos de Apple. Obtenido de CVE Detalles: https://www.
cvedetails.com/productlist/vendor_id49/Apple.html
• Detalles CVE. (Dakota del Norte). Detalles de la vulnerabilidad de Apple iOS. Obtenido de CVE Detalles: https://
www.cvedetails.com/product/15556/AppleIphoneOs.html?vendor_id=49
• Detalles CVE. (Dakota del Norte). Detalles de vulnerabilidad de Apple Mac OS X. Obtenido de CVE Detalles:
https://www.cvedetails.com/product/156/AppleMacOsX.html?vendor_id=49
• Detalles CVE. (Dakota del Norte). Estadísticas de vulnerabilidad de Apple Safari. Obtenido de CVE Detalles:
https://www.cvedetails.com/product/2935/AppleSafari.html?vendor_id=49
• Detalles CVE. (Dakota del Norte). Estadísticas de vulnerabilidad de Apple. Obtenido de CVE Detalles: https://
www.cvedetails.com/vendor/49/Apple.html
• Detalles CVE. (Dakota del Norte). Estadísticas de vulnerabilidad de Google Android. Obtenido de CVE Detalles:
https://www.cvedetails.com/product/19997/GoogleAndroid.html?vendor_id=1224
• Detalles CVE. (Dakota del Norte). Detalles de la vulnerabilidad de Google Chrome. Obtenido de CVE Detalles:
https://www.cvedetails.com/product/15031/GoogleChrome.html?vendor_id=1224
• Detalles CVE. (Dakota del Norte). Lista de productos de Google. Obtenido de CVE Detalles: https://www.
cvedetails.com/productlist/vendor_id1224/Google.html
• Detalles CVE. (Dakota del Norte). Estadísticas de vulnerabilidad del kernel de Linux. Obtenido de CVE Detalles:
https://www.cvedetails.com/product/47/LinuxLinuxKernel.html?vendor_id=33
• Detalles CVE. (Dakota del Norte). Lista de productos de Microsoft. Obtenido de CVE Detalles: https://www.
cvedetails.com/productlist/product_type/ firstchar/vendor_id26/page1/
productospornombre.html?sha=4b975b df63b781745f458928790e4c8fd6a77f94&order
=3&trc=525
• Detalles CVE. (Dakota del Norte). Detalles de la vulnerabilidad de Windows 10. Obtenido de CVE Detalles: https://
www.cvedetails.com/product/32238/MicrosoftWindows10.html?vendor_id=26
• Detalles CVE. (Dakota del Norte). Detalles de vulnerabilidad de Windows Server 2016. Obtenido de Detalles de
CVE: https://www.cvedetails.com/product/34965/MicrosoftWindowsServer2016.
html?vendor_id=26
• Detalles CVE. (Dakota del Norte). Estadísticas de vulnerabilidad de Microsoft Edge. Obtenido de Detalles de CVE:
https://www.cvedetails.com/product/32367/MicrosoftEdge.html?vendor_id=26
• Ribeiro, R. (sf). Comprender los beneficios de seguridad de Windows 10. Obtenido
de BizTech: https://biztechmagazine.com/article/2016/04/understandingsecurity
beneficioswindows10
• Detalles CVE. (Dakota del Norte). Estadísticas de vulnerabilidad canónicas de Ubuntu Linux. Obtenido de Detalles
de CVE: https://www.cvedetails.com/product/20550/CanonicalUbuntuLinux.
html?vendor_id=4781
• Detalles CVE. (Dakota del Norte). Detalles de la vulnerabilidad de Mozilla Firefox. Obtenido de CVE Detalles:
https://www.cvedetails.com/product/3264/MozillaFirefox.html?vendor_id=452
• Detalles CVE. (Dakota del Norte). Estadísticas de vulnerabilidad de Mozilla Firefox. Obtenido de CVE Detalles:
https://www.cvedetails.com/product/3264/MozillaFirefox.html?vendor_id=452
• Microsoft. (Dakota del Norte). Año nuevo, navegador nuevo: el nuevo Microsoft Edge está fuera de vista previa y
ahora está disponible para descargar. Obtenido de Microsoft: https://blogs.windows.com/
windowsexperience/2020/01/15/nuevoañonuevonavegadorelnuevomicrosoftedge estáfuerade
vista previayahoradisponibleparadescargar/
Capítulo 3 117

4
La evolución del malware
Siempre he pensado en el malware como sinónimo de "automatización de atacantes". Los proveedores de
malware buscan comprometer los sistemas por una variedad de motivaciones, como describí en el Capítulo 1.
Cualquier sistema que envíe y reciba correo electrónico, se use para navegar por la web, tenga aplicaciones
que se conecten a una red o tome otras formas de entrada puede ser atacado, independientemente de si se
fabricó en Redmond, Raleigh, Cupertino, Helsinki o en cualquier otro lugar. El Instituto AVTEST, uno de los
principales laboratorios independientes de pruebas de antivirus del mundo, con sede en Alemania, tiene una
de las colecciones de malware más grandes del mundo (AVTest Institute, 2020). Han acumulado esta
colección durante 15 años. “Cada día, el Instituto AVTEST registra más de 450.000 nuevos programas
maliciosos (malware) y aplicaciones potencialmente no deseadas (PUA)” (AVTest Institute, sf). Las estadísticas
que han publicado indican que el volumen de malware total ha aumentado cada año; por ejemplo, en 2013
detectaron 182,9 millones de muestras de malware, en comparación con el momento actual (julio de 2022) con
1.400 millones de muestras de malware, un aumento del 646 %. (Instituto AVTest, 10 de julio de 2020).
Según los datos que AVTest ha publicado en sus informes anuales de seguridad, la cuota de malware
desarrollado para sistemas operativos Windows fue del 69,96% en 2016 (AVTest Institute, 2017), del 67,07%
en 2017 (AVTest Institute, 2018), del 51,08% en 2018 (AVTest Institute, 2019) y del 78,64% en 2019 (AVTest
Institute, 2019). Instituto de Pruebas, 2020).
El sistema operativo con la siguiente mayor proporción de muestras de malware en estos años fue Google
Android, con menos del 7 % de la participación en cada año informado (AVTest Institute, 2020). La cantidad
de nuevas muestras de malware detectadas para sistemas operativos Linux fue de 41 161 en marzo de 2019,
mientras que la cantidad de muestras de malware para Windows durante el mismo período fue de 6 767 397
(AV Test Institute, 2019). Las muestras de malware para macOS durante este mes aumentaron a 11 461 desde
las 8057 del mes anterior (AVTest Institute, 2019).
120 La evolución del malware
Estos datos sugieren claramente que la plataforma elegida por los autores de malware es el sistema operativo
Windows. Es decir, se desarrolla más malware único para atacar sistemas basados en Windows que cualquier otra
plataforma. Una vez que los sistemas de Windows se ven comprometidos, los atacantes generalmente recopilan
software y claves de juegos, información financiera como números de tarjetas de crédito y otra información
confidencial que pueden usar para robar identidades, a veces tomando el control del sistema y sus datos a cambio
de un rescate. Muchos atacantes utilizarán sistemas comprometidos como plataformas para perpetrar ataques ,
utilizando el anonimato que les brindan los sistemas comprometidos.
Dado que los atacantes han estado apuntando y aprovechando los sistemas basados en Windows más que cualquier
otra plataforma, y dada la ubicuidad de Windows, los expertos en seguridad deben comprender cómo y dónde los
atacantes han estado usando estos sistemas. Los CISO, los aspirantes a CISO, los equipos de seguridad y los
expertos en ciberseguridad pueden beneficiarse al comprender cómo se atacan los sistemas basados en Windows
al menos de varias maneras:
• Los CISO y los equipos de seguridad que son responsables de los sistemas Windows en su entorno deben
comprender cómo los atacantes han estado atacando los sistemas basados en Windows con malware, así
como también cómo ha evolucionado esto con el tiempo.
• Tener conocimientos sobre malware ayudará a los equipos de seguridad a hacer mejor su trabajo.
• Este conocimiento puede ser útil para ayudar a reconocer el miedo, la incertidumbre y la duda que utilizan
algunos proveedores de seguridad para vender sus productos y servicios; comprender cómo los atacantes
han estado usando malware ayudará a los CISO a realizar mejores inversiones relacionadas con la seguridad y
decisiones
• Los CISO y los equipos de seguridad que son responsables de los sistemas basados en Linux y otros sistemas
operativos que no son de Microsoft deben tener una idea de cómo sus adversarios están comprometiéndose
y utilizando los sistemas Windows para atacarlos. Podemos tomar lecciones del ecosistema de Windows y
aplicarlas a sistemas basados en Linux y otras plataformas. Muy a menudo, los métodos que utilizan los
autores de malware en la plataforma Windows se adaptarán para atacar otras plataformas, aunque
normalmente a menor escala. Comprender los métodos de los autores de malware es importante para los
equipos de seguridad, independientemente de los tipos de sistemas que protejan.
Desafortunadamente, los CISO no pueden desconectarse de las amenazas basadas en Windows, incluso si no lo hacen.
utilizar Windows en sus entornos.
• Finalmente, en mi opinión, es difícil para los expertos en la materia de seguridad cibernética usar ese
apodo si desconocen felizmente las tendencias de malware en un ecosistema en línea que consta de más
de mil millones de sistemas que, en ocasiones, admiten más de las tres cuartas partes de todo el malware
nuevo en el mundo . No importa si hay más dispositivos móviles, más dispositivos IoT o sistemas operativos
más seguros.
Capítulo 4 121
Es innegable que Windows está en todas partes. Posteriormente, todos los expertos en ciberseguridad
deberían saber un poco sobre el mayor participante en el panorama global de amenazas.
Este capítulo proporcionará una perspectiva histórica única, detallada y basada en datos de cómo ha evolucionado el
malware en todo el mundo. Hay algunas diferencias muy interesantes en las tasas de detección de malware regional y
las tasas de infección en las que también me sumergiré en este capítulo. Esta vista del panorama de amenazas ayudará
a los CISO y los equipos de seguridad a comprender cómo los atacantes cambian sus ambiciones de malware con el
tiempo. Estos datos no solo son muy interesantes, sino que pueden ayudar a eliminar parte del miedo, la incertidumbre
y la duda (FUD) de las conversaciones sobre el malware y cómo gestionar los riesgos que plantea.
Hablando de FUD, también proporcionaré una inmersión profunda en cómo el ransomware ha cambiado con el tiempo
para desmitificar este término, ya que en gran medida ha sido secuestrado y sobrecargado en los últimos años.
Explicaré cómo el ransomware siempre ha sido una de las categorías de malware menos frecuentes, pero continúa
infundiendo miedo en los CISO y los equipos de seguridad y se ha convertido en un elemento fijo en las noticias.
• Algunas de las fuentes de datos de las que proviene la inteligencia de amenazas para Windows
• Definición de categorías de malware y cómo se mide su prevalencia
• Evolución y tendencias globales del malware
• Tendencias regionales de malware para Oriente Medio, la Unión Europea, Europa del Este y
Rusia, Asia y Oceanía, y América del Norte y del Sur
• La evolución del ransomware
Introducción
En 2003, cuando trabajé en el equipo de respuesta a incidentes orientado al cliente de Microsoft, comenzamos a
encontrar rootkits en modo usuario en sistemas comprometidos con cierta regularidad, tanto que uno de nuestros
mejores ingenieros creó una herramienta que podía encontrar rootkits en modo usuario que se escondían de Windows.
Un rootkit en modo usuario se ejecuta como cualquier otra aplicación que ejecutaría un usuario normal, pero se oculta.
Entonces, un día, recibimos una llamada de un ingeniero de soporte de Microsoft que estaba ayudando a solucionar un
problema que tenía un cliente en un servidor de correo electrónico de Exchange. El síntoma del problema era que una
vez cada pocos días, el servidor mostraba una pantalla azul. El ingeniero de soporte no pudo entender por qué y estaba
realizando una sesión de depuración remota, tratando de encontrar el código que provocó que el servidor mostrara una
pantalla azul. Tardó semanas, pero una vez que encontró el código responsable de la pantalla azul, no pudo explicar
cuál era el código ni cómo se instaló en el servidor. Fue entonces cuando nos llamó para pedir ayuda.
Cuando el servidor mostró una pantalla azul y se reinició, esto nos permitió ver un volcado de memoria parcial del sistema.
Después de unos días de análisis, determinamos que el servidor estaba comprometido de una manera que nunca antes
habíamos visto. Un controlador de dispositivo en el sistema se ocultaba a sí mismo y a otros componentes. Habíamos
encontrado el primer rootkit en modo kernel que habíamos visto en la naturaleza.
Esto fue un gran problema. A diferencia de un rootkit en modo usuario, desarrollar e instalar un rootkit en modo kernel requería
una experiencia increíble. Esto se debe a que este tipo de rootkit se ejecuta en la parte más privilegiada del sistema operativo,
que pocas personas realmente entienden. En ese momento, aunque el concepto de rootkits en modo kernel se discutía entre
los expertos en seguridad, encontrar uno instalado en un servidor que se ejecutaba en el entorno de producción de una
empresa indicaba que los atacantes se estaban volviendo mucho más sofisticados que en el pasado . Pasar de los rootkits en
modo usuario a los rootkits en modo kernel fue un gran avance en la evolución del malware.
Para nuestro equipo de respuesta a incidentes, esta fue una llamada a la acción. Teníamos que informar a los desarrolladores
del kernel de Windows en Microsoft que lo que hace de Windows una base informática confiable, su kernel, estaba siendo
atacado directamente por sofisticados autores de malware. Hasta entonces, un rootkit en modo kernel que se ejecutaba en la
naturaleza era mítico. Pero ahora teníamos pruebas de que estos rootkits eran reales y se usaban para atacar a clientes
empresariales. Programamos una reunión con los principales desarrolladores, evaluadores y administradores de programas del
equipo de desarrollo del kernel de Windows.
Nos reunimos en una sala utilizada para capacitación, con un retroproyector, para que pudiéramos guiar a los desarrolladores
a través del volcado de memoria que teníamos del servidor comprometido para mostrarles cómo funcionaba el rootkit. Les
proporcionamos algo de contexto sobre el servidor, como dónde se estaba ejecutando, la versión del sistema operativo, el nivel
del paquete de servicio, una lista de todas las aplicaciones que se ejecutan en el servidor, etc. Respondimos numerosas
preguntas sobre cómo depuramos el origen de la pantalla azul, encontramos el controlador oculto y descubrimos cómo
funcionaba.
Al principio, el equipo del kernel de Windows se mostró completamente escéptico de que hubiéramos encontrado un rootkit en
modo kernel ejecutándose en un servidor de Windows. Pero después de que presentamos toda la evidencia y les mostramos
los detalles de depuración, gradualmente aceptaron el hecho de que era un rootkit en modo kernel. Nuestro equipo esperaba
admiración y respeto por todo el trabajo técnico que habíamos realizado, así como por nuestra experiencia en las funciones
internas del kernel de Windows que nos permitieron hacer este descubrimiento. En cambio, los desarrolladores del kernel nos
dijeron que nuestras herramientas y nuestros métodos eran tan malos como los de los autores del malware. Nos advirtieron
que dejáramos de usar nuestras herramientas para encontrar rootkits, ya que las herramientas podrían hacer que los sistemas
Windows en los que se ejecutaban fueran inestables a menos que se reiniciaran. Finalmente, ofrecieron no hacer nada para
endurecer el kernel y evitar este tipo de ataques en el futuro. Fue una reunión decepcionante para nosotros, ¡pero no puedes ganarlos todos!
Capítulo 4 123
Después de los exitosos ataques de gusanos a gran escala de 2003 y 2004, esta sintonía cambió. Todo el
equipo de Windows detuvo el trabajo de desarrollo que estaba realizando en lo que más tarde se convertiría en
Windows Vista. En su lugar, trabajaron para mejorar la seguridad de Windows XP y Server 2003, lanzando el
Service Pack 2 de Windows XP y el Service Pack 1 de Windows Server 2003. Incluso se habló de una nueva
versión de Windows, cuyo nombre en código era Palladium, que tenía un kernel de seguridad para ayudar a
mitigar los rootkits como el que descubrimos, pero nunca sucedió (Wikipedia, sin fecha). En última instancia,
nuestro trabajo en la detección de rootkits en modo kernel ayudó a impulsar un cambio positivo, ya que las
futuras versiones de Windows de 64 bits no permitirían la instalación de controladores en modo kernel, como el
que descubrimos, a menos que tuvieran una firma digital válida.
Más adelante en mi carrera en Microsoft, tuve la oportunidad de trabajar con investigadores y analistas de
malware de clase mundial en el laboratorio de investigación y respuesta antimalware de Microsoft, quienes
protegían mil millones de sistemas de millones de nuevas amenazas de malware. El malware como el rootkit en
modo kernel que habíamos descubierto 4 o 5 años antes era ahora una mercancía. Los atacantes usaban la
automatización a gran escala y el polimorfismo del lado del servidor para crear millones de piezas únicas de
malware cada semana. Para ganar esta guerra, la industria antivirus tendría que tener una automatización mejor
y más grande que los proveedores a gran escala de malware comercial, lo que ha demostrado ser
sorprendentemente difícil de lograr.
¿Por qué hay tanto malware en Windows en

comparación con otras plataformas?
Ciertamente, hoy en día hay más dispositivos móviles conectados a Internet que sistemas basados en Windows.
La adopción de dispositivos móviles se disparó cuando Apple, Google, Samsung y otros trajeron productos muy
populares al mercado global. Pero si hay muchos más dispositivos móviles, ¿no debería haber muchas más
familias de malware desarrolladas para esas plataformas?
La respuesta a esta pregunta radica en cómo se distribuyen las aplicaciones en estos ecosistemas. La App
Store de Apple fue un cambio de juego para la industria. No solo facilitó a los usuarios de iPhone la búsqueda e
instalación de aplicaciones, sino que eliminó casi por completo el malware para dispositivos basados en iOS.
Apple pudo lograr esto al hacer de la App Store el único lugar desde el que los consumidores podían instalar
aplicaciones (aparte del jailbreak). Los proveedores de software independientes (ISV) que desean llevar sus
aplicaciones a los dispositivos basados en iOS de los consumidores, como iPhones y iPads, necesitan colocar
sus aplicaciones en la App Store de Apple. Para hacer esto, esas aplicaciones deben cumplir con los requisitos
de seguridad de Apple, que verifican entre bastidores. Esto convierte a la App Store en un cuello de botella
perfecto que evita que el malware entre en los dispositivos de Apple.
Por el contrario, Microsoft Windows se desarrolló en tiempos más ingenuos, cuando nadie podía predecir que, algún día, habría más
archivos maliciosos en el ecosistema de Windows que archivos legítimos.
Una de las grandes ventajas de Windows para los desarrolladores era que podían desarrollar su software para Windows y venderlo
directamente a consumidores y empresas. Este modelo fue el modelo de distribución de software predominante para PC durante
décadas. Dado que el software se puede instalar sin tener en cuenta su procedencia y con una capacidad limitada para determinar
su confiabilidad, el malware floreció en este ecosistema y continúa haciéndolo. Microsoft ha tomado numerosas medidas durante
décadas para combatir este "efecto secundario" de este modelo de distribución de software, con un éxito limitado.
Algunos dirían que el ecosistema de Android ha terminado en algún lugar entre estos dos extremos. Google también tiene una tienda
de aplicaciones, llamada Google Play. Google también ha tomado medidas para minimizar el malware en esta tienda de aplicaciones.
Sin embargo, no todas las tiendas de aplicaciones de terceros para dispositivos basados en Android mantuvieron los altos estándares
de seguridad de Google, lo que posteriormente permitió que el malware para estos dispositivos ingresara al ecosistema. Pero, como
mencioné anteriormente, la cantidad de muestras de malware detectadas para dispositivos basados en Android es mucho menor
que la de dispositivos basados en Windows.
Estas diferencias en los modelos de distribución de software, al menos parcialmente, ayudan a explicar por qué hay mucho más
malware desarrollado para Windows que para otras plataformas. Los profesionales de la ciberseguridad pueden aprender algunas
lecciones de esto en sus propios entornos de TI. Controlar cómo se introduce el software en un entorno de TI empresarial también
puede ayudar a minimizar la cantidad de malware que contiene. Esta es una de las ventajas de aprovechar la integración continua
(CI)/implementación continua
(CD) tuberías. Las canalizaciones de CI/CD pueden ayudar a las empresas a crear su propia tienda de aplicaciones y restringir cómo
el software se introduce en sus entornos.
Ahora que hemos discutido brevemente cómo los modelos de distribución de software pueden afectar la distribución de malware,
profundicemos en el malware. Los equipos de seguridad pueden aprender mucho del estudio del malware desarrollado para los
sistemas operativos Windows, incluso si ellos mismos no usan Windows. Los métodos que emplean los autores de malware en
Windows pueden usarse y se usan para malware desarrollado para muchas plataformas diferentes, incluido Linux. Estudiar cómo
funciona el malware en el ecosistema de malware más grande puede ayudarnos a defendernos de él en casi cualquier otro lugar.
Pero antes de sumergirme directamente en los datos históricos de tendencias de malware, es importante que comprenda las fuentes
de los datos que le mostraré. Como mencioné en el Capítulo 2, Lo que debe saber sobre Threat Intelligence, la inteligencia de
amenazas, también conocida como Cyber Threat Intelligence (CTI), es tan buena como su fuente, así que comencemos allí.
Capítulo 4 125
Fuentes de datos
La fuente principal de los datos históricos de este capítulo es el Informe de inteligencia de seguridad de Microsoft
(Microsoft Corporation, sin fecha). Durante el tiempo que trabajé con los investigadores y analistas en el Centro de
protección contra malware de Microsoft (MMPC), fui el editor ejecutivo y colaborador del Informe de inteligencia
de seguridad de Microsoft, al que llamamos "el SIR". Durante los 8 o 9 años que ayudé a producir el SIR,
publicamos más de 20 volúmenes y ediciones especiales de este informe, que abarcan miles de páginas. Di
literalmente miles de informes de inteligencia de amenazas a clientes de todo el mundo, así como entrevistas con
la prensa y analistas. He leído, releído y releído cada página de estos informes; conozco muy bien los entresijos
de estos datos.
Los datos de estos informes provienen de los productos antimalware de Microsoft, incluida la herramienta de
eliminación de software malicioso, Microsoft Safety Scanner, Microsoft Security Essentials, Microsoft System
Center Endpoint Protection, Windows Defender, Windows Defender Advanced Threat Protection, Windows
Defender Offline, Azure Security Center y el filtro SmartScreen integrado en los navegadores web de Microsoft .
Otros productos y servicios no relacionados con la seguridad que brindan datos valiosos para los volúmenes de
este informe incluyen Exchange Online, Office 365 y Bing. Tenga en cuenta que algunos de los nombres de estos
productos y herramientas han cambiado desde que se publicaron estos informes. Permítanme explicar con más
detalle cómo este grupo ecléctico de fuentes de datos ayuda a pintar una imagen completa del panorama de
amenazas.
La herramienta de eliminación de software malicioso

La herramienta de eliminación de software malicioso (MSRT) es una herramienta interesante que proporciona datos valiosos.
A raíz de los ataques del gusano Blaster (hubo variantes) (Microsoft Corporation, sin fecha) en el verano de 2003,
Microsoft desarrolló una "herramienta de eliminación de Blaster" gratuita diseñada para ayudar a los clientes a
detectar y eliminar el gusano Blaster y sus variantes. Recuerde que, en este momento, relativamente pocos
sistemas ejecutaban software antivirus en tiempo real actualizado. La herramienta de eliminación de Blaster era
gratuita. Esta herramienta marcó una gran diferencia ya que decenas de millones de sistemas la ejecutaron.
Debido al éxito de la herramienta y al aluvión constante de ataques de malware que la siguieron en la historia,
como Sasser, MyDoom y muchos otros, y al hecho de que tan pocos sistemas tenían un software antivirus en
ejecución, Microsoft decidió lanzar una "herramienta de eliminación de software malicioso" todos los meses. Nació el MSRT.
Estaba destinado a ser una forma de detectar sistemas infectados y limpiar las amenazas de malware más
frecuentes o graves de todo el ecosistema de Windows. El laboratorio antimalware de Microsoft decide qué nuevas
detecciones agregar al MSRT cada mes. En el sitio web de Microsoft se publica una lista de todo el malware que
detecta (Microsoft Corporation, sin fecha). Entre enero de 2005 y julio de 2022, 427
Se agregaron familias de malware a las detecciones para MSRT.
Tenga en cuenta que hay al menos cientos de miles, si no millones, de familias de malware conocidas, por lo que este
es un subconjunto muy pequeño del total que detectan los paquetes de software antimalware en tiempo real. El MSRT
se ha lanzado mensualmente (más o menos) con actualizaciones de seguridad el "martes de parches", el segundo
martes de cada mes. Se descarga automáticamente desde Windows Update o Microsoft Update a todos los sistemas
Windows del mundo que hayan optado por ejecutarlo. Durante el tiempo que estuve publicando datos de MSRT en SIR,
MSRT se estaba ejecutando en cientos de millones de sistemas por mes en promedio.
Una vez que se acepta el EULA, el MSRT se ejecuta en silencio sin una interfaz de usuario, ya que es una herramienta
de línea de comandos. Si no encuentra ninguna infección de malware, detiene la ejecución y se descarga de la memoria.
En este caso, no se envían datos a Microsoft. Pero si MSRT detecta malware, intentará eliminar el malware del sistema
e informará la infección al usuario y a Microsoft. En este caso, los datos se envían a Microsoft.
Microsoft publica la lista específica de campos de datos que MSRT envía para su análisis, incluida la versión de
Windows en la que se detectó el malware, la configuración regional del sistema operativo y un hash MD5 de los archivos
maliciosos eliminados del sistema, entre otros (Microsoft Corporation, sin fecha). Los administradores pueden descargar
el MSRT y ejecutarlo manualmente; el MSRT también se puede configurar para que no envíe datos a Microsoft. La
mayoría de las empresas con las que hablé que ejecutaban el MSRT normalmente bloqueaban los datos enviados a
Microsoft en su firewall. Posteriormente, mi conjetura fundamentada es que el 95 % o más de los cientos de millones de
sistemas que devuelven datos MSRT a Microsoft son probablemente sistemas de consumidores.
El MSRT proporciona una excelente instantánea de la exposición posterior al malware de una pequeña lista de malware
predominante conocido que está infectando los sistemas de los consumidores en todo el mundo. Cuando el laboratorio
antimalware de Microsoft agrega una detección al MSRT para una amenaza que es muy frecuente, deberíamos esperar
ver un aumento en las detecciones de esa familia de malware en los datos. Esto sucede de vez en cuando, como verá
en los datos. Tenga en cuenta que los sistemas infectados pueden haber estado infectados durante semanas, meses o
años antes de que se agregue la detección al MSRT. Dado que MSRT se ejecuta en sistemas de todo el mundo y
devuelve la configuración regional de Windows y la ubicación del país de los sistemas infectados, nos brinda una forma
de ver las diferencias regionales en las infecciones de malware. Discutiré esto en detalle más adelante en este capítulo.
Herramientas antimalware en tiempo real
A diferencia del MSRT, que limpia los sistemas basados en Windows que ya han sido infectados exitosamente con
malware prevalente, el propósito principal del software antimalware en tiempo real es

bloquear la instalación de malware.
Capítulo 4 127
Lo hace escaneando los archivos entrantes, monitoreando los sistemas en busca de signos reveladores de infección,
escaneando los archivos cuando se accede a ellos y escaneando periódicamente el almacenamiento. El software
antimalware en tiempo real también puede encontrar infecciones preexistentes en los sistemas cuando se instala
inicialmente el paquete antimalware en tiempo real . El software antimalware en tiempo real generalmente obtiene
actualizaciones de firmas y motores periódicamente (diariamente, semanalmente, mensualmente, etc.). Esto lo ayuda a
bloquear amenazas nuevas y emergentes, pero también amenazas antiguas que antes no podía detectar.
Por ejemplo, si se agrega la detección de una amenaza de malware, pero esa amenaza de malware ya ha
infectado con éxito los sistemas que ejecutan el software antimalware en tiempo real, la actualización permite que
el software antimalware detecte y, con suerte, elimine la infección existente.
Mi punto es que los datos del software antimalware en tiempo real nos brindan una visión diferente del panorama
de amenazas en comparación con MSRT. Microsoft Security Essentials, Microsoft System Center Endpoint
Protection, Windows Defender (ahora llamado Microsoft Defender) y Windows Defender Advanced Threat
Protection son ejemplos de software antimalware en tiempo real que son fuentes de datos. Windows Defender es
el paquete antimalware predeterminado para los sistemas basados en Windows 10, que ahora se ejecuta en más
de la mitad de todas las computadoras personales del mundo (Keizer, Windows by the numbers: Windows 10
reanuda la marcha hacia un dominio sin fin). Microsoft Defender Antivirus está instalado en los sistemas Windows
11 de forma predeterminada. Esto significa que Windows Defender podría ejecutarse potencialmente en cientos
de millones de sistemas en todo el mundo, lo que lo convierte en una gran fuente de datos de inteligencia de
amenazas.
Durante algunas de las sesiones informativas sobre inteligencia de amenazas que realicé, algunos asistentes
afirmaron que este enfoque solo brinda una vista del malware que Microsoft conoce. Pero esto no es del todo cierto.
Los principales proveedores de antimalware comparten información entre ellos, incluidas muestras de malware.
Entonces, mientras que el primer laboratorio antimalware que descubre una amenaza tendrá detecciones para
esa amenaza antes que nadie, con el tiempo, todos los proveedores de antimalware tendrán detecciones para
ella. Microsoft administra varios programas de intercambio de información de seguridad, con el objetivo de ayudar
a todos los proveedores a proteger mejor a sus clientes compartidos (Microsoft Corporation, 2019). Además, en
los últimos años, Microsoft ha ampliado la compatibilidad con Microsoft Defender a sistemas operativos que no
son de Microsoft, como Android, iOS y macOS, lo que les brindará aún más datos sobre las amenazas en estas
plataformas (Microsoft Corporation, sin fecha).
Aunque los navegadores web Internet Explorer y Edge de Microsoft no han tenido una participación de mercado
tan grande como algunos de los otros navegadores web disponibles, el filtro SmartScreen integrado en estos
navegadores nos brinda una vista del malware alojado en la web (Microsoft Corporation, nd). SmartScreen es
como un software antimalware para el navegador. A medida que los usuarios navegan por la web, SmartScreen
les advertirá sobre los sitios web maliciosos conocidos que intentan visitar y escaneará los archivos que se
descargan en el navegador en busca de malware.
Los datos de los sitios que alojan software malicioso y los archivos maliciosos en sí mismos pueden darnos una visión de las
amenazas más comunes alojadas en la web, así como también en qué parte del mundo se alojan la mayoría de las amenazas y
las regiones en las que se encuentran las poblaciones de víctimas.
Fuentes de datos que no son de seguridad
Las fuentes de datos, como los servicios de correo electrónico y los servicios de búsqueda en Internet, pueden proporcionar una
dimensión adicional a la inteligencia de amenazas. Por ejemplo, los datos de Office 365 (ahora llamado Microsoft 365) y
Outlook.com brindan visibilidad de las amenazas que fluyen a través del correo electrónico, incluidas las fuentes.
y destinos de estas amenazas y sus volúmenes. El volumen de datos que Microsoft tiene de
Office 365 es alucinante, con cientos de miles de millones de mensajes de correo electrónico de clientes de todo el mundo que
fluyen todos los meses (Microsoft Corporation, 2018).
Bing, el servicio de motor de búsqueda de Internet de Microsoft, también es una rica fuente de datos de inteligencia de amenazas.
A medida que Bing indexa miles de millones de páginas web para que sus usuarios puedan obtener resultados de búsqueda
rápidos y relevantes, también busca sitios de descarga oculta, sitios de alojamiento de malware y sitios de phishing. Estos datos
pueden ayudarnos a comprender mejor en qué parte del mundo se aloja el malware, hacia dónde se mueve con el tiempo y
dónde están las víctimas.
Cuando los datos de algunas fuentes de datos no relacionadas con la seguridad seleccionadas se combinan con datos de algunas
de las fuentes de datos de seguridad que analicé anteriormente, podemos obtener una visión más completa del panorama de
amenazas. Office 365 y Outlook.com reciben correos electrónicos enviados desde todo tipo de clientes y servidores de correo
electrónico que no son de Microsoft , y Bing indexa el contenido alojado en todo tipo de plataformas. Ciertamente, la combinación
de estos datos no nos brinda una visibilidad perfecta, pero la escala de estas fuentes de datos nos brinda el potencial para
obtener buenos conocimientos.
Ahora que sabe de dónde obtuve los datos históricos relacionados con el malware que voy a compartir con usted, echemos un
vistazo rápido a las diferentes categorías de malware que se incluyen en los datos y el análisis. Estas categorías de malware han
sido elementos fijos en el panorama de las amenazas globales durante décadas, lo que significa que los CISO y los equipos de
seguridad deben conocer bien estas categorías. Le mostraré cómo los atacantes cambian las categorías de malware que usan
con el tiempo cuando esas categorías se vuelven menos efectivas. Algunas personas llaman a esto "evolución", pero yo lo llamo
vino viejo en botellas nuevas porque los datos muestran claramente que los atacantes pasan de una categoría de malware
conocida a otra categoría de malware conocida. No es muy frecuente que se descubra una nueva categoría de malware; más a
menudo, los atacantes utilizan variaciones de temas inventados hace décadas. Esto no quiere decir que nada haya cambiado;
como ejemplo, examinaremos las formas en que el ransomware ha cambiado con el tiempo más adelante en este capítulo.
Capítulo 4 129
Acerca del malware

Antes de sumergirnos en los datos históricos de amenazas, debo brindarle algunas definiciones de
los términos que usaré en el resto de este capítulo.
El software malicioso, también conocido como malware, es software cuya intención del autor es maliciosa. Los desarrolladores
de malware intentan impedir la confidencialidad, integridad y/o disponibilidad de los datos y/o los sistemas que los procesan,
transmiten y almacenan.
Como mencioné en el Capítulo 1, los autores de malware pueden estar motivados por muchas cosas diferentes,
incluida la arrogancia, la notoriedad, el espionaje militar, el espionaje económico y el hacktivismo.
La mayoría de las familias de malware actuales son amenazas combinadas. Lo que quiero decir con esto es que hace muchos
años, las amenazas eran discretas: eran un gusano o una puerta trasera, pero no ambos. Hoy en día, la mayoría de los
programas maliciosos tienen características de múltiples categorías de programas maliciosos. Los analistas en los laboratorios
antimalware que realizan ingeniería inversa de muestras de malware suelen clasificar el malware según la forma principal o más
destacada en que se comporta cada muestra.
Por ejemplo, una pieza de malware puede exhibir características de un gusano, un troyano y un ransomware.
Un analista podría clasificarlo como ransomware porque ese es su comportamiento o característica dominante. El volumen de
amenazas ha crecido dramáticamente a lo largo de los años. Los investigadores de malware en los principales laboratorios
antimalware generalmente no tienen tiempo para pasar semanas o meses investigando una amenaza de malware, como podrían
haberlo hecho hace 20 años. Sin embargo, he visto a analistas en CERT o laboratorios de investigación boutique hacer esto
para amenazas sofisticadas específicas que se encuentran en los entornos de sus clientes.
Proteger una gran cantidad de sistemas de un volumen cada vez mayor de amenazas graves significa que algunos de los
principales laboratorios antivirus dedican menos tiempo a investigar y publicar hallazgos detallados sobre cada amenaza que
descubren. Además, la mayoría de los clientes empresariales están más interesados en bloquear infecciones o recuperarse de
infecciones lo más rápido posible y continuar con el negocio que sumergirse en el funcionamiento interno del malware actual.
En términos generales, la investigación y respuesta de malware tiene más que ver con la automatización y la ciencia ahora que
con el arte que alguna vez fue. No me malinterpreten; si puede comprender cómo se propaga una pieza de malware y cuál es
su carga útil, entonces puede mitigarlo de manera efectiva. Pero el volumen y la complejidad de las amenazas que se ven hoy
desafiarán a cualquier organización a hacer esto a cualquier escala. En cambio, los equipos de seguridad generalmente deben
dedicar tiempo y recursos a mitigar tantas amenazas de malware como sea posible, no solo una categoría o familia popular.
Como verá en los datos históricos que proporciono en este capítulo, algunos atacantes incluso usan infectadores de archivos
(virus) de la vieja escuela.

Cómo se propagan las infecciones de malware

El malware no es mágico. Debe entrar en un entorno de TI de alguna manera. Con suerte, recordará los
sospechosos habituales de ciberseguridad, es decir, las cinco formas en que las organizaciones se ven
comprometidas inicialmente , sobre las que escribí en detalle en el Capítulo 1. Para refrescar su memoria, los
sospechosos habituales de ciberseguridad son:
• Vulnerabilidades sin parchear
• Configuraciones incorrectas de seguridad
• Credenciales débiles, filtradas y robadas
• Ingeniería social
• Amenazas internas
Las amenazas de malware pueden utilizar todos los sospechosos habituales de ciberseguridad para comprometer los
sistemas. Algunos programas maliciosos se utilizan para comprometer inicialmente los sistemas para que los actores
de amenazas logren sus objetivos. Algunos programas maliciosos se utilizan en entornos de TI después de que el
entorno ya se ha visto comprometido. Por ejemplo, después de que los atacantes usen uno o más de los sospechosos
habituales de ciberseguridad para comprometer inicialmente una red, pueden usar malware que encriptará datos
confidenciales y/o encontrará credenciales de administrador almacenadas en caché y las cargará en un servidor
remoto. Algunos programas maliciosos son lo suficientemente sofisticados como para ser utilizados tanto para el
compromiso inicial como para los objetivos posteriores al compromiso. Como mencioné anteriormente, siempre he
pensado en el malware como sinónimo de "automatización de atacantes". En lugar de que el atacante escriba
manualmente comandos o ejecute scripts, el malware es un programa que realiza actividades ilícitas para el atacante,
de forma autónoma o semiautónoma. El malware ayuda a los atacantes a lograr sus objetivos, ya sea que su objetivo
sea la destrucción y la anarquía o el espionaje económico.
Las categorías de malware que analizaré en este capítulo incluyen diferentes tipos de troyanos, modificadores
de navegador, exploits, kits de exploits, software potencialmente no deseado, ransomware, virus y gusanos.
Microsoft proporciona definiciones para estas categorías de malware y otras (Microsoft Corporation, nd). Su
proveedor de antimalware o proveedor de inteligencia de amenazas favorito puede tener definiciones
diferentes a estas. Eso está perfectamente bien, pero tenga en cuenta que puede haber algunas diferencias
menores matizadas entre las definiciones. Le proporcionaré mis propias definiciones, menos formales, para
que este capítulo sea más fácil de leer y comprender.
Capítulo 4 131
troyanos
Comenzaré con los troyanos ya que, en todo el mundo, han sido la categoría de malware más prevalente durante la
última década o más. Un troyano es un programa o archivo que se representa a sí mismo como una cosa cuando en
realidad es otra, como la historia del caballo de Troya en la que se basa. Se engaña al usuario para que lo descargue
y lo abra o lo ejecute. Los troyanos no se propagan usando vulnerabilidades sin parches o contraseñas débiles como
lo hacen los gusanos; deben confiar en la ingeniería social.
Un troyano de puerta trasera es una variación de esto. Una vez que se engaña al usuario para que ejecute el
programa malicioso (los scripts y las macros también pueden ser maliciosos), un troyano de puerta trasera proporciona
a los atacantes acceso remoto al sistema infectado. Una vez que tienen acceso remoto, pueden potencialmente robar
identidades y datos, robar software y claves de juegos, instalar software y más malware de su elección, incluir el
sistema infectado en redes de bots para que puedan hacer "trabajo de proyecto" para los atacantes, y así
sucesivamente. El trabajo del proyecto puede incluir extorsión, ataques de denegación de servicio distribuido (DDoS) ,
almacenamiento y distribución de contenido ilícito y cuestionable, o cualquier otra cosa por la que los atacantes estén
dispuestos a intercambiar o vender el acceso a su red de sistemas comprometidos.
Los descargadores y cuentagotas de troyanos son otra variación de este tema. Una vez que se engaña al usuario
para que ejecute el programa malicioso, el troyano descomprime más malware de sí mismo o descarga más software
malicioso de servidores remotos. El resultado suele ser el mismo: servidumbre maliciosa y explotación del sistema
por todo lo que vale. Los descargadores y droppers de troyanos estaban de moda entre los atacantes en 2006 y
2007, pero han hecho apariciones dramáticas en períodos de tiempo limitados desde entonces. Un gran ejemplo de
un descargador y cuentagotas de troyanos es la notoria amenaza llamada Zlob. Se engañó a los usuarios para que
lo instalaran en sus sistemas cuando visitaban sitios web maliciosos que tenían contenido de video que querían ver.
Cuando hicieron clic en el archivo de video para verlo , el sitio web les dijo que no tenían instalado el códec de video
correcto para verlo.
Afortunadamente, el sitio web ofreció el códec de video para descargar para que el usuario pudiera ver el video.
El usuario realmente estaba descargando e instalando Zlob (Microsoft Corporation, nd). Una vez instalado, expondría
al usuario a anuncios emergentes de "software de seguridad" gratuito que lo ayudaría a proteger su sistema. Los
usuarios que hacían clic en los anuncios para descargar e instalar el software de seguridad otorgaban a los atacantes
cada vez más control sobre sus sistemas.
Software potencialmente no deseado

Mientras analizo las amenazas que utilizan la ingeniería social, otra categoría de amenazas casi omnipresente se
denomina software potencialmente no deseado, también conocido como aplicaciones potencialmente no deseadas,
programas potencialmente no deseados y algunos otros nombres. ¿Por qué esta categoría tiene tantos nombres
aparentemente sin pretensiones? Esta es una categoría de amenazas que inventaron los abogados.
Eso no es necesariamente algo malo, realmente es una categoría de amenaza interesante. Hay algunos
matices de gris en la investigación de malware, y esta categoría lo expone.
Permítanme darles un ejemplo hipotético de software potencialmente no deseado que no se basa en ninguna
empresa u organización del mundo real. ¿Qué pasaría si una empresa legítima ofreciera a los consumidores
un juego gratis a cambio de monitorear sus hábitos de navegación en Internet, todo para que pudieran ser
dirigidos con mayor precisión con la publicidad en línea? Creo que la mayoría de las personas que conozco
pensarían que eso es espeluznante y no renunciarían a su privacidad a cambio del acceso a un juego gratuito.
Pero si esta compensación de privacidad solo se incluyera en el Acuerdo de licencia de usuario final (EULA)
del juego gratuito, donde muy pocas personas lo leerían, ¿cuántas personas simplemente descargarían el
juego gratuito y lo jugarían? En este caso, supongamos que el juego gratuito terminó como una muestra de
malware en la colección de amenazas de una empresa antimalware. Los analistas del laboratorio antimalware
podrían decidir que la compañía del juego no estaba siendo lo suficientemente transparente con los usuarios
del juego y clasificarlo como un troyano. La compañía antimalware luego actualizaría las firmas de sus
productos antimalware para detectar esta nueva amenaza. La solución antimalware de la empresa antimalware
detectaba y eliminaba el juego de todos los sistemas en los que se ejecutaba. ¿La compañía antimalware
ayudó a sus clientes al eliminar el juego y su capacidad para rastrear sus hábitos de navegación en Internet?
¿O perjudicó el negocio de una empresa legítima al considerar su producto como malware y eliminarlo de los
sistemas de sus clientes sin permiso?
La respuesta que se le ocurrió a la industria antimalware fue llamarlo "Software potencialmente no deseado" (o
un nombre similar), marcarlo para los usuarios cuando se detecte y pedirles que aprobaran o desaprobaran
explícitamente su eliminación . De esta forma, el cliente de la empresa de juegos decide si quiere eliminar el
producto de la empresa de juegos, no el de la empresa antimalware. Esto ayuda a mitigar los reclamos y
litigios por daños predecibles que enfrenta la industria antimalware con software potencialmente no deseado.
Muchas, muchas variaciones del ejemplo que describí aquí se ofrecen hoy en Internet y están instaladas en
sistemas de todo el mundo. Algunos de ellos son empresas legítimas con negocios legítimos, mientras que
otros son actores de amenazas que pretenden ser empresas legítimas con productos legítimos. Algunas
familias de esta categoría de amenazas comienzan como programas legítimos, pero luego se vuelven
maliciosos cuando su cadena de suministro se ve comprometida o sus operadores se vuelven malévolos.
Otros ejemplos de esta categoría incluyen software antivirus falso, software protector de navegador falso,
paquetes de software que contienen un montón de diferentes ofertas y componentes de software, etc. Mi
consejo y mantra durante muchos años ha sido no confíes en el software si no confías en las personas que
lo escribieron. Verá que el software potencialmente no deseado aparece de forma destacada en los datos de
amenazas que comparto en este capítulo.
Capítulo 4 133
Exploits y kits de exploits

A continuación, veamos los exploits y los kits de exploits. El Capítulo 3, Uso de tendencias de vulnerabilidad
para reducir riesgos y costos, se dedicó al tema de las vulnerabilidades. Recuerde que una vulnerabilidad puede
permitir que un atacante comprometa la confidencialidad, la integridad o la disponibilidad de hardware o software.
Los exploits son malware que se aprovecha de las vulnerabilidades. También puede recordar de mi discusión sobre
las vulnerabilidades en el Capítulo 3 que no todas las vulnerabilidades son iguales. Algunas vulnerabilidades, si se
explotan, tienen un mayor impacto potencial en el sistema que otras. Los atacantes buscan mucho los exploits para
vulnerabilidades calificadas como críticas. Esto se debe a que brindan a los atacantes la mejor oportunidad de tomar
el control total del sistema vulnerable y ejecutar el código arbitrario de su elección.
Ese código arbitrario puede hacer cualquier cosa que pueda hacer el contexto de usuario en el que se está
ejecutando. Por ejemplo, puede descargar más malware de servidores en Internet que permitirán a los atacantes
controlar el sistema de forma remota, robar identidades y datos, incorporar el sistema a una botnet, etc.
Los exploits de trabajo para vulnerabilidades en navegadores web, sistemas operativos y analizadores de archivos
(para formatos de archivo como .pdf, .doc, .xlsx, etc.) pueden valer mucho dinero debido a la ubicuidad de estos
productos. Posteriormente, se ha desarrollado un mercado sofisticado durante las últimas dos décadas en torno a la
oferta y la demanda de exploits.
Los exploits deben entregarse a su objetivo. Se pueden entregar de varias maneras diferentes, algunas de las
cuales dependen de la ingeniería social para tener éxito. Por ejemplo, un atacante podría generar un exploit mediante
el desarrollo de un archivo .pdf con formato incorrecto diseñado para explotar una vulnerabilidad específica sin
parches en un analizador como Adobe Acrobat Reader o Microsoft Word.
Cuando una víctima abre el archivo .pdf con un analizador que no está parcheado para la vulnerabilidad que está
utilizando el atacante, y si no hay otras mitigaciones, entonces la vulnerabilidad se explota en el sistema, lo que
podría ejecutar el código arbitrario elegido por el atacante. Pero, ¿cómo logra el atacante que la víctima ejecute el
exploit? Una forma es la ingeniería social. El archivo .pdf mal formado se puede enviar a la víctima a través de un
correo electrónico, con el remitente haciéndose pasar por un compañero de trabajo o amigo de la víctima. Dado que
la víctima confía en su compañero de trabajo o amigo, abre el archivo adjunto del correo electrónico y se ejecuta el
exploit. Los exploits pueden alojarse en páginas web como descargas para las víctimas, enviarse a través de redes
sociales y distribuirse en unidades USB y otros medios extraíbles.
Un kit de exploits es una biblioteca de exploits con algún software de gestión que facilita a los atacantes la gestión
de ataques que utilizan exploits. La biblioteca de exploits de un kit puede contener cualquier cantidad de exploits
para cualquier cantidad de productos. Un kit de exploits también puede proporcionar a los atacantes páginas web
que faciliten la entrega de los exploits en su biblioteca de exploits a las víctimas.
Cierto nivel de software de administración integrado en el kit ayuda a los atacantes a comprender qué exploits están
aprovechando con éxito las vulnerabilidades en los sistemas de las víctimas y cuáles no. Esto ayuda a los atacantes a
tomar mejores decisiones sobre qué exploits usar y dónde maximizar el retorno de la inversión. Este software de
administración también podría ayudar a los atacantes a identificar y reemplazar exploits en sus páginas web que ya no
son efectivos con nuevos exploits. Los ejemplos de kits de explotación incluyen Angler (también conocido como Axpergle),
Neutrino y el notorio kit de explotación Blackhole.
Este enfoque sustenta un modelo de negocio y ha llevado a acuñar una nueva frase, Malware as a Service (MaaS).
gusanos
Un gusano proporciona su propio mecanismo de entrega para que pueda propagarse automáticamente de un sistema a
otro. Los gusanos pueden usar vulnerabilidades sin parches, malas configuraciones de seguridad, contraseñas débiles e
ingeniería social para propagarse de un sistema a otro. Un gran ejemplo de un gusano es Conficker. Había al menos
algunas variantes de este gusano. Usó vulnerabilidades sin parches, como MS08067, una lista codificada de contraseñas
débiles y abuso de funciones de ejecución automática (una función en Windows) para propagarse de un sistema Windows
a otro sistema Windows (Rains, 2011). Podría propagarse a través de unidades extraíbles, como unidades USB, así
como a través de redes. Los gusanos exitosos pueden ser muy difíciles de eliminar de un entorno de TI una vez que
ingresan al entorno. Esto se debe a que pueden "ocultarse" en medios de almacenamiento en línea y fuera de línea e
imágenes del sistema operativo.
Otros ejemplos de gusanos exitosos incluyen SQL Slammer y Microsoft Blaster, que se extendieron como la pólvora por
todo el mundo utilizando vulnerabilidades sin parches. También hay gusanos como MyDoom que se propagan por correo
electrónico. Es interesante que millones de personas estuvieran dispuestas a hacer doble clic en un archivo adjunto de
correo electrónico llamado MyDoom cuando llegó a su bandeja de entrada. Al abrir este archivo adjunto, se ejecutó el
gusano que luego envió una copia de sí mismo a todas las direcciones de correo electrónico en la lista de contactos del usuario.
Los gusanos no son una amenaza del pasado lejano. Desde los días de Conficker (2007), ha habido algunas
vulnerabilidades de gusanos en Windows a las que se podía acceder a través de excepciones predeterminadas en el
Firewall de Windows. En la mayoría de estos casos, Microsoft pudo parchear cientos de millones de sistemas en Internet
lo suficientemente rápido como para evitar los ataques de gusanos a gran escala. Pero este es un escenario tan peligroso
como puede ser para un mundo que depende tanto de la tecnología.
Permítanme pintarles una imagen del peor de los casos de gusanos, basada en ataques de gusanos globales exitosos
en el pasado. Un atacante descubre una nueva vulnerabilidad de día cero en un servicio de Windows. El servicio se
ejecuta de forma predeterminada en la gran mayoría de los sistemas Windows del mundo.
Capítulo 4 135
El servicio vulnerable utiliza un puerto TCP conocido para escuchar en la red los intentos de conexión. Hay una
regla predeterminada en el Firewall de Windows en cada sistema que permite conexiones de red directamente
al servicio vulnerable. El atacante diseña un gusano capaz de explotar esta vulnerabilidad de día cero y lo libera
en Internet.
El gusano utiliza la vulnerabilidad para propagarse antes de que Microsoft sea consciente de la vulnerabilidad y
antes de que haya una actualización de seguridad disponible para corregir la vulnerabilidad. Con una regla
predeterminada en el Firewall de Windows que permite que el gusano se comunique directamente con el puerto
TCP que está escuchando el servicio vulnerable, no hay nada que impida que el gusano explote la vulnerabilidad
en prácticamente todos los sistemas de consumo que ejecutan Windows que están directamente conectados a
Internet y no tienen un firewall adicional que lo proteja . Pero los sistemas Windows vulnerables detrás de
firewalls empresariales administrados profesionalmente tampoco serían seguros, ya que las computadoras
portátiles infectadas introducirían el gusano en los entornos de TI corporativos cuando se conectan a través de
VPN o en sus redes inalámbricas (Microsoft Corporation, sin fecha). El gusano se propaga de un sistema a otro en todo el mundo en
cuestión de minutos.
La Internet pública y la mayoría de las redes privadas se verían interrumpidas y quedarían inutilizables. En primer
lugar, el tráfico de red generado por el gusano a medida que intenta propagarse una y otra vez, de un sistema a
otro, interrumpiría significativamente el tráfico de red legítimo en Internet, así como las redes privadas en las que
encontró su camino. Después de que un sistema se infecta, el gusano intenta infectar todos los sistemas con los
que tiene conectividad de red. Simplemente intenta conectarse al servicio vulnerable a través del puerto TCP en
el que está escuchando, en todos los sistemas a los que puede acceder el sistema infectado. Cientos de millones
de sistemas que hacen esto al mismo tiempo interrumpirían Internet global y las redes privadas. Cuando el
gusano aprovecha la vulnerabilidad sin parchear, hace que el sistema de destino se desestabilice, provocando
una "Pantalla azul de la muerte", un volcado de memoria y un reinicio del sistema. Esto exacerba el problema
porque es difícil desinfectar y parchear los sistemas que se reinician constantemente.
Todos los sistemas que se reinician generan aún más tráfico de red. Cuando cada sistema vuelve a funcionar,
generan tráfico de Protocolo de resolución de direcciones (ARP) y solicitan direcciones IP a sus servidores
DHCP. Cuando los segmentos de red con servidores DHCP se saturan con solicitudes de direcciones IP, se
impide que los servidores DHCP proporcionen direcciones IP a los sistemas de reinicio. Posteriormente , los
sistemas que se reinician comienzan a utilizar direcciones IP privadas automáticas que normalmente no son
enrutables (169.254.xx). Posteriormente, en algunos casos, el software de administración utilizado para
parchearlos, actualizar las firmas antimalware o implementar posibles mitigaciones o soluciones alternativas ya
no puede acceder a estos sistemas.
El daño que podría causar un ataque de este tipo no debe subestimarse. El gobierno de los Estados Unidos ha
identificado 16 sectores de infraestructura crítica (Departamento de Seguridad Nacional de los Estados Unidos,
sin fecha). Estos sectores se consideran críticos porque si su red o sus sistemas se interrumpen, tendrían
consecuencias nefastas para la seguridad, la economía y la salud pública y la seguridad del país. Estos sectores
incluyen el sector químico, el sector de instalaciones comerciales, el sector de comunicaciones, el sector de
manufactura crítica, el sector de represas, el sector de base industrial de defensa, el sector de servicios de
emergencia, el sector de energía, el sector de servicios financieros, el sector de alimentos y agricultura, el sector
de instalaciones gubernamentales, el sector de atención médica y salud pública, el sector de tecnología de la
información, el sector de reactores nucleares, materiales y desechos, el sector de sistemas de transporte y el
sector de sistemas de agua y aguas residuales (Departamento de Seguridad Nacional de EE. UU., sin fecha).
Cuando el gusano explota la vulnerabilidad de día cero en los sistemas vulnerables de estos sectores, la
economía, la energía, el agua, las comunicaciones, el transporte, los hospitales y muchas otras funciones críticas
para la sociedad se ven interrumpidas y potencialmente desconectadas. Si el atacante incluyó una carga útil
maliciosa con el gusano, como cifrar datos o destruir medios de almacenamiento, la recuperación sería lenta en
la mayoría de los casos. Recuperarse de un ataque de este tipo requeriría mucha intervención manual, ya que
las herramientas de software de gestión y los sistemas de automatización se verían afectados, al igual que las
redes a las que están conectados. Si los medios de almacenamiento subyacentes en los sistemas infectados
también tuvieran que ser reemplazados, el daño de tal ataque persistiría durante años.
Por supuesto, he pintado una imagen del peor de los casos. ¿Cuáles son las posibilidades de que tal ataque
de gusano pueda ser perpetrado? Solo en 2019 , hubo tres vulnerabilidades de gusanos en los sistemas
operativos Windows. El 14 de mayo de 2019, Microsoft anunció la existencia de una vulnerabilidad de
clasificación crítica (CVE20190708) en los servicios de escritorio remoto de Windows que se podía detectar
con gusanos (NIST, sin fecha). En su anuncio, el Centro de respuestas de seguridad de Microsoft (MSRC) escribió lo siguiente:
”Esta vulnerabilidad es de autenticación previa y no requiere interacción del usuario. En otras
palabras, la vulnerabilidad es 'gusana', lo que significa que cualquier futuro malware que
aproveche esta vulnerabilidad podría propagarse de una computadora vulnerable a otra
vulnerable de manera similar a como se propagó el malware WannaCry por todo el mundo
en 2017. Si bien no hemos observado ninguna explotación de esta vulnerabilidad, es muy
probable que los actores malintencionados escriban una explotación para esta vulnerabilidad
y la incorporen a su malware ” . —(Microsoft Corporation, sin fecha)

Capítulo 4 137
CVE20190708, la llamada vulnerabilidad BlueKeep, aplicada a Windows 7, Windows Server 2008 y Windows
Server 2008 R2; un tercio de todos los sistemas Windows todavía ejecutaban Windows 7 en 2019 (Keizer, 2020).
Esta vulnerabilidad fue tan grave que Microsoft lanzó actualizaciones de seguridad para sistemas operativos
antiguos no compatibles, como Windows XP y Windows Server 2003. Hicieron esto para proteger la gran cantidad
de sistemas que nunca se habían actualizado desde sistemas operativos antiguos que no tenían soporte. La
protección de estos sistemas antiguos, que ya no reciben actualizaciones de seguridad regulares, de un ataque
de gusano altamente probable deja menos "combustible" en Internet para que un gusano ataque los sistemas
compatibles. Una gran cantidad de sistemas que carecen de actualizaciones de seguridad para vulnerabilidades
clasificadas como críticas son una receta para el desastre, ya que pueden usarse para todo tipo de ataques
después de que se vean comprometidos, incluidos los ataques DDoS.
Luego, el 13 de agosto de 2019, Microsoft anunció la existencia de dos vulnerabilidades de gusanos más
(CVE20191181 y CVE20191182). Más versiones de Windows contenían estas vulnerabilidades, incluidas
Windows 7, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows 8.1 y todas las
versiones de Windows 10 (incluidas las versiones de servidor). En el anuncio,
MSRC escribió:
"Es importante que los sistemas afectados se parchen lo más rápido posible debido a los
elevados riesgos asociados con las vulnerabilidades de gusanos como estas..." —
(Microsoft Corporation, 2019)
En cada uno de estos tres casos en 2019, Microsoft fue capaz de encontrar y corregir estas vulnerabilidades
críticas antes de que los posibles atacantes las descubrieran y perpetraran ataques de gusanos que habrían
tenido efectos paralizantes como los que pinté aquí. Desafortunadamente, ha habido otros CVE con gusanos
desde 2019, incluido CVE202221907, publicado el 11 de enero de 2022 (Microsoft Corporation. 11 de enero de
2022).
Secuestro de datos
Otra categoría clásica de malware que puede tener consecuencias potencialmente devastadoras es el somware
ejecutado. Una vez que el ransomware ingresa a un sistema utilizando uno o más de los sospechosos habituales
de ciberseguridad, cifrará los datos y/o bloqueará al usuario fuera del escritorio del sistema. El escritorio bloqueado
puede mostrar un mensaje que exige el pago de un rescate e instrucciones sobre cómo pagarlo.
Los exitosos ataques de ransomware han sido noticia en todo el mundo. Ejemplos de familias de ransomware
incluyen Reveton (Microsoft Corporation, nd) y Petya (Microsoft Corporation, nd).
Los atacantes que usan ransomware son descarados en sus intentos de extorsionar a todo tipo de organizaciones,
incluidos hospitales y todos los niveles de gobierno.
Aunque el ransomware ocupa los titulares, como verá en los datos de este capítulo, en realidad es una
de las categorías de amenazas menos frecuentes, desde una perspectiva global. Incluso los virus
antiguos suelen ser más frecuentes que el ransomware. Pero recuerda que el riesgo se compone de
probabilidad e impacto. Lo que hace que el ransomware sea una amenaza de alto riesgo no es la
probabilidad de encontrarlo ; es el impacto cuando se encuentra. Los datos que han sido encriptados por
ransomware que utiliza un cifrado fuerte implementado correctamente desaparecen para siempre sin las claves de descifrad
Posteriormente, muchas organizaciones deciden pagar el rescate sin ninguna garantía de que podrán recuperar todos
sus datos. Dedicar tiempo y recursos a implementar una estrategia de mitigación de ransomware es una buena
inversión. Hacer copias de seguridad fuera de línea de todos los conjuntos de datos que son activos de alto valor es
un buen punto de partida. Las copias de seguridad son el objetivo de los atacantes que usan ransomware. Por lo tanto,
mantener las copias de seguridad fuera de línea es una práctica efectiva y necesaria.
Además, tenga en cuenta que nada permanece igual por mucho tiempo y el ransomware evoluciona constantemente.
No hay nada que impida que los autores de amenazas más frecuentes y exitosas incorporen tácticas de ransomware
como cargas útiles en su malware. El ransomware se ha utilizado en ataques dirigidos durante años. Una cosa que
probablemente gobierne el uso de tácticas de ransomware es cuán criminales son los atacantes; una cosa es
desarrollar y lanzar de forma anónima malware en Internet que perturba a las personas y las organizaciones, pero
mantener activos para pedir rescate y cobrar ese rescate es una propuesta diferente, generalmente perpetrada por un
tipo de delincuente completamente diferente. Independientemente, las organizaciones deben tener una estrategia de
mitigación para esta amenaza.
En los últimos cinco años, la amenaza del ransomware ha crecido de forma espectacular. Este crecimiento no se debe
a que la categoría clásica de malware de repente se volvió más frecuente. La taxonomía cambió. Es decir, la forma en
que la industria comenzó a utilizar el término “ransomware” ha evolucionado. Esto ha causado cierta confusión entre
los consumidores, los gobiernos, los profesionales de TI empresariales y los profesionales de la seguridad por igual.
Después de ver los datos históricos sobre el ransomware en este capítulo, profundizaré en el ransomware para
desmitificar cómo ha evolucionado esta amenaza de alto perfil.
virus
Anteriormente, mencioné los virus. Los virus existen desde hace décadas. Por lo general, son infectores de archivos
autorreplicantes. Los virus pueden propagarse cuando se copian inadvertidamente entre sistemas. Debido a que
infectan archivos y/o el registro de arranque maestro (MBR) en los sistemas, a veces de manera indiscriminada, pueden
ser amenazas muy "ruidosas" que son fáciles de detectar, pero difíciles de desinfectar. En la última década más o
menos, los virus parecen haber vuelto a estar de moda entre algunos atacantes. Los atacantes modernos que
desarrollan virus normalmente no solo infectan archivos como lo hicieron sus predecesores hace décadas; pueden ser
más imaginativos y maliciosos. Recuerde, la mayoría de las amenazas se combinan.

Capítulo 4 139
Se sabe que los virus modernos descargan otro malware una vez que infectan un sistema, desactivan el software antimalware, roban
credenciales almacenadas en caché, encienden el micrófono y/o la cámara de video en una computadora, recopilan datos de audio y
video, abren puertas traseras para los atacantes y envían datos robados a servidores remotos para que los atacantes los recojan. En los
tiempos modernos, los virus no han sido tan frecuentes como los troyanos o el software potencialmente no deseado, pero siempre parece
haber cierto volumen de detecciones. Un gran ejemplo de una familia de virus que existe desde hace años es Sality (Microsoft
Corporation, sin fecha).
modificadores de navegador
La categoría de amenaza final que discutiré aquí son los modificadores del navegador. Estas amenazas están diseñadas para modificar
la configuración del navegador sin el permiso de los usuarios. Algunos modificadores del navegador también instalan complementos del
navegador sin permiso, cambian el proveedor de búsqueda predeterminado, modifican los resultados de la búsqueda, inyectan anuncios
y cambian la página de inicio y la configuración del bloqueador de ventanas emergentes.
Los modificadores del navegador normalmente se basan en la ingeniería social para su instalación. La motivación de los modificadores
de navegador suele ser el beneficio; los atacantes los utilizan para perpetrar fraudes de clics. Pero como todas las amenazas, se pueden
combinar con otras categorías y proporcionar acceso de puerta trasera y capacidades de comando y control de descarga para los
atacantes.
Medición de la prevalencia del malware

En la siguiente sección, ofrezco una perspectiva histórica sobre cómo evolucionaron las infecciones de malware durante un período de
diez años. Esto lo ayudará a comprender cómo los atacantes cambian sus ataques con el tiempo.
Antes de sumergirse en esos datos, deberá comprender dos de las formas en que se puede
medir la prevalencia del malware. El primero se llama equipos limpios por mil (CCM) (Microsoft
Corporation, nd). El término "por mil" en latín significa "en cada mil". Usamos esta medida en
Microsoft para medir cuántos sistemas Windows estaban infectados con malware por cada
1000 sistemas que analizó MSRT. Recordará que MSRT se ejecuta en cientos de millones de
sistemas cuando se lanza el segundo martes de cada mes con las actualizaciones de
seguridad para los productos de Microsoft. El CCM se calcula tomando el número de sistemas
infectados por MSRT en un país y dividiéndolo por el número total de ejecuciones de MSRT en ese país.
Luego, multiplícalo por 1,000. Por ejemplo, digamos que MSRT encontró 600 sistemas infectados con malware después de escanear 100
000 sistemas; el CCM sería (600/100.000)*1.000 = 6 (Microsoft Corporation, 2016).

El CCM es útil porque nos permite comparar las tasas de infección de malware de diferentes países al
eliminar el sesgo de la base de instalación de Windows. Por ejemplo, es justo decir que hay más sistemas
Windows ejecutándose en EE. UU. que en España. España es un país más pequeño con una población
más pequeña que los EE.UU. Si comparamos el número bruto de sistemas infectados en los EE. UU. con el
número bruto de sistemas infectados en España, es probable que los EE. UU. parezcan muchas, muchas
más veces infectados que España. De hecho, el CCM expone que durante muchos periodos de tiempo, el
número de sistemas infectados por cada 1.000 escaneados en España era muy superior al de Estados Unidos.
Antes de que un sistema pueda infectarse con malware, primero debe encontrarlo. Una vez que un
sistema encuentra malware, el malware utilizará uno o más de los sospechosos habituales de
ciberseguridad para intentar infectar el sistema. Si el malware infecta con éxito el sistema, MSRT se
ejecuta en el sistema, detecta la infección y limpia el sistema. Esto se reflejará en el MCP.
La tasa de encuentros con malware (ER) es la segunda definición que debe conocer para comprender los
datos que voy a compartir con usted. Microsoft define la sala de emergencias como:
"El porcentaje de computadoras que ejecutan software de seguridad en tiempo real de Microsoft que
informan haber detectado malware o software potencialmente no deseado, o informan haber
detectado una amenaza o familia específica, durante un período". —(Corporación Microsoft, 2016)
Dicho de otra manera, de los sistemas que ejecutan software antimalware en tiempo real de Microsoft
que describí anteriormente en este capítulo, la ER es el porcentaje de esos sistemas donde se bloqueó
la instalación de malware o donde se limpió una infección de malware.
Usaré estas dos medidas para mostrarle cómo ha cambiado el panorama de amenazas con el tiempo. El
único inconveniente de usar estos datos es que Microsoft no publicó ambas medidas para cada período
de tiempo. Por ejemplo, publicaron datos de CCM de 2008 a 2016 y luego dejaron de publicar datos de
CCM. Comenzaron a publicar datos de ER en 2013 y continuaron publicando algunos datos de ER en
2019. Pero, como verá, no publicaron datos de ER para la segunda mitad de 2016, dejando un vacío en
los datos disponibles. Adicionalmente, en ocasiones, los datos se publicaban en periodos semestrales y
otras veces en periodos trimestrales. Hice lo mejor que pude para compensar estas inconsistencias en el
análisis que compartiré con ustedes a continuación.
Una de las cosas que espero que se lleve de esta sección es cómo estar íntimamente familiarizado con
las fuentes de datos lo ayuda a interpretar los datos con precisión. Hay muchas maneras de interpretar
estos datos, pero entender realmente cómo las fuentes de datos generan datos es clave para interpretarlos
con precisión.
Capítulo 4 141
Análisis global de infecciones de malware de Windows

He agregado datos de más de 20 volúmenes y ediciones especiales del SIR para brindar una vista de cómo
evolucionó el panorama de amenazas durante un largo período de tiempo. La primera medida que veremos
es el CCM promedio mundial. Esta es la cantidad de sistemas que MSRT encontró infectados con malware
por cada 1000 sistemas que analizó en todo el mundo. La figura 4.1 incluye todos los períodos de tiempo para
los que Microsoft publicó datos de CCM en el SIR, cada trimestre entre el tercer trimestre de 2008 y el segundo
trimestre de 2016.
Figura 4.1: Tasa de infección de malware promedio mundial (CCM) 2008–2016 (Microsoft
Corporation, nd)
El eje horizontal ilustra los períodos de tiempo representados por el trimestre y el año. Por ejemplo, 3T08 es la
abreviatura del tercer trimestre de 2008, mientras que 4T13 es el cuarto trimestre de 2013. El eje vertical
representa el CCM mundial para cada período de tiempo. Por ejemplo, en el primer trimestre de 2009 (1T09),
el promedio mundial de CCM fue de 12,7.
El CCM promedio mundial para los 32 trimestres ilustrados en la Figura 4.1 es 8.82. Para aclarar este número,
vamos a convertirlo en un porcentaje: 8,82/1000*100 = 0,882%. Para el período de 8 años entre el tercer
trimestre de 2008 y el final del segundo trimestre de 2016, la tasa de infección promedio mundial, medida por
el MSRT, es inferior al 1 por ciento. Es probable que esto sorprenda a algunos de ustedes que han pensado
durante mucho tiempo que la base de instalación de Windows siempre ha tenido tasas de infección de
malware realmente altas. Por eso es interesante comparar las tasas de infección de diferentes países y
regiones. Algunos países tienen tasas de infección mucho más altas que el promedio mundial, y algunos
países tienen CCM mucho más bajos. Discutiré esto en detalle más adelante en este capítulo. El otro factor
que contribuye a una tasa de infección de malware más baja de lo que podría haber esperado es que la fuente
de estos datos es el MSRT. Recuerde que MSRT es un limpiador de ecosistemas gratuito diseñado para
limpiar sistemas en gran parte desprotegidos de las amenazas más frecuentes y graves. Si observa las fechas
en que se agregaron las detecciones al MSRT, verá que realmente está limpiando un pequeño
fracción de las familias de malware conocidas.
Por ejemplo, según la lista, a fines de 2005, el MSRT había detectado 62 familias de malware (Microsoft Corporation,
nd). Pero es una certeza que hubo órdenes de magnitud más
malware en la naturaleza en 2005.
Si bien MSRT solo es capaz de detectar una fracción de todas las familias de malware, se ejecuta en cientos de
millones de sistemas en todo el mundo cada mes. Esto nos proporciona una instantánea limitada, pero valiosa, del
estado relativo de las poblaciones de computadoras en todo el mundo. Cuando cruzamos datos de MSRT con datos
de soluciones antimalware en tiempo real y algunos de los
otras fuentes de datos que describí, obtenemos una imagen más completa del panorama de amenazas.
Otro aspecto del MSRT que es importante comprender es que mide qué familias de malware han infectado con
éxito los sistemas a gran escala. Los investigadores de Microsoft agregan detecciones al MSRT para familias de
malware que creen que son muy frecuentes. Luego, cuando se lanza el MSRT con las nuevas detecciones, los
investigadores de malware pueden ver si adivinaron correctamente. Si agregaron detecciones para una familia de
malware que estaba muy extendida, aparecerá como un pico en la tasa de infección de malware. Agregar una sola
detección nueva a la MSRT puede resultar en un gran aumento en la tasa de infección mundial. Por ejemplo, entre
el tercer y cuarto trimestre de 2015 (3T15 y 4T15 en la Figura 4.1), el CCM aumentó de 6,1 a 16,9. Este es un
cambio del 177% en la tasa de infección de malware en un solo trimestre. Luego, en el siguiente trimestre, el CCM
bajó a 8,4. Qué
impulsó este dramático aumento y luego disminuyó? Los investigadores de malware de Microsoft agregaron detecciones
al MSRT por una amenaza llamada Win32/Diplugem en octubre de 2015 (Microsoft Corporation). Esta amenaza es
un modificador del navegador que resultó estar instalado en muchos sistemas. Cuando Microsoft agregó la detección
al MSRT en octubre, limpió Diplugem de muchos sistemas en octubre, noviembre y diciembre. Por lo general,
cuando se agrega una nueva detección al MSRT, limpiará muchos sistemas infectados en el primer mes, menos en
el segundo mes y menos aún en el tercer mes. Se limpiaron muchos sistemas de Diplugem en los tres meses del
cuarto trimestre de 2015. Una vez que se drenó la mayor parte del pantano de Diplugem en el 4T15, la tasa de
infección se redujo en un 50 % en el primer trimestre de 2016.
Este tipo de pico de detección también se puede ver entre el tercer y cuarto trimestre de 2013 (3T13 y 4T13, en la
Figura 4.1) cuando el CCM aumentó de 5.6 a 17.8. Este es un cambio del 218% en la tasa de infección de malware
en un solo trimestre. Se agregaron cinco nuevas detecciones al MSRT en el cuarto trimestre de 2013.
El aumento de la tasa de detección en el 4T13 fue el resultado de agregar detección a MSRT para una amenaza
llamada Win32/Rotbrow (Microsoft Corporation, nd), que es una familia de troyanos que pueden instalar otro malware
como Win32/Sefnit (Microsoft Corporation, nd). Después del gran aumento de CCM que produjo esta detección, el
CCM retrocedió a niveles más bajos durante los siguientes dos trimestres.
Capítulo 4 143
Para ver lo que está sucediendo en un período de tiempo más reciente, tendremos que usar el ER de
malware en lugar del CCM porque Microsoft dejó de publicar datos de CCM en 2016. La figura 4.2
ilustra el ER para el período desde el primer trimestre de 2013 (1T13) hasta el cuarto trimestre de
2018 (4T18). Microsoft no publicó un ER promedio mundial para la segunda mitad de 2016, por lo que
nos quedamos sin datos para ese período.
Figura 4.2: Tasa de encuentro promedio mundial (ER) 20132018
La ER promedio para el período comprendido entre 2013 y el cierre del primer semestre de 2016 fue de 18,81%.
Esto significa que alrededor del 19 % de los sistemas Windows que ejecutaban el software antimalware en tiempo
real de Microsoft encontraron malware. Casi todos estos encuentros probablemente dieron como resultado que el
software antimalware bloqueara la instalación del malware. Una proporción más pequeña de encuentros
probablemente resultó en desinfección.
La ER cayó 62% entre el segundo trimestre de 2016 (2T16) y el primer trimestre de 2017 (1T17) y no volvió a subir
a niveles normales. En 2017 y 2018, la ER promedio mundial fue solo del 6%. No he visto una explicación
satisfactoria para esta reducción, por lo que su causa sigue siendo una
misterio para mi.
Eso le ha dado una visión a largo plazo de las tendencias de malware en los sistemas operativos Windows desde
una perspectiva global. Muchos de los CISO y equipos de seguridad a los que he informado utilizando datos
similares expresaron su sorpresa por lo bajos que son los números globales de ER y CCM, dada toda la prensa
negativa que ha generado el malware en Windows a lo largo de los años. De hecho, durante algunos de mis
compromisos de hablar en conferencias, les preguntaba a los asistentes qué porcentaje de los sistemas Windows
en el mundo pensaban que estaban infectados con malware en un momento dado. Las conjeturas de los asistentes
normalmente comenzarían en un 80% y avanzarían desde allí. Los CISO, los equipos de seguridad y los expertos
en seguridad deben estar firmemente arraigados en la realidad si quieren liderar sus organizaciones y la industria
en direcciones que realmente tengan sentido. Eso es lo que hace que estos datos sean útiles e interesantes.
Dicho esto, encuentro las perspectivas regionales mucho más interesantes y esclarecedoras que la perspectiva global.
A continuación, veamos cómo los encuentros con malware y las infecciones difieren entre zonas geográficas.
lugares alrededor del mundo.
Análisis regional de infecciones de malware de Windows

Empecé a estudiar las tasas regionales de infección de malware en 2007. Al principio, estudié un grupo relativamente
pequeño de países, probablemente seis o siete. Pero con el tiempo, nuestro trabajo en el SIR se amplió para
proporcionar datos de ER y CCM de malware para todos los países (más de 100) donde había suficientes datos para
informar hallazgos estadísticamente significativos. A lo largo de los años, de los datos surgieron tres grupos de
ubicaciones débilmente acoplados:
• Ubicaciones que constantemente tenían tasas de infección de malware (CCM) más bajas que el mundo
amplio promedio
• Ubicaciones que normalmente tenían tasas de infección de malware consistentes con el av mundial
edad
• Ubicaciones que constantemente tenían tasas de infección de malware mucho más altas que en todo el mundo
promedio
La Figura 4.3 ilustra algunas de las ubicaciones con las ER más altas y más bajas del mundo entre 2015 y 2018. La
línea punteada representa la ER promedio mundial para que pueda ver cuánto se desvían del promedio las otras
ubicaciones enumeradas. Países como Japón y Finlandia han tenido

las tasas de detección de malware más bajas y las tasas de infección de malware más bajas del mundo desde que
comenzó a estudiar estos datos hace más de 10 años. Noruega también se encuentra entre los lugares con CCM y ER
bajos. Irlanda es una nueva incorporación a la lista de lugares menos afectados. El CCM y ER para Irlanda fueron
típicamente más bajos que el promedio mundial, pero no uno de los cinco o seis más bajos.
Por ejemplo, en 2008, el CCM promedio mundial fue de 8,6, mientras que Japón tuvo un CCM de 1,7 y el CCM de
Irlanda fue de 4,2 (Microsoft Corporation, 2009). Puede ser tentador pensar, duh, una tasa de encuentro más baja
significa una tasa de infección más baja, ¿verdad? Algunas ubicaciones tienen CCM bajo y ER bajo. Pero ese no es
siempre el caso.
Con el tiempo, he visto muchos ejemplos de ubicaciones que tienen ER altos pero aún mantienen CCM bajos, y
viceversa. Una de las razones de esto es que no todas las ubicaciones tienen la misma tasa de adopción de software
antimalware. Esta es una de las razones por las que Microsoft comenzó a ofrecer software antimalware en tiempo real
como descarga gratuita y ahora lo ofrece como parte del sistema operativo. Había partes del mundo con tasas de
adopción de antimalware alarmantemente bajas. Si estos lugares se infectaran gravemente, podrían usarse como
plataformas para atacar al resto del mundo.

Capítulo 4 145
Los países con una alta adopción de protección antimalware pueden tener altas ER, pero generalmente tienen
CCM mucho más bajos. Esto se debe a que el software antimalware en tiempo real bloquea el malware de
instalando, aumentando así el ER y dejando amenazas menos frecuentes para que el MSRT las limpie, reduciendo
así el CCM.
Figura 4.3: ER regionales de malware más alto y más bajo (Microsoft Corporation, nd)
Hace muchos años, lugares como Pakistán, los Territorios Palestinos, Bangladesh e Indonesia tenían
CCM mucho más bajos que el promedio mundial (Microsoft Corporation, 2009). Pero con el tiempo,
esto cambió y estos lugares han tenido algunas de las ER más altas del mundo en los últimos años.
Desafortunadamente, no podemos ver si el CCM para estas regiones también aumentó porque Microsoft
dejó de publicar datos de CCM en 2016. Los últimos CCM publicados para estas ubicaciones en 2016
se muestran en la Tabla 4.1. (Microsoft, 2016). Los CCM para estos lugares son muchas veces más
altos que el promedio mundial, mientras que Japón, Finlandia y Noruega son mucho más bajos.
Tabla 4.1: Tasas de infección de malware (CCM) regionales más altas y más bajas en el primer y
segundo trimestre de 2016 (Microsoft Corporation, nd)
En este punto, es posible que se pregunte por qué existen diferencias regionales en las tasas de detección de
malware y las tasas de infección. ¿Por qué lugares como Japón y Finlandia siempre tienen tasas de infección
ultra bajas, mientras que lugares como Pakistán y los Territorios Palestinos tienen tasas de infección muy altas?
¿Hay algo que estén haciendo los lugares con bajas tasas de infección que otros lugares puedan beneficiarse?
Cuando comencé a estudiar estas diferencias, planteé la hipótesis de que el idioma podría ser la diferencia clave
entre ubicaciones bajas y altamente infectadas. Por ejemplo, Japón tiene un idioma difícil de aprender, ya que
es lo suficientemente diferente del inglés, el ruso y otros idiomas, por lo que podría ser una barrera para los
posibles atacantes. Después de todo, es difícil atacar con éxito a las víctimas mediante la ingeniería social si no
entienden el idioma que está utilizando en sus ataques. Pero esto también es cierto para Corea del Sur, aunque
tenía uno de los CCM más altos del mundo en 2012, con un CCM que oscilaba entre 70 y 93 (uno de los CCM
más altos jamás publicados en el SIR) (Rains, 2013).
En última instancia, tratamos de desarrollar un modelo que pudiéramos usar para predecir las tasas regionales de infección de malware.
Si pudiéramos predecir qué lugares tendrían altas tasas de infección, entonces éramos optimistas de que
podríamos ayudar a esos lugares a desarrollar políticas públicas y asociaciones entre el sector público y el
privado que podrían marcar una diferencia positiva. Algunos colegas míos en Trustworthy Computing en Microsoft
publicaron una edición especial de Microsoft Security Intelligence Report centrada en este trabajo: The
Cybersecurity Risk Paradox, Impact of Social, Economic, and Technological Factors on Rates of Malware (David
Burt, 2014). Desarrollaron un modelo que utilizó 11 factores socioeconómicos en 3 categorías para predecir las
tasas regionales de infección de malware. Las categorías y factores incluidos (David Burt, 2014):
1. Acceso digital:
• Usuarios de Internet per cápita
• Servidores de red seguros por millón de personas
• Penetración de Facebook
2. Estabilidad institucional:
• Corrupción gubernamental
• Imperio de la ley
• Tasa de alfabetización
• Estabilidad del régimen
3. Desarrollo económico:
• Calidad regulatoria
• Productividad
Capítulo 4 147
• Renta bruta per cápita
• PIB per cápita
El estudio encontró que a medida que las naciones en desarrollo aumentaban el acceso de sus ciudadanos a la
tecnología, aumentaba su CCM. Pero las naciones más maduras que aumentaron el acceso de sus ciudadanos
a la tecnología vieron disminuciones en sus CCM. Esto sugiere que hay un punto de inflexión para los países en
desarrollo a medida que pasan de ser países en desarrollo a ser más maduros en las categorías antes
mencionadas, donde el aumento del acceso a la tecnología ya no aumenta la CCM; en cambio, lo disminuye.
Un ejemplo de un país que pareció hacer esta transición en 20112012 fue Brasil. Con algunos cambios positivos
en algunos de los factores socioeconómicos en las categorías de acceso digital y estabilidad institucional, el CCM
de Brasil disminuyó de 17,3 a 9,9 (una reducción del 42 %) entre 2011 y 2012 (David Burt, 2014).
Otro matiz del estudio es que los lugares que tenían algunos de los CCM más altos y los factores socioeconómicos
de peor desempeño tendían a ser países devastados por la guerra, como Irak. Otra información interesante es
que en lugares que no tienen muy buena conectividad a Internet, ya sea porque están geográficamente aislados
o porque un conflicto militar perpetuo ha afectado la disponibilidad y la calidad de Internet, el malware infecta los
sistemas a través de unidades USB y otros tipos de medios de almacenamiento extraíbles; es decir, cuando
Internet no puede ayudar a los atacantes a propagar su malware, prevalece el malware que no depende de la
conectividad de la red. Cuando la conectividad y el acceso a Internet mejoran, los CCM tienden a aumentar en
estos lugares hasta que las condiciones socioeconómicas mejoran hasta el punto en que los gobiernos y las
asociaciones del sector público y privado comienzan a marcar una diferencia positiva en la seguridad cibernética
en la región. Los conflictos, y la pobreza que puede seguir, pueden ralentizar las tasas de actualización de la
tecnología, lo que facilita que los atacantes se aprovechen de las personas. Esta es un área de investigación muy
interesante.
Mirar países individuales es interesante y útil porque ilumina lo que está sucediendo en los lugares más y menos
afectados. Podemos aprender de los fracasos y éxitos de estos lugares. Pero, muy a menudo, los CISO preguntan
sobre el panorama de amenazas en los grupos de países donde sus organizaciones hacen negocios o de dónde
ven que provienen los ataques. Examinar las tendencias de malware para grupos de ubicaciones facilita la
identificación de anomalías en esos grupos. También ayuda a identificar qué países mantienen niveles bajos de
ER y CCM de malware, a pesar de que sus vecinos están luchando contra el malware. ¿Qué podemos aprender
de estos países que podamos aplicar en otros lugares para mejorar sus ecosistemas? En la siguiente sección, te
mostraré las tendencias históricas de los siguientes grupos de países:
• Medio Oriente y África del Norte: siempre hay un gran interés en lo que está sucediendo
en esta región, especialmente en Irán, Irak y Siria. Este dato es súper interesante.
• La Unión Europea (UE): La UE se enorgullece de mantener bajas las tasas de infección de malware. Sin embargo, este no
siempre ha sido el caso y no ha sido consistente en todos

Estados miembros de la UE.
• Europa del Este, incluida Rusia: Muchos de los CISO con los que he hablado creen que esta zona del mundo es la fuente
de gran parte del malware del mundo. Pero, ¿qué hacen estos países?
¿Cómo se ven las tasas de infección de malware?
• Asia y Oceanía: siempre hay un gran interés en las tendencias de malware en lugares como China, Pakistán e India. Es aún
más interesante observar las tendencias en el este de Asia, el sur de Asia, el sudeste de Asia y los países de Oceanía.
• América del Norte y del Sur: EE. UU. y Brasil son grandes mercados que siempre obtienen grandes
interés, pero ¿qué pasa con las situaciones de sus vecinos?
Es posible que algunas de estas regiones no le interesen. Siéntase libre de saltar a la sección de la región que más le interese.
Comencemos analizando quizás la región más interesante del mundo desde una perspectiva de amenazas históricas, el Medio
Oriente y África del Norte.
El panorama de las amenazas en Oriente Medio y el norte de África

Como región, Oriente Medio y África del Norte ha tenido niveles elevados de ER y CCM de malware durante muchos años. He
tenido la oportunidad de visitar a los CISO y equipos de seguridad en algunos de estos lugares a lo largo de los años. Las 14
ubicaciones que he incluido en mi análisis tenían un CCM trimestral promedio de 23,9 en los 26 trimestres entre 2010 y 2016,
mientras que el promedio mundial durante el mismo período fue de 8,7 (Microsoft Corporation, sin fecha). Estas ubicaciones
como grupo tenían casi tres veces el CCM promedio que el resto del mundo. La ER promedio trimestral de estas localidades para
los 23 trimestres entre el último semestre de 2013 y 2019 fue de 21,9, mientras que el promedio mundial fue de 12,5.
La Figura 4.4 ilustra el CCM para varias ubicaciones en esta región para el período, que comienza en
el primer trimestre de 2010 y finaliza en el segundo trimestre de 2016, cuando Microsoft dejó de
publicar datos de CCM (Microsoft Corporation, nd).
Boleta de calificaciones regional de 10 años para el Medio Oriente y el Norte

África
Esta boleta de calificaciones se refiere a los siguientes datos:
• Región: Medio Oriente y África del Norte

Capítulo 4 149
• Ubicaciones incluidas en el análisis: Argelia, Bahrein, Irán, Irak, Israel, Jordania, Kuwait, Líbano, Omán, Autoridad
Palestina, Qatar, Arabia Saudita, Siria y Emiratos Árabes Unidos
• CCM promedio (2010–2016): 23,9 (93 % más que el promedio mundial)
• TI promedio (2013–2019): 21,9 % (55 % más que el promedio mundial)
Figura 4.4: Tasas de infección de malware para ubicaciones seleccionadas en Medio Oriente y África
20102016 (Microsoft Corporation, nd)
Quizás el ejemplo más extremo de tasas de infección de malware que se salen de control a medida que los factores
socioeconómicos se vuelven muy negativos es Irak. En el cuarto trimestre de 2013, el CCM en Irak fue de 31,3, mientras
que el promedio mundial fue de 17,8 (que, por cierto, es el promedio mundial más alto registrado durante este período de
5 años). En el primer trimestre de 2014, el CCM en Irak aumentó un 254% a 110,7 (uno de los CCM más altos jamás
registrados). Durante este tiempo en Irak, el gobierno iraquí perdió el control de Faluya ante los militantes islamistas (Al
Jazeera, 2014). El primer trimestre de 2014 vio olas de violencia en Irak con múltiples suicidios y atentados con coches
bomba; la policía estaba siendo atacada y la violencia aumentaba en previsión de las elecciones parlamentarias (Wikipedia,
sin fecha). A medida que la economía del país sufría y sus bases gubernamentales y sociales se desvanecían en la
oscuridad de estas condiciones extremas, el malware prosperaba.
Las tasas de infección de malware se mantuvieron muchas veces por encima del promedio mundial durante al menos los
siguientes 2 años, después de lo cual ya no tenemos datos de CCM. Los datos de la tasa de encuentros con malware
sugieren que la sala de emergencias en Irak se redujo a puntos por debajo del promedio mundial en 2017, antes de
normalizarse en aproximadamente tres veces el promedio mundial en el último trimestre de 2018 y en 2019.
Los datos de ER también nos muestran que Irak no tuvo la ER más alta en la región, con Argelia, la Autoridad
Palestina y Egipto teniendo ER más altas en puntos entre 2013 y 2019.
Figura 4.5: Primer plano del aumento en las tasas regionales de infección de malware en MENA en 2011 (Microsoft
Corporation, sin fecha)
Otro ejemplo más sutil de cambios regionales en los MCP que podrían estar vinculados a cambios
socioeconómicos se puede observar entre el cuarto trimestre de 2010 (4T10) y el primer trimestre de 2011
(1T11). Los MCP para ubicaciones en la región durante este período se ilustran en la Figura 4.5.
La Primavera Árabe comenzó en esta región en diciembre de 2010, lo que provocó un período turbulento en
varios lugares (Wikipedia). Una semana antes, acababa de regresar a los EE. UU. de un viaje de negocios a
Egipto, y fue desconcertante ver un edificio del gobierno que acababa de visitar en llamas en CNN.
Los disturbios civiles y las protestas masivas provocaron cambios en el liderazgo del gobierno en varios
lugares clave de la región. Durante este mismo tiempo, los CCM aumentaron en todas las ubicaciones de las
que tengo datos en la región. Las ubicaciones que normalmente tenían CCM más bajos que el promedio
mundial, como el Líbano, la Autoridad Palestina y Qatar, de repente tenían CCM más altos que el promedio
mundial. Desde entonces, los CCM de estas ubicaciones no han caído por debajo del promedio mundial.
A medida que las protestas masivas afectaron las economías de algunos lugares clave de la región y los
informes de delitos aumentaron drásticamente, los servicios gubernamentales se interrumpieron y floreció el
malware. Quizás también se esté preguntando sobre el gran aumento en la tasa de infección de malware en
Qatar en el 1T11. Durante este tiempo, la prevalencia de gusanos en Qatar estaba muy por encima del
promedio mundial. Gusanos como Rimecud, Autorun y Conficker estaban infectando sistemas con gran éxito.
Estos tres gusanos utilizan la función Autorun para propagarse. Una vez que se desinfectaron los sistemas
infectados en Qatar , la tasa de infección volvió a un rango más normal.
Capítulo 4 151
Figura 4.6: Tasas de encuentro de malware (ER) para ubicaciones seleccionadas en MENA 2013–2019
(Microsoft Corporation, nd)
El Medio Oriente y África del Norte es una región muy interesante. Probablemente podría dedicar un capítulo entero
de este libro a las cosas que he observado en los datos de esta región a lo largo de los años.
Desde la perspectiva de las amenazas a la ciberseguridad, sigue siendo una de las regiones más activas del mundo,
si no la más interesante.
Dirijamos ahora nuestra mirada al panorama de amenazas en Europa.
El panorama de amenazas en la Unión Europea y Europa

del Este
Antes del Brexit, había 28 estados soberanos en la Unión Europea (UE). Viví en el Reino Unido
durante el período en que ocurría el Brexit. Fui líder de seguridad y cumplimiento para el sector
público mundial en Europa, Medio Oriente y África (EMEA) en Amazon Web Services
(AWS) en ese momento. En este cargo, viajé a Europa continental para visitar a los CISO y los equipos de seguridad
casi todas las semanas. Fue una experiencia muy interesante estar en la intersección del Brexit, la llegada del
Reglamento General de Protección de Datos (GDPR), la introducción de la Ley CLOUD, la creciente popularidad de
la computación en la nube y una mayor preocupación por la ciberseguridad. Aprendí mucho sobre las perspectivas
europeas en muchos temas, incluida la privacidad y la soberanía de los datos. Recomiendo encarecidamente la
experiencia internacional tanto para el crecimiento personal como profesional.
Desde la perspectiva del malware, en contraste con el Medio Oriente y el norte de África, la UE generalmente ha
tenido tasas de infección mucho más bajas. Las 28 ubicaciones en la UE anterior al Brexit tenían un CCM trimestral
promedio de 7,9 para los 26 trimestres entre 2010 y 2016. El CCM promedio mundial durante el mismo período fue de
8,7. La tasa de detección de malware trimestral promedio para la UE durante los 23 trimestres entre la última mitad
de 2013 y 2019 fue de 11,7, mientras que el promedio mundial fue de 12,5.
Como grupo, la UE anterior al Brexit tenía un CCM y un ER más bajos que el promedio mundial.
La Figura 4.7 ilustra el CCM para las 28 ubicaciones en la UE para el período que comienza en el primer
trimestre de 2010 y finaliza en el segundo trimestre de 2016, cuando Microsoft dejó de publicar
datos del MCC.
Boleta de calificaciones regional de 10 años para la Unión Europea

• Región: Unión Europea (preBrexit)
• Ubicaciones incluidas en el análisis: Austria, Bélgica, Bulgaria, Croacia, Chipre, República Checa,
Dinamarca, Estonia, Finlandia, Francia, Alemania, Grecia, Hungría, Irlanda, Italia, Letonia,
Lituania, Luxemburgo, Malta, Países Bajos, Polonia, Portugal, Rumanía, Eslovaquia, Eslovenia,
España, Suecia y el Reino Unido
• CCM promedio (2010–2016): 7.9 (10% menos que el promedio mundial)
• TI promedio (2013–2019): 11,7 % (7 % menos que el promedio mundial):
Figura 4.7: Tasas de infección de malware (CCM) para los estados miembros de la UE 2010–2016
Lo primero que puede notar sobre estos datos es que España tuvo las tasas de infección más altas, o una de
las más altas, en la UE durante varios trimestres en 2010, 2011, 2013 y 2015. La ER de España estuvo por
encima del promedio mundial en 16 de los 23 trimestres entre 2013 y 2019. España ha tenido un panorama de
amenazas muy activo; a lo largo de los años, he visto aparecer malware primero a nivel local en España antes
de convertirse en amenazas globales crecientes.
En 2010, gusanos como Conficker, Autorun y Taterf (Microsoft Corporation, nd) aumentaron las tasas de
infección. Rumania también se encontraba entre los lugares más activos de la UE, y en ocasiones tenía el CCM
y ER más altos de la región.
El aumento en las tasas de infección de malware en el cuarto trimestre de 2013 (4T13) se debió a tres
amenazas que dependían de la ingeniería social, los descargadores de troyanos Rotbrow y Brantall, y un
troyano llamado Sefnit (Microsoft Corporation, sin fecha).
Capítulo 4 153
El pico de CCM en el cuarto trimestre de 2015 (4T15) se debió al aumento global en la prevalencia de un
modificador de navegador llamado Diplugem (Microsoft Corporation, nd).
Figura 4.8: Tasas de encuentro de malware (ER) para ubicaciones seleccionadas en la Unión Europea
El pico observado en la sala de emergencias de Alemania en el tercer y cuarto trimestre de 2014 se debió a
algunas familias de amenazas que estaban en aumento en Europa durante ese tiempo, incluidas EyeStye (también
conocida como SpyEye), Zbot (también conocida como la botnet Zeus), Keygen y el notorio kit de explotación
BlackHole (Rains, New Microsoft Malware Protection Center Threat Report Published: EyeStye).
Los lugares con los CCM y ER consistentemente más bajos en la UE son Finlandia y Suecia.
Ni el CCM de Finlandia ni el CCM de Suecia han superado el promedio mundial. La ER de Suecia no superó el
promedio mundial, mientras que la ER más alta de todos los tiempos de Finlandia estuvo una fracción de punto
por encima del promedio mundial. Los factores socioeconómicos positivos en el trabajo en los países nórdicos,
incluidos Noruega, Dinamarca e Islandia, parecen haberlos vacunado contra el malware en comparación
a la mayor parte del resto del mundo.
Tabla 4.2: Izquierda: ubicaciones de la UE con el CCM promedio más alto, 1T10–2T16; derecha:
ubicaciones de la UE con el CCM promedio más bajo, 1T102T16 (Microsoft Corporation, nd)
Tabla 4.3: Izquierda: ubicaciones de la UE con la ER promedio más alta, 3T13–3T19; derecha:
ubicaciones de la UE con el ER promedio más bajo, 3T193T19 (Microsoft Corporation, nd)
Por supuesto, cuando se habla de malware, siempre hay un gran interés en Rusia y sus vecinos de Europa del Este.
En mi carrera, he tenido la oportunidad de visitar CISO y expertos en seguridad cibernética en Rusia, Polonia y
Turquía. Siempre aprendo algo de los expertos en seguridad cibernética en esta región, ya que siempre hay mucha
actividad. ¡Mi experiencia también sugiere que no hay un mal restaurante en Estambul!
El CCM de Rusia se ha mantenido alrededor o por debajo del promedio mundial constantemente a lo largo del tiempo.
Esto es a pesar de que la sala de emergencias en Rusia suele estar por encima del promedio mundial. Rusia sufrió
los mismos picos de infecciones de malware en 2013 y 2015 que el resto de Europa.
El lugar más activo en esta región ha sido Turquía. El CCM y ER en Turquía han sido consistentemente
significativamente más altos que el promedio mundial. Ha tenido el CCM más alto de estos lugares en todos menos
un cuarto, entre 2010 y 2016. Turquía tuvo el ER más alto de estos lugares hasta la segunda mitad de 2016, cuando
el ER de Ucrania comenzó a superarlo. El panorama de amenazas de Turquía es tan único como su ubicación en el
punto donde se encuentran Europa y Asia, impulsado por una mezcla ecléctica de troyanos, gusanos y virus. Hubo un
gran aumento tanto en el CCM como en el ER en Turquía en 2014. Curiosamente, 2014 fue un año de elecciones
presidenciales en Turquía (El primer ministro de Turquía es proclamado ganador de las elecciones presidenciales de
2014) y vio grandes protestas antigubernamentales relacionadas con las nuevas regulaciones propuestas de Internet
allí (Ece Toksabay, 2014). También hubo picos significativos en CCM y ER en Turquía a fines de 2015 y en 2016.
Nuevamente, es interesante que se celebraron elecciones generales en junio de 2015 y hubo una serie de bombardeos
y ataques relacionados con ISIS en Turquía durante este tiempo.
Estonia ha tenido el CCM y ER más bajos durante gran parte del período que estudié, ambos típicamente por debajo
del promedio mundial.

Capítulo 4 155
Pero hay picos en los datos de ER en el cuarto trimestre de 2017 y el segundo trimestre de 2018.
Podemos obtener algunas ideas del informe de 2018 (Autoridad del Sistema de Información de la República
de Estonia, 2018) y el informe de 2019 (Autoridad, 2019) publicados por la Autoridad del Sistema de
Información de Estonia, que parece señalar con el dedo las campañas de ransomware WannaCry y
NotPetya y la explotación de vulnerabilidades sin parches.
Boleta de calificaciones regional de 10 años para ubicaciones seleccionadas de

Europa del Este
• Región: ubicaciones selectas de Europa del Este
• Ubicaciones incluidas en el análisis: Bulgaria, Estonia, Letonia, Eslovaquia, Rusia, Turquía y

Ucrania
• ER promedio (2013–2019): 17,2 % (32 % más que el promedio mundial)
Figura 4.9: Tasas de infección de malware para ubicaciones seleccionadas en Europa del Este 20102016
(Microsoft Corporation, nd
Figura 4.10: Tasas de encuentro de malware (ER) para ubicaciones seleccionadas en Europa del Este
Tabla 4.4: Izquierda: ubicaciones seleccionadas de Europa del Este, CCM promedio, 1T10–2T16; derecha:
ubicaciones seleccionadas de Europa del Este, ER promedio, 3T19–3T19 (Microsoft Corporation, nd)
Después de observar el panorama en Europa y Europa del Este, cambiemos de marcha y examinemos las tendencias.
para algunos lugares de Asia.
El panorama de amenazas en ubicaciones seleccionadas de Asia y Oceanía

¿Sabías que alrededor del 60% de la población mundial vive en Asia? He tenido la suerte de visitar Asia y Oceanía
varias veces en mi carrera, visitando CISO y equipos de seguridad en Japón, Corea, Singapur, Hong Kong, Malasia,
India, China, Filipinas, Australia, Nueva Zelanda y tantos otros lugares interesantes allí. Ambos continentes tienen
un interesante panorama de amenazas donde, en su conjunto, tienen una ER y CCM significativamente más altas
que los promedios mundiales. Varias ubicaciones en Asia tienen CCM y ER muy por encima del promedio mundial.
Pakistán, Corea, Indonesia, Filipinas, Vietnam, India, Malasia y Camboya tienen MCP mucho más altos que el
promedio mundial. Los países asiáticos como Japón y China y los países de Oceanía como Australia y Nueva
Zelanda tienen tasas de infección mucho más bajas que la mayoría de los países asiáticos y están muy por debajo
del promedio mundial.
Capítulo 4 157
Tabla 4.5: Ubicaciones en Asia con el CCM promedio más alto y más bajo, 1T10–2T16 (Microsoft
Corporation, nd)
Tabla 4.6: Ubicaciones en Asia con el ER promedio más alto y más bajo, 3T13–3T19 (Microsoft
Corporation, nd)
Boleta de calificaciones regional de 10 años para Asia y Oceanía

• Región: Asia y Oceanía
• Ubicaciones incluidas en el análisis: Australia, Camboya, China, RAE de Hong Kong, India, Indonesia, Japón,
Corea, Malasia, Nueva Zelanda, Pakistán, Filipinas, Singapur, Taiwán,
y Vietnam
• ER promedio (2013–2019): 17,2 % (32 % más que el promedio mundial)
Figura 4.11: Tasas de infección de malware (CCM) para ubicaciones seleccionadas en Asia y Oceanía, 2010–
Como ilustra la Figura 4.11 , hubo grandes aumentos en la tasa de infección de malware en Corea del Sur en el
segundo y cuarto trimestre de 2012. Corea tuvo la tasa de infección de malware más alta de Asia durante este
tiempo, incluso más alta que Pakistán, que en ocasiones ha tenido uno de los panoramas de amenazas más activos
del mundo. Estos picos en la tasa de infección fueron impulsados por solo dos familias de amenazas que dependían
de la ingeniería social para propagarse. Una de estas amenazas fue el software antivirus falso que se encontró en
una cantidad significativa de sistemas en Corea. Tenga en cuenta que este pico solo ocurrió en Corea. La ingeniería
social generalmente se basa en el lenguaje para engañar a los usuarios para que tomen malas decisiones de confianza.
Aparentemente, una versión en coreano de este software antivirus falso tuvo mucho éxito en ese momento. Pero
esa amenaza no engañaría a muchas personas que no hablan coreano.
Capítulo 4 159
Recuerdo haber visitado Corea del Sur en ese momento para concienciar a las organizaciones del sector público
y del sector comercial sobre la alta tasa de infección de malware del país. Muchas de las personas con las que
hablé en Seúl expresaron sorpresa e incluso incredulidad de que el país tuviera la tasa de infección más alta del
mundo.
También puede notar el fuerte aumento en la tasa de infección de malware en Pakistán en 2014. Pakistan
también tuvo una de las ER más altas en Asia durante este período de tiempo, junto con Indonesia. Cabe
señalar que hubo disturbios civiles e inestabilidad política en Pakistán durante 2014 que dieron lugar a múltiples
bombardeos, tiroteos y acciones militares (Wikipedia, sin fecha).
Figura 4.12: Tasas de encuentro de malware (ER) para ubicaciones seleccionadas en Asia y Oceanía,
Asia es tan grande y diversa que podemos obtener una mejor visibilidad de los CCM y ER relativos de estos
lugares al dividir los datos en subregiones. Mi análisis no incluye todos los países de todas las regiones, pero los
resultados son interesantes, no obstante. Oceanía tuvo una tasa de infección y una tasa de encuentro más bajas
en comparación con cualquier región de Asia; el CCM y ER de Oceanía están por debajo del promedio mundial,
mientras que los de las regiones asiáticas están por encima del promedio mundial. Sin el pico de CCM
mencionado anteriormente en Corea del Sur, el CCM de Asia Oriental probablemente también habría estado por
debajo del promedio mundial. Estos datos ilustran claramente que el sur de Asia tiene niveles significativamente
más altos de encuentros con malware e infecciones que en cualquier otro lugar de Asia.
Estos son incluso más altos que el promedio de CCM y ER en el Medio Oriente y África del Norte, con 23,9 y 21,9%,
respectivamente.
Figura 4.13: Tasas de infección de malware regional de Asia y Oceanía (20102016) y tasas de
encuentro (20132019) (Microsoft Corporation, nd)
A continuación, examinemos la situación en las Américas. He tenido la oportunidad de vivir tanto en los Estados Unidos
como en Canadá, donde me he reunido con innumerables CISO y equipos de seguridad a lo largo de los años. También
he tenido la oportunidad de visitar CISOs en diferentes lugares de América del Sur.
El panorama de amenazas en ubicaciones seleccionadas en las Américas

Cuando examino los datos de CCM de 2007 y 2008, puedo encontrar períodos en los que Estados Unidos tuvo una tasa
de infección de malware superior al promedio mundial. Pero durante la mayor parte del período entre 2010 y 2016, el
CCM en los EE. UU. osciló cerca o por debajo del promedio mundial. La sala de emergencias en los EE. UU. también
suele estar por debajo del promedio mundial.
Los EE. UU. solían ser el objetivo principal de los atacantes porque los sistemas de los consumidores en los EE. UU.
tenían una conectividad a Internet relativamente buena, procesadores relativamente rápidos y mucho almacenamiento
disponible, todo lo que los atacantes podían usar para sus fines ilícitos. Pero con el tiempo, los consumidores en los EE.
UU. se volvieron más conscientes de las tácticas de los atacantes y los proveedores comenzaron a activar funciones de
seguridad en los sistemas más nuevos de forma predeterminada. Con el tiempo, la calidad de Internet mejoró en otros
países, al igual que los sistemas informáticos de los consumidores. Los atacantes siguieron a las nuevas poblaciones a
medida que se conectaban y el enfoque en atacar los sistemas de los consumidores en los EE. UU. retrocedió. En
períodos más recientes, lugares como Brasil, Argentina, México, Venezuela y Honduras han tenido las tasas de infección
de malware más altas de las Américas.
Capítulo 4 161
Boleta de calificaciones regional de 10 años para las Américas

• Región: Las Américas

• Ubicaciones incluidas en el análisis: Argentina, Bolivia, Brasil, Canadá, Chile, Colombia, Costa
Rica, Ecuador, Guatemala, Honduras, México, Nicaragua, Panamá, Paraguay, Perú, el
Estados Unidos, Uruguay y Venezuela
• TI promedio (2013–2019): 16,5 % (26 % más que el promedio mundial)
Figura 4.14: Tasas de infección de malware para ubicaciones seleccionadas en las Américas, 20102016
Figura 4.15: Tasas de encuentro de malware (ER) para ubicaciones seleccionadas en las Américas
Tabla 4.7: Ubicaciones en las Américas con el CCM promedio más alto y más bajo, 1T10–2T16
Tabla 4.8: Ubicaciones en las Américas con el promedio de ER más alto, 3T13–3T19 (Microsoft
Corporation, nd)
Capítulo 4 163
En su conjunto, las Américas tienen un CCM y una ER más altos que el promedio mundial. Sin embargo, América del
Norte, América Central y América del Sur tienen niveles ligeramente diferentes de encuentros e infecciones de malware.
Aunque mi análisis no incluye todas las ubicaciones en las Américas, desglosar los datos por región hace que sea un
poco más fácil compararlos.
Figura 4.16: Tasas regionales promedio de infección de malware (2010–2016) y tasas de encuentro
(2013–2019) de América (Microsoft Corporation, sin fecha)
Espero que hayas disfrutado de esta gira alrededor del mundo. Me tomó meses hacer esta investigación y análisis, por
lo que obviamente encuentro las tendencias regionales de malware realmente interesantes. Y para los equipos de
seguridad que viven en estas regiones, especialmente fuera de los Estados Unidos, puede ser difícil encontrar inteligencia
de amenazas regional creíble, mientras que el miedo, la incertidumbre y la duda siempre parecen estar cerca.
Permítanme compartir con ustedes algunas conclusiones de este análisis.
Conclusiones del análisis regional de infecciones de malware de Windows

La figura 4.17 ilustra los datos de desglose regional en un solo gráfico, lo que facilita ver los niveles
relativos de CCM y ER en todo el mundo. Durante el período de 10 años que examiné, los sistemas en
el sur de Asia, el sudeste de Asia y el Medio Oriente y el norte de África han encontrado más malware
que en cualquier otro lugar del mundo. Este es probablemente un factor principal que contribuye a que
estas regiones también tengan las tasas de infección de malware más altas del mundo.
Esto contrasta con los ER y CCM mucho más bajos de Oceanía, Asia oriental y la UE.
Figura 4.17: CCM y ER promedio para regiones de todo el mundo, 2013–2019 (Microsoft Corporation, nd)
Las 10 ubicaciones principales con los CCM y ER promedio más altos del mundo se enumeran en la Tabla 4.9
aquí. El CCM promedio mundial para el mismo período es 8,7 y el ER promedio es 12,5. Todas estas ubicaciones
tienen al menos el doble de ER y CCM que el promedio mundial.
Tabla 4.9: Ubicaciones con los CCM y ER más altos del mundo 1T10–2T16 (Microsoft Corporation,
nd)
¿Qué significa todo esto para los CISO y los equipos de seguridad
empresarial?
A lo largo de los años, he conocido a muchos equipos que bloquean todo el tráfico de Internet que se origina en
China, Irán y Rusia debido a los ataques que ven que se originan en esos rangos de direcciones IP a nivel de país.
Capítulo 4 165
Por lo que me han dicho los CISO, incluidos los informes de atribución publicados por los gobiernos de EE. UU.
y el Reino Unido y los informes de la prensa, ciertamente no parece haber ninguna duda de que muchos
ataques se originan en estos lugares. Pero, por supuesto, los atacantes no se limitan a usar rangos de
direcciones IP de su país de origen o de cualquier país en particular, por lo que esta no es una solución
milagrosa. Y recuerda que los sistemas de las víctimas de este tipo de ataques se utilizan para perpetrar
ataques contra otras víctimas potenciales, por lo que sus direcciones IP pueden ser el origen de muchos ataques.
Cuando los sistemas se ven comprometidos por el malware, algunos de ellos se utilizan en ataques, incluidos
los ataques DDoS, los ataques de descarga oculta, los ataques de abrevadero, el alojamiento de malware y
otros "proyectos" para los atacantes. Por lo tanto, algunos CISO toman la medida de precaución de bloquear el
tráfico de Internet hacia/desde las ubicaciones con las tasas de infección de malware más altas del mundo. Si
su organización no hace negocios en estas ubicaciones ni tiene socios o clientes potenciales en ellas, minimizar
la exposición a los sistemas en estas ubicaciones podría funcionar como una mitigación adicional para las
infecciones de malware. Muchas organizaciones usan reglas administradas de firewall, proxy y WAF por este mismo motivo.
Pero dado que mi análisis es para una década completa, para poder estar en la lista de las ubicaciones más
infectadas , estas ubicaciones deben tener tasas de infección consistentemente altas. Limitar los lugares que
los trabajadores de la información pueden visitar en Internet reducirá la cantidad de amenazas potenciales a las
que se exponen.
Para los equipos de seguridad que viven en estos lugares o que apoyan las operaciones en estos lugares,
espero que puedan usar estos datos para obtener el apoyo adecuado para su estrategia de seguridad cibernética
de su Csuite, la industria local y todos los niveles de gobierno. Usando esa analogía del submarino sobre la
que escribí en el prefacio de este libro, no hay lugar en la Tierra con más presión sobre el casco del submarino.
que en estos lugares.
Esta es una espada de doble filo, ya que ejerce más presión sobre los equipos de seguridad en estos lugares,
pero también les brinda el contexto y la claridad que las organizaciones en otras partes del mundo no tienen.
Utilice estos datos para generar conciencia entre sus comunidades de partes interesadas en ciberseguridad y
para obtener el apoyo que necesita para tener éxito.
Algunos de los CISO que conozco han usado datos de CCM y ER como referencia para sus organizaciones.
Utilizan su software antimalware para desarrollar datos de detección, bloqueo y desinfección para sus entornos
de TI. Comparan el CCM y ER de sus entornos con las cifras globales publicadas por Microsoft u otros
proveedores de antimalware. También compararán sus puntos de datos de CCM y ER con cifras regionales en
los países donde tienen operaciones de TI. Esto les permite ver si su organización se ve más o menos afectada
que los sistemas de consumo promedio en su país o en todo el mundo. Su objetivo es tener siempre cifras de
CCM y ER más bajas que las de su país y más bajas que los promedios mundiales.
Consideran que los datos de malware globales y regionales son una referencia útil para determinar si están
haciendo un buen trabajo al administrar el malware en su entorno.
Desde una perspectiva de política pública, parece que algunos de los gobiernos de Oceanía, Asia oriental y la UE
tienen algo que enseñar al resto del mundo sobre cómo mantener bajo control el panorama de las amenazas.
Específicamente, los gobiernos de Australia, Nueva Zelanda, los países nórdicos y Japón deberían ayudar a las
regiones altamente infectadas a tomar el camino correcto. Pero esta no será una tarea fácil, ya que los altos
niveles de conflicto parecen ser el factor subyacente que afecta los factores socioeconómicos que están vinculados
a las altas tasas regionales de infección de malware. Abordar la corrupción gubernamental, adoptar el estado de
derecho y mejorar las tasas de alfabetización, la estabilidad del régimen, la calidad regulatoria, la productividad,
el ingreso bruto per cápita y el PIB per cápita son las primeras órdenes del día para reducir las tasas de infección
de malware en muchos lugares. Los CISO corporativos y los líderes de seguridad cibernética en el sector público
pueden contribuir a un futuro mejor al educar a las personas influyentes en las políticas públicas de sus países.
Ahora que le brindé una inmersión profunda en los encuentros e infecciones de malware regionales, veamos cómo
ha evolucionado el uso de diferentes categorías de malware con el tiempo a nivel mundial, es decir, cómo los
atacantes han cambiado sus tácticas cuando ya no son efectivos. A riesgo de sonar como un geek de datos de
seguridad cibernética, ¡estos datos son mis datos favoritos relacionados con el malware! La ingeniería social es
una técnica fundamental para los atacantes, y esta visión de 10 años de cómo los atacantes han usado malware
lo ilustra claramente.
Evolución mundial del malware

Comprender la evolución del malware ayudará a los CISO y a los equipos de seguridad a poner en contexto la
histeria que leen en las noticias. Tenga en cuenta los sospechosos habituales de ciberseguridad mientras lee esta
sección.
Tras los exitosos ataques de gusanos a gran escala de 2003 y principios de 2004, Microsoft presentó Windows
XP Service Pack 2 en agosto de 2004. Entre otras cosas, Windows XP Service Pack 2 activó el Firewall de
Windows de forma predeterminada por primera vez en un sistema operativo Windows .
Antes de esto, era una configuración opcional que se dejaba a los clientes para activar, configurar y probar con
sus aplicaciones. Este paquete de servicio también ofreció la aleatorización del diseño del espacio de direcciones
(ASLR) y Prevención de ejecución de datos (DEP) por primera vez en un sistema operativo Windows (David Ladd,
2011). Estas tres características frenaron el éxito de futuros ataques masivos de gusanos que buscaban usar las
mismas tácticas que SQL Slammer y MSBlaster.
Capítulo 4 167
Una vulnerabilidad en un servicio que escucha en un puerto de red no puede explotarse si hay un firewall basado
en host que bloquea los paquetes para que no lleguen al puerto. La ubicación de memoria de una vulnerabilidad
puede no ser la misma en todos los sistemas, lo que dificulta su búsqueda y explotación.
18 meses después del lanzamiento del Service Pack 2 de Windows XP y su adopción generalizada, los datos nos
muestran que los gusanos y las puertas traseras cayeron en desgracia entre los atacantes. Como se muestra en
la Figura 4.18, la cantidad de detecciones de estas categorías de malware experimentó reducciones dramáticas
en 2006, 2007 y 2008.
Un tipo diferente de gusano, uno que no solo usaba vulnerabilidades sin parches, se hizo popular entre los
atacantes en 2009, 5 años después de que Windows Firewall, ASLR y DEP se activaran en los sistemas
operativos Windows.
Figura 4.18: Detecciones por categoría de amenaza, incluidas puertas traseras, spyware, virus y gusanos, por
porcentaje de todos los sistemas basados en Windows que informaron detecciones, 2006–2012 (Microsoft
Corporation, sin fecha)
Una vez que los gusanos ya no fueron efectivos para los ataques masivos, los datos nos muestran que el software
diverso potencialmente no deseado se hizo popular en 2006, 2007 y 2008. Puede ver este marcado aumento en
la Figura 4.19. Como describí anteriormente en este capítulo, esta categoría de amenaza normalmente se basa
en la ingeniería social para acceder a los sistemas.
El software antivirus falso, las suites de detección de software espía falsos y los protectores de navegador falsos estaban
de moda durante este período.
Figura 4.19: Detecciones por categoría de amenaza, incluidas puertas traseras, spyware, virus, gusanos
y software diverso potencialmente no deseado por porcentaje de todos los sistemas basados en Windows
que informaron detecciones, 2006–2012 (Microsoft Corporation, nd)
A medida que el uso de software potencialmente no deseado alcanzó su punto máximo en 2006 y más personas se dieron
cuenta de ellos, las detecciones tendieron a la baja en 2007 y 2008. Durante este tiempo, los datos muestran que los
troyanos que descargan y descargan se pusieron de moda. Esto se refleja claramente en la Figura 4.20. Esta categoría
de amenaza también se basa principalmente en la ingeniería social para comprometer inicialmente los sistemas. Engañan
al usuario para que los instale y luego descomprimen o descargan más malware en el sistema para dar a los atacantes un
mayor control. Durante este tiempo, no era raro que los descargadores y lanzadores de troyanos incorporaran los sistemas
de sus víctimas a botnets para usarlos en otros tipos de ataques.
Figura 4.20: Detecciones por categoría de amenaza, incluidas puertas traseras, software espía, virus,
gusanos, software diverso potencialmente no deseado y descargadores y lanzadores de troyanos por
porcentaje de todos los sistemas basados en Windows que informan detecciones, 2006–2012 (Microsoft
Corporation , sin fecha)
Capítulo 4 169
A medida que las personas se dieron cuenta de los trucos sucios que los atacantes estaban usando con los troyanos
que descargan y descargan, y las empresas de antivirus se enfocan en erradicar esta categoría popular de malware, los
datos muestran que la popularidad de los descargadores y descargadores está disminuyendo, mientras que las
detecciones de varios troyanos alcanzaron su punto máximo en 2008 y nuevamente en 2009. Esta categoría de
amenaza también depende principalmente de la ingeniería social para tener éxito. Los datos también nos muestran que
hubo un aumento significativo en la detección de ladrones de contraseñas y herramientas de monitoreo entre 2007 y 2011.
Hubo un resurgimiento en la popularidad de los gusanos en 2008, cuando Conficker mostró a los atacantes lo que era
posible al combinar tres de los sospechosos habituales de ciberseguridad en un solo gusano.
Desde entonces, los gusanos que se basan en vulnerabilidades sin parches, el abuso de funciones de ejecución
automática (ingeniería social ) y contraseñas débiles, filtradas y robadas han seguido siendo populares. En la Figura
4.21, observe el aumento lento pero constante de los exploits a partir de 2009. Esta tendencia alcanzó su punto máximo
en 2012, cuando los kits de exploits estaban de moda en Internet. Además, tenga en cuenta que no hay un volumen
significativo de ransomware durante todo este período. Al salir de este período a fines de 2012, las categorías en la
esquina superior derecha del gráfico, troyanos y software potencialmente no deseado, dependen de la ingeniería social
para tener éxito.
Figura 4.21: Detecciones por categoría de amenaza, todas las categorías, por porcentaje de todos los sistemas
basados en Windows que informaron detecciones, 2006–2012 (Microsoft Corporation, sin fecha)
A principios de 2013, Microsoft comenzó a usar ER para medir las detecciones de amenazas. Tenga en cuenta que la
medida utilizada entre 2013 y 2017 es ER frente a la medida de detecciones utilizada en el período anterior. Estos son
puntos de datos ligeramente diferentes. Microsoft no publicó datos de ER en el tercer y cuarto trimestre de 2016, por lo
que hay un agujero en los datos de este período. Los datos de ER confirman que los troyanos misceláneos fueron la
categoría de amenazas encontrada con más frecuencia en 2013. Desafortunadamente, no pude encontrar una fuente
de datos publicada para ER de software potencialmente no deseado, por lo que falta en la Figura 4.22.
El pico de ER para descargadores y droppers de troyanos en la segunda mitad de 2013 se debió a tres amenazas:
Rotbrow, Brantall y Sefnit (Microsoft, 2014).
Al final de este período, en el cuarto trimestre de 2017, el ransomware tenía una ER del 0,13 %, mientras que los
troyanos diversos tenían una ER del 10,10 %, lo que significa que los troyanos diversos se encontraron 78 veces
más a menudo que el ransomware. Discutiré el motivo de esta diferencia más adelante en el capítulo cuando
profundice en el ransomware. Tenga en cuenta que aunque el ransomware tiene un ER bajo, el impacto de una
infección de ransomware puede ser devastador. Por lo tanto, no olvide mirar ambas partes de un cálculo de riesgo,
es decir, la probabilidad y el impacto de las amenazas. Esta es una tendencia que continúa en el último trimestre
de 2019. Parece que las inversiones que Microsoft hizo en las características de seguridad de la memoria y otras
mitigaciones en los sistemas operativos Windows ayudaron a reducir la ER global, a pesar de la creciente cantidad
de divulgaciones de vulnerabilidades en Windows. Si ER es un indicador, la única táctica de la que los proveedores
de malware parecen obtener un sólido retorno de la inversión (ROI) es la ingeniería social.
Figura 4.22: Tasas de encuentro por categoría de amenaza en sistemas basados en Windows que informan
detecciones, 2013–2017 (Microsoft Corporation, sin fecha)
La gran mayoría de los datos que acabo de explicar provienen de sistemas de consumidores de todo el mundo
que han informado datos a Microsoft. Existen algunas diferencias entre la prevalencia de las amenazas en los
sistemas de los consumidores y en las empresas que los equipos de seguridad y los expertos en ciberseguridad
deben conocer. Después de estudiar estas diferencias durante muchos años, puedo resumirlas . Tres ideas útiles
de los datos informados a Microsoft desde entornos empresariales son:
• Gusanos: por lo general, esta era la categoría número uno de amenazas en entornos empresariales que se
informaron a Microsoft a lo largo de los años. Esta categoría de malware se autopropaga, lo que significa
que los gusanos pueden propagarse rápidamente y ser muy difíciles de eliminar una vez que están dentro
de un entorno empresarial. Los gusanos pueden ocultarse en entornos de TI empresariales y reaparecer
rápidamente. Por ejemplo, pueden ocultarse en redes de área de almacenamiento donde no se ha
implementado ningún software antivirus .
Capítulo 4 171
• Pueden ocultarse en imágenes antiguas de escritorios y servidores que, cuando se utilizan para construir nuevos
sistemas, reintroducen gusanos en el entorno. También se pueden resucitar de las copias de seguridad
cuando se restauran. Muchos CISO que conozco lucharon contra gusanos como Conficker durante años
después de su introducción inicial en sus entornos. Estos gusanos generalmente se propagan de tres formas:
vulnerabilidades sin parches, contraseñas débiles e ingeniería social. ¿Suena familiar?
Deberían porque estos son tres de los cinco sospechosos habituales de ciberseguridad. Centrarse en los
fundamentos de la ciberseguridad lo ayudará a mantener alejados a los gusanos y contener a los que ya están
dentro de su entorno. Es importante implementar antimalware actualizado en todas partes para detener estas
amenazas.
• Unidades USB y otros medios de almacenamiento extraíbles: muchas amenazas, como gusanos y virus, se
introducen en los entornos empresariales en las unidades USB. La implementación de políticas que bloqueen
el acceso al puerto USB en equipos de escritorio y servidores evitará que los trabajadores de la información
introduzcan este tipo de amenazas en su entorno de TI. La configuración del software antimalware para
escanear archivos al acceder, especialmente para medios extraíbles, también ayudará a bloquear estas
amenazas, muchas de las cuales son antiguas y bien conocidas por los laboratorios antimalware.
• Sitios web maliciosos o comprometidos: los ataques de descarga oculta y los ataques de abrevadero exponen los
sistemas de los trabajadores de la información a vulnerabilidades y, si tienen éxito, a malware. Piense
detenidamente si su organización realmente necesita una política que permita a los trabajadores de la
información navegar por Internet sin restricciones. ¿Todos los miembros de la organización necesitan acceder
a todos los dominios de Internet, incluso a las direcciones IP de los países que tienen las tasas de infección
de malware más altas del mundo de forma consistente? Permitir que los trabajadores solo accedan a sitios
confiables que tienen un propósito comercial puede no ser una política popular entre ellos, pero reducirá
drásticamente la cantidad de amenazas potenciales a las que están expuestos.
Esta mitigación no funcionará para todas las organizaciones debido a la naturaleza de su negocio, pero me atrevo a
decir que funcionará para muchas más organizaciones que las que actualmente la usan.
Piense si el acceso sin restricciones a Internet y la visita a sitios con contenido en idiomas extranjeros es realmente
necesario para su personal, así como si el equipo de seguridad puede realizar algunos cambios que tengan un alto
valor de mitigación y un impacto bajo o nulo en la productividad. Las reglas de proxy de salida administradas, IDS/IPS
y las listas blancas del navegador son controles que pueden ayudar.
Y por supuesto, ¡parche, parche, parche! Los ataques de descargas no autorizadas no funcionan cuando las
vulnerabilidades subyacentes en las que se basan están parcheadas. Aquí es donde las organizaciones que parchean
una vez por trimestre o una vez por la mitad realmente sufren; permiten que sus empleados vayan a todas partes en
Internet con sistemas que saben que tienen cientos o miles de vulnerabilidades conocidas públicamente.
¿Qué podría salir mal?

Ahora que ha visto la tendencia histórica a largo plazo y comprende cómo los atacantes evolucionaron sus
ataques con el tiempo, es posible que se pregunte qué ha estado sucediendo con el malware más recientemente.
Microsoft ofrece una vista de sus datos antimalware de los últimos 30 días en esta página: https://
www.microsoft.com/enus/wdsi/threats. Le permite observar las principales amenazas globales, así como profundizar
en las principales amenazas regionales. También le brinda una vista de cuántos sistemas han encontrado malware
en todo el mundo y por país. En el momento de redactar este informe (mediados de agosto de 2022), el sitio indicaba
que había 79 388 601 dispositivos con encuentros en todo el mundo en los últimos 30 días (Microsoft Corporation,
sin fecha). Las principales amenazas detectadas en estos encuentros incluyeron algunas herramientas que usan
los piratas informáticos y los piratas informáticos, así como un troyano (Microsoft Corporation, sin fecha):
• HackTool:Win32/AutoKMS
• HackTool:Win64/AutoKMS
• HackTool:Win32/Keygen
• Troyano:Win32/Wacatac.B!ml
• HackTool:MSIL/AutoKms
Observar las principales amenazas en los diferentes países que le interesan le mostrará cuán diferentes son las
amenazas regionales y qué amenazas tienen en común. Vale la pena analizar estos datos para asegurarse de que
su equipo de seguridad esté al tanto de las principales amenazas presentes en los lugares donde su organización
tiene presencia, así como también donde tiene clientes y socios.
Conclusiones de la evolución global del malware

Estos datos de categoría de malware nos muestran que los proveedores de malware realmente están limitados a
solo unas pocas opciones cuando intentan comprometer inicialmente los sistemas. Explotar vulnerabilidades sin
parchear es un método confiable solo por períodos de tiempo limitados, pero esto no impide que los atacantes
intenten explotar vulnerabilidades antiguas durante años después de que haya una actualización de seguridad
disponible. Los gusanos se ponen y pasan de moda con los atacantes y requieren habilidades técnicas para
desarrollarse. Pero la única táctica que es una táctica principal es la ingeniería social. Cuando los otros cuatro
sospechosos habituales de ciberseguridad no son opciones viables, muchos atacantes intentarán utilizar la buena ingeniería social a la a
A pesar de todos los datos de malware que acabo de compartir con usted, algunos expertos en ciberseguridad aún
afirman que el software antimalware no vale la pena para las empresas. Profundicemos en este argumento para ver
si tiene validez. Pero primero, echemos un vistazo más de cerca a cómo ha evolucionado el ransomware.
Capítulo 4 173
La evolución del ransomware

Secuestro de datos. La sola palabra infunde miedo en los CISO, equipos de seguridad y líderes empresariales
en todas partes. Un encuentro con ransomware podría ser un evento de extinción para muchas organizaciones,
particularmente aquellas que no se han preparado adecuadamente para tal encuentro. La idea de que los datos
críticos se cifren o destruyan y la necesidad de pagar un elevado rescate para que los delincuentes vuelvan a
tener acceso a los datos no es la forma en que los equipos de seguridad o las empresas a las que brindan apoyo
normalmente quieren pasar su tiempo.
La Figura 4.22 ilustra que la ER para ransomware fue típicamente la más baja de cualquier categoría de malware
durante un período de años. La Figura 4.23 nos muestra que el ER para ransomware fue una fracción del 1 %
trimestre tras trimestre entre 2014 y 2016. ¿Fue solo un período lento para los proveedores de ransomware?
¿Qué pasa con algunos de los titulares que he visto a lo largo de los años, como “Aumento del 1000 % en
ransomware”? Este titular podría ser cierto porque un aumento del 1000% en un número pequeño sigue siendo
un número relativamente pequeño en este contexto. Por ejemplo, un aumento del 1000 % de una ER del 0,1 % es del 1,1 %.
Figura 4.23: Ransomware ER entre el tercer trimestre de 2014 y el cuarto trimestre de 2017
En comparación con otras categorías de malware, la categoría clásica de ransomware se detecta en relativamente
pocos sistemas. La Figura 4.24 revela esto al comparar la ER de troyanos y gusanos con la de ransomware
durante ocho trimestres entre 2014 y 2016.
Durante el trimestre donde el ransomware tuvo su mayor ER durante este período, el cuarto trimestre de
2014, el ER de troyanos y gusanos fue 18 veces y 17 veces mayor que el ransomware, respectivamente.
Figura 4.24: ER para ransomware, gusanos y troyanos entre el tercer trimestre de 2014 y el
cuarto trimestre de 2017 (Microsoft Corporation, sin fecha)
¿Podría haber cambiado esta tendencia en períodos de tiempo más recientes, o una fuente de datos diferente
pintaría una imagen diferente? Vamos a revisar. La tabla 4.10 contiene datos del Informe de seguridad de AVTest
2018/19 (AVTest Institute, abril de 2019) que comparan el porcentaje de nuevos troyanos desarrollados para
Windows con el porcentaje de nuevo ransomware desarrollado para Windows en función de las muestras que
recopila AVTest. Estos datos indican que el nuevo ransomware recopilado en enero de 2018, agosto de 2018 y
marzo de 2019 fue una fracción de un porcentaje, mientras que los nuevos troyanos constituyeron la mayoría del nuevo malware.
Tabla 4.10: Nuevos troyanos y nuevo ransomware desarrollados para Windows como porcentaje
de todo el nuevo malware desarrollado para Windows en enero de 2018, agosto de 2018 y marzo
de 2019 (AVTest Institute, abril de 2019)
Capítulo 4 175
Si todavía eres escéptico, no te culpo. Una vez que las historias de ransomware comenzaron a aparecer en las
noticias de la noche en las principales cadenas de televisión y en los medios de comunicación en línea, fue fácil
concluir que el ransomware se había convertido en una amenaza muy frecuente. Revisemos una fuente de datos
creíble más y por un período de tiempo ligeramente diferente.
El Informe de amenazas de McAfee Labs 06.21 proporciona la cantidad de muestras únicas de malware que
recopilaron durante períodos trimestrales. En promedio, en los siete trimestres entre el 3.er trimestre de 2019 y el
1.er trimestre de 2021, McAfee recopiló más de 71 millones de nuevas muestras de malware por trimestre.
La figura 4.25 revela que, de estas decenas de millones de muestras de malware, la mayor proporción de nuevas
muestras de ransomware en cualquier trimestre fue del 6,03 % en el cuarto trimestre de 2020 y cada uno de los
otros trimestres estuvo por debajo del 4 % (McAfee Labs, junio de 2021).
Figura 4.25: Nuevas muestras de ransomware como porcentaje del total de nuevas muestras de malware
entre el tercer trimestre de 2019 y el primer trimestre de 2021 (McAfee Labs, junio de 2021)
Podríamos examinar incluso más datos de otras fuentes confiables que respalden la idea de que la categoría clásica
de malware llamada ransomware no es tan frecuente como otras categorías de malware. Sin embargo, creo que la
explicación de por qué este es el caso es sencilla, y no serán necesarios más datos una vez que quede claro.
Recuerde que el ransomware es una categoría de malware que se acuñó por primera vez a mediados de la década de 1980.
Además de un par de categorías de malware que son capaces de autopropagarse como gusanos y virus, otras
categorías de malware generalmente deben depender de humanos y otro malware para propagarse. El software
de rescate no es una excepción. Como mencioné anteriormente, los troyanos han sido la categoría de malware de
mayor volumen durante mucho tiempo. Esto se debe a que, en general, los troyanos tienen más éxito a la hora de
ofrecer un compromiso inicial a los atacantes que otras categorías de amenazas.
Los troyanos se basan en la ingeniería social para propagarse y su desarrollo puede resultar menos complicado
técnicamente que los gusanos o los virus, con algunas excepciones. Una vez que los atacantes han comprometido
inicialmente un sistema mediante un troyano, normalmente desempaquetan o descargan más malware en el
sistema que les permite seguir adelante con sus objetivos. Si su objetivo es el beneficio, la destrucción o la
anarquía, la implementación de ransomware podría ser la segunda etapa o la carga útil de su ataque.
¿Qué sucede cuando el intento de compromiso inicial no tiene éxito? Es decir, cuando el troyano no tiene éxito
porque es detectado y bloqueado por un software antimalware, la segunda etapa del ataque que involucra
ransomware no tiene oportunidad de ejecutarse. Cuando usamos fuentes de datos CTI, como el software
antimalware, los datos normalmente contendrán los encuentros de malware para los troyanos, pero no el
ransomware porque nunca se encontró el ransomware. El ataque se detuvo antes de que el troyano descomprimiera
o descargara el ransomware en el sistema. Esta es otra razón por la cual el malware de primera etapa, como los
troyanos, es mucho más frecuente que el malware de segunda etapa, como el ransomware.
Los datos de AVTest, basados en la cantidad de muestras de malware de ransomware que recopilan, brindan una
idea de cuántos troyanos únicos se desarrollan en comparación con otros ransomware.
El ransomware suele ser una fracción del 1% de todas las muestras de malware que recopilan, mientras que los
troyanos constituyen la mayoría en cada trimestre. Estos datos sugieren que los atacantes desarrollan y emplean
constantemente troyanos mucho más que ransomware.
Si el ransomware realmente es mucho menos frecuente que otras categorías de malware, ¿por qué se lo considera
una amenaza tan grave? Recuerde que el riesgo es la combinación de probabilidad e impacto. No creo haber visto
eventos de extinción anunciados para organizaciones después de que se hayan encontrado con troyanos, a pesar
de lo frecuentes que han sido. Por otro lado, la probabilidad de encontrar software de rescate puede ser baja, pero
el impacto podría ser muy alto. Las amenazas de alto riesgo, como el ransomware, suelen merecer una atención
adicional por parte de los equipos de seguridad porque sus estrategias para mitigar amenazas como esta no
deberían ser esperanzadoras: juegan con las probabilidades de que sus organizaciones simplemente no las encuentren.
Otra razón por la que los equipos de seguridad deben prestar más atención al ransomware ahora que en el pasado
es que en los últimos tres a cinco años, el significado del término ransomware ha cambiado. Esto ha llevado a
cierta confusión en la industria. El término "ransomware" todavía se refiere a la categoría clásica de malware que
se vio por primera vez en la década de 1980. Este es un ransomware con baja prevalencia en relación con otras
categorías de malware. Sin embargo, en los últimos años, este término se ha utilizado de forma rutinaria para
describir cualquier ataque cibernético en el que esté involucrada la extorsión. Esto incluye los mismos tipos de
ataques dirigidos que hemos visto en los últimos 15 años, incluso cuando el ransomware (la categoría de malware) no es
utilizado en absoluto. Ransomware es ahora la etiqueta utilizada para ataques DDoS donde los atacantes exigen un rescate.
para prevenir o detener un ataque. No hay malware ransomware involucrado en estos ataques DDoS.
Capítulo 4 177
En mi opinión, etiquetar todos estos diferentes tipos de ataques como "ransomware" no es útil. Confunde las
conversaciones entre los CISO, los equipos de seguridad, sus partes interesadas, los proveedores de ciberseguridad
e incluso las agencias gubernamentales que brindan orientación sobre ciberseguridad. He estado en muchas
reuniones en las que una persona habla sobre la categoría clásica de malware mientras que los demás hablan sobre
ataques dirigidos a la educación en los que se roban datos confidenciales y los atacantes amenazan con divulgarlos públicamente.
Mientras tanto, las formas en que necesitan protegerse, detectar, responder y recuperarse pueden ser bastante
diferentes dependiendo de en cuál de estas cosas realmente quieran enfocarse. En tales reuniones, me resultó
útil proporcionar una definición de ransomware a los participantes para que todos en la reunión se refirieran a lo
mismo. Luego, el grupo podría tener una conversación productiva de un solo hilo sobre las amenazas específicas
que tenían en mente.
¿Cómo evolucionó el concepto detrás de una sola categoría de malware impopular para volverse tan turbio y tan
generalizado al mismo tiempo? Al menos parte de la respuesta a esta pregunta radica en la forma en que
evolucionó el malware ransomware. Examinemos algunas de las formas clave en que ha evolucionado el
ransomware, para dar sentido a cómo se usa este término en la actualidad. Hay al menos cinco formas diferentes
en que el ransomware ha evolucionado con el tiempo. Veamos cada uno brevemente.
Mecanismos de entrega
Durante décadas, la categoría clásica de ransomware de malware fue propagada en gran medida por humanos y
otro malware. Antes de la llegada de Internet, los disquetes y las redes de área local eran realmente la única
forma de propagar este tipo de malware. La suerte desempeñó un papel en qué sistemas serían victimizados y
cuáles no porque no había realmente un sistema de entrega dirigido para el malware. En la última década, a
medida que el ransomware se volvió más popular entre los atacantes, se desarrolló más malware combinado que
permitió que el ransomware se propagara más fácilmente, como gusanos que también encriptaban datos a medida
que se autoreplicaban de un sistema a otro. Hoy en día, el ransomware se aprovecha de forma rutinaria en
ataques dirigidos en los que los humanos, con las manos en los teclados, inicialmente comprometen los entornos
de TI de sus víctimas (o compran acceso a un corredor de acceso), se mueven lateralmente, descubren datos y
sistemas valiosos y luego usan ransomware u otras herramientas para negar el acceso a los propietarios legítimos.
Algunos proveedores han llamado a este tipo de ataque "ransomware operado por humanos". Los ataques
dirigidos han sido comunes durante al menos 15 años, pero en lugar de intentar permanecer persistentes y extraer
datos para vender o intercambiar, los atacantes simplemente atacan la yugular de sus víctimas lo más rápido
posible. Esto ha resultado en un cambio en los tiempos de permanencia de los atacantes de varios meses a solo
unas pocas horas; tan pronto como encuentran datos lo suficientemente valiosos como para extorsionar a sus
víctimas, los extraen, los encriptan, los eliminan, etc., después de lo cual no les preocupa si se detecta su presencia.
Para facilitar este patrón de ataque comprimido de "aplastar y agarrar", los atacantes han estado utilizando
herramientas comerciales de emulación de amenazas que aceleran sus ataques, reducen la barrera de entrada
para los atacantes técnicamente menos sofisticados y actúan como un mecanismo de entrega para el ransomware.
”Las suites de Cobalt Strike pirateadas se han convertido en los especiales de los sábados por la noche
del delito cibernético: están ampliamente disponibles en los mercados clandestinos y se pueden
personalizar fácilmente... Como resultado, la mayoría de los casos de ransomware que hemos visto
durante el último año han involucrado el uso de Cobalt Strike Beacons. Si bien muchos operadores de
malware usan puertas traseras asociadas con el marco Metasploit de código abierto, Cobalt Strike
Beacons se ha convertido en la herramienta favorita de los afiliados de ransomware y los corredores de
acceso que venden compromisos a las pandillas de ransomware y, a menudo, se ven vinculados a la
ejecución de ransomware ". – Informe de amenazas de Sophos 2022
Por supuesto, están aquellos que aspiran a recolectar grandes demandas de rescate y no tienen las habilidades
técnicas requeridas para desarrollar herramientas sofisticadas de ransomware y patrones de ataque. Para estas
personas, están disponibles intermediarios de acceso y RansomwareasaService (RaaS) . Los corredores de
acceso son personas que venden los detalles de las redes comprometidas a otros delincuentes. En otras palabras,
tienen conocimiento de las organizaciones que se han visto comprometidas y están dispuestas a vender las "claves"
a los atacantes que las usarán para perseguir sus propias motivaciones, ya sea para obtener ganancias a través de
programas de rescate o cualquier otra cosa. Las pandillas de ransomware desarrollan y proporcionan las
herramientas necesarias para perpetrar ataques y sus afiliados usan esas herramientas para victimizar a las
organizaciones. Bajo este modelo de negocio RaaS , estos dos grupos comparten las ganancias de los ataques
exitosos de ransomware. RaaS no solo reduce la barrera de entrada para los atacantes, sino que también hace que
sea mucho más difícil para los proveedores de Cyber Threat Intelligence (CTI) realizar una atribución sólida. Si
varios grupos de afiliados usan el mismo conjunto de herramientas RaaS, los atacantes son mucho más difíciles de distinguir entre sí (So
Bandas de ransomware como Conti, Revil, Ryuk y otras han desarrollado el modelo RaaS con el tiempo.
Mecanismos de ejecución
El modus operandi de los extorsionadores ha evolucionado con el tiempo. La mayoría de las familias de ransomware
en la categoría clásica de malware cifraron los datos en el almacenamiento adjunto del sistema local o bloquearon
el escritorio antes de solicitar un rescate. Algunos desarrolladores de malware no implementaron correctamente sus
algoritmos de cifrado, lo que permitió a las empresas de seguridad ayudar a las víctimas a descifrar sus datos sin
pagar el rescate a cambio de las claves de descifrado.
Capítulo 4 179
A veces, los mecanismos de descifrado del atacante fallaban, o solo descifraban algunos de los datos, o
tardaban mucho tiempo en descifrarse. Estos fracasos hicieron menos probable que futuras víctimas
pagaran rescates. Con el tiempo, la mayoría de los proveedores de ransomware eliminaron los errores de
sus mecanismos de cifrado y descifrado.
Como mencioné anteriormente, hoy en día, el ransomware operado por humanos se ha vuelto común. Los ataques
de ransomware operados por humanos pueden o no emplear la categoría clásica de ransomware de malware. Es
posible que estos atacantes no opten por cifrar los datos en absoluto. Los atacantes se han dado cuenta de que las
víctimas están dispuestas a pagar por las claves de descifrado, pero muchas de ellas también están dispuestas a
pagar simplemente para recuperar el control de sus datos, ya sea que estén cifrados o no. Por ejemplo, en la nube,
la categoría clásica de ransomware suele tener muchas más dificultades para tener éxito porque los dispositivos
informáticos y de almacenamiento masivo están desacoplados. Es decir, el ransomware clásico requiere
computación para ejecutarse y, por lo general, encripta los dispositivos de almacenamiento conectados localmente.
En la nube, el cómputo puede tomar muchas otras formas, incluyendo sin servidor y AI/ML. El almacenamiento
también puede verse y comportarse de manera diferente en la nube en comparación con la computación tradicional
con almacenamiento conectado localmente. Posteriormente, los atacantes tuvieron que idear otros métodos para
aprovecharse de sus víctimas en la nube. Por ejemplo, después de que los atacantes comprometan inicialmente
una cuenta en la nube y eleven sus privilegios (si es necesario), pueden cambiar las políticas de la cuenta en la
nube para negarle al propietario legítimo el acceso a la cuenta o limitar su acceso a recursos específicos dentro de la cuenta. Luego exig
rescate para restaurar el acceso al propietario de la cuenta. El dueño de la cuenta sabe que el atacante tiene
control de sus datos de manera que les permita exfiltrarlos, eliminarlos, encriptarlos, etc.
Esto crea una sensación de extrema urgencia para la víctima y la voluntad de pagar un rescate para recuperar el
control de la cuenta lo antes posible. Tenga en cuenta que no hubo malware ni encriptación involucrados en este
escenario de ataque; el acceso no autorizado fue el único mecanismo de ejecución utilizado.
Muchas víctimas están dispuestas a pagar a los atacantes para mantener la confidencialidad de sus datos robados después de la exfiltración.
El daño a la marca de una revelación pública de que sufrieron una violación de datos los motiva a pagar tales
demandas de rescate. Nuevamente, no se involucraron mecanismos de cifrado o descifrado. Naciones Unidas
el acceso autorizado y la exfiltración de datos fueron los mecanismos de ejecución utilizados.
Métodos de pago de rescate

Si hay un área de avance que ha impulsado el crecimiento de los ataques que implican extorsión, son los métodos
de pago. Los métodos de pago utilizados por la categoría clásica de malware cambiaron con el tiempo a medida
que aparecieron nuevos métodos para transferir dinero u otros objetos de valor. Al principio, los esquemas que
requerían transferencias bancarias generalmente empleaban "mulas de efectivo", personas contratadas para
ingresar físicamente a un banco para hacer un retiro de efectivo.
Este es un negocio arriesgado ya que la víctima podría decidir no pagar el rescate y, en cambio, asociarse con las
fuerzas del orden para arrestar a la persona que recoge el rescate. Una cosa es desarrollar un programa que cifra las
unidades de disco y exige un rescate para descifrarlas, pero otra muy distinta es entrar físicamente en un banco con
la intención de cometer fraude. Estos son dos tipos diferentes de delincuentes. Los desarrolladores de ransomware
que no tenían el estómago para cometer delitos en el mundo real tenían que asociarse con aquellas personas que sí
lo tenían para tomar posesión físicamente de su rescate. Cuantas más personas estén involucradas en un delito,
mayor será el riesgo de que alguien revele detalles o sea atrapado.
A medida que otros métodos de pago estuvieron disponibles, los desarrolladores de ransomware tuvieron opciones
para los métodos de pago. Las estafas de mensajes SMS premium y las tarjetas de regalo se convirtieron en los
métodos de pago favoritos de muchos proveedores de ransomware. Se obligó a la víctima a enviar un mensaje de
texto a un número de teléfono específico a razón de $20 por mensaje de texto hasta alcanzar el monto del rescate, o
se le pidió a la víctima que enviara por correo una cantidad de tarjetas de regalo con un valor equivalente a la
demanda de rescate. En ambos escenarios, los extorsionadores pudieron cobrar sus rescates manteniendo su
anonimato y sin involucrar mulas de efectivo. Sin embargo, las demandas de rescate tenían un tamaño limitado debido
a las cantidades relativamente pequeñas de efectivo que estos métodos podían transferir.
La innovación que permitió a las pandillas de ransomware aumentar drásticamente sus demandas de rescate en
millones de dólares fueron las criptomonedas. La proliferación de estas herramientas financieras permitió a los
atacantes mantener su anonimato mientras recaudaban millones de dólares en pagos ilícitos.
Las criptomonedas también ayudaron a los atacantes extranjeros a atacar a víctimas internacionales a través de las
fronteras. Por ejemplo, según informes de prensa, en el ataque al Oleoducto Colonial, los atacantes recibieron 75
bitcoins, el equivalente a $4,4 millones en ese momento (Bussewitz, 2021). Por supuesto, a medida que la industria y
los gobiernos desarrollen métodos efectivos para contrarrestar esta tendencia, los métodos de pago de rescate
evolucionarán una vez más.
Demandas de rescate y comunicaciones

Las demandas de rescate y las comunicaciones con las víctimas, los medios y los gobiernos han evolucionado con el
tiempo. Con la categoría clásica de malware, el malware en sí mismo comunicaba la demanda de rescate al usuario
en la pantalla del sistema después de que se infectara y cifrara. Pero a medida que evolucionaron algunos métodos
de pago para permitir cantidades de demanda cada vez mayores, las comunicaciones de las pandillas de ransomware
se volvieron cada vez más descaradas. Las demandas silenciosas de rescate directamente a las víctimas se han
complementado con ejercicios muy públicos de vergüenza de las víctimas que utilizan blogs, páginas web y otros
canales de comunicación pública para persuadir a sus víctimas de que paguen. Los atacantes están apostando a que
las grandes organizaciones que tienen marcas sólidas y obligaciones de cumplimiento regulatorio complicadas están
dispuestas a pagar millones de dólares para recuperar el control de sus datos confidenciales y evitar las consecuencias
financieras, de relaciones públicas, legales y regulatorias de la revelación pública de que han tenido una violación de datos.
Capítulo 4 181
Esto ha llevado al gobierno federal de EE. UU. y a las propias industrias a tratar de estandarizar específicamente
los requisitos de notificación de violaciones de datos y las notificaciones de pago de ransomware. Si existe una
regulación que requiere la divulgación de una violación de datos o el pago de un rescate, esto es un desincentivo
para que las organizaciones de víctimas participen. La luz del sol es el mejor desinfectante.
En el ataque de Colonial Pipeline, la pandilla de ransomware supuestamente envió a sus víctimas una URL a una
"página de fuga personal". Esta página contenía los datos robados de la víctima, que estaban a punto de publicarse
si la demanda de rescate no se pagaba antes de la fecha límite (Russon, 2021).
Rusia fue vista por algunos como cómplice del ataque porque se pensó que los perpetradores, identificados como
la banda de ransomware DarkSide, estaban en Rusia. La pandilla DarkSide tomó la medida extraordinaria de
comunicarse públicamente directamente con el gobierno de los EE. UU. a través de su sitio web, para asegurarles
que el motivo del ataque fue el lucro y no un ataque a la infraestructura crítica como un acto de guerra o una
declaración política. Escribieron en su sitio web: “Nosotros no participamos en la geopolítica, no necesitamos
atarnos con un gobierno definido y buscar… nuestros motivos… Nuestro objetivo es ganar dinero y no crear
problemas para la sociedad…” (Russon, 2021). Presumiblemente, hicieron esto para reducir la tensión política
entre EE. UU. y Rusia a fin de reducir la probabilidad de que fueran perseguidos por las fuerzas del orden en
Rusia. Qué red enredada de hecho.
No solo han cambiado las formas en que los extorsionadores entregan sus demandas de rescate, sino que también
ha cambiado el número y la naturaleza de esas demandas. No contentos con victimizar a las organizaciones solo
una vez, se ha convertido en un enfoque popular para que los atacantes hagan múltiples demandas de rescate
una vez que tienen a una víctima en el anzuelo. Una demanda de rescate para devolver el control de los datos y
la infraestructura a la víctima, otra a cambio de prometer no divulgar públicamente los datos confidenciales de la
víctima, otra a cambio de prometer eliminar los datos extraídos de la víctima, otra a cambio de no vender el acceso
a la infraestructura comprometida de la víctima a otros atacantes, y así sucesivamente. Esta es la razón por la que
tantos expertos en seguridad aconsejan a sus clientes que no paguen dinero ; la única forma de ganar este juego
es no jugar: planee ser violado, prepárese y practique.
modelo de negocio
La evolución de los mecanismos de entrega, los mecanismos de ejecución, los métodos de pago de rescate y las
demandas y comunicaciones de rescate ha permitido a los atacantes cambiar sus modelos comerciales con el
tiempo. En décadas pasadas, antes de que Internet fuera omnipresente, los proveedores de ransomware clásico
confiaban en la suerte para respaldar ataques a muy pequeña escala, generalmente una computadora personal a la vez.
Una vez que Internet se estableció y se hizo muy popular, los atacantes pudieron aprovechar los ataques de
descargas ocultas y los gusanos para escalar sus ataques. Sin embargo, el éxito de los ataques aún dependía en
gran medida de la suerte, ya que no tenían un mecanismo de orientación preciso.
Una vez que los métodos de pago permitieron pagos ilícitos por valor de millones de dólares, los llamados actores
de amenazas persistentes avanzadas (APT, por sus siglas en inglés) , capaces de perpetrar ataques dirigidos con
éxito contra empresas, cambiaron su modus operandi. En lugar de tratar de maximizar sus tiempos de permanencia
para robar información valiosa para vender o intercambiar, ahora simplemente podrían extorsionar a la víctima
directa y rápidamente. En otras palabras, podrían obtener un día de pago mucho más grande mucho más rápido que nunca.
Los avances en la automatización de atacantes, como RaaS y las herramientas comerciales de simulación de ataques,
han bajado el listón de entrada en esta industria criminal y han acelerado su crecimiento.
En las sesiones informativas sobre ransomware que he realizado con los CISO y los equipos de seguridad, en este
punto alguien suele preguntar: "¿Qué significa todo esto?" Lo que realmente están preguntando es cómo la evolución
de ran somware cambia el trabajo de los estrategas, arquitectos y equipos de operaciones de ciberseguridad. Creo
que la respuesta a esta pregunta es sencilla. Defina claramente el ransomware para su organización.
Si su organización está mitigando el ransomware como si fuera solo una categoría de malware, entonces
tendrá brechas enormes en su estrategia. Los equipos de seguridad que tratan el ransomware como si fuera
una categoría de malware suelen emplear una estrategia de seguridad cibernética que llamo la estrategia de
"Proteger y recuperar" que se enfoca en evitar que el ransomware se propague en su entorno de TI y luego
restaurar desde las copias de seguridad cuando falla. Cubriré esta estrategia, así como muchas otras, en el
Capítulo 9, Estrategias de ciberseguridad. Existen mejores estrategias para mitigar las amenazas modernas,
como el ransomware operado por humanos: ataques dirigidos en los que se involucra la extorsión.
La clave para diseñar una estrategia de mitigación efectiva para el ransomware es definirla primero para que toda la
comunidad de interesados, incluido el CISO, el equipo de seguridad, el liderazgo de TI, los profesionales de TI, las
partes interesadas comerciales y todos los proveedores de los que obtiene capacidades de TI y ciberseguridad, aclare
cualquier confusión sobre cuál es esta amenaza para su organización. Por ejemplo, así definí ransomware en 2016 en
el blog de seguridad de Microsoft:
"El ransomware es un tipo de malware que retiene computadoras o archivos para pedir un rescate
mediante el cifrado de archivos o el bloqueo del escritorio o el navegador en sistemas que están
infectados con él, y luego exige un rescate para recuperar el acceso". – Tim Lluvias, 2016
Esta definición sigue siendo precisa, pero como he discutido en esta sección, el término ransomware también se usa
de diferentes maneras hoy, años después. Para asegurarse de que todos en su organización tengan una comprensión
compartida de una amenaza de alto riesgo en la que planea gastar el presupuesto y los recursos para mitigarla,
simplemente defínala para todos.

Capítulo 4 183
Hoy, después de años de evolución del ransomware en las formas que mencioné, si tuviera que volver a escribir
esa publicación de blog, definiría el ransomware como un modelo comercial extorsionista que puede emplear
una variedad de tácticas, técnicas y procedimientos para negar a las víctimas el acceso a sus datos valiosos,
infraestructura de TI o servicios hasta que cumplan con las demandas de rescate de los atacantes . Esto podría
o no implicar el uso de la categoría clásica de ransomware de malware o cifrado en general. Independientemente
de si planea mitigar la categoría de ransomware de malware, los ataques dirigidos que involucran extorsión en
general, o ambos, el compromiso inicial siempre utilizará uno o más de los sospechosos habituales de seguridad
cibernética que analicé en detalle en el Capítulo 1 .
Una vez que se ha definido la amenaza, su estrategia, arquitectura, CIRT, CSOC y equipos de TI pueden
abordarla con la perspectiva adecuada en mente. Para la mayoría de las organizaciones, una "estrategia de
ransomware" es idéntica a una estrategia de ciberseguridad empresarial integral. Dicho de otra manera, una
estrategia de software de rescate no es más limitada que una estrategia que busca mitigar todos los ataques
dirigidos. Después de todo, en el léxico moderno, el ransomware es cualquier ataque que involucra extorsión.
No lo aborde como si fuera solo malware porque puede ser mucho más sofisticado con muchas partes móviles
que las soluciones antimalware y las copias de seguridad por sí mismas no pueden detener.
El gran debate: ¿realmente valen la pena las soluciones

antimalware?
A lo largo de los años, he escuchado a algunos expertos en seguridad cibernética en conferencias de la industria ridiculizar la eficacia
de soluciones antimalware y recomendar que las organizaciones no se molesten en usar dichas soluciones.
Tienden a justificar este punto de vista señalando que el software antimalware no puede detectar y limpiar todas
las amenazas. Esto es cierto. También señalan que las soluciones antimalware pueden tener vulnerabilidades
en sí mismas que pueden aumentar el área de superficie de ataque en lugar de reducirla. Esto también es
cierto. Dado que el software antimalware generalmente tiene acceso a partes sensibles de los sistemas
operativos y los datos que analizan, pueden ser un objetivo eficaz para los atacantes. Algunos proveedores de
antimalware incluso han sido acusados de utilizar el acceso privilegiado a los sistemas que tienen sus productos
para proporcionar acceso ilícito a los sistemas (Solon, 2017). Otros proveedores han sido acusados de compartir
indebidamente la información recopilada por sus productos (Krebs on Security, 2017).
Pero recuerde que los proveedores de malware producen millones de amenazas de malware únicas por
semana. A medida que los laboratorios antimalware de todo el mundo obtienen muestras de estas amenazas,
las inoculan a sus clientes. Por lo tanto, si bien las soluciones antimalware no pueden proteger a las
organizaciones de todas las amenazas, especialmente de las amenazas nuevas y emergentes, pueden
protegerlas de cientos de millones de amenazas conocidas. Por otro lado, si no ejecutan una solución
antimalware, no estarán protegidos contra ninguna de estas amenazas.
Realice el cálculo de riesgo utilizando datos recientes y creo que verá que ejecutar un software antimalware es una
obviedad. Para las empresas, no ejecutar un software antimalware actualizado de un proveedor confiable es una
negligencia grave.
No todos los productos antimalware son iguales. En mi experiencia, los proveedores de antimalware son tan buenos
como los investigadores, analistas y personal de soporte en sus laboratorios de investigación y respuesta. Los
proveedores que minimizan los falsos positivos al tiempo que brindan los mejores tiempos de respuesta y detecciones
para amenazas del mundo real pueden ser muy útiles para los equipos de seguridad. Para comparar productos en
estas medidas, consulte los resultados de las pruebas de terceros de AVTest y AV Comparatives. Ha habido
discusiones en la comunidad de laboratorios antimalware durante décadas sobre la mejor manera de probar sus productos.
En el pasado, el debate se centró en cómo los resultados de las pruebas pueden sesgarse en función de la
recopilación de muestras de malware con las que se prueban los productos. Por ejemplo, si un laboratorio en
particular es realmente bueno en la detección de rootkits y las pruebas incluyen más muestras de rootkits, entonces
ese producto antimalware podría obtener una puntuación mejor que el promedio, incluso si está por debajo del
promedio en la detección de otras categorías de amenazas. Lo contrario también es cierto: si la prueba no incluye
rootkits o incluye muy pocos rootkits, el producto podría obtener una puntuación más baja que el promedio. Dado
que las pruebas antimalware no pueden incluir todas las muestras de malware conocidas debido a las limitaciones
de recursos del mundo real, las muestras que prueben influirán en la puntuación de los productos probados.
Algunos laboratorios antimalware han argumentado que esto les obliga a mantener las detecciones de amenazas
más antiguas que ya no prevalecen en sus productos, en lugar de permitirles centrarse en las amenazas actuales
y emergentes que es más probable que encuentren sus clientes. El contraargumento es que las soluciones
antimalware deberían poder detectar todas las amenazas, independientemente de su prevalencia actual. Las
pruebas y la industria continúan evolucionando con mejores pruebas, más competidores y enfoques novedosos
para detectar, bloquear y desinfectar amenazas. Muchos proveedores han evolucionado sus productos mucho
más allá de los simples sistemas de detección basados en firmas al aprovechar la heurística, el análisis de
comportamiento, la IA, el ML y la computación en la nube, entre otros métodos. Detección y respuesta de puntos finales (EDR) y detecc
Las herramientas (XDR) prometen llevar las soluciones antimalware al siguiente nivel.
Recuerde, usted no quiere ser el que tenga que explicarle al Csuite, a la junta directiva y a los accionistas que la razón
por la que un ataque de ransomware tuvo éxito es que eligió no ejecutar una solución antimalware porque no son
perfectos.
Esto concluye mi discusión maratónica sobre malware, soluciones antimalware, el panorama global de amenazas de
Windows y ransomware. Siento que solo he arañado la superficie aquí, ¡pero tenemos muchos otros temas interesantes
para discutir! Recuerde las prácticas recomendadas y los consejos sobre lo que hace una buena CTI que compartí en
el Capítulo 2, Lo que debe saber sobre la inteligencia de amenazas, cuando consuma inteligencia de amenazas en el
futuro.
Capítulo 4 185
Resumen
Este capítulo requirió mucha investigación. Traté de brindarle una visión única a largo plazo del panorama de amenazas y un contexto
útil. Ahora intentaré resumir los puntos clave de este capítulo.
El malware utiliza los sospechosos habituales de ciberseguridad para comprometer inicialmente los sistemas; estos sospechosos
habituales son vulnerabilidades sin parches, malas configuraciones de seguridad, contraseñas débiles, filtradas y robadas, amenazas
internas e ingeniería social. De estos, la ingeniería social es la táctica favorita de los atacantes, como lo demuestra la prevalencia
constante de categorías de malware que la aprovechan. El malware también se puede emplear después del compromiso inicial para
otros objetivos de los atacantes.
Algunas familias de malware exitosas impactan en los sistemas de todo el mundo rápidamente después de su lanzamiento, mientras
que otras comienzan como amenazas regionales antes de convertirse en amenazas globales. Algunas amenazas permanecen
localizadas en una región porque dependen de un idioma específico que no sea el inglés para engañar a los usuarios para que las instalen.
Las regiones tienen diferentes tasas de detección e infección de malware. La investigación realizada por Microsoft indica que algunos
factores socioeconómicos, como el PIB, podrían estar influyendo en estas diferencias.
Las regiones con niveles inusualmente altos de conflicto y las condiciones socioeconómicas que lo acompañan suelen tener tasas
más altas de detección e infección de malware.
Centrarse en los fundamentos de la ciberseguridad, que abordan los sospechosos habituales de la ciberseguridad, ayudará a mitigar
las amenazas de malware. Además, ejecutar soluciones antimalware actualizadas de un proveedor de confianza ayudará a bloquear
la instalación de la mayoría de los malware y desinfectar los sistemas que se infecten. Bloquear el acceso de los trabajadores de la
información a regiones de Internet que no tienen fines comerciales legítimos puede ayudar a prevenir la exposición a malware y
sistemas comprometidos en estas regiones.
Ransomware ha evolucionado con el tiempo, y ahora este término significa diferentes cosas para diferentes personas.
Asegurarse de que su organización tenga una comprensión compartida de lo que es el ransomware moderno ayudará a alinear las
estrategias y los recursos necesarios para mitigarlo. Una estrategia eficaz de ransomware es lo mismo que una estrategia de
ciberseguridad empresarial integral diseñada para mitigar los ataques dirigidos.
Hasta ahora, hemos examinado las tendencias a largo plazo de vulnerabilidades y malware. En el próximo capítulo, exploraremos
las formas en que los atacantes han estado usando Internet y cómo estos métodos han
evolucionado con el tiempo.
Referencias
• Aljazeera (4 de enero de 2014). El gobierno de Irak pierde el control de Faluya. Obtenido de Alja zeera.com:
https://www.aljazeera.com/news/middleeast/2014/01/iraqgovernment
losescontrolfaluya20141414625597514.html
• Autoridad, RO (2019). Evaluación anual de seguridad cibernética de la Autoridad del Sistema de Información de Estonia
ment 2019. Autoridad del Sistema de Información de la República de Estonia.
• Instituto AVTest (2017). Informe de seguridad de AVTEST 2016/2017. Magdeburgo, Alemania:

Instituto AVTest
• Instituto AVTest (2018). Informe de seguridad de AVTEST 2017/2018. Magdeburgo, Alemania:

Instituto AVTest
• Instituto AVTest (abril 2019). El Informe de seguridad de AVTEST 2018/2019. Magdeburg, Alemania : AVTest
Institute. Obtenido de AVTest: https://www.avtest.org/fileadmin/
pdf/informe_de_seguridad/AVTEST_Informe_de_seguridad_20182019.pdf
• Instituto AVTest (abril 2019). El Informe de seguridad de AVTEST 2019/2020. Magdeburg, Alemania : AVTest
Institute. Obtenido de AVTest: https://www.avtest.org/fileadmin/
pdf/informe_de_seguridad/AVTEST_Informe_de_seguridad_20192020.pdf
• Instituto AVTest (abril de 2020). Sobre el Instituto AVTEST. Obtenido de AVTest:

https://www.avtest.org/en/abouttheinstitute/
• Instituto AVTest (nd). Estadísticas de malware de AVTest. Obtenido de AVTest: https://www.
avtest.org/en/statistics/malware/
• Instituto AVTest (julio 2022). Malware total de prueba AV. Obtenido de AVTest: https://
www.avtest.org/en/statistics/malware/
• Instituto AVTest (abril de 2020). Presencia Internacional y Publicaciones. Obtenido

de AVTest Institute: https://www.avtest.org/en/abouttheinstitute/publications/
• David Burt, PN (2014). La paradoja del riesgo de ciberseguridad, edición especial del informe de
inteligencia de seguridad de Microsoft . Microsoft. Obtenido de: https://query.prod.cms.rt.microsoft.
com/cms/api/am/binary/REVroz
• David Ladd, FS (2011). El informe de progreso de SDL. Microsoft. Obtenido de: http://
download.microsoft.com/download/c/e/f/cefb7bf3de0c4dcb995ac1c69659bf49/
sdlprogressreport.pdf
• Ece Toksabay (22 de febrero de 2014). La policía lanza gases lacrimógenos en una protesta antigubernamental
en Estambul. Obtenido de Reuters: https://www.reuters.com/article/usturkeyprotest/police
fuegogaslacrimógenoatistanbulantigobiernoprotestaidUSBREA1L0UV20140222
Capítulo 4 187
• Keizer, G. (4 de enero de 2020). Números de Windows: Windows 10 reanuda la marcha hacia un

dominio sin fin. Obtenido de Computerworld Reino Unido: https://www.computerworld.com/
article/3199373/windowsbythenumberswindows10continúacanibalizando
windows7.html
• Krebs on Security (17 de agosto de 2017). Emisiones de carbono: el error de compartir demasiado vuelve a
poner al proveedor de seguridad en el centro de atención. Obtenido de Krebs on Security: https://krebsonsecurity.

com/2017/08/carbonemissionsoversharingbugputssecurityvendorbackin
destacar/
• Leyden, J. (nd). Microsoft lanza la herramienta de limpieza Blaster. Obtenido de El Registro: https://
www.theregister.co.uk/2004/01/07/microsoft_releases_blaster_cleanup_tool/
• Microsoft (2014). Informe de inteligencia de seguridad de Microsoft Volumen 16. Obtenido de
Informe de inteligencia de seguridad de Microsoft Volumen 16: https://go.microsoft.com/fwlink/p/?linkid
=2036139&clcid=0x409&culture=enus&country=us
• Microsoft (14 de diciembre de 2016). Informe de inteligencia de seguridad de Microsoft Volumen 21. Obtenido
de Informe de inteligencia de seguridad de Microsoft Volumen 21: https://go.microsoft.com/
fwlink/p/?linkid=2036108&clcid=0x409&culture=enus&country=us
• Microsoft Corporation (8 de abril de 2019). Informe de inteligencia de seguridad de Microsoft Volumen 6.
Obtenido de Informe de inteligencia de seguridad de Microsoft Volumen 6: https://go.microsoft.
com/fwlink/p/?linkid=2036319&clcid=0x409&culture=enus&country=us
• Microsoft Corporation (7 de julio de 2016). Informe de inteligencia de seguridad de Microsoft Volumen 20.
Obtenido de Informe de inteligencia de seguridad de Microsoft Volumen 20: https://go.microsoft.
• Microsoft Corporation (17 de agosto de 2017). Informe de inteligencia de seguridad de Microsoft Volumen 22.
Obtenido del Volumen 22 del informe de inteligencia de seguridad de Microsoft: https://go.microsoft.
• Corporación Microsoft (2018). Informe de inteligencia de seguridad de Microsoft Volumen 23. Obtenido de
Informe de inteligencia de seguridad de Microsoft Volumen 23: https://go.microsoft.com/
fwlink/p/?linkid=2073690&clcid=0x409&culture=enus&country=us
• Microsoft Corporation (10 de agosto de 2019). Programas de colaboración de la industria. Obtenido de Microsoft:
https://docs.microsoft.com/enus/windows/security/threat
protección/inteligencia/ciberseguridadindustriasocios
• Microsoft Corporation (13 de agosto de 2019). Parche nuevas vulnerabilidades de gusanos en Servicios de
escritorio remoto (CVE20191181/1182). Obtenido del blog del Centro de respuestas de seguridad de
Microsoft: https://msrcblog.microsoft.com/2019/08/13/patchnewwormable vulnerabilitiesinremotedesktop

servicescve201911811182/
• Corporación Microsoft (nd). Descripción de Diplugem. Obtenido de Microsoft Security

Intel Ligence: https://www.microsoft.com/enus/wdsi/threats/malwareencyclopediade
scription?Name=BrowserModifier%3aWin32%2fDiplugem
• Microsoft Corporation (11 de enero de 2022). Vulnerabilidad de ejecución remota de código de pila de
protocolo HTTP (CVE202221907). Obtenido del Centro de respuestas de seguridad de Microsoft https://
msrc.microsoft.com/updateguide/vulnerability/CVE202221907
• Corporación Microsoft (nd). Acceso directo. Obtenido de Microsoft Corporation: https://

docs.microsoft.com/enus/windowsserver/remote/remoteaccess/directaccess/
acceso directo
• Corporación Microsoft (nd). Cómo identifica Microsoft el malware y las aplicaciones

potencialmente no deseadas. Obtenido de Microsoft Corporation: https://
docs.microsoft.com/en us/windows/security/threatprotection/intelligence/criteria
• Corporación Microsoft (nd). Tasas de encuentro de malware. Obtenido de Seguridad de Microsoft
Informe de inteligencia: https://www.microsoft.com/securityinsights/Malware
• Corporación Microsoft (nd). Informe de inteligencia de seguridad de Microsoft. Obtenido

de Mic rosoft Security: https://www.microsoft.com/enus/security/business/security
informe de inteligencia
• Corporación Microsoft (nd). Más de una década de informes sobre el panorama de las amenazas.
Obtenido de Microsoft Corporation: https://www.microsoft.com/enus/security/operations/
informe de inteligencia de seguridad
• Corporación Microsoft (nd). Descripción de Petia. Obtenido de Microsoft Security Intel

Ligence: https://www.microsoft.com/enus/wdsi/threats/malwareencyclopedia
description?Name=Ransom:DOS/Petya.A&threatId=2147257025
• Corporación Microsoft (nd). Evite un gusano actualizando Servicios de escritorio remoto
(CVE 20190708). Obtenido del blog del Centro de respuestas de seguridad de
Microsoft: https://msrc blog.microsoft.com/2019/05/14/preventawormbyupdatingremotedesktop
servicioscve20190708/
• Corporación Microsoft (nd). Elimine malware predominante específico con la Herramienta de eliminación
de software malintencionado de Windows . Obtenido de Microsoft Corporation: https://support.microsoft.
com/enus/help/890830/removespecificprevalentmalwarewithwindows
software maliciosoremo
• Corporación Microsoft (nd). Seguridad en línea de Microsoft Defender, simplificada.

Obtenido de https://www.microsoft.com/enus/microsoft365/microsoftdefenderfor
individuos
Capítulo 4 189
• Corporación Microsoft (nd). Descripción de Zlob. Obtenido de Microsoft Security Intelli

gencia: https://www.microsoft.com/enus/wdsi/threats/malwareencyclopediade
scription?Name=TrojanDownloader:Win32/Zlob&threatId=16998
• Corporación Microsoft (nd). Descripción de Revetón. Obtenido de Microsoft Security Intel

descripción?Name=Rescate:Win32/Reveton.T!lnk&threatId=2147285370
• Corporación Microsoft (nd). Descripción Rotbrow. Obtenido de Microsoft Security

Intelligence : https://www.microsoft.com/enus/wdsi/threats/malwareencyclopedia
descripción?name=win32%2frotbrow
• Corporación Microsoft (nd). Descripción de salidad. Obtenido de Microsoft Security

Intelligence : https://www.microsoft.com/enus/wdsi/threats/malwareencyclopediade
scription?Name=Virus%3aWin32%2fSality
• Corporación Microsoft (nd). Descripción de Sefnit. Obtenido de Microsoft Security Intel

Ligence: https://www.microsoft.com/enus/wdsi/threats/malwareencyclopedia description?
Name=Win32/Sefnit
• Corporación Microsoft (nd). SmartScreen: preguntas frecuentes. Obtenido de Microsoft
Corporation: https://support.microsoft.com/engb/help/17443/windowsinternetexplorer
Smartscreenpreguntas frecuentes
• Corporación Microsoft (nd). Descripción de Taterf. Obtenido de Microsoft Security Intel

descripción? Nombre = Win32/Taterf
• Corporación Microsoft (nd). Alerta de virus sobre el gusano Blaster y sus variantes. Obtenido
de Microsoft Corporation: https://support.microsoft.com/enus/help/826955/
alertadevirussobreelgusanoblasterysusvariantes
• NIST (sf). CVE20190708 Detalle. Obtenido de la base de datos de vulnerabilidad nacional:

https://nvd.nist.gov/vuln/detail/CVE20190708
• Lluvias, T. (27 de junio de 2011). Defensa contra ataques de ejecución automática. Obtenido del blog
de seguridad oficial de Microsoft: https://www.microsoft.com/security/blog/2011/06/27/
defensacontraautorunataques/
• Lluvias, T. (24 de septiembre de 2013). Examinando el panorama de amenazas de la montaña rusa

de Corea. Obtenido del blog de seguridad oficial de Microsoft: https://www.microsoft.com/security/
blog/2013/09/24/examinandocorearollercoasterthreatlandscape/
• Lluvias, T. (nd). Nuevo informe de amenazas del Centro de protección contra malware de Microsoft publicado: EyeStye.
Obtenido del blog de seguridad oficial de Microsoft: https://www.microsoft.com/enus/
security/blog/2012/07/20/newmicrosoftmalwareprotectioncenterthreat
informepublicadoeyesye/
• Autoridad del Sistema de Información de la República de Estonia (2018). Autoridad del Sistema de
Información de Estonia : Evaluación Anual de Seguridad Cibernética 2018. Autoridad del Sistema
de Información de la República de Estonia . Obtenido de: https://www.ria.ee/sites/default/files/content
editores/kuberturve/riacsa2018.pdf
• Solon, O. (13 de septiembre de 2017). El gobierno de EE. UU. prohíbe a las agencias usar el
software de Kaspersky por temor a espiar. Obtenido de The Guardian: https://www.theguardian.com/
tecnología/2017/sep/13/estadosunidosgobiernoprohíbekasperskylabrusoespionaje
• El primer ministro de Turquía es proclamado ganador de las elecciones presidenciales (10 de agosto
de 2014). Obtenido de The New York Times: https://www.nytimes.com/2014/08/11/world/europe/
erdoganturkeyspremierwinspresidentialelection.html?_r=0/
• Departamento de Seguridad Nacional de EE. UU. (nd). Sectores de Infraestructura Crítica.

Obtenido de CISA Cyber Infrastructure: https://www.cisa.gov/criticalinfrastructuresectors
• Wikipedia (sf). 2014 en Irak. Obtenido de Wikipedia.com: https://en.wikipedia.
org/wiki/2014_en_Irak
• Wikipedia (sf). 2014 en Pakistán. Obtenido de Wikipedia.com: https://en.wikipedia.

org/wiki/2014_en_Pakistán
• Wikipedia (sf). Base informática segura de última generación. Obtenido de Wikipedia.com:

https://en.wikipedia.org/wiki/NextGeneration_Secure_Computing_Base
• Wikipedia (sf). Cronología de la Primavera Árabe. Obtenido de Wikipedia.com: https://

en.wikipedia.org/wiki/Timeline_of_the_Arab_Spring
• Corporación Microsoft (nd). Inteligencia de seguridad de Microsoft. Obtenido de https://www.

microsoft.com/enus/wdsi/amenazas
• McAfee Labs (junio de 2021). Informe de amenazas de McAfee Labs 06.21. Obtenido de https://www.
mcafee.com/enterprise/enus/assets/reports/rpthreatsjun2021.pdf
• SophosLabs, noviembre de 2021. Informe de amenazas de Sophos 2022. Obtenido de https://www.

sophos.com/eses/content/securitythreatreport
• Popkin, G. (2020, 12 de agosto). El calentamiento global podría desbloquear el carbono del

suelo tropical. El New York Times. https://www.nytimes.com/2020/08/12/climate/tropicalsoils
cambioclimático.html
Capítulo 4 191
• Bussewitz, Cathy. (2021, 19 de mayo). Colonial Pipeline confirma que pagó 4,4 millones de dólares a
los piratas informáticos . Associated Press. https://www.pbs.org/newshour/economy/colonialpipeline
confirmaquepagó44millonesahackers
• Russon, MaryAnn. (2021, 10 de mayo). Los piratas informáticos de los oleoductos de EE. UU. "no tenían la intención de crear problemas".
Noticias de la BBC. https://www.bbc.com/news/business57050690
• Lluvias, Tim. (2016, 22 de abril). Ransomware: comprensión del riesgo. Blog de

seguridad de Microsoft. https://www.microsoft.com/security/blog/2016/04/22/
ransomware comprensióndelriesgo/

5
Amenazas basadas en Internet
Durante el último cuarto de siglo, los atacantes han aprendido a aprovechar Internet para comprometer los
entornos de TI de sus víctimas, lograr sus objetivos ilícitos y satisfacer sus motivaciones. Los CISO y los
equipos de seguridad pueden informar sus estrategias de ciberseguridad al estudiar cómo los atacantes
usan Internet. En este capítulo, veremos algunas de las formas en que los atacantes han estado usando
Internet y cómo estos métodos han evolucionado con el tiempo. En este capítulo, veremos los siguientes temas:
• Ataques de phishing
• Ataques de descargas no autorizadas
• Sitios de alojamiento de malware
Comencemos observando la anatomía de un patrón de ataque típico.
Introducción
En los últimos dos capítulos, brindé un examen profundo de los datos y las tendencias para la divulgación de
vulnerabilidades y el malware. Ambos tipos de amenazas son aprovechados constantemente por atacantes que buscan
comprometer a organizaciones y consumidores de todo el mundo. Posteriormente, el riesgo que estas amenazas
representan son gestionados activamente por las empresas. Pero las formas en que los atacantes entregan sus armas, ya
sean explotaciones de vulnerabilidades o malware que proporciona puertas traseras ilícitas para los atacantes, son variadas.
En este capítulo, veremos algunos de los métodos que utilizan los atacantes para atacar a sus víctimas; Comprenderlos
es tan importante como comprender cómo han evolucionado las vulnerabilidades y el malware.
194 Amenazas basadas en Internet
Las amenazas que hemos examinado hasta ahora tienen el potencial de permitir que los atacantes comprometan
aplicaciones, clientes, servidores, dispositivos IoT y de consumidores, equipos de enrutamiento y conmutación, y otros
sistemas en los que confían las empresas. Ya sea que estos ataques estén diseñados para victimizar a un gran número de
organizaciones y consumidores o estén dirigidos a organizaciones específicas, los atacantes utilizarán los sospechosos
habituales de ciberseguridad para comprometer inicialmente los sistemas de TI. Como recordatorio, estos incluyen
vulnerabilidades sin parches, malas configuraciones de seguridad, ingeniería social, amenazas internas y credenciales
débiles, filtradas o robadas.
Es raro que un atacante esté sentado físicamente frente al teclado del sistema que intenta comprometer. La gran mayoría
de los atacantes perpetran sus ataques de forma remota a través de redes, ninguno más que Internet. De la misma manera
que Internet ha permitido que las pequeñas empresas compitan con las grandes multinacionales, también permite que
individuos y pequeños grupos ataquen a una gran cantidad de consumidores y las organizaciones más grandes del mundo.
Ahora veamos un patrón de ataque típico como ejemplo de cómo los atacantes han aprendido a aprovechar
La Internet.
Un ataque típico
En este ejemplo ficticio, el atacante se encuentra físicamente en Australia y la víctima prevista del ataque tiene su sede en
los Estados Unidos. La motivación del atacante es el lucro y buscan robar información valiosa de la organización a la que
apuntan y venderla.
La víctima prevista tiene un CISO y un equipo de seguridad. Los constantes análisis de vulnerabilidades del atacante en el
perímetro de la víctima revelan que son competentes en la gestión de vulnerabilidades, ya que las vulnerabilidades en los
sistemas con acceso a Internet se reparan rápida y eficientemente. Después de investigar un poco sobre la organización
víctima, el atacante decide utilizar un enfoque múltiple para comprometer inicialmente a la organización.
El atacante siempre ha tenido éxito, de una forma u otra, utilizando la ingeniería social para engañar
gente de negocios sin conocimientos técnicos para que tomen malas decisiones de confianza que podrían capitalizarse. Una
decisión de poca confianza en este contexto es cuando la víctima decide abrir un archivo adjunto o hacer clic en una URL
en un correo electrónico, reducir la configuración de seguridad de su sistema, abrir puertos de firewall basados en host o
tomar otras acciones que permitan al atacante victimizarlos más fácilmente . En este caso, el atacante utilizará dos tácticas
diferentes para intentar comprometer las computadoras portátiles de algunos trabajadores de la información, con el objetivo
de obtener acceso a sus bandejas de entrada de correo electrónico. Ambas tácticas aprovecharán el correo electrónico como
mecanismo de entrega y se basarán en la ingeniería social y la mitigación de seguridad descuidada para tener éxito.
Capítulo 5 195
La primera táctica es enviar correos electrónicos de phishing a personas específicas que el atacante ha identificado que
trabajan en el departamento de finanzas de la empresa utilizando el sitio web público de la empresa como fuente de
información. No tomó mucho tiempo obtener una lista de las direcciones de correo electrónico de las personas a las que
el atacante quería dirigirse. El objetivo de los correos electrónicos de phishing es engañar a uno o más de los trabajadores
de la información objetivo para que compartan sus credenciales de Microsoft 365, que el atacante puede usar para acceder.
su bandeja de entrada de correo electrónico.
La segunda táctica es enviar correos electrónicos a los mismos trabajadores de la información que contienen un enlace malicioso.
a un sitio de descarga driveby. Si los trabajadores de la información muerden el anzuelo y hacen clic en el enlace, su
navegador web los llevará a una página web maliciosa que los expondrá a varios exploits para las vulnerabilidades del
navegador y del sistema operativo. Si su cliente no está completamente parcheado, existe una buena posibilidad de
que el atacante pueda instalar una puerta trasera en su sistema que podría permitirle obtener acceso privilegiado a la
computadora portátil de la víctima y, en última instancia, a su correo electrónico.
Por supuesto, si el atacante obtiene acceso privilegiado a la computadora portátil de la víctima, es posible que pueda
recopilar todo tipo de información valiosa además del correo electrónico. Los ejemplos incluyen documentos
almacenados localmente en la computadora portátil, listas de contactos, acceso a cuentas de redes sociales, claves
de licencia de software, información de gastos y tarjetas de crédito, información y credenciales bancarias, así como
información personal que puede usarse para el robo de identidad, etc. Si la computadora portátil es administrada
pasivamente por TI, podría usarse para almacenar material ilícito, inscribirse en una botnet y usarse en ataques contra
otros objetivos. Por ejemplo, podría usarse para campañas de spam y phishing, para albergar ataques de descarga
oculta, malware, fraude de clics publicitarios, ataques DDoS o cualquier “proyecto

trabajo” que el atacante decide emprender.
Además, el atacante podría vender o intercambiar cualquier información que robara, incluidas las credenciales de la
cuenta. Los delincuentes a los que les dan esta información podrían estar ubicados mucho más cerca de la víctima y
ser mucho más agresivos al aprovechar la información para maximizar sus ganancias y/o el daño a la víctima.
Este tipo de ataque es demasiado típico. Involucró a tres de los cinco sospechosos habituales de ciberseguridad,
incluida la ingeniería social, vulnerabilidades sin parches y credenciales robadas. Ahora echemos un vistazo más de
cerca a algunos de estos métodos, cómo funcionan y qué tan populares son en realidad. Para hacer esto, me basaré
en la inteligencia de amenazas y los datos que han sido publicados por los líderes de la industria a lo largo de los años.
Comencemos analizando el phishing.

Ataques de phishing
La ingeniería social es una táctica fundamental para los atacantes de todo el mundo. El phishing se encuentra en la
intersección de dos de los sospechosos habituales de la ciberseguridad: la ingeniería social y las contraseñas débiles,
filtradas y robadas. Muchas de las filtraciones de datos más grandes de la historia comenzaron con un ataque de phishing.
En términos simples, el phishing es una táctica de ingeniería social en la que el atacante intenta engañar a su víctima para
que comparta información confidencial con ellos. Los atacantes usan correos electrónicos, sitios web y publicidad para
incitar a las personas a revelar credenciales de cuentas, detalles personales, tarjetas de crédito e información de cuentas
financieras, entre otras cosas. La información que las víctimas revelan puede usarse para acceder ilegalmente a cuentas
en línea, realizar transacciones financieras ilegales y robar la identidad de las víctimas, entre otros fines.
Algunos atacantes lanzan una amplia red indiscriminada para sus ataques de phishing para atrapar a la mayor cantidad
de personas posible con el fin de aumentar las probabilidades de éxito. Algunos atacantes enfocan sus actividades de
phishing en una industria o grupo de objetivos. La suplantación de identidad (spear phishing) se utiliza para centrar los
ataques en individuos, presumiblemente porque tienen acceso a la información o riqueza que desea el atacante.
Muy a menudo, después de que los atacantes comprometan con éxito el sistema de un trabajador de la información, las
propias listas de contactos de las víctimas se utilizan para atacar a sus amigos, familiares, compañeros de trabajo y
contactos comerciales. Por ejemplo, una vez que la cuenta de la red social de la víctima ha sido comprometida, los
atacantes pueden usar la cuenta de la víctima para comunicarse con la red social de la víctima. Dado que las comunicaciones son
aparentemente proveniente de una fuente confiable, otros en la red social de la víctima son fácilmente engañados por
correos electrónicos de phishing y sitios web compartidos a través de la cuenta de la víctima. Los atacantes no se limitan
a atacar las cuentas corporativas de su objetivo y buscarán comprometer los sistemas personales de los trabajadores de
la información, sabiendo que estos sistemas a menudo tienen acceso remoto a los activos corporativos.
Es común instalar keyloggers u otros tipos de malware para automatizar la recopilación de datos de los sistemas de las
víctimas.
Los ataques de phishing pueden involucrar varios componentes tecnológicos, incluidos los clientes de las víctimas y la
infraestructura utilizada para atacar a las víctimas; por ejemplo, los servidores de correo electrónico desde los que se
originan los correos electrónicos de phishing o los servidores web en los que se alojan las páginas de phishing. Muy a
menudo, estos servidores web y de correo electrónico están alojados en sistemas legítimos que se han visto comprometidos
y, posteriormente, se utilizan para campañas de phishing.

Capítulo 5 197
Las botnets, que son redes potencialmente grandes de sistemas comprometidos que se controlan de forma
ilícita de forma remota, se utilizan comúnmente para campañas de phishing. El uso de sistemas comprometidos
para la infraestructura de la campaña de phishing reduce los costos para los atacantes, protege sus identidades
y los ayuda a alcanzar una escala que probablemente no podrían lograr de otra manera. La disponibilidad de
kits de phishing facilita que casi cualquier persona realice un ataque de phishing.
Echemos un vistazo más de cerca a dónde se alojan los sitios de phishing y dónde están sus víctimas. Primero,
es importante darse cuenta de la escala de este problema. Por volumen, el phishing, junto con los troyanos
(como discutí en el Capítulo 4, La evolución del malware), son las tácticas más utilizadas por los atacantes.
¿Cuántos sitios web de phishing hay?
Buenas fuentes de datos para los sitios de phishing son los motores de búsqueda de Internet y los navegadores
web. Después de todo, Google y Bing indexan constantemente miles de millones de páginas web en Internet
para que las búsquedas puedan generar resultados rápidos y precisos. Además, muchos millones de personas
utilizan los navegadores web Google Chrome y Microsoft para navegar por Internet. Los navegadores permiten
a los usuarios informar sobre sitios sospechosos o totalmente inseguros. Google y Microsoft emplean capacidades
en sus navegadores y motores de búsqueda para buscar sitios de phishing, sitios de alojamiento de malware y
otros tipos de sitios web maliciosos. Luego, ayudan a los usuarios de sus productos y servicios a evitar los sitios
maliciosos que encuentran al integrar listas continuamente actualizadas de URL y direcciones IP maliciosas en
sus productos y servicios. Tanto los navegadores como los motores de búsqueda, entre otros servicios, pueden
advertir a los usuarios cuando intentan visitar un sitio web malicioso conocido, como un sitio de phishing. Esto
genera datos en sitios web maliciosos que tanto Google como Microsoft publican periódicamente.
Por ejemplo, la tecnología de Google que busca sitios web maliciosos se llama Navegación segura. Así lo
describe Google:
Aproximadamente cuatro mil millones de dispositivos se benefician de la tecnología de navegación segura de Google.
Cuando nuestros sistemas identifican un sitio como potencialmente dañino, Navegación segura activa una advertencia
para los usuarios. Estas advertencias están diseñadas para evitar que los usuarios visiten sitios dañinos y ayudarlos
a mantenerse seguros en línea”.
— Google, sin fecha

En 2019, la navegación segura de Google detectó un promedio de 32 677 nuevos sitios de phishing por
semana. Este volumen se refleja en la Figura 5.1. Los factores que probablemente influyan en el volumen de
nuevos sitios de phishing incluyen la cantidad de personas que emplean tácticas de ingeniería social, la
disponibilidad de kits de phishing y otra automatización (como botnets) que ayudan a facilitar los ataques,
costos operativos bajos continuos y tasas de éxito aceptables.
Figura 5.1: Número de sitios web de phishing detectados por Google Safe Browsing por semana
en 2019 (Google, 2020)
El Grupo de Trabajo AntiPhishing (APWG) publica Informes de Tendencias de Actividad de Phishing del APWG
trimestralmente. Al agregar los datos de los cuatro informes trimestrales del APWG publicados para 2021, la
Figura 5.2 revela que la cantidad de sitios únicos de phishing siguió creciendo a lo largo del año, acelerándose
rápidamente en la segunda mitad del año (APWG, sin fecha).
Capítulo 5 199
Figura 5.2: Número promedio de sitios web de phishing únicos detectados por miembros del
APWG cada mes en 2021, por trimestre (APWG, nd)
El APWG comentó sobre esta tendencia en el Informe de tendencias de actividad de phishing del APWG para el
cuarto trimestre de 2021:
APWG vio 316,747 ataques en diciembre de 2021, que fue el total mensual más alto en el
historial de informes de APWG. La cantidad de ataques de phishing recientes se ha más
que triplicado desde principios de 2020, cuando APWG observaba entre 68 000 y 94 000
ataques por mes”. – APWG 23 de febrero de 2022
También podemos obtener una idea de la escala del phishing observando cuántas personas intentaron visitar sitios
de phishing usando sus navegadores web. Google publica la cantidad de advertencias que proporciona a los usuarios
de varios navegadores (incluido Google Chrome) que aprovechan la Navegación segura de Google.
La Figura 5.3 ilustra la cantidad promedio de advertencias de navegador por semana en cada trimestre en los tres
años que abarcan 2019 y 2021. La cantidad promedio de advertencias de navegador semanales para todos
2021 fue 4.128.779.
Figura 5.3: La cantidad promedio de advertencias del navegador proporcionadas a los usuarios por Google
Safe Browing cada semana, por trimestre, entre 2019 y 2021 (Google, nd)
El número de advertencias fue relativamente bajo durante 2020 y 2021 en comparación con años anteriores.
Se produjeron picos notables en las advertencias del navegador la semana del 15 de julio de 2012 (64 165 701
advertencias), la semana del 21 de septiembre de 2014 (33 059 895 advertencias) y la semana del 31 de julio de
2016 (60 953 154 advertencias). El período de 2020 y 2021 tuvo el volumen más bajo de advertencias semanales
del navegador desde al menos octubre de 2010.
Google, Microsoft y muchas otras organizaciones han tratado de facilitar que los consumidores y las empresas
denuncien los sitios de phishing. Cuando se informan o detectan sitios de phishing, se emplean procesos legales
y técnicos para eliminar estos sitios maliciosos. Por ejemplo, Microsoft llevó a cabo más de 168 000
desmantelamientos de sitios de phishing en 2021 (Microsoft Corporation, octubre de 2021). En agosto de 2022,
anunciaron que eliminaron "más de 531 000 URL de phishing únicas y 5400 kits de phishing entre julio de 2021 y
junio de 2022, lo que llevó a la identificación y cierre de más de 1400 cuentas de correo electrónico maliciosas
utilizadas para recopilar credenciales de clientes robadas" (Microsoft Corporation, agosto de 2022).
Capítulo 5 201
Según Microsoft, “el 91 por ciento de todos los ciberataques comienzan con el correo electrónico” (Ganacharya, marzo de 2020).
El volumen de correos electrónicos de phishing ha aumentado con el tiempo. Una gran fuente de datos sobre correos
electrónicos de phishing son los servicios de correo electrónico masivos, como Microsoft Office 365 (ahora llamado
Microsoft 365) y Google Gmail, entre otros, que reciben y filtran solicitudes de phishing para clientes empresariales de todo el mundo.
Microsoft informó un gran aumento en los correos electrónicos de phishing dirigidos a destinatarios que usan Office 365 en 2018:
Microsoft analiza y escanea en Office 365 más de 470 mil millones de mensajes de correo
electrónico cada mes en busca de phishing y malware, lo que brinda a los analistas una visión
considerable de las tendencias y técnicas de los atacantes. La proporción de correos electrónicos
entrantes que eran mensajes de phishing aumentó un 250 % entre enero y diciembre de 2018”.
— Corporación Microsoft, 2019
Microsoft indicó que el mes pico para los correos electrónicos de phishing en 2018 fue noviembre, donde el 0,55 % del total
de correos electrónicos entrantes fueron correos electrónicos de phishing; eso es el equivalente a 2.585.000.000 de correos
electrónicos de phishing en un mes (Microsoft Corporation, 2019).
Julio de 2019 parece ser el mes con los niveles más altos en el período 2018/2019, con un 0,85 % de correos electrónicos
de phishing detectados del volumen total de correos electrónicos analizados por Microsoft en todo el mundo. Al sumar
el mismo volumen de mensajes de correo electrónico de 470 mil millones por mes, esto equivale a 3,995,000,000 de
mensajes de correo electrónico de phishing en un mes. Por supuesto, hay muchos otros servicios de correo electrónico
locales y en línea que reciben volúmenes significativos de correos electrónicos de phishing que no se incluyen en estas
cifras. Por ejemplo, en agosto de 2019, Google reveló que estaba bloqueando 100 millones de correos electrónicos de
phishing todos los días:
Los aproximadamente 100 millones de correos electrónicos de phishing que Google bloquea todos
los días se dividen en tres categorías principales: phishing de lanza altamente dirigido pero de bajo
volumen dirigido a individuos distintos, 'phishing de boutique' que se dirige solo a unas pocas
docenas de personas y phishing masivo automatizado dirigido a miles o cientos de miles de personas ".
— Pegoraro, 2019
Eso es aproximadamente 3 mil millones de correos electrónicos de phishing por mes en promedio, en el mismo estadio de
béisbol que Microsoft en ese momento. En 2021, el volumen de correos electrónicos de phishing continuó con una tendencia
al alza. En la primera mitad de 2021, la cantidad de correos electrónicos de phishing observados en el flujo de correo global
de Microsoft Exchange, por mes, estuvo entre 620 millones y 820 millones (Microsoft Corporation, 2021). Noviembre parece
ser uno de los meses favoritos de los atacantes para las campañas de phishing. Después de ese notable aumento en
noviembre de 2018, se produjo otro aumento en noviembre de 2020 cuando Microsoft midió volúmenes que casi alcanzaron
los 1,2 billones de correos electrónicos de phishing (Microsoft Corporation, 2021).
Los volúmenes de correos electrónicos de phishing y la cantidad de sitios de phishing activos hacen que los atacantes de
phishing sean la táctica más utilizada. La mayoría de los correos electrónicos de phishing incluyen un hipervínculo a un sitio
web de phishing. “Más del 75 % de los correos de phishing incluyen direcciones URL maliciosas a sitios de phishing”.
(Corporación Microsoft, 2018). Los correos electrónicos de phishing generalmente intentan aprovechar eventos deportivos y
sociales populares, situaciones de crisis, conflictos, ofertas de ventas y oportunidades, así como reclamos de facturas
vencidas, problemas con cuentas bancarias y fallas en el envío de paquetes, para jugar con las emociones de sus víctimas
y crear una sensación de urgencia. Los phishers utilizarán cualquier tema para captar la atención de las víctimas potenciales
y obligarlas a tomar medidas que, en última instancia, conducen a decisiones de confianza y divulgación de información deficientes.
Los objetivos frecuentes de los ataques de phishing incluyen servicios en línea, sitios financieros, sitios de redes sociales,
sitios de comercio electrónico, etc. El Informe de tendencias de actividad de phishing del APWG para el cuarto trimestre de
2021 indica que las instituciones financieras (23,2 %), SaaS/Webmail (19,5 %) y el comercio electrónico/minorista (17,3 %)
fueron los sectores más frecuentemente atacados por ataques de phishing durante el trimestre (APWG, 23 de febrero de
2022).
Quizás se pregunte dónde se alojan la mayoría de los sitios de phishing. En el cuarto trimestre de 2021, el APWG descubrió
que los dominios de nivel superior genéricos (gTLD) y de código de país (ccTLD) con la mayoría de los sitios de phishing
incluían .com (la mayoría de los sitios por un amplio margen), .xyz, .org, .net, .buzz y .br (Brasil) (APWG 23 de febrero de
2022). El Informe de tendencias de actividad de phishing del APWG para el segundo trimestre de 2021 incluyó una lista de
TLD que tenían los dominios de segundo nivel más exclusivos utilizados para el phishing durante el segundo trimestre. Los
ccTLD incluidos en esa lista eran para el Reino Unido, Montenegro, Tokelau, Malí, Australia y la República Centroafricana.
Según los datos de tendencias de phishing para 2021 publicados en mayo de 2022 por JPCERT/CC, los ccTLD que alojaron
la mayoría de los sitios de phishing incluyeron .cn ( China con 69 %), .cc (Islas Cocos (Keeling) con 7 %) y .jp (Japón con 4
%) (JPCERT/CC, 2022).
En el pasado, planteé la hipótesis de si existe una conexión entre la tasa de infección de malware de un país y la cantidad
de sitios de phishing alojados en el ccTLD de ese país. La teoría era que los phishers usan sistemas comprometidos para
albergar ataques de phishing.

Capítulo 5 203
Posteriormente, los países con las tasas de infección de malware más altas también deberían tener niveles elevados de
sitios de phishing. Mi conclusión de un examen no científico de los datos históricos que tengo es que no parece que los
phishers confíen en la disponibilidad de una gran cantidad de sistemas comprometidos para configurar una cantidad
relativamente grande de sitios de phishing. Sin embargo, creo que se requiere un estudio más riguroso para sacar
conclusiones reales.
Independientemente de dónde los atacantes alojen sus operaciones de phishing, las organizaciones quieren mitigar estos
ataques. A continuación, analicemos algunas de las mitigaciones que las empresas pueden emplear para administrar los
ataques de phishing.
Mitigar el phishing
Los sitios web de phishing solían ser más fáciles de identificar para los usuarios que en la actualidad. Si una página web
le solicitaba credenciales o información confidencial, pero no protegía esos datos en tránsito mediante HTTPS (la falta
del ícono de candado legítimo en el navegador web indica esto), entonces, ¿por qué escribiría algo en esa página? Pero
esta ya no es una forma efectiva de identificar sitios de phishing, como descubrió el APWG en su investigación. A partir
del tercer trimestre de 2020, se descubrió que el 80 % o más de los sitios de phishing usaban certificados TLS (APWG,
22 de septiembre de 2021).
Mitigar los ataques de phishing es fácil y difícil. Por ejemplo, los ataques de phishing que buscan robar credenciales se
pueden mitigar en gran medida al hacer cumplir el requisito de usar la autenticación multifactor (MFA). Según estudios
realizados por Microsoft:
Su contraseña no importa, ¡pero MFA sí! Según nuestros estudios, su cuenta tiene más de
un 99,9 % menos de probabilidades de verse comprometida si utiliza MFA”.
—Weinert, 2019
Requerir un segundo factor para la autenticación mitiga en gran medida los riesgos asociados con contraseñas débiles,
filtradas y robadas. Si un atacante engaña con éxito a un usuario para que revele sus credenciales en un ataque de
phishing, pero el acceso a la cuenta requiere otro factor, como el acceso físico a un token, teléfono fijo o móvil, entonces
las credenciales por sí solas no le darán a los atacantes acceso a la cuenta. Por supuesto, eso no impide que los
atacantes intenten usar esas credenciales robadas en cientos de sitios financieros y de comercio electrónico en línea,
apostando a la posibilidad de que el usuario haya usado las mismas credenciales varias veces; sus scripts hacen esto
segundos después de obtener las credenciales filtradas y robadas. Reutilizar la misma contraseña en todas las cuentas
sigue siendo demasiado común, pero se puede mitigar en gran medida aprovechando MFA en todas partes.
Pero como mencioné en un capítulo anterior, MFA no está disponible en todas partes, especialmente en entornos
empresariales con décadas de aplicaciones heredadas. Incluso cuando MFA está disponible, un porcentaje
sorprendentemente bajo de consumidores y empresas parece aceptarlo. Los CISO y los equipos de seguridad
deberían ser grandes defensores de MFA en todas partes porque puede ser muy efectivo.
Recuerde también que, como mínimo, los altos ejecutivos deben usar MFA en todas partes y son las últimas personas
que deben estar exentas de las políticas de MFA; después de todo, son los principales objetivos de Business Email
Compromise y otros ataques de ingeniería social. Facilitar la vida de los ejecutivos dándoles excepciones para las
mismas políticas y controles de seguridad que mitigan los ataques contra ellos específicamente no es prudente y es
literalmente un regalo para los atacantes.
Una herramienta eficaz que he visto que se utiliza en los casos en que los ejecutivos exigen excepciones para las
políticas de seguridad son las cartas de aceptación de riesgos. Una carta de aceptación de riesgos o una carta de
reconocimiento de riesgos documenta que los riesgos asociados con la excepción de la política de seguridad se han
explicado al ejecutivo, que comprende estos riesgos y los acepta en nombre de toda su organización.
Periódicamente, estas cartas de aceptación de riesgos deben ser revisadas por el CISO, los altos ejecutivos y,
potencialmente, la Junta Directiva, para garantizar que el riesgo sistémico a largo plazo no se haya aceptado de
manera adecuada. Cuando se enfrentan a una de estas cartas, los ejecutivos que quieren excepciones a la política
de seguridad suelen hacer una pausa en el último minuto una vez que tienen tiempo para reflexionar sobre las
posibles consecuencias para sus organizaciones y sus propias carreras. Al final, muchos de estos ejecutivos deciden
prudentemente no exigir excepciones a la política de seguridad.
Por supuesto, el phishing no se limita al robo de credenciales. Los atacantes utilizan el phishing en sus intentos de
engañar a las personas para que revelen información que de otro modo no compartirían. MFA no mitiga este tipo de
ataques. En estos casos, la mejor mitigación es la educación. Capacitar a los trabajadores de la información para
que reconozcan posibles ataques de phishing y otras tácticas de ingeniería social no es infalible, pero puede ser
muy eficaz. Algunas organizaciones simplemente se niegan a aprobar los ejercicios de phishing diseñados para
capacitar a sus trabajadores de la información para que reconozcan los ataques de phishing. La gerencia de estas
organizaciones perjudica a sus empleados con tales decisiones.
Una de las herramientas con las que cuentan los CISO, ante equipos directivos que no soportan este tipo de
formación, es la gestión de riesgos. Según mi experiencia, los CISO que cuantifican el riesgo para sus equipos de
gestión tienen más posibilidades de éxito; ayuda a poner sus esfuerzos en contexto, incluso cuando no pasa nada
malo. Recuerde que el riesgo es la combinación de probabilidad e impacto. El hecho de que la mayoría de las
violaciones de datos más grandes y de más alto perfil en la historia comenzaron con correos electrónicos de phishing
puede ayudar a comunicar el riesgo. También puede hacerlo el volumen de correos electrónicos de phishing y la
cantidad de sitios de phishing que proporcioné en este capítulo.
Capítulo 5 205
Los datos nos dicen que se envían un mínimo de 100 millones de correos electrónicos de phishing todos los días, y el número
total es probablemente un múltiplo de esto. Además, decenas de miles de nuevos sitios web activos de phishing aparecen en
línea cada semana (como mínimo). Combine esto con los datos de phishing de su propia organización para cuantificar la
probabilidad de que los trabajadores de la información reciban correos electrónicos de phishing y visiten sitios web
comprometidos, cuántos y con qué frecuencia.
Luego desarrolle algunas estimaciones de impacto cuantitativas, que van desde ningún impacto porque los correos electrónicos
de phishing se filtraron antes de que llegaran a los trabajadores de la información, hasta un compromiso exitoso que involucró
la filtración de datos y el daño a la reputación subsiguiente y responsabilidad legal para la organización . Estas cifras pueden
ayudar a que la decisión de capacitar a las personas para que reconozcan los ataques de ingeniería social sea menos
abstracta y más fácil de comparar con los otros riesgos que los equipos de administración ya manejan.
Considere también si los trabajadores de la información de su organización realmente necesitan acceso ilimitado a Internet.
¿Realmente necesitan visitar sitios web ubicados en los lugares que albergan la mayoría de los sitios de phishing? ¿Existe
realmente una necesidad comercial legítima de permitir que todos en una organización vayan a todas partes en Internet? El
dominio .com generalmente tiene más sitios de phishing que cualquier otro dominio genérico de nivel superior. ¿No es esto
suficiente riesgo sin permitir que todos en una organización visiten cualquier sitio en los ccTLD que generalmente tienen dos o
tres veces la cantidad de sitios de phishing que el promedio mundial? Permitir que los trabajadores de la información accedan
a los ccTLD donde tengan fines comerciales legítimos en estos dominios y bloquear las conexiones a otros sitios desde los
activos administrados por la empresa; esto parece que podría reducir las posibilidades de visitar un sitio de phishing alojado
en un dominio de nivel superior de código de país, así como otras amenazas basadas en Internet que analizo en este capítulo.
El empleo de soluciones de filtrado web administradas activamente puede hacer que esta mitigación sea relativamente fácil.
Ahora veamos la segunda táctica que usaron los atacantes en nuestro ejemplo de un ataque típico, un ataque drive by
download.
Ataques de descargas no autorizadas

Mientras que los ataques de phishing se encuentran en la intersección de la ingeniería social y las contraseñas débiles, filtradas
y robadas, los ataques de descarga oculta se encuentran en la intersección de la ingeniería social y las vulnerabilidades sin
parches. Los ataques driveby suelen ser realizados por atacantes que utilizan ingeniería social para engañar a los usuarios
para que visiten un sitio web malicioso. Pueden hacerlo de varias maneras, incluso a través de correo electrónico, anuncios en
línea, colocando enlaces a sitios maliciosos en las secciones de comentarios de las páginas web y publicaciones en redes
sociales, y muchas otras tácticas. A veces, los atacantes comprometen un sitio web legítimo y lo utilizan para albergar ataques
de descargas ocultas; cuanto más popular sea el sitio web, mejor para los atacantes, ya que aumenta sus posibilidades de
comprometer con éxito tantos sistemas como sea posible.

Llevar a las víctimas potenciales a sitios web maliciosos bajo el control de los atacantes es el primer paso del
ataque. El siguiente paso es explotar las vulnerabilidades sin parchear en los sistemas de las víctimas. Para hacer
esto, los atacantes intentarán ejecutar secuencias de comandos que tienen direcciones URL incrustadas o utilizarán
un marco en línea (IFrame) para cargar otra página de documento HTML sin que el usuario lo sepa. Los IFrames
tienen usos legítimos, por lo que es complicado distinguir entre buenos y maliciosos.
Los atacantes colocarán IFrames del tamaño de un píxel en sus páginas web maliciosas para que los usuarios no
puedan verlos. Cuando estos documentos HTML se cargan, pueden, entre otras cosas, ejecutar secuencias de
comandos que detectan el sistema operativo y las versiones del navegador de la víctima, seleccionar y descargar
los exploits correspondientes para las vulnerabilidades comunes de estas versiones y, en última instancia, descargar
e instalar otro malware que otorga a los atacantes un control ilícito del sistema comprometido. Dichos IFrames
maliciosos se pueden colocar en páginas web de sitios web legítimos que se han visto comprometidos. Esto
significa que visitar un sitio web confiable con un sistema que no está completamente parcheado puede resultar en
un sistema comprometido que los atacantes pueden controlar de forma remota, paralizarlo con ransomware, etc.
La figura 5.4 revela que, para el período comprendido entre julio de 2012 y enero de 2020, la mayor cantidad de
páginas de descarga oculta descubiertas en Internet fue en 2013, donde se encontró más de una página de
descarga oculta por cada 1000 URL indexadas por el motor de búsqueda Bing de Microsoft. Sin embargo, más
recientemente, el promedio mundial fue de 0,09 y 0,08 de estos sitios maliciosos por cada 1000 URL indexadas en
2018 y 2019, respectivamente. Eso significa que la cantidad de sitios de descargas no autorizadas en 2013 fue 14
veces mayor que la cantidad en 2019. Los datos de la Figura 5.4 se recopilaron del Informe de inteligencia de
seguridad de Microsoft y los Informes de inteligencia de seguridad interactivos de Microsoft.
Microsoft parece haber dejado de publicar estos datos regularmente.
Figura 5.4: Páginas de descargas no autorizadas por cada 1000 URL indexadas por el motor de búsqueda Bing de
Microsoft entre 2012 y 2020 según lo publicado en los volúmenes 14 a 21 del informe de inteligencia de seguridad
de Microsoft (Microsoft Corporation, 2012 a 2017) y en los informes interactivos de inteligencia de seguridad de
Microsoft (Microsoft Corporation, mayo de 2020)

Capítulo 5 207
Los componentes utilizados en los ataques de descargas ocultas se pueden distribuir, con varios sistemas
remotos diferentes que los alojan. Los scripts que se ejecutan se pueden alojar en diferentes servidores de
"redireccionamiento", los exploits utilizados para explotar vulnerabilidades sin parches se pueden alojar en
servidores de exploits separados y el malware que finalmente se descarga en los sistemas de las víctimas se
puede alojar en servidores de alojamiento de malware separados. La distribución de componentes de ataques
de descargas no autorizadas de esta manera proporciona varias ventajas a los atacantes. Permite a los atacantes
ser más ágiles, permitiéndoles ajustar sus ataques rápidamente. Esto les ayuda a optimizar sus ataques y
dificulta encontrar y desmantelar todos los componentes que utilizan los atacantes.
Posteriormente, la infraestructura utilizada para alojar los componentes de los ataques de descargas ocultas
se distribuye por todo el mundo. La tabla 5.1 proporciona las ubicaciones con el mayor número de URL de
descarga por cada 1000 URL indexadas por el motor de búsqueda Bing de Microsoft en 2019 (Microsoft
Corporation, 2020). Comparto datos de este período de tiempo específico con usted porque es especialmente
interesante: tenga en cuenta la entrada superior de la tabla.
Tabla 5.1: Ubicaciones con la mayor cantidad de sitios de descargas ocultas en 2019 (Microsoft
Corporation, 2020)
La cantidad de páginas de descarga oculta por cada 1000 URL en Omán en 2019 no es un error tipográfico.
Según los datos publicados por Microsoft, hubo 687,3 URL de descarga oculta por cada 1000 URL en Omán,
en promedio durante los doce meses de 2019 (Microsoft Corporation, 2020). Eso es 8.591,25 veces superior
a la media mundial. En noviembre de 2019, Microsoft informa que hubo 1251,94 URL de descarga oculta por
cada 1000 URL encontradas por Bing en Omán (Microsoft Corporation, 2020). Eso sugiere una concentración
muy alta de URL de descarga oculta en este ccTLD en ese momento.
Aunque esto podría ser un simple error en los datos, podría haber otra explicación menos banal.
El ccTLD de Omán es .om. Los atacantes podrían registrarse y usar nombres de dominio en este ccT LD para atrapar a
los usuarios de navegadores web que escriben .om en lugar de .com. Esta hipótesis parece plausible dada la frecuencia
con la que las personas pueden cometer el error trivial de escribir google.om en lugar de google.
com, apple.om en lugar de apple.com, etc. ¿Cuántas personas cometerían errores como este todos los
días? Parece que podría ser suficiente para llamar la atención de los atacantes que aprovechan los sitios
de descargas ocultas. Esto es lo que informaban algunos investigadores de ciberseguridad en 2016.
¿Podría esta táctica seguir siendo de uso generalizado casi tres años después, en el último trimestre de 2019?
Según los investigadores de seguridad de Endgame, el dominio de nivel superior del país
de Oriente Medio, Omán (.om), está siendo explotado por typosquatters que han registrado
más de 300 nombres de dominio con el sufijo .om para empresas y servicios estadounidenses
como Citibank, Dell, Macys y Gmail. Endgame hizo el descubrimiento la semana pasada e
informa que varios grupos están detrás de las campañas de typosquatter.
— Primavera, 2016
Mitigación de los ataques de descargas ocultas

Estos ataques tienden a depender de vulnerabilidades sin parches para tener éxito. Los atacantes tienen bibliotecas de
exploits que aprovechan para sus ataques de descarga oculta. Los estudios han demostrado que los atacantes han
utilizado entre uno y más de veinte exploits en una sola URL oculta. Si se reparan las capacidades subyacentes de los
vulnerables que estos exploits intentan aprovechar, estos ataques no tendrán éxito.
Por lo tanto, un programa de administración de vulnerabilidades bien ejecutado mitigará los ataques de descargas ocultas.
Además, puede ser útil evitar la exposición a sitios web maliciosos, como los sitios de descargas ocultas . Considere si
permitir que los trabajadores de la información y los administradores de sistemas tengan acceso sin restricciones a Internet
es necesario y si vale la pena el riesgo. ¿Por qué necesitan acceso al ccTLD .om , por ejemplo, oa cualquiera de los otros
dominios ccTLD donde probablemente no haya razones comerciales legítimas para visitar? Aprovechar los servicios de
filtrado web administrados activamente puede ser útil; bloquear el acceso a partes de Internet de los activos corporativos
que no tienen un propósito comercial claro también puede ser útil.
No permita que los administradores del sistema visiten Internet utilizando navegadores web de servidores que procesan
cualquier cosa o de sistemas que son importantes. Las estaciones de trabajo de acceso seguro o las estaciones de trabajo
de acceso privilegiado deben usarse para la administración del servidor a fin de limitar el riesgo de los sistemas importantes.
Capítulo 5 209
La navegación a sitios en la Internet pública debe estar estrictamente prohibida en dichos sistemas y
evitada con controles técnicos. En entornos donde esto simplemente no es posible, se debe aplicar un
filtrado estricto de URL en las conexiones de Internet salientes para permitir el acceso a sitios web
aprobados y evitar el acceso sin restricciones a Internet.
Ejecutar un software antimalware actualizado de un proveedor antimalware confiable también puede ser una mitigación
efectiva. Los ataques de descargas no autorizadas generalmente provocan que se descargue malware en el sistema
de la víctima. Si el software antimalware detecta el intento de explotación y bloquea la descarga e instalación de dicho
malware, se evita un posible desastre.
Mencioné que los atacantes suelen distribuir componentes de ataques de descargas no autorizadas a través de
infraestructuras separadas ubicadas en diferentes lugares del mundo. Ahora echemos un vistazo más de cerca a los
sitios de distribución de malware, que se pueden usar como parte de ataques de descargas ocultas o para entregar
malware empleando otras tácticas a las víctimas.
Sitios de alojamiento de malware

Hemos visto que una gran fuente de datos para sitios web maliciosos, como sitios de phishing y sitios de descargas
ocultas, son los motores de búsqueda de Internet y los navegadores web populares. Estas fuentes de datos también
pueden darnos una idea de los sitios de alojamiento de malware en Internet. Digo un vistazo, porque las cosas pueden
cambiar muy rápidamente ya que muchos atacantes se han vuelto expertos en cubrir sus huellas y dificultar la
búsqueda de la infraestructura que utilizan para sus ataques. Recuerda, nadie es omnisciente. Tenemos un montón
de instantáneas de datos que podemos unir con el tiempo para darnos una idea del panorama de amenazas. Con
frecuencia, el panorama cambia antes de que los investigadores puedan recopilar, analizar, comprender y actuar sobre
dichos datos.
Aquí es donde la promesa del aprendizaje automático (ML) y la inteligencia artificial (IA) está ayudando: procesar
cantidades masivas de conjuntos de datos complicados mucho más rápido de lo que los humanos pueden hacer este
trabajo manualmente. Y, por supuesto, los atacantes también han estado ocupados tratando de encontrar formas de
derrotar a los sistemas que aprovechan ML y AI (Microsoft Defender ATP Research Team, 2018).
Pero comencemos mirando algunos datos que Google ha publicado en sitios que alojan malware. Tienen una visión
única de los sitios que alojan malware, ya que operan el motor de búsqueda de Internet más popular del mundo.
Google publica datos sobre los sitios que alojan malware que encuentran a través de su servicio de navegación segura.
Describen esto de la siguiente manera:
El malware puede esconderse en muchos lugares y puede ser difícil incluso para los expertos
averiguar si su sitio web está infectado. Para encontrar sitios comprometidos, escaneamos la web
y usamos máquinas virtuales para analizar sitios donde hemos encontrado señales que indican
que un sitio ha sido comprometido".
— Google, 2020
Con el tiempo, la herramienta "Historial de análisis del sistema autónomo" de Google proporcionó datos sobre "sitios
de ataque" desde enero de 2007 hasta hace poco, cuando dejaron de publicar estos datos. Según los datos que
publicaron, parece que la mayoría de los sitios de ataque que alojan malware que encontraron fue en noviembre de 2012.
La semana del 11 de noviembre de 2012, el servicio de navegación segura de Google identificó 6.192 sitios de
ataque en Internet (Google, 2020). Otro pico notable fue la semana que comenzó el 15 de septiembre de 2013,
cuando se identificaron 5282 sitios de ataque (Google, 2020). Estos números relativamente grandes han disminuido
en tiempos más recientes. Entre 2018 y 2019, la mayor cantidad de sitios de ataque identificados por Navegación
segura fue de 379, y entre enero y abril de 2020, 30 sitios de ataque parecen ser el máximo identificado en una sola
semana (Google, 2020). Al igual que los sitios de descargas ocultas, la cantidad de sitios que alojan malware parece
haber disminuido con el tiempo.
Otra fuente de datos sobre sitios de distribución de malware es URLhaus (https://urlhaus.abuse.ch/

Estadísticas/). URLhaus recopila direcciones URL de sitios que alojan malware y las comparte con Google Safe
Browsing, entre otros. Su propósito, según su sitio web, es el siguiente:
URLhaus es un proyecto operado por abuse.ch. El propósito del proyecto es recopilar, rastrear y
compartir URL de malware, ayudando a los administradores de red y a los analistas de seguridad
a proteger su red y a sus clientes de las ciberamenazas”.
— URLhaus, 2022
Según los datos publicados por URLhaus, entre el 25 de julio de 2022 y el 21 de agosto de 2022, había entre 3290 y
7000 sitios de distribución de malware activos en línea todos los días (URLhaus, 2022).
Capítulo 5 211
Las redes de hospedaje en los Estados Unidos y China aparecen con mayor frecuencia en sus listas de las principales
redes de hospedaje de malware (URLhaus, 2022).
Mitigación de la distribución de malware

Los sitios web legítimos que se ven comprometidos y luego se utilizan para distribuir malware pueden generar
muchos resultados deficientes tanto para los consumidores como para las organizaciones. Por esta razón, es
importante que las organizaciones que operan sitios web comprendan y se concentren en los fundamentos de la ciberseguridad.
Recuerde su introducción a los sospechosos habituales de ciberseguridad en el capítulo 1. Los sospechosos
habituales de ciberseguridad incluyen vulnerabilidades sin parches, configuraciones erróneas de seguridad,
credenciales débiles, filtradas y robadas, amenazas internas e ingeniería social. La gestión de los fundamentos de
la ciberseguridad es fundamental para evitar que los sitios web se conviertan en sitios de distribución de malware.
Todos los que crean un sitio web en Internet deben aceptar esta responsabilidad.
Los proveedores y las organizaciones que recorren Internet en busca de sitios de distribución de malware
normalmente se ponen en contacto con los webmasters de los sitios que encuentran distribuyendo malware. Según
los datos que Google publicó sobre sus actividades de notificación entre 2006 y 2022, el tiempo promedio más bajo
de respuesta de un webmaster a una notificación de que su sitio estaba infectado con malware fue de 15 días
(Google, 2022). 90 días fue un tiempo de respuesta promedio mucho más común. Google también rastreó si los
sitios web infectados se volvieron a infectar después de que los webmasters fueron notificados y desinfectados.
a ellos. Las tasas promedio de reinfección de sitios web oscilaron entre el 2 % y el 40 % entre 2006 y 2022. Los
datos sugieren que este no es un problema de los webmasters desatentos del pasado lejano, ya que las tasas de
reinfección de sitios web siguen siendo más altas de lo esperado incluso en los últimos tiempos. Por ejemplo, la
semana del 2 de enero de 2022, la tasa de reinfección fue del 37 %, cerca del extremo superior del rango de tasa de
reinfección para el período de 16 años (Google, 2022). La semana del 15 de mayo de 2022, la tasa de reinfección
había bajado al 14 %. Nuevamente, si los sospechosos habituales de ciberseguridad subyacentes no se abordan
continuamente, esto permite a los atacantes comprometer los entornos de TI repetidamente y vender el acceso a otros.
Ante estos datos, la llamada a la acción es clara. Si su organización opera un sitio web en Internet, es responsabilidad
de su organización prestar atención a los informes de abuso. Revisar los informes de abuso de los activos
corporativos no es algo que el personal de TI deba hacer en su tiempo libre; debe ser parte de los procesos de
gobierno de cada empresa.
Lo que está en juego para operar un sitio web en Internet es administrar activamente los fundamentos de
ciberseguridad y monitorear y actuar sobre los informes de abuso en un período de tiempo responsable. Si una
organización no está dispuesta a hacer estas cosas, debería hacerles un favor a todos y cerrar sus sitios web.
La ejecución de soluciones antimalware actuales, de un proveedor de confianza, en sistemas conectados a Internet
también puede ser una mitigación eficaz. Pero recuerde que los atacantes a menudo buscarán subvertir una solución
de timalware una vez que comprometan inicialmente con éxito un sistema. Los proveedores de antimalware lo saben
y dificultan que los atacantes lo hagan. Pero una vez que un atacante tiene acceso de sistema o administrador a un
sistema, es dueño de ese sistema, lo que hace que sea mucho más difícil evitar que se comprometan las defensas de
seguridad del sistema. Un gran ejemplo es un rootkit que se esconde del sistema operativo y del software de seguridad
que se basa en él. Por esta razón, me gusta realizar análisis antivirus periódicos fuera de línea. Por ejemplo, Microsoft
ofrece Windows Defender Offline, que escaneará el sistema sin usar el kernel del sistema operativo activo. Windows
Defender Offline está horneado

en Windows 10 y Windows 11 y está disponible para versiones anteriores de Windows a través de una descarga
que se puede ejecutar desde un DVD o una unidad USB (Microsoft Corporation, 2020). Las herramientas de
detección y respuesta de punto final (EDR) y detección y respuesta extendida (XDR) también prometen ayudar.
Por supuesto, las organizaciones que utilizan la nube pueden simplemente apagar los sistemas cada dos horas y
reconstruirlos automáticamente a partir de buenas instancias conocidas. Los sistemas de corta duración como este
proporcionan muy poco tiempo para que los atacantes utilicen los sistemas comprometidos. Sin embargo, incluso en
entornos de corta duración, un programa de administración de vulnerabilidades bien ejecutado y soluciones antimalware
pueden ser útiles. Discutiré esto con más detalle en el Capítulo 12, Enfoques modernos para la seguridad y el cumplimiento.
Pero ahora, veamos la etapa final del patrón de ataque típico con el que comenzamos este capítulo, algunas de las
actividades típicas posteriores al compromiso.
Compromiso posterior: botnets y ataques DDoS

Una vez que los sistemas se han visto comprometidos inicialmente a través de uno de los sospechosos habituales de
ciberseguridad, como vulnerabilidades sin parches y/o ingeniería social como discutimos en este capítulo, cualquier
información de valor se desvía de los sistemas de las víctimas para venderla o intercambiarla. En este punto, los
atacantes tienen el control total de los sistemas que han comprometido. Muchas veces, los sistemas de las víctimas se
incorporan a botnets y se utilizan para realizar cualquier proyecto ilícito que deseen sus operadores, incluidos los ataques DDoS.
Se puede escribir mucho sobre las redes de bots, cómo funcionan y los proyectos en los que normalmente se emplean.
De hecho, se han dedicado libros enteros a las botnets. No intentaré duplicarlos aquí. Pero quiero mencionar
brevemente algunas cosas sobre este tema.
No hace falta decir que las botnets han atraído mucha atención a lo largo de los años. Cuando trabajé en
Microsoft, la Unidad de Delitos Digitales de Microsoft (DCU) trabajó con expertos de la industria y del orden
público para interrumpir algunas de las redes de bots más grandes en funcionamiento. Este trabajo ayudó a
reducir drásticamente el spam en Internet y a degradar el poder de ataque que estas botnets proporcionaban a sus operadores.
Capítulo 5 213
Algunas de estas botnets estaban compuestas por cientos de miles o millones de sistemas comprometidos y eran
capaces de enviar decenas de miles de millones de mensajes de correo electrónico de spam y phishing por día.
Rustock y Waledac son dos ejemplos de este tipo de botnets. Para ello, la DCU tuvo que abordar el problema como
un desafío legal novedoso en el que buscaban y se les otorgaba el control legal sobre los dominios y la infraestructura
física que utilizaban estas botnets (Jones, 2011).
Los atacantes extraerán cualquier cosa de valor de los sistemas sobre los que tienen control total, incluidas las
credenciales almacenadas en caché. Se han encontrado en Internet listas masivas de credenciales filtradas y robadas
a lo largo de los años (Solomon, 2017). Si los sistemas o cuentas comprometidos tienen acceso autenticado y
autorizado a otros sistemas en el entorno, los atacantes también tendrán acceso y control sobre ellos, lo que agravará
el daño a la organización.
Acelerar las actividades de detección y recuperación puede reducir la cantidad de tiempo que controlan los atacantes.
estos activos, reduciendo así potencialmente el daño que causan a otras víctimas y los costos asociados con la
recuperación y restauración de las operaciones normales. La inteligencia de amenazas puede ayudar a las
organizaciones a identificar sistemas que se comunican con infraestructuras de comando y control de botnet conocidas.
Los atacantes lo saben y han alojado algunas de sus infraestructuras en entornos de nube y alojamiento web público
en un esfuerzo por ocultar sus operaciones entre el tráfico de red legítimo.
Uno de los fines ilícitos para los que se han utilizado las botnets a lo largo de los años ha sido el de los ataques de
denegación de servicio distribuido (DDoS) . Los ataques DDoS modernos utilizan técnicas sofisticadas para abrumar
a sus objetivos con tráfico de red, privando así del uso legítimo de los servicios alojados por
la víctima.
¿Qué tan grandes pueden llegar a ser los ataques DDoS? En febrero de 2018, los atacantes lanzaron un ataque a
GitHub. Se dice que este ataque DDoS alcanzó un máximo de 1,35 Tbps, lo que equivale a más de 126 millones de
paquetes por segundo (Kottler, 2018). Este ataque utilizó un enfoque novedoso, al abusar de instancias de
Memcached que no eran seguras. Este enfoque permitió a los atacantes amplificar su ataque por un factor de 51.000;
Dicho de otra manera, por cada byte de tráfico de red que enviaron los atacantes, se enviaron hasta 51 000 bytes (51
KB) a su objetivo. Esto permitió a los atacantes abrumar la capacidad de la red de GitHub con una gran cantidad de
tráfico UDP que interrumpió la conectividad de la red al sitio.

durante casi 10 minutos.
Más recientemente, en enero de 2022, Microsoft mitigó otro ataque DDoS volumétrico sin precedentes
que arrojó 3,47 Tbps a su red, enviando aproximadamente 340 millones de paquetes por segundo.
El ataque mitigado por Microsoft provino de unas 10.000 fuentes y de países que incluyen
Estados Unidos, China, Corea del Sur, Rusia, Tailandia, India, Vietnam, Irán, Indonesia y
Taiwán. Los vectores de ataque fueron inundaciones de paquetes de protocolo de datagramas
de usuario reflejados en el puerto 80 utilizando servidores SSDP, CLDAP, NTP y del sistema
de nombres de dominio”. — Dan Goodin, enero de 2022
El 1 de junio de 2022, según se informa, Google evitó que el ataque HTTPS DDoS más grande de la historia
negara el servicio a uno de los servicios de Internet de sus clientes alojados en la nube de Google. Este ataque
de 69 minutos alcanzó un máximo de 46 millones de solicitudes por segundo utilizando solicitudes basadas en
HTTPS. Según el gerente de producto de Google que fue entrevistado después del ataque, fue como “recibir
todas las solicitudes diarias a Wikipedia (uno de los 10 sitios web más traficados del mundo) en solo 10
segundos” (Kan, 18 de agosto de 2022). Se sospechaba que una botnet generaba los ataques.
Quizás un ataque DDoS menos sofisticado pero más interesante de los libros de historia fue el ataque a la
infraestructura crítica en Estonia en 2007. Algunos atribuyeron este ataque a Rusia (Ander son, 2007). La razón
por la que esto es interesante es que tal vez nos dio una vista previa de lo que podemos esperar en futuros
conflictos de guerra cibernética: ataques cinéticos y en línea simultáneos que abruman la capacidad de librar la
guerra física y logísticamente. Según los informes, se utilizó una versión moderna de este libro de jugadas justo
antes de la invasión militar de Ucrania por parte de Rusia, 15 años después, en 2022. A mediados de febrero de
ese año, los ataques DDoS se dirigieron a instituciones militares y financieras en Ucrania. Ocho días después
, Rusia cruzó la frontera y comenzó su invasión de Ucrania. Estos ataques DDoS no fueron re
poner el cordón, pero podría haber sido mucho más perturbador si no se hubiera mitigado de manera efectiva.
Los ataques DDoS más poderosos contra sitios del gobierno ucraniano alcanzaron un
máximo de más de 100 Gbps, dijo SSSCIP. Si bien está muy por encima del tamaño promedio
de los ataques DDoS, la investigación de Radware muestra que el mayor ataque DDoS
registrado durante los primeros tres trimestres de 2021 fue de 348 Gbps, o 3,5 veces el
tamaño de los ataques DDoS más poderosos contra Ucrania”. — Alspach, 7 de marzo de 2022
El libro de jugadas de ataque utilizado contra Ucrania antes y durante la invasión es de gran interés para muchas
personas, incluidos otros gobiernos y los propios proveedores de mitigación de DDoS.
Capítulo 5 215
Por supuesto, no todos los ataques DDoS deben ser tan grandes o innovadores para ser disruptivos. Sin embargo, las
organizaciones tienen opciones para ayudarlas a mitigar tales ataques. Hay muchos proveedores que ofrecen servicios de
protección DDoS, algunos de los cuales incluyen AWS Shield, Amazon CloudFront, Google Cloud Armor, Microsoft Azure DDoS
Protection, Cloudflare, Akamai y muchos otros. Además de los servicios de protección, la nube ofrece técnicas que se pueden
usar para escalar la infraestructura automáticamente según sea necesario durante los ataques DDoS (Amazon Web Services,
junio de 2015).
En resumen, la clave es centrarse en los fundamentos de la ciberseguridad, de modo que sus sistemas no terminen siendo parte
de una botnet y se utilicen para atacar a innumerables otras organizaciones y consumidores. Como analizo en el Capítulo 9,
Estrategias de ciberseguridad, invertir en capacidades de detección y respuesta ayudará a las organizaciones a minimizar el daño
y los costos asociados con las botnets y el dolor que traen consigo a Internet.
Resumen
Este capítulo se centró en las amenazas basadas en Internet. Examinamos los ataques de phishing, los ataques de descarga
oculta y los sitios de distribución de malware. Tantos ataques aprovechan la ingeniería social que los CISO y los equipos de
seguridad deben dedicar tiempo y recursos para mitigarlos. Por ejemplo, cada semana se conectan a Internet decenas de miles
de nuevos sitios de phishing y cada mes se envían miles de millones de correos electrónicos de phishing a posibles víctimas.
La mayoría de los correos electrónicos de phishing incluyen un enlace a un sitio de phishing (Microsoft Corporation, 2018) y la
mayoría de los sitios de phishing utilizan HTTPS (certificados TLS) (APWG, 22 de septiembre de 2021). Las cuentas tienen casi
un 100 % menos de probabilidades de verse comprometidas cuando MFA está habilitado (Weinert, 2019). La capacitación en
ingeniería antisocial para los trabajadores de la información también puede ser una mitigación eficaz.
Los ataques de descargas no autorizadas aprovechan las vulnerabilidades sin parches para instalar malware sin que el usuario lo
sepa. La cantidad de URL ocultas se ha reducido drásticamente desde el pico en 2013.
De acuerdo con los datos publicados por Microsoft, el ccTLD de Omán alojó 8591 veces más sitios de descarga automática que
el promedio mundial en 2019 (Microsoft Corporation, 2020). Esto podría indicar que los atacantes están utilizando el dominio .om
para atacar a los usuarios que escriben incorrectamente las URL en el dominio .com.
Un programa de administración de vulnerabilidades bien ejecutado y la ejecución de antimalware actualizado de un proveedor
confiable pueden ser mitigadores efectivos para las descargas ocultas.
La cantidad de sitios que alojan malware, sitios de descarga oculta y sitios de phishing cambia con el tiempo, a veces de forma
drástica. Posteriormente, una estrategia de seguridad cibernética que no incluya mitigaciones para todos estos tipos de amenazas
basadas en Internet podría tener brechas de alto riesgo.

Los sistemas comprometidos por ataques de phishing, descargas ocultas y otros sitios web maliciosos pueden
terminar siendo incluidos en botnets y utilizados para atacar a otras organizaciones y consumidores, incluida la
participación en ataques DDoS.
Eso concluye nuestra mirada a las amenazas basadas en Internet. Lo he expuesto a una gran cantidad de datos,
gráficos y tablas en los últimos tres capítulos en un esfuerzo por brindar una visión basada en datos de algunas de
las amenazas que enfrentan los CISO y los equipos de seguridad todos los días. Voy a elevar esta conversación
sobre las amenazas en los próximos capítulos y explorar por qué tantos CISO y equipos de seguridad con los que
me he reunido durante la última década ven a los gobiernos como amenazas para su organización. Esta área
temática trata menos sobre programas maliciosos y más sobre la política pública y los objetivos de política exterior
de los gobiernos nacionales. Examinaremos las funciones que desempeñan los gobiernos en la ciberseguridad, así
como el tema que el 99 % de todos los clientes empresariales fuera de los Estados Unidos querían discutir conmigo
cuando nos reunimos, la amenaza del acceso gubernamental a los datos. Cuando finalmente discutamos las
estrategias de seguridad cibernética más adelante en este libro, debe tener una comprensión completa de la mayoría
de las amenazas que necesita mitigar con sus estrategias.
Referencias
• Amazon Web Services (junio de 2015). “Prácticas recomendadas de AWS para la resiliencia de
DDoS”. Servicios web de Amazon . Obtenido de: https://d1.awsstatic.com/whitepapers/Security/DDoS_
White_Paper.pdf Última edición: 21 de septiembre de 2021
• Anderson, N. (14 de mayo de 2007). “Los ataques DDoS masivos se dirigen a Estonia; Rusia acusó”. Ars
Technica. Obtenido de: https://arstechnica.com/informationtechnology/2007/05/
ataquesddosmasivosobjetivoestoniarusiaacusado/
• Google (sf). “Informe de transparencia de Google. Navegación segura de Google”. Google.

Obtenido de https://transparencyreport.google.com/safebrowsing/overview?unsafe=datase
t:0;serie:malware,phishing;start:1148194800000;end:1587279600000&lu=no seguro
• Google (mayo de 2020). "Estado del sitio de navegación segura". Informe de transparencia de Google. Obtenido
de: https://transparencyreport.google.com/safebrowsing/search?hl=en
• Google (agosto de 2022). "Navegación segura." Informe de transparencia de Google. Obtenido de:
https://transparencyreport.google.com/safebrowsing/search?hl=en
• Google (9 de mayo de 2020). “Dónde se origina el malware”. Informe de transparencia de Google.
Obtenido de: https://transparencyreport.google.com/archive/safebrowsing/
malware?autonomous_scan_history=systemId:18779;conjunto de datos:0&lu=global_
malware&global_malware=tiempo:q
Capítulo 5 217
• Jones, J. (17 de marzo de 2011). “Eliminación de Microsoft de Rustock Botnet”. Microsoft. Obtenido de:
https://www.microsoft.com/security/blog/2011/03/17/microsofttakedown
derustockbotnet/
• Kottler, S. (1 de marzo de 2018). “Informe de incidente DDoS del 28 de febrero”. El blog de GitHub.
Obtenido de: https://github.blog/20180301ddosincidentreport/
• Corporación Microsoft (20122017). Informe de inteligencia de seguridad de Microsoft. Redmond:

Microsoft Corporation
• Corporación Microsoft (20122017). Informe de inteligencia de seguridad de Microsoft Volúmenes 14–21.

Redmond: Corporación Microsoft.
• Corporación Microsoft (20152017). Informe de inteligencia de seguridad de Microsoft Volúmenes 19–23.

Redmond: Corporación Microsoft. Obtenido de: www.microsoft.com/sir
• Corporación Microsoft (2016). Informe de inteligencia de seguridad de Microsoft Volumen 21. Redmond:
Microsoft Corporation. Obtenido de: https://query.prod.cms.rt.microsoft.com/
cms/api/am/binario/RE2GQwi
Microsoft Corporation. Obtenido de: https://query.prod.cms.rt.microsoft.com/
cms/api/am/binario/RWt530
Microsoft Corporation. Recuperado de: https://info.microsoft.com/wwlandingM365
SIRv24ReporteBook.html?lcid=enus
• Microsoft Corporation (8 de mayo de 2020). “Páginas de descargas no autorizadas”. Corporación Microsoft.

Recuperado de: https://www.microsoft.com/securityinsights/Driveby en abril de 2020
• Microsoft Corporation (15 de mayo de 2020). "Ayuda a proteger mi PC con Microsoft
Defender Offline". Corporación Microsoft. Obtenido de https://support.microsoft.com/enus/
windows/ayudaaprotegermipcconmicrosoftdefenderoffline9306d52864bf
46685b80ff533f183d6c
• Microsoft Corporation (8 de mayo de 2020). "Tasas de encuentro de malware". Corporación Microsoft.

Recuperado de: https://www.microsoft.com/securityinsights/Malware en abril de 2020
• Equipo de investigación ATP de Microsoft Defender (9 de agosto de 2018). "Proteger al protector:
fortalecer las defensas de aprendizaje automático contra los ataques de los adversarios".
Microsoft Corporation . Obtenido de: https://www.microsoft.com/enus/security/blog/2018/08/09/
protegerelprotectorendureceraprendizajemáquinadefensascontra
ataques adversarios/
• Pegoraro, R. (9 de agosto de 2019). “Seguimos cayendo en los correos electrónicos de phishing, y Google
acaba de revelar por qué”. Fast Company. Recuperado de: https://www.fastcompany.com/90387855/
Seguimos cayendo en los correos electrónicos de phishing y Google acaba de revelar por qué.
• Solomon, H. (11 de diciembre de 2017). "Base de datos de búsqueda de 1.400 millones de credenciales
robadas encontradas en la web oscura". Mundo de TI de Canadá. Obtenido de: https://www.itworldcanada.
com/article/searchabledatabaseof14billionstolencredentialsfoundon
darkweb/399810
• Primavera, T. (14 de marzo de 2016). “Typosquatters apuntan a los usuarios de Mac con la nueva
estafa de dominio '.om' ”. Mensaje de amenaza. Obtenido de: https://threatpost.com/typosquatterstarget
usuariosdeapplemacconnuevodominioomscam/116768/
• URLhaus (9 de mayo de 2020). "Acerca de." URLhaus. Obtenido de: https://urlhaus.abuse.

ch/acerca de/
• URLhaus (24 de agosto de 2022). "Estadísticas." URLhaus. Recuperado de: https://urlhaus.

abuse.ch/estadísticas/
• Weinert, A. (9 de julio de 2019). “Tu pa$$palabra no importa”. Corporación Microsoft.

Obtenido de: https://techcommunity.microsoft.com/t5/azureactivedirectoryidentity/
tupapalabranoimporta/bap/731984#
• APWG (Grupo de Trabajo AntiPhishing) (nd). "Informes de tendencias de actividad de phishing de APWG
para varios trimestres". APWG. Obtenido de https://apwg.org/trendsreports/
• APWG (Grupo de Trabajo AntiPhishing). (23 de febrero de 2022). “Informes de tendencias de

actividad de phishing del APWG, cuarto trimestre de 2021”. APWG. Obtenido de https://apwg.org/
informes de tendencias/
• APWG (Grupo de Trabajo AntiPhishing). (22 de septiembre de 2021). “Informes de tendencias de

actividad de phishing del APWG, segundo trimestre de 2021”. APWG. Obtenido de https://apwg.org/
informes de tendencias/
• Corporación Microsoft. (octubre, 2021). "Informe de defensa digital de Microsoft".

Microsoft. Obtenido de https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RWMFIi
• Ganacharya, Tanmay. (20 de marzo de 2020). "Protección contra ataques de phishing relacionados
con el coronavirus". Blog de seguridad de Microsoft. Obtenido de: https://www.microsoft.com/security/
blog/2020/03/20/proteccióncontralosataquesdephishingtemáticoscoronavirus/
• JPCERT/CC (25 de mayo de 2022). "Tendencias de sitios de phishing informados y dominios

comprometidos en 2021". JPCERT/CC Ojos. Obtenido de: https://blogs.jpcert.or.jp/en/2022/05/
phishing2021.html
Capítulo 5 219
• Corporación Microsoft. (agosto de 2022). "Señales cibernéticas de agosto de 2022".

Microsoft Corporation . Obtenido de https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/
RE54L7v
• Kan, Michael. (18 de agosto de 2022). “Google evita un ataque DDoS sin precedentes”. PC Mag.
Obtenido de: https://www.pcmag.com/news/googlefendsoffrecordbreaking
ataque ddos
• Goodin, Dan. (28 de enero de 2022). “Microsoft evita un ataque DDoS de 3,47
Tbps que rompe récords”. Ars Technica. Obtenido de: https://arstechnica.com/
informationtechnology/2022/01/microsoftfendsoffrecordbreaking347tbpsddos
ataque/
• Alspach, Kyle. (7 de marzo de 2022). "Ucrania: hemos repelido los ataques DDoS
'ininterrumpidos' de Rusia". Venture Beat. Obtenido de: https://venturebeat.com/
security/ukraine weverepellednonstopddosattacksfromrussia/

6
Los roles que juegan los gobiernos en
La seguridad cibernética
Cuando tenía 17 años, comencé a trabajar en una licenciatura en artes de 4 años, con especialización en
ciencias políticas. Estaba muy interesado en varias facetas de la ciencia política, incluido el federalismo, la
división de poderes en el gobierno, cómo y por qué funcionan las elecciones, la teoría de la autorización, las
relaciones internacionales y la filosofía política. Más tarde, también estudié informática y completé un MBA.
Cuando mi carrera me llevó más y más a la ciberseguridad, no tenía idea de que estudiar ciencias políticas
sería tan valioso en este campo. En aquel entonces, la lectura de obras de Platón, René Descartes, Thomas
Hobbes, David Hume, Karl Marx y George Orwell parecía poco aplicable a las computadoras o a la seguridad
de las mismas. Pero como me di cuenta una o dos décadas después, el campo de la ciberseguridad
evolucionaría hacia la intersección de la tecnología, la seguridad, la privacidad, las regulaciones, la seguridad
pública, la política exterior y la seguridad nacional.
En mi carrera, entre otras experiencias, tuve la suerte de trabajar como uno de los asesores de ciberseguridad
más importantes tanto en Microsoft como en Amazon Web Services (AWS). Dirigí equipos de asesores de
ciberseguridad en ambas empresas. En estos roles, me reuní con muchas de las organizaciones a las que me
refiero en este capítulo. Aprendí mucho en estas discusiones. Quiero compartir algunos de estos conocimientos
con ustedes.
Cuando trabajé como asesor jefe de seguridad global de Microsoft, viajé por todo el mundo reuniéndome con
los CISO y los equipos de seguridad para brindar informes de inteligencia sobre amenazas y analizar cómo
podíamos ayudar a sus programas de seguridad cibernética. Pasaría semanas seguidas en Europa, África,
Asia y América del Sur. También recibí a los CISO de las cuentas más grandes de Microsoft en la sede de
Microsoft en Redmond, Washington.
222 Los roles que juegan los gobiernos en la ciberseguridad
Aprendí mucho al pasar tiempo con estas personas y escuchar cómo pensaban sobre amenazas,
riesgos, mitigaciones y ciberseguridad. Muchas de las cosas que aprendí de ellos informan mi
opinión sobre la ciberseguridad. La sabiduría colectiva de estos CISO fue increíble.
Inicialmente, pasé la mayor parte de mi tiempo con clientes del sector privado que se concentraban en proteger
los datos de la empresa, los activos y, en última instancia, el valor de sus accionistas. Luego comencé a reunirme
con más y más organizaciones del sector público y aprendí que sus desafíos eran mucho más grandes y
posiblemente más importantes que desarrollar productos y servicios para los mercados, crear marcas
significativas, maximizar las ganancias e impulsar el crecimiento.
Cuando me uní a AWS como líder mundial de cumplimiento y seguridad del sector público para
Europa , Medio Oriente y África (EMEA), mi familia y yo nos mudamos a Londres en el Reino Unido .
En este rol, mi trabajo de tiempo completo fue asesorar a gobiernos federales y provinciales/estatales,
instituciones paneuropeas, agencias de seguridad nacional, instituciones educativas y de salud,
organizaciones sin fines de lucro, bancos federales y otras verticales del sector público en EMEA.
Durante los siguientes dos años y medio, viajé a dos o tres ciudades a la semana en EMEA para
reunirme con organizaciones del sector público para hablar sobre ciberseguridad. Pasé mucho tiempo
en ciudades que eran los centros de gobierno de sus países o regiones, como Londres, París, Bruselas,
La Haya, Berlín, Estocolmo, Helsinki, Berna y muchas otras. Puede sonar glamoroso, ¡pero la cantidad
de viajes que hice fue extrema! La cantidad de aviones, trenes, buses y taxis que tomaba todas las semanas era vertigino
En este trabajo, representando a una gran empresa estadounidense muy conocida en EMEA, aprendí mucho
sobre la perspectiva europea de la privacidad. Las expectativas de privacidad impregnan los sectores público y
privado de Europa occidental. He visto a ejecutivos de empresas estadounidenses luchar con esta perspectiva
europea , irritados por lo que consideraban simplemente como un entorno comercial restrictivo creado por
gobiernos "socialistas". Pero como aprendí de mis muchas conversaciones con clientes y compañeros de trabajo
en Alemania específicamente, los eventos de la década de 1930 en Alemania y, posteriormente, la Segunda
Guerra Mundial, influyeron profundamente en el imperativo de privacidad en Alemania y en el resto de Europa.
El Holocausto cambió irrevocablemente Europa y la privacidad se considera una herramienta clave para evitar
que algo así vuelva a ocurrir allí. Desde esta perspectiva, el derecho a la privacidad de los ciudadanos es mucho
más importante que optimizar los entornos regulatorios para obtener resultados comerciales exitosos.
Cuando las empresas estadounidenses no entienden y no prestan atención a esta perspectiva, se crea una
tensión evidente entre sus objetivos comerciales y el tipo de sociedad en la que los europeos quieren vivir. Esto
se refleja en regulaciones como el Reglamento General de Protección de Datos (GDPR ) .
Capítulo 6 223
Después de trabajar en EMEA durante casi tres años, mi familia y yo nos mudamos de regreso a Seattle, donde
trabajé como líder de cumplimiento y seguridad global de AWS para el sector público mundial. En este cargo,
trabajé con equipos de asesores de ciberseguridad en todo el mundo apoyando a los equipos de ventas de campo
de AWS en EE. UU., Canadá, América del Sur, Asia y EMEA. En estos roles crecí mucho profesional y
personalmente. También terminé con una comprensión profunda de los desafíos únicos que enfrentan las
organizaciones del sector público con el cumplimiento normativo, la privacidad y la ciberseguridad.
Cuando se trata de seguridad cibernética, muchos de los CISO a los que he asesorado confían en los gobiernos
para ayudarlos a lograr sus objetivos al establecer y regular los estándares de seguridad de la industria, mientras
que otros ven a los gobiernos como una fuente de inteligencia, orientación y protección contra amenazas; mientras
que otros CISO ven a los gobiernos como amenazas para sus organizaciones. ¿Qué papel juegan realmente los
gobiernos en la ciberseguridad? Después de miles de conversaciones con organizaciones del sector público y
privado de todo el mundo sobre ciberseguridad, pensé en compartir algunas ideas que podrían ayudar a responder
esta pregunta. Exploremos esto a continuación.
La búsqueda de la felicidad
Antes de profundizar en los roles que desempeñan los gobiernos en la seguridad cibernética y por qué desempeñan
esos roles, creo que es un contexto útil revisar las razones por las que existen los gobiernos en primer lugar. Sin
este contexto, he visto a algunos profesionales de la seguridad cibernética esforzarse por entender lo que el gobierno
medios para sus programas de seguridad y para la industria en general.
Los filósofos políticos han pontificado sobre el propósito del gobierno durante siglos y ciertamente no
intentaré duplicar su trabajo aquí. La teoría del contrato social ayuda a preparar el escenario para la
dirección que quiero llevarte. El libro Leviatán de Thomas Hobbes , publicado por primera vez en 1651,
describe un tiempo antes de que los gobiernos y los derechos que otorgaban existieran como un "estado
de naturaleza" donde cada persona tenía un derecho natural a todo. Es decir, no había propiedad privada:
la propiedad era tuya siempre que pudieras evitar que otros te la quitaran. Posteriormente, hubo guerra
perpetua y violencia. El resultado fue que la vida era “solitaria, pobre, desagradable, brutal y corta” (Hobbes, 2008).
Sin embargo, si cada persona estuviera dispuesta a renunciar a su derecho natural a todo a través de un contrato
social entre sí, el orden político y la seguridad mejorarían la vida de todos. En otras palabras, debido a que cada
uno de nosotros ha renunciado a su derecho natural a todo y ha permitido que un gobierno reine sobre nosotros,
nos beneficiamos de una sociedad civil con seguridad.
Este mismo estado de naturaleza existe entre países. Posteriormente, los países necesitan militares para proteger
sus intereses nacionales y el derecho internacional y las relaciones internacionales se utilizan para tratar de manejar
las tensiones entre países para que la guerra sea menos frecuente.
Por supuesto, estoy pasando por alto muchos detalles aquí y no menciono trabajos igualmente
interesantes de John Locke, JeanJacques Rousseau y muchos otros, pero se supone que este es un
libro sobre ciberseguridad, ¿no ? El Leviatán de Hobbes establece una “teoría de la autorización”: el
“cómo” y el “por qué” existen los gobiernos.
Avance rápido unos 125 años y la siguiente declaración se incluyó en el nuevo escrito
Declaración de Independencia de los Estados Unidos, relativa a los derechos otorgados a las personas por su Creador y
que el gobierno debe proteger:
Sostenemos que estas verdades son evidentes, que todos los hombres son creados
iguales, que están dotados por su Creador de ciertos derechos inalienables, que entre
estos están la vida, la libertad y la búsqueda de la felicidad”. – (La Declaración de
Independencia de los Estados Unidos, 1776).
Por supuesto, EE. UU. no es el único país donde se tuvo un discurso político sobre los derechos de los ciudadanos y el
papel del gobierno; hay varios conceptos similares utilizados por otros países. Algunos ejemplos incluyen la Carta
Canadiense de Derechos y Libertades que contiene “vida, libertad, seguridad de la persona” (Carta Canadiense de
Derechos y Libertades, s 7, Parte 2 de la Ley de Constitución, 1982) y el lema nacional de Francia, “libertad, igualdad,
fraternidad” (Embajada de Francia en los EE. UU., 2013).
Si los gobiernos existen para proporcionar a sus ciudadanos tales beneficios, ¿cómo se las arreglan para hacerlo? La
respuesta simple de hoy en día es que establecen ministerios, departamentos y/o agencias para realizar funciones
específicas y dividen el trabajo de servir a los ciudadanos entre ellos. Deja que te dé algunos ejemplos:
• El Departamento de Defensa de los EE. UU., cuya misión es “proporcionar las fuerzas militares necesarias para
impedir la guerra y garantizar la seguridad de nuestra nación” (Departamento de Defensa de los EE. UU., 2022).
• Asuntos Globales de Canadá, quienes “definen, dan forma y promueven los intereses y valores de Canadá en un
entorno global complejo. Gestionamos las relaciones diplomáticas, promovemos el comercio internacional y
brindamos asistencia consular. Lideramos los esfuerzos internacionales de desarrollo, humanitarios y de asistencia
para la paz y la seguridad. También contribuimos a la seguridad nacional y al desarrollo del derecho
internacional” (Gobierno de Canadá, 2022).
• El papel de la Policía Federal Australiana (AFP) es “hacer cumplir la ley penal de la Commonwealth,
contribuir a combatir el crimen complejo, transnacional, grave y organizado que afecta la
seguridad nacional de Australia, y proteger los intereses de la Commonwealth de la actividad
criminal en Australia y en el extranjero” (Policía Federal Australiana, 2022).
Capítulo 6 225
• En el Reino Unido, el Ministerio de Justicia tiene tres prioridades que incluyen, "proteger al público
de los delincuentes graves y mejorar la seguridad de nuestras prisiones, reducir la reincidencia,
brindar acceso rápido a la justicia" (Gobierno del Reino Unido, 2022).
• En Alemania, la Oficina Federal de Seguridad de la Información (conocida como BSI) tiene el objetivo
declarado de “promover de manera preventiva la información y la seguridad cibernética para permitir y
promover el uso seguro de la tecnología de la información y la comunicación en la sociedad” ( Oficina
Federal de Seguridad de la Información de Alemania, 2022).
Los ejemplos en esta lista son de diferentes países, pero la mayoría de los países desarrollados grandes tienen
ministerios, departamentos o agencias que desempeñan todos los roles que se ven en la lista, así como muchos más.
Idealmente, la suma de las partes del gobierno de un país debería respaldar los objetivos generales del gobierno,
como la búsqueda de la felicidad de los ciudadanos, por ejemplo. Me doy cuenta de que he simplificado muchos
conceptos a lo largo del camino y ni siquiera he tocado las diferencias entre el gobierno nacional, provincial/estatal,
regional y local. Tampoco he discutido diferentes filosofías políticas o sistemas de gobierno, como el comunismo,
y cómo los objetivos de los gobiernos pueden ser diferentes cuando se basan en diferentes filosofías políticas.
Tuve la oportunidad de visitar China y Rusia en mi carrera para reunirme con organizaciones del sector público y
privado, hablar en eventos de seguridad cibernética y hacer entrevistas de prensa. Los profesionales de la
ciberseguridad en estos países definitivamente operan en diferentes entornos políticos, económicos, culturales y
sociales. Sin embargo, al igual que las democracias occidentales, también tienen adversarios con muchos recursos
y, en consecuencia, también deben confiar en que sus gobiernos desempeñen funciones críticas en la seguridad
cibernética de sus naciones, las regiones y los municipios dentro de sus fronteras y sus organizaciones individuales.
Es posible que se organicen de manera diferente, pero creo que verá roles y funciones de seguridad cibernética
muy similares en diferentes gobiernos grandes y desarrollados de todo el mundo.
Creo que he proporcionado suficiente contexto de alto nivel para abordar la pregunta central: ¿qué papel juegan
los gobiernos para proporcionar ciberseguridad a sus ciudadanos?
En mis conversaciones con los CISO, a menudo los escuché usar el término "gobierno" de una manera que sugiere
que es una cosa. Por ejemplo, “el gobierno debería hacer esto” o “el gobierno tomó la medida equivocada”. Pero
como ya he comentado, los gobiernos suelen estar organizados en muchas partes diferentes. También es
importante tener en cuenta que algunas partes del gobierno pueden llevar a cabo sus agendas de maneras que
potencialmente entren en conflicto con otras partes del mismo gobierno. Por ejemplo, una agencia con cierta
responsabilidad en la seguridad pública podría participar en los esfuerzos de la industria para reducir las
vulnerabilidades en el software y generar conciencia entre los consumidores para mantener sus sistemas actualizados.
Reducir la cantidad de vulnerabilidades en los productos que usan los consumidores y mantener los sistemas de los consumidores
parcheados significa menos explotación criminal de los ciudadanos, menos delitos que las fuerzas del orden deben gestionar, menos
casos penales en los tribunales, menos costos asociados para la sociedad, etc. Pero en otra parte del mismo gobierno que tiene
cierta responsabilidad por la seguridad nacional, intentan de manera proactiva descubrir nuevas vulnerabilidades y comprar nuevas
vulnerabilidades de otros investigadores de seguridad. En lugar de informar las vulnerabilidades a los proveedores que pueden
solucionarlas, como recomiendan la agencia de seguridad pública y la industria, acumulan vulnerabilidades en secreto para que
puedan usarse para atacar a los adversarios en un contexto de seguridad nacional. Es importante reconocer que estas dos agendas
contrastantes son importantes y apoyan la búsqueda de la felicidad de los ciudadanos.
Si bien puede parecer inocuo, referirse a un gobierno como una entidad simple y única en lugar de un grupo de departamentos o
ministerios individuales con estatutos diferentes, a veces en conflicto, a menudo conduce a conclusiones demasiado simplistas en un
contexto de seguridad cibernética. En mi experiencia, esto tendía a ser especialmente cierto en las declaraciones hechas sobre el
gobierno de los EE. UU. por profesionales de la seguridad fuera de los EE. UU. Una vez que consideraban que “el gobierno de los
EE. UU.” era una amenaza para su organización, ese pensamiento simplista significaba que todos los departamentos gubernamentales
y todas las empresas del sector privado que hacían negocios con el gobierno eran, en el mejor de los casos, sospechosos. Culpa
por asociación: el software, el hardware, los servicios en la nube y las tecnologías de encriptación de repente se vuelven poco
confiables simplemente porque todo el gobierno de EE. UU. fue etiquetado como no confiable y como una amenaza. Tuve esta
conversación con tantos CISO en EMEA que dediqué un capítulo completo de este libro a este tema: Capítulo
7, Acceso del gobierno a los datos.
Ahora echemos un vistazo más de cerca a algunas de las funciones que desempeñan los gobiernos en la ciberseguridad.
Los gobiernos como participantes del mercado de la ciberseguridad

Los gobiernos participan en todo tipo de mercados. Licencian propiedad intelectual, arriendan, compran y venden activos tales como
bienes raíces, valores, energía, publicidad, bienes y servicios. Los gobiernos adquieren y administran flotas de automóviles, barcos
y aeronaves. Los gobiernos también son muy activos en los mercados laborales, donde suelen ser los principales empleadores que
contratan y despiden empleados, trabajadores por contrato, agencias y otras partes externas. Las economías de la mayoría de los
países dependen de los gobiernos como fuente principal de gasto y empleo.
El alcance y la escala de los gobiernos nacionales suelen eclipsar incluso a las empresas más grandes del sector privado dentro de
sus fronteras. Recuerde que los gobiernos nacionales suelen tener numerosos departamentos o ministerios que representan brazos
de las fuerzas armadas, la policía nacional, los tribunales nacionales, las capacidades de inteligencia nacional, los bancos nacionales,
las instituciones de salud, las instituciones educativas, la energía y muchas otras funciones.
Capítulo 6 227
Para operar a una escala tan grande, se requieren abundantes recursos. Por ejemplo, el gasto presupuestario
proyectado para el gobierno federal de EE. UU. en 2022 fue de 7,2 billones de dólares (USASpending.gov, 2022).
Los gobiernos también requieren tecnología de la información y ciberseguridad. Todos los departamentos y agencias
gubernamentales deben contar con las personas, los procesos y las tecnologías necesarias para enviar sus estatutos y para
proteger, detectar, responder y recuperarse de las amenazas modernas. Para ello, deben adquirir muchas de las mismas
tecnologías que las empresas que operan en el sector privado, como clientes, servidores, sistemas operativos, protección de
terminales, IDS/IPS, sistemas de gestión de eventos e información de seguridad (SIEM), capacidades de copia de seguridad/
restauración, servicios en la nube, servicios de seguridad gestionados y otros . La combinación de estos factores suele otorgar
a los gobiernos un inmenso poder adquisitivo.
Para aprovechar esto, la mayoría de las grandes empresas de tecnología tienen grupos de ventas, servicios profesionales y
soporte dedicados a las cuentas del sector público en cada país donde hacen negocios. Trabajé con grupos dedicados del
sector público tanto en Microsoft como en AWS. Estos equipos dedicados tienden a comprender y atender a los clientes del
sector público mucho mejor que simplemente tratarlos como si fueran clientes del sector comercial. La mayoría de los clientes
del sector público no están motivados por las ganancias como suelen estarlo los clientes del sector privado. Apoyar a los
ciudadanos y su búsqueda de la felicidad tiende a ser la fuerza motivadora de los clientes del sector público. Comprender cómo
los gobiernos adquieren tecnologías y servicios es clave para competir por su negocio.
Si bien los gobiernos adquieren muchas tecnologías y capacidades de ciberseguridad, también requieren la experiencia técnica
para desarrollar, implementar y operar capacidades de TI y ciberseguridad. Sin embargo, los gobiernos deben competir por el
talento técnico con el sector privado. En términos generales, las empresas grandes y rentables del sector privado generalmente
pueden permitirse el lujo de los mejores talentos de la industria, mientras que la mayoría de los departamentos gubernamentales
generalmente no pueden. Las empresas de tecnología utilizan acciones, opciones sobre acciones y/o grandes bonos anuales
en efectivo como partes clave de sus paquetes de compensación total para atraer y retener a los mejores talentos. Mientras
tanto, la mayoría de los gobiernos intentan constantemente restringir o reducir sus presupuestos de TI y hacer más con menos
recursos, aprovechando la deslocalización, así como el uso de servicios de nube administrados y servicios de seguridad
administrados. Eso no significa que los gobiernos no atraigan y retengan a personas muy talentosas; es común ver algunos
puestos de departamentos gubernamentales en eventos de la industria de ciberseguridad enfocados en reclutar los mismos
grupos de asistentes que las organizaciones del sector comercial.
El poder adquisitivo de los gobiernos es tan grande que normalmente requieren que sus socios de la cadena de suministro
cumplan con estándares específicos. A continuación, examinemos el papel de los gobiernos como organismos de normalización.
Los gobiernos como organismos de normalización

El término “estándares” es un término sobrecargado en ciberseguridad. Significa diferentes cosas para diferentes
personas. Por ejemplo, la guía popular a menudo se denomina estándar. En este contexto, la orientación es un
conjunto de recomendaciones para resolver un problema, mientras que los estándares son especificaciones sobre
cómo se deben hacer las cosas y se utilizan en evaluaciones comparativas. En esta sección, lo uso con un
significado amplio, que no se limita estrictamente a lo que producen las organizaciones que desarrollan estándares formales.
Debido a que los gobiernos adquieren tantos bienes y servicios, es importante que establezcan y mantengan
estándares para garantizar niveles mínimos mensurables de funcionalidad y calidad en las cosas que adquieren.
Esto también se aplica a las capacidades de ciberseguridad. Así es como el Instituto Nacional de Estándares y
Tecnología (NIST) describe los estándares de ciberseguridad.
El objetivo de los estándares de seguridad cibernética es mejorar la seguridad de los sistemas,
redes e infraestructuras críticas de tecnología de la información (TI). Un estándar de seguridad
cibernética define los requisitos tanto funcionales como de garantía dentro de un entorno de
producto, sistema, proceso o tecnología. Los estándares de seguridad cibernética bien
desarrollados permiten la coherencia entre los desarrolladores de productos y sirven como una
métrica confiable para comprar productos de seguridad”. (Scarfone, K., Benigni, D. y Grance, T., 2009)
NIST es parte del Departamento de Comercio de los Estados Unidos. Su misión es “promover la innovación y la
competitividad industrial de EE. UU. mediante el avance de la ciencia, los estándares y la tecnología de medición
de manera que aumenten la seguridad económica y mejoren nuestra calidad de vida” (NIST, sin fecha). La
declaración de visión de NIST es: “NIST será el líder mundial en la creación de soluciones de medición críticas y
la promoción de estándares equitativos. Nuestros esfuerzos estimulan la innovación, fomentan la competitividad
industrial y mejoran la calidad de vida” (NIST, sin fecha).
La mayoría de los CISO a los que asesoré a lo largo de los años solían utilizar los estándares de ciberseguridad
del NIST en al menos tres formas. Primero, si su organización hacía negocios con el gobierno federal de EE. UU.
o aspiraba a hacerlo, seleccionaría uno o más estándares NIST que fueran aplicables al producto o servicio que
deseaba vender y trabajaría para cumplir con los requisitos de esos estándares.
Una segunda forma en que muchos CISO aprovecharon los estándares NIST fue asegurarse de que sus conjuntos de control estuvieran completos.
Compararían los controles implementados en sus propiedades de TI y su configuración con los estándares NIST
para asegurarse de que no tuvieran brechas obvias. Algunas organizaciones van un paso más allá y utilizan el
cumplimiento de los estándares como su estrategia de ciberseguridad empresarial. Discutiré esta estrategia, a la
que llamo "Cumplimiento como estrategia de seguridad", en detalle en el Capítulo 9, Estrategias de seguridad cibernética.
Capítulo 6 229
La tercera forma en que vi que muchos CISO usaban los estándares NIST fue para demostrar que estaban administrando
sus programas de seguridad de una manera que cumplía con los estrictos estándares de seguridad cibernética del
gobierno de los EE. UU., ya sea que hicieran negocios con el gobierno de los EE. UU. o no. Si estos CISO tuvieran una
violación de datos bajo su vigilancia, podrían señalar el cumplimiento de los estándares NIST como evidencia de que
no eran atípicos y que estaban administrando su programa de seguridad cibernética de manera responsable y en
alineación con otros en la industria. Esto podría ayudar a mitigar los posibles daños financieros y reputacionales
negativos y los resultados regulatorios que acompañan a las filtraciones de datos con tanta frecuencia en la actualidad.
Los estándares NIST que encontré con mayor frecuencia en estos tres contextos incluyeron NIST SP 80053
y NIST SP 800171. Pasé meses ayudando a clientes de diferentes países a planificar e implementar el cumplimiento
de NIST SP 80053 en sus entornos de AWS. Si no ha visto NIST SP 80053, no es una lista de verificación simple que
deben seguir los equipos de TI. La revisión 5 tiene 492 páginas que incluyen 357 páginas de controles. Ante tanta
complejidad, los procesos repetibles y la automatización se convierten en tus mejores amigos. Hablaré de esto con más
detalle en el Capítulo 12, Enfoques modernos para la seguridad y el cumplimiento.
Además de los estándares de ciberseguridad, NIST también ejecuta programas y publica una gran
cantidad de marcos útiles y excelente información. Algunos de los recursos que utilicé mucho con los clientes
incluir:
• Programa de validación de módulos criptográficos (CMVP) del NIST : proporciona a las agencias federales
de EE. UU. una “métrica de seguridad para usar en la adquisición de equipos que contienen módulos
criptográficos validados” (NIST, sin fecha). Muchos equipos de seguridad exigen que los módulos de
cifrado en el hardware que adquieren y los kernels de los sistemas operativos que utilizan se validen
conforme a FIPS 1402 o, más recientemente, FIPS 1403. El CMVP proporciona una base de datos de
búsqueda de proveedores y sus productos que han sido validados.
• El marco de seguridad cibernética (CSF) del NIST: proporciona una guía útil para las organizaciones que están
iniciando un programa de seguridad cibernética o que desean mejorar su programa existente. El CSF incluye
cinco funciones clave en las que deben centrarse los equipos de seguridad, incluidas identificar, proteger,
detectar, responder y recuperar. Puede encontrar más información en la Publicación especial 1271 del NIST
(NIST, agosto de 2021).
Por supuesto, el gobierno de EE. UU. no es la única organización que publica estándares de ciberseguridad.
Este es un buen lugar para insertar un chiste para los geeks: “Lo bueno de los estándares es que hay tantos para
elegir” (Tanenbaum, Andrew S. nd). De hecho, el otro organismo normativo importante para la ciberseguridad es una
organización no gubernamental. Muchos de los clientes que conocí fuera de los EE. UU., que no hacían negocios con
el gobierno de los EE. UU., optaron por basarse en los estándares de la Organización Internacional de Normalización
(ISO) en lugar de NIST.

Para ellos, NIST estaba demasiado centrado en el gobierno de EE. UU. e ISO se consideraba más
reconocida internacionalmente. Los CISO con los que trabajé generalmente elegían uno u otro y
basaban sus operaciones y auditoría interna en él. Es decir, eran una "tienda NIST" o una "tienda ISO".
Sin embargo, algunos de los CISO que conocí habían adoptado los estándares de NIST e ISO por varias
razones; la más común es que los clientes a los que vendían sus productos eran globales, no solo
ubicados en los EE. UU. Posteriormente, intentaron cumplir con los estándares de ambas organizaciones
para atraer a la mayor cantidad posible de clientes en todo el mundo.
ISO tiene su sede en Ginebra, Suiza. Quizás se pregunte por qué el acrónimo de la Organización
Internacional de Normalización es ISO en lugar de IOS. Puede imaginar que esta pregunta se hace
mucho, por lo que ISO publica la respuesta en su sitio web.
Debido a que 'Organización Internacional de Normalización' tendría diferentes

siglas en diferentes idiomas (IOS en inglés, OIN en francés para Organización
internacional de normalización), nuestros fundadores decidieron darle la forma
abreviada ISO. ISO se deriva del griego 'isos', que significa igual. Sea cual sea el
país, sea cual sea el idioma, siempre somos ISO”. (ISO, sin fecha)
Note el énfasis en “ser iguales”. Esto se debe a que la ISO está compuesta por miembros de diferentes
países, todos los cuales tienen influencia sobre las normas basadas en el consenso que publica la ISO.
ISO se describe a sí mismo de esta manera,
ISO es una organización internacional no gubernamental independiente con una membresía
de 167 organismos nacionales de normalización. A través de sus miembros, reúne a expertos
para compartir conocimientos y desarrollar Normas Internacionales voluntarias, basadas en el
consenso y relevantes para el mercado que respaldan la innovación y brindan soluciones a
los desafíos globales”. (ISO, sin fecha)
Actualmente, ISO tiene 24 481 normas, 167 miembros que representan cada uno a un país y 808 comités
y subcomités técnicos para gestionar el desarrollo de normas (ISO, sin fecha). Las normas ISO con las
que me encontré con más frecuencia al hablar con los CISO incluían la familia de normas ISO/IEC 27000,
que incluye, entre otras, la norma ISO/IEC 27001 sobre gestión de la seguridad de la información y la ISO/
IEC 27018, “Tecnología de la información — Técnicas de seguridad — Código de prácticas para la
protección de información de identificación personal (PII) en nubes públicas que actúan como procesadores
de PII” (ISO, 2019 ) .
Capítulo 6 231
Otro ejemplo de una organización no gubernamental que desarrolla estándares es el Grupo de Trabajo de Ingeniería
de Internet (IETF).
El Grupo de trabajo de ingeniería de Internet (IETF) es una gran comunidad internacional abierta de diseñadores,
operadores, proveedores e investigadores de redes preocupados por la evolución de la arquitectura de Internet
y el buen funcionamiento de Internet”.
(Grupo de Trabajo de Ingeniería de Internet, sin fecha)
Puede conocer la misión del IETF en: https://www.ietf.org/about/mission/.
Pero volvamos a los gobiernos que actúan como organismos de normalización. Los gobiernos de otros países,
además de los EE. UU., también tienen organismos de estándares que publican estándares de seguridad cibernética
para organizaciones en sus regiones y sus socios de la cadena de suministro. Un gran ejemplo es la Oficina Federal
de Seguridad de la Información (conocida como BSI) en Alemania. Tuve la oportunidad de reunirme con
representantes de BSI varias veces a lo largo de los años. Alemania es el mercado individual más grande de la Unión Europea
(UE). Esto significa que las normas publicadas por BSI son muy influyentes en Alemania y en la UE. Posteriormente,
los grandes proveedores de tecnología global como Microsoft y AWS, entre otros, así como los proveedores de
tecnología con sede en Europa Occidental, prestan mucha atención a la guía y los estándares que publica BSI. El
BSI describe su misión de esta manera,
“Asumimos la responsabilidad de todos los temas relacionados con la seguridad de la información. Protegemos a la
administración federal de los ataques cibernéticos y monitoreamos la situación actual de seguridad cibernética a nivel nacional
e internacional, investigamos y evaluamos los riesgos de seguridad existentes y anticipamos el impacto de nuevos desarrollos.
Con base en este conocimiento, apoyamos a ciudadanos, empresas y autoridades a nivel federal, estatal y municipal con
servicios en las áreas medulares de información, consultoría, protección operativa y desarrollo, incluyendo normalización [sic]
y certificación”. (BSI, 2022)
BSI ofrece estándares y certificaciones en numerosas áreas, que incluyen:
• Estándares mínimos BSI para TI de la Administración Federal
• eSalud
• RFID
• Identidades Electrónicas
• Medición inteligente
• Transacciones de pago electrónico

• Especificaciones criptográficas
• Otros
La mayoría de los países desarrollados grandes tienen alguna oficina o agencia responsable de desarrollar
estándares de seguridad cibernética para el uso de su gobierno nacional o más ampliamente en todas las industrias
dentro de sus fronteras. Sin embargo, en muchos casos he encontrado que son similares a NIST SP 80053. Esta
es otra razón por la que muchos de los CISO que conozco adoptan NIST SP 80053 como el estándar al que intentan ajustarse.
A continuación, examinemos el papel de los gobiernos como ejecutores.
Los gobiernos como ejecutores

Los gobiernos proporcionan al menos dos funciones diferentes en su papel como ejecutores, en un contexto de
seguridad cibernética: reguladores y aplicación de la ley. Veamos rápidamente ambas funciones.
Reguladores
Acabamos de hablar de los gobiernos como organismos de normalización. Como discutimos, los estándares son
importantes no solo para fines de contratación pública, sino también para los mercados más amplios. Sin embargo,
el hecho de que un organismo de estándares publique algunos estándares no significa necesariamente que las
organizaciones del sector público y privado dediquen tiempo, esfuerzo o presupuesto para cumplir con esos estándares.
Por lo general, debe haber algún tipo de beneficio o incentivo claro para que las organizaciones cambien la forma
en que operan.
A veces, los mercados o las industrias son demasiado lentos para cambiar por sí mismos y se produce una "falla
del mercado". En casos como este, los gobiernos usan las herramientas que tienen en sus cajas de herramientas;
en el caso de la ciberseguridad esto incluye la regulación. Las regulaciones típicamente implementan restricciones
con las que las industrias deben cumplir. Los ejemplos de estándares regulados para fines de ciberseguridad
incluyen la Ley de Privacidad del Consumidor de California, la Ley Federal de Modernización de la Seguridad de la
Información (FISMA) en los EE. UU. y el Reglamento General de Protección de Datos (GDPR) en la UE y el
Espacio Económico Europeo (EEE). Para darle una idea de los dientes que el Parlamento Europeo puso en el
GDPR, el incumplimiento de este podría resultar en una multa de hasta 20 millones de euros o hasta el 4% de los
ingresos mundiales anuales, lo que sea mayor . Se han impuesto más de 900 multas administrativas relacionadas
con el incumplimiento del RGPD, la mayor parte de las cuales se otorgaron a grandes empresas de alta tecnología
como Amazon (877 millones de dólares), WhatsApp (255 millones de dólares), Google Ireland (102 millones de
dólares), Facebook (68 millones de dólares) y muchas otras (Tessian, 5 de mayo de 2022). Evitar estas multas
administrativas es el incentivo para que las organizaciones del sector público y privado cumplan con este reglamento.
estándar.
Capítulo 6 233
Como dicen, una marea alta levanta todos los barcos. El alcance extraterritorial de GDPR ha ayudado a mejorar los
estándares y prácticas de protección de datos en todo el mundo. La mayoría de los equipos de cumplimiento con los
que hablé se enfocaban en cumplir con el estándar de protección de datos más estricto, que es el RGPD, que luego
hace que cumplir con otros estándares menos estrictos generalmente sea mucho más fácil y menos costoso.
El ransomware es otra área donde la regulación está cambiando el comportamiento del mercado. A raíz del ataque de
ransomware de Colonial Pipeline Company que cerró un sistema de tuberías en el este de los EE. UU. durante varios
días en mayo de 2021, surgieron llamados a una nueva regulación. Estos son algunos ejemplos de actividades
relacionadas con la regulación que resultan de este ciberataque:
• La Comisión Federal de Regulación de Energía (FERC) de EE. UU. renovó las convocatorias de
estándares obligatorios de ciberseguridad para la infraestructura de tuberías de los Estados Unidos
( Comisión Federal de Regulación de Energía, 2021).
• La Agencia de Protección Ambiental de EE. UU. (EPA) emitió una segunda exención de combustible de
emergencia destinada a aliviar aún más la escasez de combustible en los estados de EE. UU. afectados por
el cierre del oleoducto (Agencia de Protección Ambiental de EE. UU., 2021). Esto eliminó los requisitos para
la gasolina convencional de baja volatilidad y la gasolina reformulada (RFG) en una docena de estados.
• El Departamento de Seguridad Nacional aprobó una exención temporal de la Ley Jones para aliviar las
restricciones de suministro de petróleo en partes específicas de la costa este de EE. UU. (Departamento de
Seguridad Nacional de EE. UU., 2021). Esta exención permitió el transporte de productos derivados del petróleo entre los
Costa del Golfo y Costa Este de los EE. UU.
• El Departamento de Transporte de EE. UU. (DOT, por sus siglas en inglés) permitió a los estados usar las carreteras
interestatales para transportar cargas con sobrepeso de gasolina y otros combustibles, para ayudar a abordar la escasez (EE. UU.
Departamento de Transporte, 2021).
• El Presidente de los Estados Unidos firmó una Orden Ejecutiva para Mejorar la Ciberseguridad de la Nación (La
Casa Blanca, 2021). Esta orden ejecutiva tuvo un efecto profundo en la forma en que se esperaba que el
gobierno federal de los EE. UU. administrara la seguridad cibernética en el futuro, incluidos todos sus
proveedores en su cadena de suministro. Los pilares de alto nivel o áreas de enfoque de la orden ejecutiva
incluyeron (La Casa Blanca, 2021):
• Eliminar las barreras al intercambio de información sobre amenazas entre el gobierno y el

Sector privado.
• Modernizar e implementar estándares de ciberseguridad más estrictos en el gobierno federal

gobierno
• Mejorar la seguridad de la cadena de suministro de software.
• Establecer una Junta de Revisión de Seguridad Cibernética.
• Crear un libro de jugadas estándar para responder a incidentes cibernéticos.
• Mejorar la Detección de Incidentes de Ciberseguridad en las Redes del Gobierno Federal.
• Mejorar las capacidades de investigación y remediación.
Por lo general, un ataque cibernético a una empresa con sede en los EE. UU. no generaría tanta actividad relacionada con la
regulación. Pero en este caso, la convergencia de otro ataque de ransomware de alto perfil, una demanda de rescate de varios
millones de dólares que se pagó potencialmente en violación de las regulaciones de la Oficina de Control de Activos Extranjeros
(OFAC) del Departamento del Tesoro de EE. UU., un ataque a una empresa en una industria que se consideraba infraestructura
crítica de EE. UU., la interrupción de casi la mitad del suministro de gas en la costa este de EE. UU. y la ubicación de los atacantes
en Rusia contribuyeron a este crescendo de la actividad gubernamental . En el centro de toda esta actividad estaba la
incertidumbre en torno a la motivación de los atacantes: ¿era simplemente una ganancia o era un ataque patrocinado por el
estado? Incluso después de que el ataque se atribuyera a atacantes en Rusia que usaban el ransomware DarkSide, sus
motivaciones aún eran sospechosas. Como mencioné en el Capítulo 4, La evolución del malware, los atacantes emitieron un
comunicado para tratar de dejar claras sus motivaciones y reducir la situación.
Observe cómo algunas de las actividades relacionadas con la regulación que resultaron de este ataque de ransomware fueron
consecuencias no deseadas, facilitando o eliminando las restricciones regulatorias para mitigar los efectos del ataque. ¿Y si
también fuera posible lo contrario? ¿Qué pasaría si los atacantes pudieran usar las regulaciones para atacar a sus víctimas? Por
ejemplo, en un escenario completamente hipotético, un delincuente notó que una gran empresa multinacional estaba registrando
información personal de sus clientes, que incluía a residentes de la UE, en un libro de contabilidad inmutable de blockchain.
Aunque la empresa podría tener razones comerciales completamente legítimas para hacer esto, la propiedad inmutable de la
base de datos que eligieron usar hace que sea imposible que la empresa elimine la información del cliente si un cliente con sede
en la UE lo solicita. Al darse cuenta de que este paso en falso probablemente viola el RGPD y que podría costarle a la empresa
decenas de millones de dólares en multas administrativas, el delincuente solicita un rescate a la empresa a cambio de su promesa
de no presentar una queja de privacidad ante una autoridad de protección de datos en la UE. Interesante enigma!
Capítulo 6 235
Cumplimiento de la ley
La otra función que realizan los gobiernos en su papel de ejecutores es la aplicación de la ley. Se supone que la
aplicación de la ley es un impedimento para el crimen. Es decir, las consecuencias de un delito grave son el arresto
y el enjuiciamiento, cosas que la mayoría de la gente quiere evitar. Sin embargo, de la misma manera que Internet
nivela el campo de juego para que las personas y las pequeñas empresas compitan con las grandes empresas,
permite la delincuencia en una escala nunca antes imaginada. Internet permite que individuos o pequeños grupos
ataquen simultáneamente a un gran número de personas, empresas e instituciones.
Esta es la primera vez en la historia humana donde un número relativamente pequeño de atacantes tiene igualdad
de condiciones que les permite atacar organizaciones mucho más grandes en números mucho más grandes.
Un individuo puede perpetrar un gran ataque DDoS o un ataque de descarga oculta contra organizaciones con
muchos recursos y tener éxito.
Hay al menos algunas razones por las que este es el caso. Primero, Internet es una red global que permite que los
ataques perpetren sus ataques desde casi cualquier parte del mundo contra víctimas ubicadas en casi cualquier
lugar. Los delincuentes han utilizado las fronteras para evadir el arresto y el enjuiciamiento durante siglos e Internet
permite esto a gran escala. Por ejemplo, dada la situación actual con Rusia invadiendo Ucrania y todas las
sanciones impuestas, es muy poco probable que Rusia priorice la investigación de delitos cibernéticos contra
organizaciones en países occidentales. Lo mismo puede decirse de la República Popular Democrática de Corea
(también conocida como Corea del Norte) y China.
La segunda razón por la que la aplicación de la ley no es un impedimento para los delitos cibernéticos graves es el
desafío de la atribución fuerte que discutí anteriormente en este libro. Si las víctimas no saben quién las está
atacando, ¿cómo pueden determinar qué es una respuesta proporcional? ¿Qué gobierno (nacional, regional,
municipal) debería ayudar con la respuesta y qué ministerio, departamento u organismo específico debería liderar?
¿Es el ataque un asunto de seguridad nacional o un asunto criminal? Si se trata de un asunto penal, ¿qué
organismos encargados de hacer cumplir la ley deberían participar: la policía nacional (como el FBI en los EE. UU.),
la policía regional (estatal/provincial) o la policía municipal? ¿Qué jurisdicción debe dirigir la investigación: dónde se
encuentran las víctimas, dónde se originó el ataque o dónde se sospecha que tienen su sede los atacantes?
Aún así, si las fuerzas del orden no hacen un esfuerzo serio para investigar, arrestar y enjuiciar a los
ciberdelincuentes, entonces realmente no hay disuasión en absoluto. Por supuesto, las fuerzas del orden en la
mayoría de los países importantes toman los delitos cibernéticos muy en serio debido a las consecuencias para las
víctimas, sus comunidades, industrias, economías y la sociedad.
En los EE. UU., varias agencias federales tienen autoridad para emprender acciones de aplicación de la ley
relacionadas con el delito cibernético, incluida la Oficina Federal de Investigaciones (FBI), la Comisión de Bolsa y
Valores (SEC), el Servicio Secreto, la Oficina del Fiscal de los EE. UU., el Servicio de Impuestos Internos (IRS), la
Comisión Federal de Comercio (FTC) y el Servicio de Inmigración y Control de Aduanas (ICE) de los EE. UU.
Debido a la escala del problema, ninguna de estas organizaciones puede investigar todos los delitos cibernéticos
de los que son víctimas los ciudadanos estadounidenses. El FBI publicó algunas pautas para el intercambio
voluntario de información sobre incidentes cibernéticos entre las organizaciones encargadas de hacer cumplir la
ley estatales, locales, tribales y territoriales (SLTT) y el gobierno federal de EE. UU.; Estas pautas brindan una idea
de los tipos de incidentes en los que el FBI está dispuesto a participar.
En particular, un incidente cibernético debe ser reportado si:
Puede afectar la seguridad nacional, la seguridad económica o la salud y seguridad públicas.
Afecta las funciones básicas del gobierno o de la infraestructura crítica.
Da como resultado una pérdida significativa de datos, disponibilidad del sistema o control de los sistemas.
Implica un gran número de víctimas.
Indica acceso no autorizado o software malintencionado presente en los sistemas de tecnología de la información
críticos.
Viola la ley federal o SLTT”. (Oficina Federal de Investigaciones de EE. UU., sin fecha)
Las pautas del FBI señalan además que, “sin importar qué “puerta” utilicen las fuerzas del orden SLTT, la
información se comparte dentro del gobierno federal para brindar una respuesta apropiada mientras se protege la
privacidad y las libertades civiles de los ciudadanos bajo la ley” (Oficina Federal de Investigaciones de EE. UU., sin fecha).
En 2020, el FBI discutió una nueva estrategia para combatir el ciberdelito, que “impondrá riesgo y consecuencias
a los ciberadversarios” (Wray, Christopher. 2020). Dijo además,
Tenemos que cambiar el cálculo de costobeneficio de los delincuentes y los estadosnación que creen que
pueden comprometer las redes de los EE. UU., robar la propiedad financiera e intelectual de los EE. UU . y
poner en riesgo nuestra infraestructura crítica, todo sin correr ningún riesgo ellos mismos…” (Wray, Christopher.
2020)
Capítulo 6 237
Los pilares de esta estrategia incluyen (US Federal Bureau of Investigation, 2020):
• Autoridades únicas: aproveche las autoridades criminales y de contrainteligencia para luchar contra los ciberdelincuentes y
los actores de amenazas extranjeros que comprometen las redes estadounidenses.
• Capacidades de clase mundial: adáptese a las amenazas cibernéticas aprovechando nuevas investigaciones innovadoras
técnicas innovadoras, desarrollando nuevas herramientas y reclutando una fuerza laboral de clase mundial.
• Asociaciones duraderas: aproveche las fortalezas del FBI para permitir que sus socios defiendan sistemas, realicen
atribuciones, impongan sanciones a los actores de amenazas y persigan a los adversarios.

exterior.
Por supuesto, otros países importantes también tienen ministerios, departamentos y agencias involucrados en acciones de
aplicación de la ley que resultan de los delitos cibernéticos. La mayoría de los gobiernos a los que asesoré tenían varias agencias
que compartían la responsabilidad de investigar y responder a los delitos cibernéticos. El ciberdelito, en los anales del crimen, es
relativamente nuevo y sigue evolucionando. En consecuencia, la forma en que los gobiernos se organizan para combatirlo también
es nueva y evoluciona. En mi experiencia, era raro encontrar una organización de aplicación de la ley federal o regional o una
autoridad reguladora que no estuviera tratando de posicionarse para ser más relevante en la lucha contra el delito cibernético,
especialmente cuando se estaban creando nuevas agencias gubernamentales para este propósito específico. Una pregunta abierta
en muchos de estos casos parecía ser, ¿se necesitaban nuevas agencias porque las antiguas instituciones no eran efectivas para
combatir el ciberdelito? ¿Los nuevos enfoques del crimen requirieron nuevos enfoques para la aplicación de la ley?
Es probable que la respuesta a estas preguntas continúe en el futuro.
Me doy cuenta de que apenas toqué la superficie de este tema, y no hablé de la aplicación de la ley como una
amenaza cibernética potencial. Sin embargo, he dedicado un capítulo completo que se enfoca en la aplicación de la
ley y la seguridad cibernética en el Capítulo 7, Acceso gubernamental a los datos. Si ve a los gobiernos como una
amenaza cibernética y a la aplicación de la ley más específicamente como una amenaza, este capítulo debería ser
de gran interés para usted.
A continuación, veamos a los gobiernos como defensores.
Los gobiernos como defensores

La aplicación de la ley es en gran medida reactiva. Es decir, alguien comete un delito y luego la policía entra en acción. Los
gobiernos también pueden invertir en capacidades proactivas de ciberseguridad. Es decir, cosas que pueden ayudar a mitigar o
mitigar los ataques contra instituciones, empresas y ciudadanos. Hay al menos tres funciones que brindan los gobiernos cuando
desempeñan el papel de defensores en un contexto de seguridad cibernética: seguridad pública, seguridad nacional y militar.
Seguridad Pública
Primero, la mayoría de los principales gobiernos nacionales tienen un departamento o ministerio responsable de la
seguridad pública. A veces, la seguridad pública es un subconjunto del trabajo que realiza un departamento gubernamental.
En los últimos doce años, he visto a más y más países crear nuevos centros nacionales de ciberseguridad
que incluyen la seguridad pública, entre otras cosas, en sus estatutos. Los ejemplos incluyen el Centro
Nacional de Seguridad Cibernética (NCSC) en el Reino Unido, el Centro Nacional de Seguridad Cibernética de Irlanda
(NCSC), la Agencia Nacional de Ciberseguridad de Francia (ANSSI), el Centro Canadiense para la Seguridad
Cibernética, la Agencia de Seguridad Cibernética (CSA) en Singapur, el Centro de Seguridad Cibernética de
Australia y la Agencia de Seguridad de Infraestructura y Ciberseguridad (CISA) en los EE. Algunos de ellos
también brindan servicios de asesoramiento sobre seguridad cibernética a departamentos gubernamentales,
protegen infraestructura crítica, administran procesos de respuesta a incidentes y administran programas de
Inteligencia de amenazas cibernéticas (CTI) .
Algunos de estos centros se crearon mediante la fusión de partes de los Equipos Nacionales de Respuesta a
Emergencias Informáticas (CERT), grandes departamentos gubernamentales con estatutos de ciberseguridad,
fuerzas del orden y agencias de inteligencia. La combinación de las capacidades que reúnen estas organizaciones
de partes interesadas es mucho mayor de lo que cualquiera de ellas podría desarrollar por sí sola. Por lo general,
la única función de la que carecen dentro de sus departamentos es la aplicación de la ley, para lo cual se asocian
con las agencias encargadas de hacer cumplir la ley.
La mayoría de estos centros de ciberseguridad ofrecen oportunidades educativas a organizaciones del sector
público y privado, y a los ciudadanos. El concepto aquí es que una sociedad mejor educada podrá reconocer los
ataques cibernéticos más fácilmente, informarlos y, con suerte, ayudar a mitigarlos. Tuve la oportunidad de asistir
a algunos de estos eventos, como el evento de seguridad CyberUK del NCSC del Reino Unido.
Capítulo 6 239
seguridad nacional
Otra función que brindan los gobiernos en su rol de defensores es la seguridad nacional. He encontrado que este es un
término cargado que significa diferentes cosas para diferentes personas. Los gobiernos han estado reuniendo inteligencia
y practicando el espionaje militar para comprender las capacidades militares de sus adversarios desde que existen
gobiernos. Hoy en día, esto incluye capacidades tanto de ciberofensiva como de ciberseguridad.
La recopilación de inteligencia suele ser una función que realizan las organizaciones de seguridad nacional. Dado que
los secretos militares están altamente clasificados, normalmente se protegen mediante tecnologías y procesos de
encriptación y gestión de claves . Por lo tanto, las agencias de inteligencia también tienen una gran experiencia en
inteligencia de señales (recopilación de inteligencia interceptando señales entre sistemas) y criptografía , para que
puedan interceptar y acceder a información clasificada a la que de otro modo no tendrían acceso, así como proteger la
información de sus propios gobiernos de manera más efectiva.
Así es como la Agencia de Seguridad Nacional de EE. UU. (NSA) describe su estatuto,
La Agencia de Seguridad Nacional/Servicio Central de Seguridad (NSA/CSS) lidera los EE. UU.
Gobierno en criptología que abarca tanto la inteligencia de señales (SIGINT) como los
productos y servicios de ciberseguridad y permite que las operaciones de redes informáticas
obtengan una ventaja decisiva para la nación y nuestros aliados”. (Agencia de Seguridad
Nacional, sin fecha)
La NSA también brinda apoyo de combate a las fuerzas armadas estadounidenses y sus aliados. Hablamos de los
gobiernos como organismos de normalización anteriormente en este capítulo. La NSA es otro ejemplo de esto, ya que
“establece protocolos y estándares comunes para que nuestro ejército pueda compartir información de manera segura
con nuestros aliados, la OTAN y las fuerzas de la coalición en todo el mundo. La interoperabilidad es clave para
operaciones y ejercicios conjuntos exitosos” (Agencia de Seguridad Nacional, sin fecha).

La NSA también se enfoca en la ciberseguridad.
La seguridad cibernética de la NSA previene y erradica las amenazas a los sistemas de seguridad
nacional de EE. UU., con un enfoque inicial en la Base Industrial de Defensa (DIB) y la mejora de la
seguridad de las armas de la nación. En esencia, la seguridad cibernética de la NSA tiene como
objetivo derrotar al adversario a través de las siete misiones y funciones principales:
Proporcionar inteligencia para advertir sobre amenazas cibernéticas maliciosas e información Política del
gobierno de EE. UU. (USG)
Desarrollar productos y servicios integrados de amenazas, vulnerabilidades, riesgos y criptográficos de
sistemas de comando y control nuclear
Lanzar productos integrados de amenaza, evaluación y mitigación/protección para el
Clientes del Departamento de Defensa (DoD) y USG
Ejecutar criptografía de alta seguridad e ingeniería de seguridad
Ofrecer operaciones combinadas de defensa/ofensiva con socios gubernamentales clave
Habilitar la defensa de las redes de la agencia en coordinación con el Jefe de la NSA

Oficina de Informacion
Promover el intercambio de información para apoyar la misión de seguridad cibernética de la agencia.
(Agencia de Seguridad Nacional, nd).
Por supuesto, otros países también tienen organizaciones dedicadas a la seguridad nacional. En el
Reino Unido, los servicios de inteligencia nacional e inteligencia extranjera son proporcionados por
la Inteligencia Militar, Sección 5 (MI5) y la Inteligencia Militar, Sección 6 (MI6), respectivamente.
Hay muchas otras partes interesadas y participantes, incluida la Sede de Comunicaciones del Gobierno
(GCHQ), el Centro Nacional de Seguridad Cibernética, el Ministerio del Interior y muchos otros.
En Canadá, las organizaciones de seguridad nacional incluyen el Servicio de Inteligencia de Seguridad Canadiense
(CSIS), la Real Policía Montada de Canadá (RCMP), el Establecimiento de Seguridad de las Comunicaciones (CSE)
y el Centro Canadiense de Seguridad Cibernética, entre otros.
El Cuerpo de Inteligencia de Israel tiene la Unidad 8200. Se dice que tiene un estatuto similar al de la NSA en los EE.
UU. y se especializa en inteligencia de señales (SIGINT). Muchos exmiembros de la Unidad 8200 han llegado a
establecer exitosas nuevas empresas de seguridad cibernética y liderar empresas importantes.

Capítulo 6 241
También existen asociaciones internacionales que se centran en la seguridad nacional de los países socios.
Un gran ejemplo de este tipo de organización es Five Eyes. Esta es una alianza entre Australia, Canadá, Nueva Zelanda, el Reino Unido
y los Estados Unidos, centrada en el intercambio de inteligencia (Oficina del Director de Inteligencia Nacional, sin fecha). El concepto
aquí es compartir inteligencia entre cinco países que proporciona a estos gobiernos una mejor visibilidad de las amenazas potenciales.
Muchos de los CISO y equipos de seguridad a los que asesoré consideraban a las agencias de inteligencia antes mencionadas como
amenazas para sus organizaciones. Hablo de la recopilación de inteligencia, como SIGINT, como amenazas cibernéticas en el Capítulo
7, Acceso gubernamental a los datos.
Una de las razones por las que los gobiernos tienen programas de inteligencia de seguridad nacional es para proporcionar a sus fuerzas
militares la información necesaria para disuadir la guerra y defender sus fronteras y sus aliados.
Analicemos esta función a continuación.
Militar
El Departamento de Defensa (DoD) es la agencia más grande del gobierno de EE. UU. y el empleador más grande del mundo, y emplea
a más de 2,9 millones de personas en más de 4800 sitios ubicados en más de 160 países (Departamento de Defensa de EE. UU.,
2022). El DoD tiene un presupuesto de $ 752,9 mil millones.
Las fuerzas armadas de los EE. UU. incluyen el Ejército, la Infantería de Marina, la Armada, la Fuerza Aérea, la Fuerza Espacial y la
Guardia Costera. Hay dos componentes de reserva: la Guardia Nacional del Ejército y la Guardia Nacional Aérea. Como mencioné
anteriormente, la misión declarada del DoD es "proporcionar las fuerzas militares necesarias para disuadir la guerra y garantizar la
seguridad de nuestra nación". Esto incluye aspectos tanto ofensivos como defensivos de la ciberseguridad.
Con tanta gente, el Departamento de Defensa realiza una gran cantidad de funciones de ciberseguridad. Estoy seguro de que se podría
dedicar un libro entero a describir lo que hace el Departamento de Defensa y las funciones de ciberseguridad que proporciona.
En esta sección, simplemente proporcionaré una introducción a una de las formas en que el Departamento de Defensa está
aprovechando las fuerzas armadas para fines de seguridad cibernética. Creo que el Comando Cibernético de los Estados Unidos
(USCYBERCOM) es un buen punto de partida, ya que brinda información sobre la estrategia de seguridad cibernética del Departamento
de Defensa y cómo se aprovechan las fuerzas armadas como parte de esa estrategia.
USCYBERCOM es un comando combatiente unificado (CCMD) del Departamento de Defensa. El Departamento de Defensa tiene once
de estos comandos combatientes unificados organizados en torno a ubicaciones geográficas o en torno a funciones específicas. Cyber
es una de esas funciones. USCYBERCOM se denomina "comando conjunto" porque está compuesto por varias partes de las fuerzas
armadas, incluidos el Ejército, la Marina, la Fuerza Aérea y la Infantería de Marina. La NSA también es socia en este comando conjunto.
La visión del DoD para USCYBERCOM es,

Lograr y mantener la superioridad en el dominio del ciberespacio para influir en el
comportamiento del adversario , brindar ventajas estratégicas y operativas para la Fuerza
Conjunta y defender y promover nuestros intereses nacionales”. – (Comando Cibernético de
los Estados Unidos, abril de 2018)
El documento de estrategia de USCYBERCOM, “Lograr y mantener el Comando de Superioridad en el Ciberespacio

Visión para el Comando Cibernético de EE. UU.”, es realmente una gran lectura. Está muy bien escrito y describe
el desafío de la ciberseguridad a través de una lente militar. Creo que las siguientes dos excepciones de este
documento resumen su estrategia. El primer extracto describe la visión de USCYBERCOM sobre el desafío que
plantean los adversarios.
La seguridad de los Estados Unidos y nuestros aliados depende de la estabilidad internacional
y la prosperidad global. La difusión de la tecnología y las comunicaciones ha permitido nuevos
medios de influencia y coerción. Los adversarios operan continuamente contra nosotros por
debajo del umbral del conflicto armado. En esta “nueva normalidad”, nuestros adversarios
están extendiendo su influencia sin recurrir a la agresión física. Provocan e intimidan a
nuestros ciudadanos y empresas sin temor a consecuencias legales o militares. Entienden
las restricciones bajo las cuales Estados Unidos elige operar en el ciberespacio, incluido
nuestro umbral tradicionalmente alto para responder a la actividad del adversario. Utilizan
este conocimiento para explotar nuestras dependencias y vulnerabilidades en el ciberespacio
y utilizan nuestros sistemas, procesos y valores en nuestra contra para debilitar nuestras
instituciones democráticas y obtener ventajas económicas, diplomáticas y militares… Los
actores no estatales agresivos como terroristas, delincuentes y hacktivistas representan
amenazas menores que los estados, pero aún pueden dañar nuestras capacidades militares
e infraestructura crítica, así como poner en peligro la vida de los estadounidenses” .
( Comando Cibernético de los Estados Unidos, abril de 2018)
Este segundo extracto del documento se centra en cómo opera USCYBERCOM para abordar estas amenazas
cibernéticas a los EE. UU.
Capítulo 6 243
La superioridad a través de la persistencia toma y mantiene la iniciativa en el ciberespacio al
enfrentarse y desafiar continuamente a los adversarios y causarles incertidumbre dondequiera que
maniobren. Describe cómo operamos, maniobrando sin problemas entre la defensa y el ataque en
el espacio de batalla interconectado. Describe dónde operamos: globalmente, lo más cerca posible
de los adversarios y sus operaciones. Describe cuándo operamos, continuamente, dando forma al
espacio de batalla. Describe por qué operamos: para crear una ventaja operativa para nosotros
mientras negamos lo mismo a nuestros adversarios... Mediante una acción persistente y una
competencia más eficaz por debajo del nivel del conflicto armado, podemos influir en los cálculos
de nuestros adversarios, disuadir la agresión y aclarar la distinción entre comportamiento aceptable
e inaceptable en el ciberespacio . Nuestro objetivo es mejorar la seguridad y la estabilidad del
ciberespacio.
Este enfoque complementará los esfuerzos de otras agencias para preservar nuestros intereses y
proteger nuestros valores. Medimos el éxito por nuestra capacidad de aumentar las opciones para
los tomadores de decisiones y por la reducción de la agresión del adversario”. (Comando
Cibernético de los Estados Unidos, abril de 2018)
Por supuesto, Estados Unidos no es la única fuerza militar en el mundo que ha estado desarrollando capacidades
ofensivas y defensivas. En 2013, la firma de ciberseguridad Mandiant publicó un informe que revelaba que una
unidad militar en China era presuntamente responsable de cientos de ciberataques a empresas estadounidenses
(CBS News, 2013). Mandiant identificó a la Unidad 61398 del Ejército Popular de Liberación (EPL) como la
fuente de estos ataques y los rastreó hasta un edificio de oficinas en Shanghái (CBS News, 2013).
En 2014, el Departamento de Justicia de EE. UU. acusó a cinco miembros de la Unidad 61398 por cargos
relacionados con el robo de propiedad intelectual. John Carlin, fiscal general adjunto de seguridad nacional,
discutió estos cargos en un evento de la Institución Brookings en ese momento.
…seguimos los hechos y las pruebas adonde nos llevan. A veces, los hechos y la evidencia nos
llevan a un pirata informático solitario en un sótano en los EE. UU. o un sindicato del crimen
organizado en Rusia. Y a veces, nos llevan a un miembro uniformado del ejército chino”. –
(Brookings, 22 de mayo de 2014)

Se cree que la Unidad 61398 es solo uno de los muchos grupos del ELP en China que se centran en las capacidades
de ciberseguridad. Unidades militares de varios otros países que supuestamente realizan operaciones cibernéticas han
aparecido en las noticias desde entonces. La República Popular Democrática de Corea (Corea del Norte) e Irán son
dos ejemplos.
Espero que eso proporcione una pequeña idea de algunas de las formas en que algunos países están aprovechando
sus fuerzas militares para fines de seguridad cibernética. Cuando se ve a través de este lente, se vuelve obvio que los
gobiernos han desarrollado y están usando capacidades cibernéticas ofensivas como parte de sus estrategias de
defensa nacional. ¿Significa esto que los gobiernos son amenazas? No creo que haya una sola respuesta a esta
pregunta porque, como hemos discutido en este capítulo, los gobiernos juegan muchos roles diferentes. Si usted o su
organización son criminales por naturaleza o son adversarios de las agencias de inteligencia o militares de un país,
entonces la respuesta es más sencilla. Sin embargo, he tenido tantos equipos de seguridad del sector público y privado,
que de ninguna manera están involucrados en empresas criminales o espionaje económico o militar, afirman que el
gobierno de los EE. UU. es una amenaza directa para ellos, que esto merece un examen más profundo.
¿Estas agencias gubernamentales y compañías importantes realmente creen que son objetivos de las operaciones
militares estadounidenses? ¿O creen que están siendo investigados por el Departamento de Justicia de los EE. UU. o
alguna agencia de aplicación de la ley? ¿Por qué considerarían al gobierno de EE. UU. como una amenaza y, por
asociación, a sus socios de la cadena de suministro con sede en EE. UU.?
Ahora que hemos discutido los roles que juegan los gobiernos, esto hace que las conversaciones sobre los gobiernos
como amenazas sean potencialmente mucho más productivas. Descubrí que cuando los equipos de seguridad pueden
articular amenazas específicas, solo entonces se pueden desarrollar mitigaciones específicas con confianza. Un ataque
cibernético por parte del ejército de los EE. UU. es un riesgo bastante diferente al de una agencia de aplicación de la
ley que sirve a una organización con una orden de registro. Ser específico sobre las amenazas y los riesgos de los que
realmente debe preocuparse lo ayuda a priorizar mejor los recursos y evitar invertir en mitigar riesgos que son
ridículamente vagos o improbables. Esta es la discusión a la que está dedicado el siguiente capítulo de este libro, el
Capítulo 7, Acceso gubernamental a los datos . En este capítulo, también examinaremos por qué tantos equipos de
seguridad en todo el mundo ven al gobierno de EE. UU. como una amenaza y si esta es una perspectiva racional.
Capítulo 6 245
Resumen
Por lo general, los gobiernos se comprometen a brindar a sus ciudadanos seguridad nacional, aplicación de la ley, sistemas
judiciales y otras funciones esenciales que brinden seguridad y apoyen la búsqueda de la felicidad de los ciudadanos. Para hacer
esto, los gobiernos se organizan en diferentes departamentos, ministerios y agencias. En este capítulo, exploramos los diferentes
roles que desempeñan los gobiernos para brindar seguridad cibernética a sus ciudadanos y algunos ejemplos del mundo real de
cómo lo hacen.
Los roles que desempeñan los gobiernos en la ciberseguridad incluyen participantes del mercado, organismos de normalización,
ejecutores y defensores. Examinamos cada uno de estos roles en este capítulo.
Los gobiernos son participantes del mercado en el sentido de que tienen poder adquisitivo en los mercados de productos,
servicios y servicios profesionales de ciberseguridad. También compiten por el talento en ciberseguridad con el sector privado.
En su papel como organismos de normalización, los gobiernos trabajan con las partes interesadas de la industria para desarrollar
y establecer estándares de ciberseguridad. NIST en los EE. UU. y BSI en Alemania son excelentes ejemplos. Organizaciones
no gubernamentales como ISO e IETF también establecen estándares.
Los gobiernos actúan como encargados de hacer cumplir la ley, por lo general, brindan funciones regulatorias y de aplicación de
la ley. Las regulaciones de seguridad cibernética generalmente buscan establecer un estándar mínimo que las organizaciones
del sector público y privado deben cumplir. Algunas organizaciones utilizan el cumplimiento de estándares regulados como
estrategias de seguridad cibernética, una estrategia que analizo en un capítulo posterior. Los gobiernos utilizan la aplicación de
la ley para disuadir la delincuencia, incluida la ciberdelincuencia. El FBI es un gran ejemplo de una agencia de aplicación de la
ley que lucha contra el delito cibernético.
Los gobiernos también juegan el papel de defensores de sus ciudadanos. Esto incluye partes de los gobiernos que brindan
seguridad pública, seguridad nacional y fuerzas militares. Examinamos cómo se aprovecha cada una de estas funciones con
fines de ciberseguridad. Las funciones militares y de seguridad nacional pueden aprovechar las capacidades de ciberseguridad
defensivas y ofensivas para respaldar sus estatutos.
Referencias
• Hobbes, T. (2008). Leviatán (JCA Gaskin, Ed.). Prensa de la Universidad de Oxford.
• Carta Canadiense de Derechos y Libertades, s 7, Parte 2 de la Ley de la Constitución de 1982, siendo el Anexo B de la Ley
de Canadá de 1982 (Reino Unido), 1982, c 11. Obtenido de https://justice.gc.ca/
esp/csjsjc/rfcdlc/ccrfccdl/check/art7.html
• Embajada de Francia en EE.UU. (20 de diciembre de 2013). Libertad, igualdad, fraternidad. Obtenido de https://
web.archive.org/web/20141018141249/http://www.ambafranceus.
org/spip.php?article620
• Departamento de Defensa de EE.UU. (2022). Sobre el Departamento de Defensa de EE.UU. Obtenido de
https://www.defense.gov/About
• Gobierno de Canadá. (2022). Asuntos Globales de Canadá. Obtenido de https://

www.international.gc.ca/globalaffairsaffairesmondiales/homeaccueil.
aspx?lang=eng
• Policía Federal Australiana. (2022). Nuestra organización. Obtenido de https://www.afp.

gov.au/aboutus/ourorganization
• Gobierno del Reino Unido. (2022). Ministerio de Justicia Sobre Nosotros. Obtenido de https://www.gov.
reino unido/gobierno/organizaciones/ministeriodejusticia/sobre
• Oficina Federal de Seguridad de la Información de Alemania. (2022). ¿Cuáles son las funciones de la BSI?
Obtenido de https://www.bsi.bund.de/EN/Home/home_node.html
• USASpending.gov. 2022. Gasto del año fiscal 2022 por función presupuestaria. Obtenido de https://
www.usaspending.gov/explorer/budget_function
• Scarfone, K. , Benigni, D. y Grance, T. (2009), Cyber Security Standards, Wiley Handbook
of Science and Technology for Homeland Security, John Wiley & Sons, Inc., Hoboken,
NJ, [en línea], https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=152153 ( consultado
el 8 de septiembre de 2022)
• NIST. (Dakota del Norte). Acerca del NIST. Obtenido de https://www.nist.gov/aboutnist
• NIST. (Dakota del Norte). Programa de Validación de Módulos Criptográficos. Obtenido de https://csrc.nist.
gov/projects/cryptographicmodulevalidationprogram
• NIST. (agosto de 2021). Publicación especial 1271 del NIST, Primeros pasos con el marco de
ciberseguridad del NIST: una guía de inicio rápido. Obtenido de https://nvlpubs.nist.gov/nistpubs/
Publicaciones especiales/NIST.SP.1271.pdf
• El Grupo de Trabajo de Ingeniería de Internet. (Dakota del Norte). Quienes somos. Obtenido de https://www.
ietf.org/about/who/
• YO ASI. (Dakota del Norte). Sobre nosotros. Obtenido de https://www.iso.org/aboutus.html
• YO ASI. (2019). ISO/IEC 27018:2019, Tecnología de la información. Técnicas de seguridad. Código de
prácticas para la protección de información de identificación personal (PII) en nubes públicas que actúan
como procesadores de PII. Obtenido de https://www.iso.org/standard/76559.html?browse=tc
• Tessiano. (5 de mayo de 2022). Las 30 multas más grandes de GDPR hasta ahora (2020, 2021, 2022). Obtenido de
https://www.tessian.com/blog/biggestgdprfines2020/
Capítulo 6 247
• Oficina Federal de Investigaciones de EE.UU. (Dakota del Norte). Informes de incidentes cibernéticos de las fuerzas del
orden, un mensaje unificado para las fuerzas del orden estatales, locales, tribales y territoriales. Obtenido de https://
www.fbi.gov/filerepository/lawenforcementcyberincidentreporting.pdf/
vista
• Wray, Cristóbal. (septiembre de 2020). La estrategia del FBI aborda la amenaza cibernética en evolución, el
director Wray enfatiza asociaciones más estrechas para combatir las amenazas cibernéticas e imponer
mayores costos a los actores cibernéticos. Obtenido de https://www.fbi.gov/news/stories/wrayannounces
ciberestrategiadelfbiencisasummit091620
• Oficina Federal de Investigaciones de EE.UU. (2020). Estrategia cibernética del FBI. Obtenido de https://
www.ic3.gov/Media/PDF/Y2020/PSA201008.pdf
• Comisión Federal Reguladora de Energía. (10 de mayo de 2021). Declaración del presidente de la FERC,
Richard Glick: El presidente Glick y el comisionado Clements piden que se examinen los estándares
cibernéticos obligatorios para oleoductos a raíz del incidente de ransomware en oleoductos coloniales.
Obtenido de https://www.ferc.gov/newsevents/news/statementfercchairmanrichard
glickpresidenteglickycomisionadoclements
• Agencia de Protección Ambiental de los Estados Unidos. (11 de mayo de 2021). La EPA emite una exención
de combustible para doce estados y el Distrito de Columbia afectados por el cierre del oleoducto colonial.
Obtenido de https://www.epa.gov/newsreleases/epaissuesfuelwaivertwelvestatesand
distritocolumbiaimpactadotuberíacolonial
• Departamento de Seguridad Nacional de EE.UU. (12 de mayo de 2021). Declaración del Secretario Mayorkas
sobre la Aprobación de una Exención de la Ley Jones en Respuesta a las Restricciones de Suministro de
Petróleo de la Costa Este. Obtenido de https://www.dhs.gov/news/2021/05/12/statementsecretarymayorkas
aprobaciónleyjonesexenciónrespuestacostaorientalpetróleo
• Departamento de Transporte de EE.UU. (11 de mayo de 2021). USDOT anuncia medidas adicionales para
ayudar a los estados en las áreas afectadas por el incidente del oleoducto colonial. Obtenido de https://www.
transportation.gov/briefingroom/usdotannouncesadditionalmeasureshelp
estadoszonasafectadascolonialoleoducto
• La Casa Blanca. (12 de mayo de 2021). Orden Ejecutiva para Mejorar la Ciberseguridad de la
Nación. Obtenido de https://www.whitehouse.gov/briefingroom/presidential
acciones/2021/05/12/ordenejecutivaparamejorarlaciberseguridaddelasnaciones/
• La Casa Blanca. (12 de mayo de 2021). HOJA INFORMATIVA: El presidente firma una orden
ejecutiva que traza un nuevo curso para mejorar la seguridad cibernética de la nación y
proteger las redes del gobierno federal. Obtenido de https://www.whitehouse.gov/briefingroom/
declaracionespublicaciones/2021/05/12/hoja informativapresidentefirmaorden ejecutiva
trazandonuevocursoparamejorarlasnacionesciberseguridadyproteger
redesdelgobiernofederal/
• Agencia de Seguridad Nacional. (Dakota del Norte). Apoyo a la misión y al combate. Obtenido de https://www.
nsa.gov/About/MissionCombatSupport/
• Oficina del Director de Inteligencia Nacional. (Dakota del Norte). Consejo de Supervisión y Revisión de Inteligencia
de los Cinco Ojos (FIORC). Obtenido de https://www.dni.gov/index.php/whoweare/

organizaciones/capacidadempresarial/chco/chcorelatedmenus/chcorelated links/reclutamiento
ydivulgación/217acerca de/organización/icigpages/2660icig
fiorco
• Agencia de Seguridad Nacional. (Dakota del Norte). Agencia de Seguridad Nacional/Servicio Central de
Seguridad. Obtenido de https://www.nsa.gov/Cybersecurity/Overview/
• Comando Cibernético de los Estados Unidos. (abril, 2018). Lograr y mantener el Comando de
Superioridad en el Ciberespacio, Visión para el Comando Cibernético de EE. UU. Obtenido de https://www.
cybercom.mil/Portals/56/Documents/USCYBERCOM%20Vision%20April%202018.
pdf?ver=20180614152556010
• Noticias de CBS. (19 de febrero de 2013). Unidad militar de China detrás de muchos ataques de piratería en
EE. UU., dice firma de seguridad cibernética. Obtenido de https://www.cbsnews.com/news/chinamilitary
unidaddetrásdemuchosataquesdepirateríacontranosotrosempresadeseguridadcibernéticadice/
• Brookings. (22 de mayo de 2014). La acusación de la unidad 61398 expone caras y nombres reales detrás de los
teclados de Shang hai utilizados para robar de empresas estadounidenses. Obtenido de https://www.brookings.
edu/blog/brookingsnow/2014/05/22/unit61398indictmentexponerealfaces and namebehind
shanghaikeyboardsusedtorobardenosotrosnegocios/

7
Acceso del gobierno a los datos
En capítulos anteriores de este libro, discutimos varios tipos de amenazas en detalle, incluida la explotación de
vulnerabilidades, diferentes categorías de malware, ransomware (ataques dirigidos con extorsión) y amenazas basadas en
Internet como phishing, ataques de descarga oculta y ataques DDoS.
En este capítulo exploraremos otra amenaza potencial que preocupa a muchos CISO y equipos de seguridad: los gobiernos.
Tenga en cuenta que discutiré conceptos y mecanismos legales, regulaciones y leyes en este capítulo. No soy abogado y
no estoy ofreciendo asesoramiento legal. Le recomiendo que consulte a un abogado calificado para obtener asesoramiento
sobre los temas que lee en este capítulo. Además, lo que está escrito en este capítulo y en todo el libro son mis propias
opiniones personales y no las de mi empleador actual o los empleadores anteriores. Dicho esto, ¡comencemos!
Las cosas cambiaron drásticamente en junio de 2013. En ese momento, trabajaba en Microsoft como Director de Informática
Confiable. En aquellos días, los clientes normalmente querían informes de inteligencia sobre amenazas de mi parte y para
hablar sobre las amenazas a sus redes de sistemas Windows, pero todo eso cambió en junio de 2013. Fue entonces
cuando Edward Snowden entregó una gran cantidad de documentos clasificados a los periodistas que revelaban detalles
sobre algunos de los programas de recopilación de inteligencia del gobierno de los Estados Unidos.
Después de que se publicaron las primeras noticias, se produjo un ciclo de noticias global. Como era de esperar, numerosas
grandes organizaciones internacionales del sector público y privado de repente se interesaron en saber si sus datos estaban
seguros en manos de empresas de tecnología con sede en los Estados Unidos.
En ese momento, la pregunta subyacente de las organizaciones internacionales era si las empresas con sede en los EE.
UU. estaban obligadas a proporcionar a las agencias de inteligencia de los EE. UU. los datos que quisieran. Desde entonces,
han salido a la luz muchos otros detalles de las actividades de las agencias de inteligencia de EE. UU., y no han dejado de
surgir preguntas sobre el papel de las empresas de tecnología con sede en EE. UU. en estas actividades.
250 Acceso del gobierno a los datos
Avance rápido 4 años hasta 2017 y estoy trabajando para otra gran empresa de tecnología con sede en los EE. UU.,
y tengo mi sede en Londres, Reino Unido. Mi trabajo consistía en asesorar a las organizaciones del sector público
sobre cómo modernizar sus estrategias de ciberseguridad y mostrarles cómo puede ayudar la computación en la
nube. Un tema sobre el que las organizaciones del sector público de Europa y Oriente Medio querían hablar era el
acceso del gobierno a los datos, más específicamente, el acceso del gobierno de EE. UU. a los datos. Esto fue
especialmente cierto en Alemania, Bélgica, Francia, Suiza, el Reino Unido y Escandinavia.
Mientras tanto, cuando regresaba a los EE. UU. y hablaba con clientes y colegas allí, en gran medida desconocían
el debate que había estado ocurriendo en Europa sobre la confiabilidad de los proveedores de tecnología de los EE.
UU. Simplemente no pensaron que los aliados más cercanos de Estados Unidos en Europa estarían preocupados
por el uso de los productos y servicios proporcionados por las empresas de tecnología con sede en Estados Unidos.
Después de todo, la posición de EE. UU. como líder dominante en innovación tecnológica en el mundo significaba
que seguirían las reglas comerciales de la Organización Mundial del Comercio (OMC) y nunca robarían propiedad
intelectual de otros países de la forma en que se acusaba a China. Si cruzaran esa línea, tendrían más que perder
que cualquier otro país del mundo. ¿Cuál es el alboroto? Debo admitir que, aunque había viajado a Europa para
visitar clientes un par de veces al año durante la década anterior, hasta que viví en Londres y hablé con empresas y
organizaciones del sector público con sede en Europa todos los días, yo tampoco me había dado cuenta del grado
en que la confiabilidad de los Estados Unidos se había visto gravemente empañada, pero aprendí que existe una
conciencia colectiva entre los europeos occidentales . Esta conciencia colectiva se ha visto permeada por el impacto
acumulativo de una serie de revelaciones sobre las operaciones de las agencias de inteligencia estadounidenses en
Europa. Deja que te dé algunos ejemplos:
• Los documentos clasificados filtrados por Edward Snowden desencadenaron una serie de ciclos de noticias
que revelaron el alcance y la escala de algunos programas de recopilación de inteligencia de EE. UU. La
Casa Blanca inicialmente defiende estos programas, pero luego se disculpa por su extralimitación. (Gida, 2013)
• Los documentos filtrados por Edward Snowden sugirieron que la Agencia de Seguridad Nacional
(NSA) monitoreó las conversaciones telefónicas de 35 líderes mundiales. (Bola, 2013)
• WikiLeaks publicó una serie de informes clasificados que llamaron “Espionnage Élysée”. Los informes alegaban
que la NSA había interceptado las comunicaciones de tres presidentes franceses diferentes, ministros del
gabinete y el embajador francés en los EE. UU. (James Regan, 2015).
WikiLeaks también afirma que “Estados Unidos ha tenido una política de una década de espionaje
económico contra Francia, incluida la interceptación de todos los contratos y negociaciones corporativos
franceses valorados en más de 200 millones de dólares”. (WikiLeaks, 2015)
Capítulo 7 251
• WikiLeaks publicó una serie de documentos clasificados que llamaron "Euro Intercepts", que alegaban
que la NSA había interceptado las comunicaciones de altos funcionarios del gobierno alemán,
incluida la canciller alemana Angela Merkel, su personal de alto nivel, así como el personal de ex
cancilleres desde hace casi 2 décadas. Según WikiLeaks, "WikiLeaks hasta ahora muestra que la
NSA se centró explícitamente en la vigilancia a largo plazo de 125 números de teléfono de altos
funcionarios alemanes y lo hizo por razones políticas y económicas, según sus propias
designaciones". (WikiLeaks, 2015)
Estas revelaciones, y otras, han dañado la relación que tenía Estados Unidos con sus aliados europeos.
Desafortunadamente, esto no se limita a Europa: Brasil (WikiLeaks, 2015) y Japón (WikiLeaks, 2015) son
otros dos ejemplos. Para las empresas de tecnología estadounidenses atrapadas en el medio, esto se
convirtió en un atolladero de desconfianza. Cada vez que asistía a una reunión con una empresa o una
organización del sector público en Europa occidental, sabía que esta conciencia colectiva generaría serios
obstáculos. ¿Qué tan fuertes eran esos vientos en contra? Durante algunos de los eventos públicos en los
que hablé, encuestaba al público con una pregunta como esta:
¿Cuál de estas amenazas le preocupa más a su organización? Selecciona solo una respuesta.
1. Atacantes de China
2. Atacantes de Rusia
3. Acceso del gobierno de EE. UU. a los datos mediante una orden o citación válida
4. Otro
En Europa Occidental, entre 2017 y 2020, típicamente entre el 80% y el 90% de las personas que encuesté
seleccionaron la respuesta 'C'. Si esto te sorprende, probablemente vivas en los Estados Unidos. Si vives
en Alemania, Francia u otro lugar en la Unión Europea (UE) o el Espacio Económico Europeo (EEE), es
probable que esto no te sorprenda en absoluto.
La buena noticia para los CISO, sus equipos de seguridad, los profesionales de cumplimiento y gestión de
riesgos y otros ejecutivos es que estas dramáticas revelaciones han llevado a niveles de transparencia que
pueden ayudarlos a cuantificar y administrar el riesgo asociado con el acceso gubernamental a los datos.
Explicaré cómo hacer esto, pero primero, debemos analizar un poco más este problema porque, por lo
general, hay muchas suposiciones, generalizaciones y conceptos erróneos al respecto. De hecho, hay
algunos escenarios diferentes que normalmente se combinan en conversaciones sobre el acceso del
gobierno a los datos; estos escenarios no tienen el mismo riesgo (probabilidad e impacto) para todas las
organizaciones. En este capítulo, compartiré algunas de las cosas que aprendí después de tener miles de
conversaciones con organizaciones de todo el mundo sobre este tema y, con suerte, eliminaré algo de la
emoción de sus cálculos de riesgo.
Comprender el acceso del gobierno a los datos

Como discutí en el Capítulo 6, Los roles que juegan los gobiernos en la seguridad cibernética, a menudo, el
término “gobierno ” se usa de una manera que sugiere que es una cosa homogénea. En realidad, los gobiernos
pueden organizarse en muchas partes diferentes. En el contexto del acceso del gobierno a los datos, es
importante reconocer que partes específicas de los gobiernos quieren usar los datos de manera que respalden
sus agendas específicas. Limitar la conversación para centrarse en estos escenarios permite comprender mejor
los riesgos que podrían representar para su organización y las posibles mitigaciones contra ellos.
Cuanto más específicamente podamos definir una amenaza, más claro será si podemos mitigar, transferir o
aceptar el riesgo que representa para nuestra organización. Pensar en el gobierno de los EE. UU. como una sola
entidad con una sola agenda no es exacto y no es útil para los CISO, los equipos de seguridad y los ejecutivos
que se toman en serio la comprensión y la mitigación de los riesgos para sus organizaciones. En las miles de
conversaciones que he tenido sobre el acceso del gobierno a los datos, muchos CISO, equipos de seguridad y
ejecutivos tendieron a combinar tres escenarios diferentes. Veamos cada uno de ellos.
El escenario de la inteligencia de señales

El escenario de inteligencia de señales es donde las agencias gubernamentales recopilan inteligencia
interceptando y analizando comunicaciones y señales electrónicas, empleando potencialmente criptoanálisis en
comunicaciones cifradas. Los programas de inteligencia de señales fueron el foco de muchos de esos dramáticos
anuncios de WikiLeaks. La realidad es que muchos gobiernos importantes de todo el mundo emplean este tipo
de recopilación de inteligencia . (Wikipedia, sin fecha) EE. UU. utiliza este tipo de recopilación de inteligencia
para obtener visibilidad sobre las capacidades militares en evolución de sus adversarios. (Servicio de Seguridad
Central de la Agencia de Seguridad Nacional , sin fecha) Tenga en cuenta que los EE. UU. comparten inteligencia
con los otros miembros de la OTAN y la alianza de intercambio de inteligencia de señales "Five Eyes". (Servicio
de Seguridad Central de la Agencia de Seguridad Nacional, sin fecha)
Muchos de los ejecutivos con los que me reuní expresaron su preocupación por la información filtrada por
WikiLeaks porque sugiere que algunos de los objetivos de la inteligencia de señales han sido líderes mundiales,
su personal y el público en general a través de programas de recolección masiva de datos. Lograr que dejaran
de lado su indignación personal y articularan cómo planean gestionar el riesgo que estos programas representan
para sus organizaciones fue a veces un desafío. Muchos ejecutivos me dijeron que simplemente no usar
proveedores de tecnología con sede en EE. UU. era la forma en que planeaban mitigar esta amenaza.
Capítulo 7 253
Dado que estos programas de inteligencia de EE. UU., sus objetivos, sus objetivos y sus capacidades están todos
clasificados, administrar tales riesgos con tan poca información puede ser un desafío, pero elegir no utilizar
proveedores de tecnología con sede en EE. UU. no mitigaría la amenaza que plantean estos programas, de ninguna
manera, porque la inteligencia de señales no depende de que sus objetivos utilicen tecnología diseñada, fabricada
u operada por empresas de tecnología con sede en EE. UU.
El escenario del acceso ilegal del gobierno a los datos

El escenario de acceso ilegal del gobierno a los datos es donde una agencia gubernamental roba datos de una
organización o un proveedor en su cadena de suministro, en lugar de obtener una orden judicial válida para obligarlo.
El espionaje militar y el espionaje económico son las motivaciones que suelen asociarse a este escenario. Estados
Unidos ha admitido haber realizado actos de espionaje militar; el ataque de Stuxnet a Irán sería un ejemplo de este
tipo de actividad. China ha sido acusada a menudo de espionaje económico: supuestamente robar propiedad
intelectual de organizaciones en Occidente y dársela a organizaciones en China para darles una ventaja competitiva
y económica. Por supuesto, también hay ejemplos de otros países que realizan actos de espionaje; los ejemplos
incluyen Francia (Ewing, 2014), los Emiratos Árabes Unidos (Christhopher Bing, 2019), Arabia Saudita (Mark
Mazzetti, 2019), Israel (Mehul Srivastava, 2019), Rusia (Wikipedia, sin fecha) y muchos otros.
¿Cómo gestionan los CISO los riesgos asociados con los adversarios que tienen presupuestos masivos o ilimitados,
pueden secuestrar cualquier experiencia técnica que necesiten e infiltrarse en sus organizaciones desde adentro?
Una vez más, tratar de mitigar este tipo de amenaza negándose a utilizar los productos y servicios de los proveedores
de tecnología estadounidenses no es efectivo. Esto podría ser emocionalmente satisfactorio para los ejecutivos que
quieren tomar una posición contra el espionaje económico, pero es una mitigación completamente ineficaz y similar
a aceptar el riesgo.
Para las organizaciones que se toman en serio la gestión de este tipo de riesgo, existen mitigaciones tanto
legales como técnicas a su disposición. Un ejemplo de mitigación legal es la Constitución de los Estados Unidos.
Si una agencia de aplicación de la ley de los EE. UU. o una agencia de inteligencia de los EE. UU. simplemente
roba datos que se almacenan dentro de los Estados Unidos, si los atrapan, están sujetos a las leyes de los Estados
Unidos, incluido el posible enjuiciamiento y tiempo en prisión para los involucrados en el crimen, pero si los mismos
datos se almacenan fuera de los Estados Unidos, en el corazón de Bavaria, Alemania, por ejemplo, no hay una
Constitución de los Estados Unidos que los proteja allí . Las organizaciones fuera de los EE. UU. que realmente se
toman en serio la gestión del riesgo de acceso ilegal del gobierno de los EE. UU. a los datos, en realidad eluden las
mitigaciones legales contra esta amenaza al exigir que sus datos permanezcan en sus países.
Esto es contrario a la intuición para muchos de los ejecutivos con los que he hablado, pero si los ejecutivos pueden
eliminar las emociones que han impregnado la conciencia colectiva de los europeos occidentales, pueden idear
estrategias de gestión de riesgos que sean mucho más efectivas.
En el caso del acceso ilegal del gobierno a los datos, la mayoría de las organizaciones del sector público y privado
tienen riesgos de mayor prioridad para gestionar, pero otras, como las agencias de inteligencia, las fuerzas armadas,
los programas de protección de testigos y las organizaciones comerciales con propiedad intelectual de alto valor que
está seriamente en riesgo por actos de espionaje, el acceso ilegal del gobierno a los datos o el espionaje es un
riesgo prioritario en el que invertirán recursos considerables para mitigarlo. El cifrado sólido y la gestión eficaz de
claves son controles técnicos cruciales en este escenario que analizaré más adelante en este capítulo, así como en
el Capítulo 9, Estrategias de ciberseguridad.
El escenario de acceso legal del gobierno a los datos

El acceso legal del gobierno a los datos es un escenario en el que una agencia de inteligencia o de aplicación de la
ley obtiene una orden judicial válida que obliga a una organización o a un proveedor en su cadena de suministro a
proporcionar evidencia específica que está en su poder, para su uso en una investigación criminal.
Para la mayoría de las grandes organizaciones del sector público y privado que he asesorado en relación con el
acceso del gobierno a los datos, el riesgo que temen no es que puedan recibir una citación u orden judicial que los
obligue a presentar pruebas en un asunto penal. Después de todo, la mayoría de estas organizaciones cuentan con
asesores generales y departamentos legales que ya gestionan dichas solicitudes legales. Con el tiempo, algunos de
estos departamentos legales han desarrollado procesos para gestionar dichas solicitudes y sacar a la luz los riesgos
que representan para la alta dirección, los comités de supervisión y sus juntas directivas.
Esto les permite gestionar los posibles riesgos legales nacionales que plantean dichas solicitudes de aplicación de la
ley. También les ayuda a gestionar posibles consecuencias legales internacionales en las que obedecer las leyes
locales podría obligarlos a infringir leyes o reglamentos internacionales como el Reglamento General de Protección
de Datos (GDPR). También les permite gestionar otros riesgos como el riesgo reputacional para su organización.
El riesgo que realmente preocupa a estas organizaciones es que uno de sus socios o un proveedor en su cadena
de suministro reciba una orden judicial para presentar pruebas en un asunto penal y no se les notifique . Si no saben
que las fuerzas del orden público están tratando de obligar a la presentación de datos de los que son responsables,
entonces no pueden emplear a sus propios abogados ni sus propios procesos legales internos para gestionar la
solicitud; es decir, existe un riesgo para su organización que no conocen y que posteriormente no pueden gestionar.
Capítulo 7 255
Quizás se pregunte con qué frecuencia ocurre un escenario como este. En los Estados Unidos, las órdenes de
mordaza que impedían que los destinatarios de las órdenes judiciales informaran al objetivo de las investigaciones
sobre la orden eran algo natural, pero Microsoft presentó una demanda contra el Departamento de Justicia de los
EE. UU. en abril de 2016 para detener la práctica. Como explicó Brad Smith, consejero general y presidente de
Microsoft: “Cuando presentamos nuestro caso, explicamos que en un período de 18 meses, 2576 de las demandas
legales que recibimos del gobierno de EE. UU. incluían una obligación de confidencialidad, y el 68 por ciento de
estas parecían ser demandas indefinidas de confidencialidad. En resumen, se nos impidió decirle a un gran número
de clientes que el gobierno había intentado acceder a sus datos”. (Smith, 2017)
Como resultado de esta demanda, el Departamento de Justicia de EE. UU. cambió sus prácticas para que tales
órdenes de mordaza sean la excepción a la regla, no la norma.
Hay mucha más transparencia y datos disponibles sobre el riesgo de acceso legal del gobierno a los datos que los
dos escenarios anteriores que he discutido. Esto facilita que los CISO y otros ejecutivos entiendan el riesgo y si su
organización debe invertir recursos para mitigarlo , transferirlo o aceptarlo. Centraré la mayor parte del resto de
este capítulo en discutir el riesgo del acceso legal del gobierno a los datos y brindaré algunas ideas para ayudarlo
a administrarlo.
Acceso legal del gobierno a los datos

Los organismos encargados de hacer cumplir la ley de todo el mundo buscan pruebas para su uso en casos
penales. Esto es fundamental para la función que desempeñan en el gobierno y en la sociedad. A veces, el rastro
de investigación que siguen los lleva a posibles pruebas que se encuentran en el extranjero. El desafío para las
fuerzas del orden en estos casos es que necesitan una forma de obligar a las personas que no están sujetas a su
jurisdicción legal local a presentar pruebas. Dicho de otra manera, los mecanismos legales nacionales que utilizan
los organismos encargados de hacer cumplir la ley para recopilar pruebas en su país no serán suficientes por sí
solos para permitir que los investigadores recopilen pruebas que se encuentran en otros países. Este desafío para
la aplicación de la ley no es nuevo. Los delincuentes han tratado de cubrir sus huellas y subvertir los procesos
legales cruzando los límites jurisdiccionales durante siglos. Este desafío se ve agravado en un mundo en el que
los datos pueden transmitirse a través de fronteras legales internacionales en una fracción de segundo y
almacenarse en casi cualquier país del mundo, utilizando tecnologías de consumo disponibles para cientos de
millones de personas, en muchos casos, de forma gratuita. ¿Cómo se supone que los organismos encargados de
hacer cumplir la ley deben realizar con éxito investigaciones sobre terrorismo, espionaje, explotación infantil y
otros delitos graves, si carecen de las herramientas legales para solicitar pruebas almacenadas fuera de su país?
Para ayudar a abordar este desafío, uno de los mecanismos legales que muchos gobiernos han
implementado son los Tratados de Asistencia Legal Mutua (MLAT). La última vez que conté, EE.
UU. había firmado aproximadamente 65 MLAT para su uso en asuntos penales con países de
todo el mundo. (Departamento de Justicia de EE. UU., nd) La mayoría de estos son tratados
bilaterales, y unos pocos son multilaterales, como con la UE. Los MLAT han estado vigentes
durante muchos años. Por ejemplo, el MLAT actual entre Estados Unidos y Alemania ha estado
vigente desde 2004. De manera similar, el MLAT actual entre EE. UU. y Francia se firmó en 1998,
el MLAT entre EE. UU. y la UE se firmó en 2003 y el MLAT entre Suecia y EE.
en la "carta de transmisión" incluida dentro de cada MLAT.
Figura 7.1: Izquierda: el MLAT entre Estados Unidos y Alemania firmado en 2003 ( Imprenta del
Gobierno de Estados Unidos, 2004); Derecha: la "Carta de transmisión" en la página 3 del
MLAT entre los Estados Unidos y Alemania que explica el propósito del MLAT ( impresión del
gobierno de EE. UU., 2004)
Capítulo 7 257
Figura 7.2: Izquierda: el MLAT multilateral entre los Estados Unidos y la UE firmado en
2003 (US GOVERNMENT PRINTING OFFICE, 2006); Derecha: la "Carta de transmisión"
en la página 3 del MLAT entre los Estados Unidos y la UE que explica el propósito del MLAT (US
IMPRENTA DEL GOBIERNO, 2006)
Los MLAT entre los EE. UU. y otros países brindan una forma para que las fuerzas del orden en los países
participantes soliciten pruebas ubicadas en los EE. UU. y viceversa. Un aspecto importante de cómo
funcionan estos MLAT es el estándar legal aplicado a las solicitudes de búsqueda e incautación. Para
entender esto, debemos volver a los documentos fundacionales de los Estados Unidos y mirar las enmiendas
iniciales a la Constitución de los Estados Unidos, también conocida como la Declaración de Derechos
(Archivos Nacionales, sin fecha). Aquí es donde se definen los derechos y libertades civiles de los ciudadanos de los Estados Uni
La Cuarta Enmienda a la Constitución de los Estados Unidos prohíbe el registro y la incautación irrazonables,
de la siguiente manera:
“[n]o se violará el derecho de las personas a la seguridad de sus personas, casas, papeles y efectos
contra allanamientos y allanamientos irrazonables, y no se emitirán órdenes judiciales sino por causa
probable, respaldadas por juramento o afirmación, y describiendo en particular el lugar a allanar y las
personas o cosas a incautar.”
(Facultad de Derecho de Cornell, sin fecha)
El concepto de “causa probable” ha sido el foco de mucho debate legal y numerosos casos judiciales desde al menos
finales de la década de 1780, cuando se propuso la Declaración de Derechos. Una definición de problema
posible causa es la siguiente:
”La causa probable es un requisito que se encuentra en la Cuarta Enmienda y que, por lo general, debe
cumplirse antes de que la policía realice un arresto, realice un registro o reciba una orden judicial. Los
tribunales generalmente encuentran causa probable cuando existe una base razonable para creer que
se puede haber cometido un delito (para un arresto) o cuando hay evidencia del delito presente en el
lugar que se va a registrar (para un registro)”. (Facultad de Derecho de Cornell, sin fecha)
Ya sea que se trate de una agencia de aplicación de la ley de EE. UU. o una agencia de aplicación de la ley en otro
país de MLAT que utilice un MLAT para solicitar datos, el estándar aplicado a la solicitud es el estándar legal de causa
probable de EE. UU. Dicho de otra manera, EE. UU. no realizará una solicitud de MLAT ni atenderá una solicitud de
MLAT a menos que cumpla con el estándar de causa probable; esto significa que las solicitudes de MLAT deben
cumplir con los estándares legales más altos del mundo para búsqueda e incautación.
Capítulo 7 259
Este matiz brinda protección adicional para las personas que están bajo investigación en países donde el
límite legal para el registro y la incautación es más bajo que en los Estados Unidos.
Quizás se pregunte cómo funcionan estos MLAT. Permítanme proporcionar un escenario de ejemplo para ilustrar
cómo funcionan. En este escenario, se ha cometido un robo en la ciudad capital de Francia.
Algunas especificaciones técnicas súper importantes y valiosas fueron robadas físicamente de una caja fuerte en
un edificio en París, pero la policía capturó al perpetrador en el acto. Según todos los indicios, se trataba de un
acto de espionaje industrial, ya que el perpetrador estaba robando propiedad intelectual que podía vender a los
competidores de la empresa víctima. En este escenario, el crimen es 100% francés: ocurrió en Francia, el
perpetrador es un ciudadano francés, la víctima es una empresa francesa, la policía francesa está investigando y
los tribunales franceses decidirán el veredicto y cualquier posible castigo por el crimen.
Mientras los agentes de la ley franceses interrogan al ladrón, descubren que un comprador de la propiedad
intelectual robada está esperando noticias de que el crimen ha tenido éxito, pero el ladrón no identificará al
comprador ante la policía. La policía sospecha que el ladrón se ha estado comunicando con el comprador por
correo electrónico. Si pudieran obtener acceso a la bandeja de entrada del correo electrónico del ladrón, podrían
identificar al comprador y procesarlo también por el delito. El ladrón no dará acceso a los investigadores a su
correo electrónico ni a ningún detalle sobre su cuenta. Después de registrar la residencia del ladrón en París, con
su permiso, e inspeccionar su computadora personal, la policía cree haber identificado el proveedor de correo
electrónico con el que el ladrón tiene una cuenta de correo electrónico. Los investigadores se comunican con el
proveedor de correo electrónico para obtener los detalles de la cuenta del ladrón, pero descubren que el proveedor
de correo electrónico es una empresa estadounidense ubicada en California. Un abogado del proveedor de correo
electrónico les dijo a los investigadores que el proveedor de correo electrónico no cooperaría en su investigación sin una autorización v
orden judicial de un tribunal de los Estados Unidos.
Después de consultar al Ministerio de Justicia de Francia, los agentes de policía determinan que si
quieren posibles pruebas de correo electrónico almacenadas en los EE. UU., deberán utilizar el MLAT
sobre asistencia legal mutua en asuntos penales que Francia ha firmado con los EE. UU.
Figura 7.3: Izquierda: MLAT multilateral entre Estados Unidos y Francia firmado en 1998
(US GOVERNMENT PRINTING OFFICE, 2000); Derecha: la "Carta de transmisión" en la
página tres del MLAT entre los Estados Unidos y Francia que explica el propósito del MLAT (US
IMPRENTA DEL GOBIERNO, 2000)
Los investigadores franceses no están 100% seguros de que el ladrón tenga una cuenta con este proveedor de correo
electrónico específico de los EE. UU., ni están seguros de que los correos electrónicos del comprador realmente existan, pero
esta es una línea de investigación que están siguiendo. Lo primero que deben determinar es si el ladrón tiene una cuenta de
correo electrónico con el proveedor de correo electrónico. Completan el papeleo de solicitud de MLAT y solicitan la confirmación
de que el ladrón tiene una cuenta de correo electrónico con el proveedor de correo electrónico. Cuando los investigadores
franceses envían su solicitud de MLAT a los EE. UU., se evalúa varias veces.
El experto legal y profesor de derecho internacionalmente reconocido, Peter Swire, describe el proceso que
forma:
Capítulo 7 261
”Cada solicitud exitosa es evaluada por la Oficina de Asuntos Internacionales del DOJ
(OIA), una oficina del Fiscal Federal, un juez federal y luego nuevamente por la Oficina
Federal de Investigaciones (FBI) y la OIA. La OIA, la oficina del fiscal de los EE. UU. y el juez
magistrado revisan cada revisión para garantizar que exista suficiente evidencia para el tipo
de información buscada: una orden de causa probable para el contenido y una orden 2703
(d) que muestra una sospecha razonable y articulable para muchos datos que no son de
contenido. Una vez que el juez de primera instancia aprueba la solicitud y la empresa produce
los registros, el FBI y la OIA revisan los registros para que solo se devuelvan a Francia los
datos que respondan a la solicitud , y que no se incluyan datos que puedan violar la Primera
Enmienda de EE. UU., como el enjuiciamiento de un delito político o de expresión”. (Peter Swire, 2016)
Todas estas revisiones y evaluaciones toman tiempo. Según los expertos legales de la Casa Blanca, las solicitudes
de MLAT válidas entrantes a los EE. UU. demoran, en promedio, diez meses en cumplirse, "y algunas solicitudes
demoran considerablemente más". (Richard A. Clarke, 2013) En nuestro escenario de robo en Francia, 10 meses
después de que los investigadores franceses enviaran su solicitud de MLAT para averiguar si el ladrón tenía una
cuenta de correo electrónico, la respuesta es afirmativa e incluye cierta información de la cuenta, como el nombre y
la dirección de la cuenta, cuándo se abrió y la dirección de correo electrónico.
Durante los 10 meses que se procesó el MLAT, los investigadores franceses continuaron con otras líneas de
investigación relacionadas con el robo. Aprendieron de un asociado del ladrón que existe un correo electrónico del
comprador, y podría ayudar a identificar y enjuiciar al comprador. Si los investigadores franceses ahora quieren
solicitar una copia de un correo electrónico específico del que tienen conocimiento en la bandeja de entrada de la
cuenta del ladrón, deberán enviar otra solicitud de MLAT. Es probable que esta nueva solicitud tarde otros 10 meses
en procesarse. Después de casi 2 años, los investigadores franceses finalmente reciben una copia del correo
electrónico que esperaban identificaría al comprador. El contenido del correo electrónico incrimina al comprador, pero
no proporciona ningún detalle sobre su identidad que no sea su dirección de correo electrónico. El proveedor de
correo electrónico que el comprador usó para enviar el correo electrónico al ladrón se encuentra en los Estados
Unidos. Los investigadores franceses ahora tendrán que hacer otra solicitud de MLAT a los EE. UU. para obtener
información de la cuenta del proveedor de correo electrónico del comprador que podría ayudarlos a revelar la
identidad del comprador. Los investigadores franceses son optimistas de que después de casi 3 años de esperar las
respuestas a las solicitudes de MLAT, sabrán la identidad del comprador de las especificaciones técnicas robadas.
Sus líneas de investigación continúan.

La moraleja de esta historia es que no te conviertas en un investigador francés. Por supuesto, estoy bromeando, pero espero que mi
escenario de ejemplo le brinde una idea de por qué los organismos encargados de hacer cumplir la ley en todo el mundo exigen
mecanismos legales más modernos para acelerar la producción de pruebas que se encuentran en el extranjero. En su opinión, los MLAT
son simplemente demasiado lentos. Estoy seguro de que esta es una opinión compartida por las víctimas de delitos graves también.
Este es el problema que trata de resolver la Ley de Clarificación del Uso Legal de Datos en el Extranjero (CLOUD, por sus siglas en inglés) .
Examinemos esto a continuación.
La Ley CLOUD y la Ley PATRIOTA

Desafortunadamente, este acrónimo mal elegido ha causado mucha confusión tanto en el sector público como en el privado. La Ley
CLOUD no solo se aplica a los proveedores de servicios en la nube (CSP). Se aplica a una variedad de proveedores de servicios, incluidos
proveedores de correo electrónico, compañías telefónicas, sitios de redes sociales y otros tipos de organizaciones, pero el acrónimo en sí
mismo ha llevado a muchos de los ejecutivos con los que he hablado a creer que la Ley CLOUD fue diseñada específicamente para
brindarle al gobierno de los EE. Esto no es cierto, pero, según mi experiencia, he visto a muchos competidores extranjeros de CSP con
sede en EE. UU. tratar de usar esta confusión a su favor, a pesar de que la Ley CLOUD se aplica a muchos, si no a todos, también.
Figura 7.4: Ley CLOUD (Congreso de los Estados Unidos, 2018)

Capítulo 7 263
La Ley CLOUD se convirtió en ley el 23 de marzo de 2018. Muchos de los ejecutivos con los que he hablado desde
que se aprobó la Ley CLOUD describen la Ley CLOUD como la "Ley USA PATRIOT 2.0". Este es otro concepto
erróneo que a las empresas de tecnología fuera de los EE. UU. les gusta jugar. Sin embargo, la Ley CLOUD de 32
páginas no es una enmienda o extensión de los 10 títulos de Uniendo y fortaleciendo a Estados Unidos al proporcionar
las herramientas apropiadas necesarias para interceptar y obstruir el terrorismo.
(PATRIOT) Ley que se promulgó en octubre de 2001 a raíz de los ataques terroristas del 11 de septiembre. Tanto la
Ley PATRIOTA como la Ley CLOUD modifican la Ley de Comunicaciones Almacenadas de diferentes maneras para
diferentes propósitos. el Título II de la Ley PATRIOTA se centró en procedimientos de vigilancia mejorados; amplió
el alcance de las escuchas telefónicas y las órdenes de vigilancia y permitió la vigilancia de las redes de conmutación
de paquetes.
Esto es diferente de la Ley CLOUD, que proporciona un marco legal internacional para agilizar el acceso legal de los
organismos encargados de hacer cumplir la ley a las pruebas almacenadas en el extranjero. Esto se conoce como
“producción de evidencia” en el lenguaje legal, pero es fácil entender por qué algunos ejecutivos llegarían a la
conclusión de que estos actos están relacionados de alguna manera, especialmente si viven en Alemania, Francia,
Brasil, Japón u otros lugares donde la inteligencia estadounidense supuestamente ha interceptado las comunicaciones
de sus líderes gubernamentales. He visto algunos proveedores de servicios administrados fuera de los EE. UU. que
utilizan la Ley PATRIOTA para convencer a las organizaciones de que compren sus servicios en lugar de los de los
proveedores con sede en los EE. UU. Estos argumentos tienen poco sentido en este contexto, ya que la mayoría de
las organizaciones del sector público y privado no están involucradas en terrorismo o lavado de dinero para apoyar el terrorismo.
Además, los 10 títulos de la Ley PATRIOTA han expirado (Electronic Frontier Foundation, 2020).
Entre muchos de los ejecutivos y equipos de seguridad cibernética que he conocido fuera de los EE. UU., no hay
duda de que se denigra la Ley PATRIOTA. La información filtrada por Edward Snowden y WikiLeaks no hizo nada
para mejorar la reputación internacional de los Estados Unidos, pero los CISO y los proveedores no están ayudando
a sus organizaciones al perpetuar argumentos obsoletos sobre riesgos etéreos ; la adquisición de productos y
servicios fuera de los EE. UU. no mitiga los riesgos percibidos. Los CISO deben ser específicos acerca de los riesgos
que sus organizaciones realmente necesitan administrar para que puedan decidir cómo aplicar los recursos limitados
que tienen a las mitigaciones específicas para esos riesgos.
La Ley CLOUD modifica la Ley de Comunicaciones Almacenadas, que se aprobó en 1986. La Ley Almacenada
La Ley de Comunicaciones permite a las fuerzas del orden de los EE. UU. incluir las comunicaciones electrónicas en sus
investigaciones, pero la Ley de Comunicaciones Almacenadas no cubría los escenarios relacionados con Internet
porque Internet era incipiente cuando se escribió. Posteriormente, no contempló escenarios como el almacenamiento
basado en Internet o los servicios globales en la nube.

La Ley CLOUD moderniza algunas de las herramientas otorgadas a las fuerzas del orden de los EE. UU. en la Ley de
Comunicaciones Almacenadas y deja en claro que las organizaciones que hacen negocios en los Estados Unidos (ya sea
que tengan su sede en los EE. UU. o en otro lugar) pueden verse legalmente obligadas a proporcionar datos para
investigaciones criminales, independientemente de dónde estén almacenados.
Hay varias cosas clave que la Ley CLOUD no cambió. La Ley CLOUD no aumentó el alcance de las órdenes judiciales
emitidas bajo la ley estadounidense. La recopilación de datos masivos todavía no está permitida. Los gobiernos extranjeros
todavía tienen inmunidad soberana; lo que significa, en términos sencillos, si un gobierno decide que no quiere participar en
una solicitud de aplicación de la ley de datos que controlan, no se metería en la cárcel. Las fuerzas del orden aún deben
tener una orden judicial válida para las pruebas específicas que desean recopilar; esto significa que la Ley CLOUD no permite
que las fuerzas del orden realicen "expediciones de pesca". No existen disposiciones en la Ley CLOUD que obliguen a los
proveedores de servicios a proporcionar una puerta trasera o acceso sin restricciones a los datos. Fundamentalmente, la Ley
CLOUD no exige que los proveedores de servicios descifren los datos que sus clientes han cifrado ni intenten romper el
cifrado que protege sus datos. Este se ha convertido en un tema candente en los últimos años con llamadas de los gobiernos
de EE. UU., Reino Unido y Australia para que los proveedores de servicios proporcionen a las fuerzas del orden público una
"puerta trasera de cifrado" que les permita descifrar datos cifrados para investigaciones policiales (Paul, 2019). Las
principales empresas de tecnología han rechazado la viabilidad técnica de esta idea, ya que los atacantes podrían usar una
puerta trasera de este tipo para comprometer los sistemas y los datos. No hace falta decir que esta será un área de la ley de
privacidad
que seguirá evolucionando en el futuro.
Al igual que la Ley PATRIOTA, he visto a algunos proveedores fuera de los EE. UU. sembrar el miedo, la incertidumbre y la
duda en la mente de sus clientes utilizando la Ley CLOUD. También he visto organizaciones del sector público y privado con
sede en Europa afirmar esto por sí mismas. El argumento que esgrimen estas personas es que el uso de un proveedor de la
nube con sede en los EE. UU. facilita que el gobierno de los EE. UU. obtenga acceso a los datos debido a la Ley CLOUD,
pero esta caracterización no brinda una imagen completa porque convenientemente omite algunos hechos clave.
Es cierto que las compañías telefónicas, los proveedores de correo electrónico, las compañías de redes sociales, los CSP y
otras compañías similares con sede en los EE. UU. deben cumplir la ley al pie de la letra en los Estados Unidos, incluida la
Ley CLOUD, pero la jurisdicción de los EE. UU. no se limita a las empresas con sede en los EE. UU. Estados Unidos tiene
jurisdicción sobre cualquier empresa que tenga “contactos mínimos” con él. Esto incluye una variedad de escenarios.
Por ejemplo, una empresa de propiedad extranjera con sede en el extranjero que tiene presencia física en los EE. UU., como
una sucursal o una sede en los EE. UU., está sujeta a la ley de los EE. UU. Si la empresa tiene personal o clientes en los
EE. UU., es probable que esté sujeta a las leyes de los EE. UU.
Capítulo 7 265
Los tribunales de los EE. UU. dictaminaron en el pasado que el simple hecho de tener un sitio web fuera de los EE. UU. que
visiten los clientes de los EE. UU. puede poner a una organización bajo la jurisdicción legal de los EE. UU. Para las
organizaciones que realmente están tratando de comprender y administrar los riesgos asociados con estar sujetos a la
jurisdicción legal de los EE. UU., deberán examinar a todos los proveedores que ya tienen en sus cadenas de suministro.
Para las empresas y los departamentos del gobierno federal, lo más probable es que los proveedores de TI, las firmas
consultoras y los proveedores de servicios "locales" que han estado utilizando durante décadas también tengan una presencia
física en los EE . No importa si estos proveedores locales tienen centros de datos en el corazón de Baviera, París o
Estocolmo. Si están sujetos a la jurisdicción de los EE. UU. porque tienen contactos mínimos con los EE. UU., pueden verse
obligados legalmente a entregar los datos almacenados en estos centros de datos para investigaciones policiales de los EE.
UU. Cuando sus ejecutivos se enfrentan a penas de prisión y sus intereses comerciales en EE. UU. se ven amenazados
debido al incumplimiento de órdenes judiciales válidas, las empresas tienden a cooperar.
No muchas empresas abandonarían sus inversiones en el mercado estadounidense simplemente para desafiar una orden
judicial válida en una investigación criminal, especialmente cuando la prohibición legal que se aplica para la búsqueda e
incautación excede el estándar legal de sus propios países.
Un ejemplo de esto es el arresto de la directora financiera de Huawei cuando volaba de Hong Kong a México con conexión
en Vancouver, Canadá, a pedido de las autoridades estadounidenses (Julie Gordon, 2018).
Huawei parecía estar dispuesto a cooperar con la investigación de las fuerzas del orden de EE. UU., dado que su director
financiero estaba bajo custodia, tenían presencia en EE. UU. y tenían ambiciones futuras para el mercado estadounidense.
En el momento de escribir este artículo, esta directora financiera todavía se encuentra en Vancouver, donde ha negociado un
acuerdo de enjuiciamiento diferido con las autoridades de EE. UU. que estará vigente hasta diciembre de 2022 (Reuters, 2021).
En pocas palabras, las organizaciones que desean acceder a los mercados de los EE. UU. deben seguir la letra de la ley de
los EE. UU., ya sea que los datos que tienen estén en los EE. UU. o no. No hemos visto un éxodo masivo de empresas
alemanas, francesas, suizas o suecas de los EE. UU., por lo que los clientes europeos de estas empresas deben aceptar que
los argumentos de protección de la residencia de datos presentados por dichas empresas son en gran medida falsos, pero
esta realidad no es necesariamente algo malo, ya que la residencia de datos no equivale a una mejor seguridad de los datos .
Después de todo, la ubicación física de los datos no mitiga ninguno de los sospechosos habituales de seguridad cibernética
que analicé en detalle en el Capítulo 1. Casi el 100% de los ataques ocurren a través de una red. Si los datos están en un
centro de datos en Berlín, Berna, Beijing o Boston, no hace ninguna diferencia para los atacantes que probablemente nunca
tendrán acceso físico a la infraestructura. El cifrado sólido y la gestión de claves eficaz, respaldados por otras tecnologías y
procesos, mitigan el acceso no autorizado a los datos, no la residencia de datos. Discutiré el cifrado y la gestión de claves
con más profundidad más adelante en este capítulo.

Otro hecho clave que rara vez mencionan los proveedores de servicios fuera de los EE. UU. es que la Ley CLOUD
permite a los EE. UU. solicitar datos para investigaciones de ciudadanos estadounidenses y residentes de los Estados Unidos.
No tiene la intención de permitir que EE. UU. recopile datos sobre ciudadanos europeos, ciudadanos brasileños,
ciudadanos japoneses, etc., que no estén relacionados con el delito que se investiga. Las audiencias más acérrimas
contra la Ley CLOUD de EE. UU. que he encontrado en Europa se quedarían muy calladas cuando les mostrara este
extracto de la Sección 3, Preservación de registros; Análisis de Cortesía del Proceso Legal, de la

Ley de la NUBE.
''(2) MOCIONES PARA ANULAR O MODIFICAR.—(A) Un proveedor de servicios de
comunicaciones electrónicas al público o servicio de computación remota, incluido un servicio
de comunicaciones electrónicas extranjero o un servicio de computación remota, que está
obligado a divulgar conforme a un proceso legal emitido en virtud de esta sección el contenido
de una comunicación por cable o electrónica de un suscriptor o cliente, puede presentar una
moción para modificar o anular el proceso legal cuando el proveedor crea razonablemente:
(i) que el cliente o suscriptor no es una persona de los Estados Unidos y no reside en los
Estados Unidos; y
(ii) que la divulgación requerida crearía un riesgo material de que el proveedor violaría las
leyes de un gobierno extranjero calificado…”
Esto no significa que los proveedores de servicios siempre podrán anular las órdenes judiciales porque no siempre
sabrán quiénes son sus clientes o cuál es su estado de ciudadanía o residencia. Además, los tribunales tienen cierta
discreción y pueden no estar de acuerdo con la decisión de un proveedor de anular, pero creo que este extracto
comunica la intención de la Ley CLOUD de una manera que contrarresta de manera efectiva las nociones combinadas
que algunas audiencias tienen sobre la inteligencia de señales, el acceso ilegal a los datos y el acceso legal a los datos.
Para que un proveedor de servicios con sede en un país fuera de los EE. UU. obtenga una "oportunidad procesal", como
una moción para anular una orden, el país del proveedor debe firmar un acuerdo ejecutivo de la Ley CLOUD con los EE.
UU. Los acuerdos ejecutivos de la Ley CLOUD se pueden utilizar para definir el alcance, los términos y las condiciones
de las órdenes de presentación de pruebas en el extranjero entre las partes del acuerdo. El gobierno del Reino Unido
fue el primer gobierno del mundo en firmar un acuerdo ejecutivo de la Ley CLOUD con los EE. UU. Publicaron los
detalles de este acuerdo ejecutivo en octubre de 2019 (Departamento de Justicia de los Estados Unidos, 2019). Algunos
de los términos y condiciones clave incluyen:

Capítulo 7 267
• Acordaron algunas definiciones, incluida una definición de "delito grave" al que se aplica la Ley CLOUD: "Delito grave significa un
delito que se castiga con una pena máxima de prisión de al menos tres años". (Departamento de Justicia de los Estados
Unidos, 2019)
• Reciprocidad: EE. UU. no puede dirigirse a los datos de personas dentro del Reino Unido y viceversa.
• Se definen algunos límites de uso: el Reino Unido puede decidir no aportar pruebas en los casos en los que EE. UU. solicite la
pena de muerte. Estados Unidos puede decidir no proporcionar pruebas en casos en los que existan preocupaciones sobre
la libertad de expresión.
• Las órdenes deben estar certificadas como legítimas: “Cada Orden sujeta a este Acuerdo debe incluir una certificación por escrito
de la Autoridad Designada de la Parte Emisora de que la Orden es legal y cumple con el Acuerdo, incluidas las normas
sustantivas de la Parte Emisora para las Órdenes sujetas a este Acuerdo”. (Departamento de Justicia de los Estados Unidos,
2019)
• Notificación de un tercer país: si el objetivo de la investigación no está en los EE. UU. o el Reino Unido, las autoridades del tercer
país deben ser notificadas a menos que existan condiciones atenuantes específicas.
están presentes.
Como puede ver en este ejemplo, un acuerdo ejecutivo de la Ley CLOUD puede proporcionar una mayor especificidad para que las
organizaciones puedan comprender mejor el alcance y los límites de la Ley CLOUD. Además, en octubre de 2019, EE. UU. y Australia
anunciaron conjuntamente que comenzaron a negociar un acuerdo ejecutivo bilateral de la Ley CLOUD (Departamento de Justicia de
los Estados Unidos, 2019). Ese acuerdo ejecutivo fue firmado por el Ministro del Interior de Australia en diciembre de 2021 (Departamento
del Interior, Gobierno de Australia, 2021).
La UE también ha expresado la intención de hacer que las solicitudes transfronterizas de pruebas electrónicas (eevidence) sean más
rápidas y sencillas con su propuesta de regulación de pruebas electrónicas (Comisión Europea, 2019):
Crear una Orden Europea de Entrega: esto permitirá que una autoridad judicial en una
Estado miembro para obtener evidencia electrónica (como correos electrónicos, mensajes de texto
o mensajes en aplicaciones, así como información para identificar a un perpetrador como primer
paso) directamente de un proveedor de servicios o su representante legal en otro Estado miembro,
que estará obligado a responder dentro de 10 días, y dentro de 6 horas en casos de emergencia
(en comparación con hasta 120 días para la orden de investigación europea existente o un
promedio de 10 meses para un procedimiento de asistencia judicial recíproca);” (Comisión Europea, 2019)
Por supuesto, no todo el mundo está de acuerdo en que acelerar la producción de pruebas en las investigaciones
penales mediante la simplificación de controles y equilibrios sea una buena idea, pero los CISO y los equipos de
seguridad deben dejar de lado sus sentimientos personales y determinar si estos desarrollos representan un
riesgo incremental en el que sus organizaciones deberían invertir para mitigar.
Gestión del riesgo de acceso gubernamental a los datos

Con tantos gobiernos de todo el mundo trabajando para encontrar formas de facilitar y acelerar la producción
transfronteriza de datos con fines de aplicación de la ley, ¿qué deben hacer los CISO? En primer lugar, es
importante reconocer que no todas las organizaciones deben preocuparse por el acceso del gobierno a los datos,
los MLAT y la Ley CLOUD. La mayoría de los ejecutivos a los que he asesorado no habían analizado previamente
las amenazas específicas que a menudo se agrupan en el riesgo de acceso gubernamental a los datos. Para
algunos de ellos, una vez que reconocieron que la inteligencia de señales, el acceso ilegal a los datos y el acceso
legal a los datos son amenazas diferentes, adoptaron un enfoque menos emocional y más pragmático, pero, para
otros, todavía querían más claridad sobre los riesgos que plantean estas amenazas. Dado que la industria tiene
muy pocos datos autorizados para informar los cálculos de riesgo de que las comunicaciones sean interceptadas
por inteligencia de señales y los datos sean robados en escenarios de acceso ilegal a datos, estos riesgos son
más difíciles de cuantificar. Dejémoslos a un lado por el momento. Centrémonos en el acceso legal del gobierno
a los datos, ya que hay muchos datos disponibles que informarán nuestros cálculos de riesgo para esta amenaza.
Tenga en cuenta que el escenario es bastante diferente si una organización está siendo investigada por actos
delictivos en lugar de pedirle que produzca datos que controlan para una investigación que no está relacionada
con ellos. Me centraré en el último escenario, ya que no estoy calificado para ofrecer consejos sobre el primero.
La pregunta que queremos tratar de responder es, en el contexto del acceso gubernamental a los datos, ¿cuál es
el riesgo incremental de agregar un proveedor o servicio de proveedor en particular a nuestra cadena de
suministro o cartera de TI? Dicho de otra manera, dado que ya existe el riesgo de que las fuerzas del orden
soliciten directamente a las organizaciones el acceso a los datos que controlan, queremos averiguar cuál es el
mayor riesgo de agregar los productos de un proveedor de servicios a su cartera de TI.
Recuerde que el riesgo es la combinación de probabilidad e impacto; es decir, la probabilidad de que se realice
una amenaza específica y el impacto en la organización si se realiza. Hay varias formas diferentes de calcular el
riesgo. Algunas de las organizaciones con las que he discutido la gestión de riesgos utilizan un enfoque
cuantitativo para calcular el riesgo en el que intentan asignar valores numéricos a los lados de probabilidad e
impacto de la ecuación de riesgo. Otras organizaciones con las que he hablado utilizan un enfoque cualitativo
para calcular el riesgo de una manera que no asigna valores numéricos a la probabilidad y el impacto; en su
lugar, utilizan categorías de riesgo, como bajo, medio y alto.
Capítulo 7 269
Algunas organizaciones utilizan una combinación de enfoques cualitativos y cuantitativos.

Independientemente del enfoque que utilice su organización, es probable que sea mejor que no utilizar
ningún enfoque basado en el riesgo. Es posible que deba iterar para encontrar qué enfoque funciona
mejor para su organización si aún no ha adoptado uno. En última instancia, estos enfoques ayudan a
determinar qué riesgos tienen la probabilidad y el impacto combinados más altos en la organización.
Determinar el impacto potencial de una orden judicial que exige la producción de datos específicos que controla
una organización, relacionados con una investigación criminal, probablemente requerirá la experiencia del
Asesor Jurídico y el equipo legal de la organización. Para una organización del sector público o privado del
tamaño de una empresa, es probable que su equipo legal ya haya gestionado este tipo de solicitudes en el
pasado y este riesgo no es nuevo para ellos, incluso si es la primera vez que el CISO lo contempla. Descubrí
que los equipos legales rara vez copian a los CISO en tales asuntos a menos que haya alguna razón convincente para hacerlo.
Esta es la razón por la cual la mayoría de los CISO no saben que su organización ya procesa las solicitudes de
información de las fuerzas del orden. Muchos de los CISO a los que he asesorado no tenían idea de que sus
departamentos legales habían recibido este tipo de solicitudes en el pasado y operaban bajo la suposición de
que se trataba de un nuevo riesgo para la organización, pero los equipos de alta dirección han estado
gestionando todo tipo de riesgos desde el día en que se formó la empresa o agencia. Incluso si la organización
nunca ha recibido una solicitud de información de una agencia de aplicación de la ley, el equipo legal suele ser
el equipo que gestionará dichas solicitudes y tiene la mejor información sobre el impacto potencial en la
organización. El equipo legal es el mejor lugar para comenzar a determinar el impacto potencial de una orden judicial o citación.
Según el tipo de organización, el negocio en el que se encuentren y la naturaleza de la solicitud, también podría
ser prudente obtener el asesoramiento de expertos en relaciones públicas, si pudiera haber un impacto potencial
en la reputación o la marca de la empresa. Solo su organización puede realmente evaluar y comprender el
impacto que podrían tener estas solicitudes.
En el lado de la probabilidad de la ecuación de riesgo, aquí es donde los informes de transparencia de la

industria y los informes de solicitud de información son valiosos. La mayoría de las empresas de tecnología de
primer nivel publican informes que brindan a sus clientes visibilidad sobre el volumen de órdenes de arresto,
citaciones, cartas de seguridad nacional y otras órdenes judiciales que reciben. Lo hacen porque ayuda a sus
clientes a comprender el riesgo del acceso gubernamental legal a los datos asociados con el uso de sus productos y servicios.
Aquí hay una lista de algunos de los informes de transparencia publicados por los principales proveedores.
• Solicitudes de aplicación de la ley de Adobe: https://www.adobe.com/legal/

solicitudes de cumplimiento de la ley/transparencia.html
• Informes de solicitud de información de Amazon: https://aws.amazon.com/compliance/amazon

solicitudes de información/
• Informe de transparencia de Apple: https://www.apple.com/legal/transparency/
• Solicitudes de cumplimiento de la ley y transparencia de Cisco para datos de clientes: https://www.

cisco.com/c/en/us/about/trustcenter/transparencia.html
• Informe de transparencia Meta (Facebook): https://transparency.facebook.com/

solicitudes de datos del gobierno
• Solicitudes de información de usuario de Google: https://transparencyreport.google.com/user

datos/resumen
• Informe de solicitudes de aplicación de la ley de Microsoft: https://www.microsoft.com/enus/

responsabilidadcorporativa/leyaplicacionessolicitudesinforme
Estos proveedores deben ser elogiados por escuchar a sus clientes y por su transparencia . Google ha publicado
una interesante “historia de la transparencia” en su sitio web: https://
transparenciareport.google.com/about.
Para los proveedores que no publican estos datos, es difícil estimar el lado de la probabilidad de la ecuación de
riesgo relacionada con el uso de sus productos; puede ser difícil administrar algo que no se puede medir. Si su
organización utiliza proveedores de servicios gestionados, ¿le han proporcionado informes similares sobre el
volumen de órdenes judiciales que han estado recibiendo? Recuerde, muchos de estos proveedores de servicios
administrados, especialmente los grandes proveedores que han estado en la industria durante décadas,
probablemente estén sujetos a la jurisdicción de los EE. UU. al igual que los CSP de hiperescala con sede en los
EE. UU. Si el acceso legal a los datos es un riesgo que su organización está interesada en comprender, debe
solicitar a todos los proveedores de su cadena de suministro datos que lo ayuden a comprenderlos y administrarlos.
Antes de profundizar en algunos de los datos de estos informes, necesitará algunas definiciones para que pueda
comprender qué significan los datos de estos informes. No existen estándares de la industria sobre el tipo de
datos que se deben publicar y cómo se deben informar, pero muchos de estos informes incluyen datos similares.
En primer lugar, están los conceptos de “contenido” y “no contenido”. En este contexto, contenido significa el
contenido de un archivo creado y/o propiedad del cliente del proveedor. Algunos ejemplos incluyen el contenido
de un correo electrónico, una imagen, una hoja de cálculo, un documento, etc. Las fuerzas del orden pueden
solicitar el contenido de un correo electrónico específico, como describí anteriormente en este capítulo. Es posible
que soliciten un documento o una imagen específicos. Es el contenido del archivo lo que les interesa para su
investigación. Esto generalmente se denomina "datos", "contenido" o "contenido de usuario" en estos informes
de transparencia de la industria.
Capítulo 7 271
Muchas veces, los investigadores encargados de hacer cumplir la ley ni siquiera saben que existe un archivo
específico o que un sospechoso tiene una cuenta para un servicio en línea en particular. Dado que no son
omniscientes y no pueden solicitar legalmente acceso sin restricciones a un servicio en línea para comprobar si
el sospechoso tiene una cuenta, deben presentar una solicitud a través de una orden judicial, citación u orden
judicial con el proveedor del servicio. La respuesta a este tipo de solicitud no involucra el contenido del usuario.
La solicitud se limita a los detalles de la cuenta, como cuándo se abrió la cuenta, el nombre y la dirección
asociados con la cuenta, la información de facturación y otros detalles de la cuenta. Esto generalmente se
conoce como "sin contenido" o "metadatos" en los informes de la industria. Tenga en cuenta que parte de la
información que podría pensar que debería considerarse contenido está clasificada por la ley como metadatos. Por ejemplo, el "a" y
Los campos "de" en un correo electrónico se consideran sin contenido. Esta información está contenida en el encabezado.
de un correo electrónico, como el sobre en el que se envía una carta física, y no se considera información
confidencial. Después de todo, es en el exterior del sobre donde cualquiera que pueda ver el sobre puede ver
las direcciones impresas en él.
Muchos de estos informes brindan cifras agregadas, como la cantidad total de solicitudes de aplicación de la ley
que recibieron en un período de tiempo específico, generalmente medio año o trimestre, y la cantidad de veces
o el porcentaje de casos en los que este contenido se proporcionó a la aplicación de la ley. La cantidad de
solicitudes recibidas y la cantidad de cuentas afectadas por esas solicitudes pueden ser diferentes. Por esta
razón, algunos de estos informes también contienen la cantidad de cuentas que se vieron afectadas. Algunos
de estos informes también proporcionan un desglose del número de solicitudes que fueron rechazadas o
cumplidas solo parcialmente. Algunos de los proveedores proporcionan un desglose de la cantidad de órdenes
de arresto, citaciones, cartas de seguridad nacional (NSL), solicitudes de conservación y otras órdenes judiciales que han recibido.
En estos informes, es posible que vea referencias a solicitudes de seguridad nacional o etiquetas similares;
generalmente hay dos tipos de órdenes que se agrupan en esta categoría, NSL y órdenes de la Ley de Vigilancia
de Inteligencia Extranjera (FISA) . La FISA de EE. UU. de 1978 y sus diversas enmiendas se centran en
Proporcionar a las fuerzas del orden y las agencias de inteligencia un mecanismo para solicitar órdenes
judiciales para apoyar investigaciones encubiertas sobre espionaje y terrorismo. Dado que las investigaciones
son encubiertas, las órdenes judiciales que respaldan estas investigaciones requieren un tribunal que no esté
abierto al público pero que tenga la supervisión adecuada. El Tribunal de Vigilancia de Inteligencia Extranjera
(FISC) revisa las solicitudes y el Tribunal de Revisión de Vigilancia de Inteligencia Extranjera (FISCR) maneja
las apelaciones (Servicio de Investigación del Congreso, 2021). Estos tribunales brindan supervisión para
garantizar que se respete la FISA en la recopilación de inteligencia. Hay un debate en curso sobre la naturaleza
de la FISA y la supervisión que requiere.
El otro tipo de orden de seguridad nacional que puede ver en algunos informes de la industria se llama NSL.
El FBI y el Poder Ejecutivo del gobierno de EE. UU. pueden usar las NSL para solicitar algunos datos de
suscriptores limitados (sin contenido) como parte de las investigaciones de seguridad nacional. Google ha
publicado un desglose de las órdenes FISA y las NSL que ha recibido, incluidas copias de algunas NSL
ligeramente redactadas que han recibido. Si está interesado en ver cómo es una NSL, visite https://
transparenciareport.google.com/userdata/usnationalsecurity. Microsoft también desglosa las órdenes
FISA y las NSL en informes separados de las solicitudes normales de aplicación de la ley que reciben.
Puede ver estos datos aquí: https://www.microsoft.com/enus/corporateresponsibility/
informedeórdenesdeseguridadnacionaldeestadosunidos. Las autoridades estadounidenses no permiten
que los proveedores publiquen el número exacto de pedidos FISA o NSL que reciben; solo pueden publicar
rangos como 0499 o 500999. Hay un retraso obligatorio de 6 meses, después del cual se pueden publicar los
datos más recientes. Presuntamente, toman estas precauciones para que los proveedores extranjeros de
espionaje o las organizaciones terroristas no puedan realizar ingeniería inversa sobre cuántas órdenes judiciales
se emiten u obtener pistas sobre las investigaciones.
El volumen de solicitudes de aplicación de la ley

Es útil comprender cuántas solicitudes de aplicación de la ley reciben los proveedores para calcular el lado de la
probabilidad de la ecuación del riesgo. La Figura 7.5 proporciona el número total de solicitudes de cumplimiento
de la ley de todo el mundo enviadas a cada proveedor, sin incluir NSL, órdenes FISA o solicitudes no relacionadas
con la cuenta, como solicitudes de información en dispositivos móviles. El período cubierto es la primera mitad
de 2018 (1S18) a la primera mitad de 2021 (1S21). Las fuentes de datos para esta tabla son los informes de
transparencia, los informes de solicitudes de aplicación de la ley, etc., que cada proveedor ha publicado en su
sitio web público (Apple, nd; Amazon, nd; Google, nd; Meta, nd; Microsoft, nd).
Capítulo 7 273
Figura 7.5: Número total de solicitudes de cumplimiento de la ley de todo el mundo que cada
proveedor informó haber recibido en cada período de 6 meses entre la primera mitad de 2018
(1S18) y la primera mitad de 2021 (1S21) (Apple, nd; Amazon, nd; Google, nd; (Meta nd); Microsoft, nd)
Existen grandes diferencias en la cantidad de solicitudes que recibió cada uno de estos proveedores.
Los proveedores que operan sistemas populares de comunicación con el consumidor, como correo electrónico, chat
y redes sociales, parecen haber recibido más solicitudes de aplicación de la ley en promedio. Esto podría deberse a
que los mecanismos de comunicación bidireccional como estos permiten a las fuerzas del orden conectar a las
víctimas y los perpetradores, y a los delincuentes con otros delincuentes, durante sus investigaciones.
Como puede ver en estos datos, con algunas excepciones, el volumen de solicitudes de aplicación de la ley
aumentó con el tiempo. Creo que esta tendencia era predecible. Espero que la cantidad de solicitudes de
información de aplicación de la ley enviadas a los proveedores de servicios, no solo a los proveedores con sede
en los EE. UU., continúe aumentando con el tiempo. Las personas y las organizaciones dependen cada vez más
de los servicios en línea. Más personas están utilizando estos servicios y están utilizando una mayor cantidad de
servicios para una cantidad creciente de propósitos, una tendencia que probablemente continuará. Al mismo
tiempo, cada vez más organismos encargados de hacer cumplir la ley en todo el mundo están aprendiendo que
los sospechosos en sus investigaciones criminales utilizan más los servicios en línea y que pueden contener
pruebas cuando se cometen delitos. Como mencioné anteriormente, muchos gobiernos de todo el mundo han
estado trabajando en formas de facilitar que las fuerzas del orden público obtengan acceso legal a los datos,
independientemente de dónde estén almacenados. Todos estos factores me llevan a creer que el volumen de
solicitudes de las fuerzas del orden en toda la industria probablemente seguirá aumentando con el tiempo. Esto
simplemente refleja que, en todo el mundo, las sociedades se mueven en línea y los delincuentes las acompañan.
Estamos comparando manzanas y naranjas en la Figura 7.5. Si bien es útil comprender el volumen total de
solicitudes de cumplimiento de la ley que recibe cada proveedor, contar las solicitudes de datos en los servicios
al consumidor no es lo mismo que las solicitudes de datos empresariales. Este contraste es claro al comparar el
volumen de solicitudes que recibe una empresa de servicios al consumidor como Meta con el de AWS, que
atiende casi exclusivamente a los sectores público y privado. En la primera mitad de 2021, AWS recibió el 0,3%
del volumen de solicitudes que recibió Meta. Recuerde, los CISO están preocupados por las solicitudes de
cumplimiento de la ley de los datos de sus organizaciones, que no son lo mismo que las solicitudes de imágenes,
correos electrónicos y textos para investigaciones criminales centradas en delitos en los que están involucrados
los consumidores. Dicho de otra manera, queremos comprender la probabilidad de que uno de estos proveedores
reciba una solicitud de datos empresariales. Para hacer esto de manera más precisa, no deberíamos contar las
solicitudes de datos de consumidores como parte de ese cálculo de probabilidad.
He visto proveedores con sede en Europa armar estos números en un esfuerzo por competir con las grandes
empresas de tecnología con sede en EE. UU. Señalarán el volumen relativamente grande de solicitudes de
aplicación de la ley que recibe Meta y pintarán a toda la industria tecnológica de EE. UU. con ese pincel.
Al escuchar su presentación, se podría creer que todas las empresas de Silicon Valley proporcionaron al gobierno
de EE. UU. acceso sin restricciones a los datos. Por supuesto, esto no es cierto. Sin embargo, es más fácil para
los ejecutivos de Europa occidental aceptar este punto de vista debido a la erosión de la confianza en los EE. UU.
que mencioné anteriormente. Si de repente se revelara que el jefe de gobierno de su país fue espiado durante
años por uno de sus aliados más cercanos, ¿cómo se sentiría? Sin embargo, los ejecutivos, los CISO y los
miembros del equipo de seguridad deben preguntarse si realmente deben preocuparse por los servicios al
consumidor con sede en EE. UU. como parte de sus propios cálculos de riesgo.
Capítulo 7 275
¿Planean almacenar sus datos empresariales en Facebook? Deben ser específicos acerca de las amenazas y los
riesgos para los datos de su organización y no distraerse con afirmaciones de que toda la industria de alta
tecnología en los EE. UU. está corrupta de alguna manera. Esta visión polarizada no es útil en la gestión de riesgos
para las organizaciones del sector público o privado.
Desglosar los datos para proporcionar el número de solicitudes enviadas país por país es otro eje que ofrecen algunos
proveedores en sus informes de transparencia. Cuantos más detalles proporcionen en sus informes, más precisas
pueden ser las estimaciones de riesgo. Por ejemplo, a muchos de los CISO con los que he hablado no les importa si
su propio país envía solicitudes de información a sus proveedores; en realidad, solo les preocupan las solicitudes de
EE. UU.
Además, muchos CISO no están demasiado preocupados por los datos que no son de contenido porque consideran
que dichos datos están disponibles públicamente o se pueden descubrir fácilmente, como una dirección de correo
electrónico, por ejemplo. Si pueden determinar la cantidad de solicitudes realizadas por las fuerzas del orden de EE.
UU. donde se produjo el contenido, eso les da una buena idea de la amenaza específica que les preocupa.
La probabilidad de que las fuerzas del orden de EE. UU. accedan a los datos en
la nube
En este punto, veamos cómo podemos usar estos datos para comprender el lado de la probabilidad de la ecuación del
riesgo. Usemos un ejemplo del mundo real. En este ejemplo, un CIO de una empresa con sede en Alemania quiere
comprender el riesgo de agregar servicios de CSP de hiperescala con sede en EE. UU. a su cartera actual de TI local.
Al CIO le preocupa que el uso de proveedores de servicios con sede en los EE. UU. facilite al gobierno de los EE. UU.
el acceso a sus datos. Ayudemos a este CIO a tener una mejor idea del lado de la probabilidad de la ecuación del
riesgo. Dado que el CIO insiste en que solo les preocupan las solicitudes de los EE. UU., solo incluiremos esas
solicitudes en nuestro cálculo. El CIO no planea usar servicios de nivel de consumidor para procesar, almacenar o
transmitir los datos de su organización, por lo que solo nos centraremos en los CSP de hiperescala que brindan
servicios para clientes empresariales. Estos CSP incluyen AWS, Google y Microsoft.
Comencemos con el número total global de solicitudes recibidas por los tres CSP en los que está interesado este CIO.
Nuevamente, estos números no incluyen órdenes de seguridad nacional como NSL o FISA. La cantidad de solicitudes
de cumplimiento de la ley recibidas por Google fue significativamente mayor que la de otros CSP. Presuntamente,
muchas de estas solicitudes se centraron en la evidencia potencial almacenada en el servicio de correo electrónico
Gmail de Google y en los resultados de búsqueda de Google, los cuales son muy utilizados por los consumidores.
Microsoft también proporciona el servicio de correo electrónico para consumidores de Outlook y Bing para búsquedas en Internet.
Figura 7.6: Número total de solicitudes de aplicación de la ley de todo el mundo enviadas a CSP
seleccionados con sede en EE. UU. entre la primera mitad de 2018 (1S18) y la primera mitad de
2021 (1S21) de agencias de aplicación de la ley de todo el mundo (Amazon, nd; Google, nd; Microsoft, nd )
Ahora, eliminemos las solicitudes realizadas por los organismos encargados de hacer cumplir la ley fuera de los EE. UU. Figura 7.7
refleja todas las solicitudes realizadas por las fuerzas del orden de EE. UU. durante las mismas escalas de tiempo. Observe cuánto
más pequeña es la escala del gráfico y estos números en comparación con la figura anterior. Esto revela que existe un volumen
significativo de solicitudes que provienen de organismos encargados de hacer cumplir la ley fuera de los EE. UU. Muchos ejecutivos a
los que aconsejé creían que EE. UU. era el único país que hacía tales solicitudes.
Capítulo 7 277
Figura 7.7: Número total de solicitudes de cumplimiento de la ley de EE. UU. enviadas a AWS,
Google y Microsoft entre la primera mitad de 2018 (1S18) y la segunda mitad de 2021 (2S21)
(Amazon, nd; Google, nd; Microsoft, nd)
Ahora, solo incluyamos las solicitudes en las que el contenido se proporcionó potencialmente a la agencia de
cumplimiento de la ley solicitante. Eliminé las solicitudes que no estaban relacionadas con el contenido, fueron
rechazadas o no válidas, o en las que no se encontraron datos. Esto requiere un pequeño análisis porque estos
proveedores informan estos datos de diferentes maneras. Esto nos da una estimación de la cantidad bruta de solicitudes
de las agencias de aplicación de la ley de EE. UU. en las que se solicitó contenido mediante una orden válida u orden
judicial, y se proporcionó parte del contenido.

Nótese nuevamente que la escala del gráfico es más pequeña que las gráficas anteriores y que los volúmenes de
solicitudes son más bajos.
Figura 7.8: Número total de solicitudes de aplicación de la ley de EE. UU. enviadas a AWS,
Google y Microsoft en las que se proporcionó algún contenido entre la primera mitad de 2018
(1S18) y la segunda mitad de 2021 (2S21) (Amazon, nd; Google, nd; Microsoft, nd)
La Figura 7.8 nos muestra el volumen de solicitudes de cumplimiento de la ley de EE. UU. recibidas por estos CSP
donde el contenido se reveló a las autoridades. Como porcentaje de todas las solicitudes de EE. UU. enviadas a
Microsoft durante este período, entre el 10 % y el 15 % dieron como resultado divulgaciones de contenido. Google
informó que el porcentaje de solicitudes que recibieron durante este período en las que se divulgó alguna información osciló entre
80% a 84%.
Los recuentos de solicitudes de AWS en la Figura 7.8 se basan en los datos publicados en los Informes de solicitudes
de información de Amazon para períodos que incluyen 2018, 2019 y la primera mitad de 2020. En estos informes, Am
azon proporciona definiciones para los diferentes tipos de demandas policiales que reciben, que incluyen
órdenes de allanamiento.
”Las órdenes de allanamiento pueden ser emitidas por tribunales locales, estatales o
federales si se demuestra causa probable y deben identificar específicamente el lugar a
buscar y los artículos a incautar. Podemos producir información sin contenido y con
contenido en respuesta a órdenes de registro válidas y vinculantes. Amazon se opone a
las órdenes de registro demasiado amplias o inapropiadas como algo natural”. (Amazonas, 2018)
Capítulo 7 279
Los recuentos de solicitudes en la Figura 7.8 se basan en recuentos de "respuesta completa" y "respuesta parcial" para
órdenes de allanamiento recibidas de tribunales locales, estatales y federales en los EE. UU. según lo publicado por Amazon.
Con estas cifras, podemos obtener una estimación de la cantidad de veces que el contenido se reveló a las fuerzas del
orden. Estas cifras pueden incluir casos en los que a AWS se le solicitó contenido, pero en su lugar solo proporcionó
contenido sin contenido (metadatos). Los informes de solicitud de información de Amazon publicados entre 2018 y la
primera mitad de 2020 no brindan suficientes detalles para ser más específicos que eso.
Durante los 5 períodos de 6 meses entre 2018 y la primera mitad de 2020, estos casos representaron entre el 7% y el 10%
de todas las solicitudes de EE. UU. que recibió AWS. Amazon cambió el formato de sus informes en la segunda mitad de
2020 y los informes recién publicados ya no incluyen estas cifras, como se refleja en la Figura 7.8. Sin embargo, para la
segunda mitad de 2020 y ambas mitades de 2021, sí incluyen el número total de todas las solicitudes de aplicación de la
ley (a nivel mundial) que resultaron en la "divulgación de información de contenido" (Amazon, 2021). Aunque no es
específico de las fuerzas del orden de los EE. UU. como lo son los datos de Google y Microsoft, estos datos aún brindan
una idea de la frecuencia con la que el contenido es

revelado a las fuerzas del orden. El número de casos en los que el contenido se divulgó como resultado de una
la solicitud válida de aplicación de la ley estuvo entre el 2 % y el 3 % de todas las solicitudes (3 % en el 2S20, 2 % en el
1S21 y 2,4 % en el 2S21) (Amazon, sin fecha).
Podemos continuar analizando esta solicitud de aplicación de la ley y los datos de divulgación en al menos un par de
formas diferentes para obtener estimaciones de probabilidad aún más precisas para nuestros cálculos de riesgo . Por
ejemplo, cuando los datos están disponibles, podemos centrarnos en la cantidad de solicitudes de aplicación de la ley que
estos CSP recibieron solo para clientes empresariales. Esto podría proporcionar al CIO en nuestro escenario la mejor
estimación de la probabilidad de que estos CSP reciban una solicitud de sus datos empresariales.
Google comenzó a publicar datos específicamente sobre solicitudes de cumplimiento de la ley para clientes empresariales
en 2019 como parte de su informe de transparencia en una página web llamada "Solicitudes empresariales en la nube
para información del cliente" (Google, sin fecha). La Figura 7.9 proporciona la cantidad de solicitudes de las fuerzas del
orden de EE. UU. que involucraron solo a clientes de la nube empresarial de Google. La cifra también proporciona el
porcentaje de estas solicitudes que resultaron en la divulgación de algún contenido.

Al igual que Microsoft, Google informa la cantidad de solicitudes de seguridad nacional por separado, por
lo que no se incluyen en estas cifras.
Figura 7.9: La cantidad de solicitudes de cumplimiento de la ley de EE. UU. que involucran solo a clientes de
la nube empresarial de Google y el porcentaje de solicitudes en las que se divulgó información del cliente de
la nube empresarial (Google, nd)
La figura 7.9 revela volúmenes de solicitudes mucho más pequeños una vez que se eliminan todas las solicitudes de
aplicación de la ley para cuentas de consumidores de Google y solo se ven las solicitudes de clientes de la nube
empresarial de Google. Por ejemplo, en la segunda mitad de 2021, hubo un total de 46 828 solicitudes de aplicación
de la ley de EE. UU., lo que resultó en que los datos se compartieran en el 84 % de esas solicitudes (Google, sin
fecha). De estas solicitudes, solo 223 involucraban a clientes de la nube empresarial de Google, lo que resultó en la
divulgación de contenido el 58 % de las veces (Google, nd).
Microsoft y AWS no parecen publicar la misma información que Google en sus respectivos informes de transparencia.
Sin embargo, en el caso de AWS, la gran mayoría de sus clientes son empresas . Se enfocan en brindar servicios en
la nube a organizaciones del sector público y privado, no a los consumidores. Presuntamente, la mayoría del volumen
de solicitudes que reciben involucra a clientes empresariales, aunque AWS no indica qué tipos de solicitudes de
cumplimiento de la ley de los clientes involucran en los Informes de solicitud de información de Amazon que cubren el
período entre 2018 y la primera mitad de 2020 (Amazon, nd). La figura 7.10 se basa en datos de estos informes y nos
muestra la cantidad de solicitudes de las fuerzas del orden de EE. UU. que recibió AWS, junto con el porcentaje de
casos en los que se brindó una respuesta parcial o total. Nuevamente, la cantidad de casos en los que el contenido
se divulgó potencialmente se estima utilizando las cifras de "respuesta parcial" y "respuesta completa" publicadas por
AWS. Los números reales podrían ser más pequeños.

Capítulo 7 281
Figura 7.10: La cantidad de solicitudes de cumplimiento de la ley de EE. UU. que recibió AWS y el
porcentaje de solicitudes en las que se brindó una respuesta parcial o total, para el período entre 2018
y la primera mitad de 2020 (Amazon, nd)
¿Qué pasa con el volumen de solicitudes de aplicación de la ley de EE. UU. que recibe Microsoft, donde se vieron
obligados a divulgar contenido de clientes empresariales? Microsoft responde a esta pregunta en la sección de
preguntas frecuentes de su Informe de solicitudes de aplicación de la ley.
”En la segunda mitad de 2021, Microsoft recibió 120 solicitudes de las fuerzas del orden
público de todo el mundo para cuentas asociadas con clientes empresariales en la nube. En
65 casos, estas solicitudes fueron rechazadas, retiradas, sin datos o la aplicación de la ley
se redirigió con éxito al cliente. En 55 casos, Microsoft se vio obligado a proporcionar
información receptiva: 29 de estos casos requirieron la divulgación de algún contenido del
cliente y en 26 de los casos nos vimos obligados a divulgar información que no es de
contenido únicamente. De las 29 instancias que requirieron la divulgación de datos de
contenido, 26 de esas solicitudes estaban asociadas con la aplicación de la ley de los EE. UU. (Microsoft, sin fecha)
Según esta información y otra información del mismo informe, los organismos encargados de hacer cumplir la ley
en todo el mundo realizaron 25 182 solicitudes en la segunda mitad de 2021. De estas, solo 120 solicitudes (0,5
%) se asociaron con clientes de nube empresarial. Microsoft se vio obligado a revelar contenido de clientes
empresariales a las autoridades estadounidenses en 26 de estos casos. Esto significa que el contenido de clientes
empresariales se reveló a las autoridades de EE. UU. en el 0,1 % de todas las solicitudes de Microsoft.
recibido en el segundo semestre de 2021.
Hay una información más que podría ayudar al CIO de la empresa con sede en Alemania a comprender la probabilidad
de que el gobierno de EE. UU. acceda a los datos. Al CIO realmente no le importa cuántas solicitudes hacen las
fuerzas del orden de EE. UU. por contenido que tienen empresas con sede en EE. UU. porque está claro que las
empresas con sede en EE. UU. están bajo la jurisdicción de las agencias de aplicación de la ley de EE. UU.
A este CIO le gustaría conocer la cantidad de solicitudes que hacen las fuerzas del orden de los EE. UU. para obtener
datos retenidos fuera de los EE. UU. en Alemania, la UE y el EEE, donde se divulga parte del contenido de los clientes.
Estas cifras podrían ser una de las mejores entradas para sus cálculos de riesgo asociados con la adición de un CSP
con sede en EE. UU. a sus operaciones de TI existentes. Afortunadamente para el CIO, AWS y Microsoft brindan
datos que responden a esta pregunta.
AWS comenzó a publicar la siguiente pregunta en la sección de Preguntas frecuentes (FAQ) de sus Informes de
solicitud de información de Amazon en la segunda mitad de 2020 cuando se actualizó el formato de su informe.
"¿Cuántas solicitudes dieron como resultado la divulgación al gobierno de los EE. UU. de datos de contenido
empresarial ubicados fuera de los Estados Unidos?" (Amazon, 2021) La figura 7.11 proporciona las respuestas que
AWS especificó para cada período de 6 meses entre la segunda mitad de 2020 y la primera mitad de 2022. En
resumen, AWS no reveló datos de contenido empresarial ubicados fuera de EE. UU. al gobierno de EE. UU. durante
los 24 meses entre la segunda mitad de 2020 (2S20) y la primera mitad de 2022 (1S22).
Figura 7.11: Respuesta de AWS a la pregunta "¿Cuántas solicitudes dieron como resultado la divulgación
al gobierno de los EE. UU. de datos de contenido empresarial ubicados fuera de los Estados Unidos?"
para cada período de 6 meses entre la segunda mitad de 2020 y la primera mitad de 2022 (Amazon, nd)
Microsoft publicó el siguiente elemento en la sección de preguntas frecuentes de su Informe de solicitudes de aplicación
de la ley, "Número de órdenes judiciales de las fuerzas del orden de EE. UU. que resultaron en la divulgación de datos
de contenido empresarial almacenados fuera de los Estados Unidos". (Microsoft, sin fecha) La figura 7.12 proporciona
los datos asociados de estos informes para cada período de 6 meses entre la primera mitad de 2020 y la segunda
mitad de 2021. Estas cifras representan entre el 0,02 % y el 0,05 % del número total de solicitudes de aplicación de la
ley de EE. UU. durante estos períodos.

Capítulo 7 283
Figura 7.12: La respuesta de Microsoft a la pregunta "Número de órdenes de las fuerzas del orden de EE.
UU. que resultaron en la divulgación de datos de contenido empresarial almacenados fuera de los Estados
Unidos" para cada período de 6 meses entre la primera mitad de 2020 (1S20) y la segunda mitad de 2021
(2S21), incluye el porcentaje del número total de solicitudes que representa cada respuesta (Microsoft, nd )
Además, en la sección de preguntas frecuentes de su Informe de solicitudes de cumplimiento de la ley, Microsoft brinda
cierto contexto sobre el volumen de solicitudes de la Ley CLOUD que recibieron, que presumiblemente ya se refleja en la
Figura 7.12.
”En la segunda mitad de 2021, Microsoft recibió 5601 demandas legales de datos de consumidores
de las fuerzas del orden público de los Estados Unidos. De esas, 136 garantías buscaban datos
de contenido que se almacenaron fuera de los Estados Unidos.
En el mismo período de tiempo, Microsoft recibió 90 demandas legales de las fuerzas del orden
en los Estados Unidos para clientes de empresas comerciales que compraron más de 50 puestos.
De esas demandas, 3 órdenes dieron como resultado la divulgación de datos de contenido
relacionados con un cliente empresarial no estadounidense cuyos datos se almacenaron fuera
de los Estados Unidos”. (Microsoft, sin fecha)
Estos datos le darán al CIO de la empresa alemana cierta confianza en que la frecuencia con la que las fuerzas del orden
estadounidenses atacan a empresas extranjeras y organizaciones del sector público con órdenes de arresto y órdenes
judiciales es realmente anómala. Estos datos ayudarán a informar el lado de la probabilidad de sus cálculos de riesgo
relacionados con el aprovechamiento de los CSP con sede en EE. UU. Además, estos datos permiten que el CIO reconozca
a los proveedores que intentan sembrar el miedo, la incertidumbre y las dudas sobre el acceso de las fuerzas del orden
público de EE. UU. a los datos en la nube. Ahora que tenemos una idea del volumen de solicitudes de aplicación de la ley, el
CIO todavía quiere comprender el volumen de las órdenes de seguridad nacional de las agencias de inteligencia de EE. UU.
que reciben estos tres CSP con sede en EE. UU. Examinemos esto a continuación.
El RGPD, FISA Sección 702 y Schrems II

Si vive en los EE. UU., es posible que se pregunte por qué el CIO de una empresa de gran prestigio en Alemania estaría
preocupado por las órdenes NSL y FISA de los EE. UU. Después de todo, si la firma del CIO no está involucrada en
terrorismo, lavado de dinero para financiar el terrorismo o espionaje, ¿por qué estarían preocupados por
¿Leyes estadounidenses establecidas para vigilar tales actividades?
La respuesta a esta pregunta es un poco complicada, pero intentaré resumir la situación, lo que significa que pasaré por
alto muchos detalles. El RGPD regula la transferencia transfronteriza de información personal fuera de la UE y el EEE.
Escuché a muchos ejecutivos estadounidenses afirmar que el RGPD no se aplica a ellos porque no hacen negocios en
la UE o el EEE. Sin embargo, el RGPD es extraterritorial, lo que significa que no solo regula la transferencia de datos
entre los estados miembros de la UE, sino que se aplica en todo el mundo. Se aplica tanto al sector comercial como al
sector público. Posteriormente, muchos países han promulgado sus propias versiones locales similares del RGPD para
garantizar que sus industrias lo cumplan.
Es importante entender que el propósito del RGPD es permitir el comercio transfronterizo mientras se protege la
información personal de las personas. Algunos de los profesionales de la seguridad en los EE. UU. con los que he
discutido el RGPD asumen que trata de evitar la transferencia de datos, pero su propósito es regular
la transferencia de datos.
”La Directiva 95/46/CE del Parlamento Europeo y del Consejo tiene por objeto armonizar
la protección de los derechos y libertades fundamentales de las personas físicas con
respecto a las actividades de tratamiento y garantizar la libre circulación de datos
personales entre los Estados miembros.” (El Parlamento Europeo y el Consejo de la
Unión Europea, 2016)
Según el RGPD, no se permite la transferencia de datos personales de interesados de la UE a países fuera del EEE
(llamados terceros países), a menos que se cumplan requisitos específicos, o el tercer país tenga una "decisión de
adecuación" del RGPD. Los datos pueden transferirse entre el EEE y el tercer país sin garantías adicionales cuando el
tercer país tiene una decisión de adecuación. La decisión de adecuación indica que el tercer país tiene niveles de
protección de datos y privacidad que cumplen con los estándares de la UE. Actualmente, solo 15 países en el mundo
tienen una de estas decisiones de adecuación.
Puede ver la lista de países con decisiones de adecuación en el sitio web de la Comisión
Europea: https://ec.europa.eu/info/law/lawtopic/dataprotection/internationaldimension
proteccióndedatos/adequacydecisions_es/.
Capítulo 7 285
Las otras dos formas en que la información personal del sujeto de datos de la UE podría transferirse fuera
del EEE eran las Cláusulas contractuales estándar (SCC) y el Escudo de privacidad UEEE. UU. El
incumplimiento del RGPD podría dar lugar a multas administrativas de hasta 20 millones de euros o el 4 %
de los ingresos anuales mundiales de la organización del año anterior, el que sea mayor; esto le da a esta
regulación suficiente potencial para atraer mucha atención. Posteriormente, todos los clientes del sector
público y privado que asesoré en Europa después de mayo de 2018, cuando comenzó la aplicación del
RGPD , querían discutir las mejores prácticas para cumplir con el RGPD. Desde entonces, se han impuesto
cientos de multas administrativas del RGPD. Hasta el momento, la multa administrativa más grande de
GDPR fue de un estimado de $ 887,000,000 (Business Insider, 2021). Las grandes empresas tecnológicas
estadounidenses, incluidas Amazon, Instagram, WhatsApp, Google y Facebook, recibieron algunas de las
multas más grandes: decenas de millones de dólares y, en algunos casos, cientos de millones (Cohen, 2022).
En julio de 2020, el Tribunal de Justicia de la Unión Europea (TJUE) invalidó la decisión de adecuación que
sustentaba el Escudo de privacidad UEEE. UU. Hasta ese momento, el Escudo de privacidad se utilizaba como
marco legal para facilitar las transferencias transfronterizas de datos personales de sujetos de datos de la UE
para usos comerciales entre la UE y los EE. UU. Al seguir los requisitos de protección de datos del programa
Privacy Shield, las transferencias de datos de los participantes del programa se considerarían compatibles con
la legislación de la UE. La decisión judicial del TJUE de invalidar el Escudo de privacidad se denomina Schrems
II, en honor al abogado austriaco que presentó la denuncia contra Facebook que dio lugar a la sentencia del
tribunal, conocida como Data Protection Commissioner v. Facebook Ireland Limited, Maximillian Schrems . La
sentencia del TJUE encontró,
”…Privacy Shield es inadecuado en parte porque no restringe las actividades de recopilación de
datos de las autoridades de inteligencia de EE. UU. De acuerdo con el TJUE, la ley de EE. UU.
permite que las agencias de inteligencia recopilen y utilicen los datos personales transferidos en
el marco del Escudo de privacidad de una manera que es incompatible con los derechos
garantizados por la ley de la UE. El TJUE se centró en la Sección 702 de la Ley de Vigilancia de
Inteligencia Extranjera , la Orden Ejecutiva 12333 y la Directiva de Política Presidencial 28, que
rigen cómo el gobierno de los EE. UU. puede realizar la vigilancia de personas no estadounidenses
ubicadas fuera de los Estados Unidos”. (Servicio de Investigación del Congreso, 2021)
El hallazgo del tribunal hizo referencia directa a la Sección 702 de FISA y la Orden Ejecutiva 12333. Es posible
que se pregunte qué tienen que ver con el RGPD y las transferencias de datos. La NSA describe la Sección 702
de FISA de esta manera,
”En general, la Sección 702 autoriza al Fiscal General y al Director de Inteligencia Nacional
a realizar y presentar al Tribunal FISA certificaciones escritas con el propósito de adquirir
información de inteligencia extranjera. Tras la emisión de una orden por parte del Tribunal
FISA que aprueba dicha certificación y el uso de procedimientos de focalización y
minimización, el Fiscal General y el Director de Inteligencia Nacional pueden autorizar
conjuntamente por hasta un año la focalización de personas no estadounidenses que
razonablemente se crea que se encuentran en el extranjero para adquirir información de
inteligencia extranjera”. (Agencia de Seguridad Nacional/Servicio Central de Seguridad, sin fecha)
Un problema que citó el TJUE fue: "Las limitaciones de la Sección 702 sobre los recursos judiciales para los
ciudadanos de la UE no cumplen con los requisitos del RGPD" (Congressional Research Service, 2021). Es
decir, en algunas circunstancias, la Sección 702 de FISA podría permitir la vigilancia secreta sin oportunidad para
revisión judicial para los ciudadanos de la UE. Por ejemplo, si las autoridades de los EE. UU. decidieran utilizar
la evidencia recopilada de la vigilancia de la Sección 702 de la FISA para enjuiciar a una persona no
estadounidense por un delito, esa persona y sus abogados, en algún momento, recibirían un aviso de que se
llevó a cabo esta vigilancia y se confrontarían con la evidencia recopilada (Congressional Research Service,
2021). Luego, el tribunal podría revisar la vigilancia y su legalidad, pero si las autoridades deciden no procesar
al objetivo de la vigilancia por un delito relacionado, es probable que el objetivo nunca sepa que ha estado bajo
vigilancia y no tendrá la oportunidad de solicitar una revisión judicial de la vigilancia y la información personal
recopilada. El TJUE también encontró que los ciudadanos de la UE no tenían derechos exigibles bajo la Orden
Ejecutiva 12333 y que no incluía suficientes protecciones para limitar la vigilancia a un alcance razonable
(Congressional Research Service, 2021).
Con el Escudo de privacidad UEEE. UU. invalidado y sin una decisión de adecuación para los EE. UU., solo quedan los
SCC para proteger a las organizaciones que transfieren los datos personales de los interesados del EEE fuera del EEE.
Las SCC son cláusulas contractuales que incluyen cláusulas preaprobadas por la UE que imponen estándares
de protección de datos a las organizaciones que las utilizan. Sin embargo, la implementación técnica de los
estándares y requisitos de protección de datos bastante vagos en los SCC deja su eficacia legal abierta a la
interpretación. Esta incertidumbre hace que algunas organizaciones se sientan incómodas con el uso de SCC
como medio legal para transferir los datos personales de los interesados del EEE fuera del EEE. Tenga en
cuenta que, para muchas de estas organizaciones, la decisión de utilizar SCC representa hasta 20 millones de
euros o el 4 % de sus ingresos mundiales anuales en posibles multas administrativas del RGPD.
Capítulo 7 287
Esta es una de las razones por las que el CIO de la empresa alemana en nuestro escenario, y tantos otros, están
preocupados por el riesgo que las órdenes de seguridad nacional de EE. UU. representan para sus organizaciones.
Según la interpretación actual del TJUE, la Sección 702 de FISA y la Orden Ejecutiva 12333 no ofrecen a los sujetos
de datos de la UE los mismos derechos que los ciudadanos estadounidenses en lo que respecta a la vigilancia de
inteligencia estadounidense. Uno de los riesgos previstos es que si las autoridades estadounidenses interceptan las
transferencias de datos transfronterizas de una organización de la UE , no existe protección legal para los interesados
de la UE afectados y podría ser una violación del RGPD para la organización que realiza la transferencia. Con el
potencial de decenas de millones de euros en multas y una reputación arruinada en todo el EEE, muchas
organizaciones están preocupadas y prestan mucha atención a los cambios en el panorama legal a su alrededor, lo
que ralentiza la adopción de nuevas tecnologías.
Las revelaciones de Edward Snowden y WikiLeaks sobre los programas de inteligencia estadounidenses han
polarizado en gran medida la conciencia colectiva entre los europeos occidentales. Los beneficios masivos del
comercio transfronterizo con uno de los mercados comerciales más grandes del mundo y el intercambio de inteligencia
con uno de los aparatos de inteligencia más grandes del mundo ya no compensan los riesgos que la UE percibe en la
recopilación de datos de inteligencia de EE. UU. También parecen estar dispuestos a renunciar a los innegables
beneficios que ofrecen los servicios de los CSP de hiperescala con sede en EE. UU., junto con otras tecnologías
modernas que EE. UU. puede proporcionar, que pueden ayudar a llevar al futuro a los sectores público y privado europeos.
Este contexto proporciona una mejor comprensión del lado del impacto de la ecuación de riesgo que enfrentan las
organizaciones si se realiza el escenario mencionado anteriormente: un máximo de 20 millones de euros o el 4% de
sus ingresos anuales en todo el mundo y una reputación arruinada, pero, en este escenario, ¿cómo se ve el lado de
la probabilidad de la ecuación de riesgo para las organizaciones que agregan los servicios de un CSP con sede en
EE. UU. a su patrimonio de TI existente? Examinemos esto a continuación para ayudar al CIO alemán al que
asesoramos a comprender ambos lados de la ecuación de riesgo.
La probabilidad de que la inteligencia estadounidense acceda a los datos en la nube

Tal vez recuerde que las órdenes de seguridad nacional incluyen NSL y órdenes FISA que se agrupan en rangos
como 0499. Veamos el volumen de estas solicitudes que Microsoft, Google y AWS
recibir.
Microsoft proporciona algo de contexto sobre por qué solo se les permite publicar el volumen de pedidos FISA y NSL
en rangos.
”Antes de 2014, a los proveedores de tecnología de EE. UU. no se les permitía reportar ninguna
información sobre las demandas de seguridad nacional de EE. UU. Como resultado del litigio que
Microsoft y otras empresas de tecnología presentaron contra el gobierno de los EE. UU. en 2014, el
gobierno acordó por primera vez permitir que las empresas de tecnología publicaran datos sobre los
pedidos de FISA. Si bien existen algunas limitaciones sobre lo que podemos publicar, este informe
presenta la imagen más completa y legalmente permisible de los tipos de solicitudes que recibimos del
gobierno de los EE. UU. de conformidad con las autoridades de seguridad nacional”. (Microsoft, 2021)
Tenga en cuenta que tanto Microsoft como Google dejan claro en sus respectivos informes que las NSL no se
pueden usar para solicitar contenido del cliente. estados de Microsoft,
”Las Cartas de seguridad nacional pueden requerir la divulgación de información básica del suscriptor,
como el nombre, la dirección y la duración del servicio de un cliente que se haya suscrito a uno de
nuestros servicios. Las NSL no se pueden utilizar para exigir la divulgación del contenido de las
comunicaciones o los datos de un cliente. Las NSL solo se pueden usar para solicitar información
básica del suscriptor que sea relevante para la seguridad nacional de los EE. UU. y no se pueden usar
para investigaciones penales, civiles o administrativas”. (Microsoft, 2021)
La descripción de Google de cómo se usan las NSL, publicada en su Informe de transparencia de Google, es
consistente con la de Microsoft. Google describió su uso de esta manera:
“Usando un NSL, el FBI puede buscar “el nombre, la dirección, la duración del servicio y los registros de
facturación de llamadas locales y de larga distancia” de un suscriptor de un servicio de comunicaciones
por cable o electrónico . El FBI no puede usar NSL para obtener nada más de Google, como contenido
de Gmail, consultas de búsqueda, videos de YouTube o direcciones IP de usuarios”. (Google, sin fecha)
Dado esto, centraré este examen en el volumen de órdenes FISA que resultaron en la divulgación de algún
contenido. Tanto Microsoft como Google proporcionan el volumen de solicitudes de seguridad nacional bajo la
FISA para solicitudes de contenido y no contenido. Veamos los volúmenes de solicitud de contenido de pedidos
FISA.
Capítulo 7 289
Según los datos publicados por Microsoft, para cada período de 6 meses desde la segunda mitad de 2011
hasta el final de la primera mitad de 2014, Microsoft recibió entre 0 y 999 pedidos FISA solicitando la divulgación
de contenido. En los 6,5 años entre 2015 y los primeros 6 meses de 2021 (el período más reciente publicado),
recibieron entre 0 y 499 de estos pedidos de búsqueda de contenido en cada período de 6 meses (Microsoft,
2021).
Google publica datos de órdenes de seguridad nacional en una sección de su Informe de transparencia
denominada " Solicitudes de seguridad nacional de Estados Unidos para información de usuarios" (Google, sin
fecha). Durante los 8 años entre 2011 y 2018, Google informa que la cantidad de solicitudes FISA de contenido
que recibieron en cada período de medio año fue de 500 a 999 (Google, sin fecha). Más recientemente, en los
2 años entre 2019 y finales de 2021, recibieron entre 0 y 499 solicitudes de este tipo en cada período de
informe (Google, sin fecha).
AWS publica el rango de solicitudes de seguridad nacional que recibe. En cada período de 6 meses en los 3,5
años entre 2018 y el final de la primera mitad de 2022, informaron que AWS recibió entre 0 y 250 solicitudes.
Han publicado la misma declaración en varios de sus Informes de solicitud de información de Amazon recientes:
"el rango de informes es 0249 para todas las solicitudes de seguridad nacional realizadas a Amazon (incluido
AWS)" (Amazon, 2021).
Dadas estas cifras informadas, es posible que ninguno de los tres CSP con sede en EE. UU. haya recibido una
orden de FISA en los últimos años. Sin embargo, debido a que las autoridades estadounidenses prohíben que
los proveedores publiquen la cantidad exacta de pedidos FISA que reciben, nos queda elegir qué cifra usar
para nuestro cálculo de riesgo, si usar cero o la cantidad máxima en el rango. Podríamos simplemente usar el
número máximo en cada rango informado para asegurarnos de no subestimar la probabilidad.
Para calcular las probabilidades, dividamos el número de solicitudes por el número de clientes activos que
utilizan estos servicios. Es probable que no podamos encontrar números exactos o incluso estimaciones de la
cantidad de clientes que usaron activamente los servicios de cada CSP durante cada período de tiempo, pero
dado que estas son algunas de las empresas de alta tecnología más grandes del mundo, sabemos
anecdóticamente que tienen millones de clientes empresariales activos cada una. Es probable que AWS,
Google y Microsoft tengan muchos millones de clientes empresariales en todo el mundo, pero usemos un
número bajo a propósito. Si solo usamos 2 millones de clientes empresariales como base de nuestro cálculo
de división, esto generará una mayor probabilidad que si usamos un número de base de clientes más grande
y preciso. Esto hará menos probable que subestimemos las probabilidades.
La Figura 7.13 contiene los porcentajes estimados de clientes empresariales de AWS afectados por los pedidos
FISA recibidos por AWS en cada período de 6 meses entre la primera mitad de 2018 (1S18) y la primera mitad
de 2022 (1S22), según los datos publicados en numerosas informaciones de Amazon.
Solicitar Informes.
La cantidad de clientes empresariales utilizada como base es solo una estimación; la cantidad real
podría ser mayor.
Figura 7.13: El volumen de pedidos FISA, según lo informado en los informes de solicitud de información de
Amazon desde 2018 hasta la primera mitad de 2022, dividido por una base estimada de 2 millones de clientes
empresariales, convertido en un porcentaje (Amazon, nd)
La figura 7.14 aprovecha los datos publicados en el Informe de transparencia de Google para el período
comprendido entre 2018 y la primera mitad de 2022. Las órdenes FISA en la figura son aquellas que buscaban contenido.
El cálculo, utilizando 2 millones de clientes como base, proporciona un porcentaje estimado de los clientes de Google
potencialmente afectados por los pedidos de FISA que buscan contenido. Es probable que el número real de clientes de
Google sea mucho mayor.
Figura 7.14 El volumen de pedidos FISA que buscan contenido, según lo informado en el Informe de
transparencia de Google desde el primer semestre de 2018 (1S18) hasta el primer semestre de 2022 (1S22),
dividido por una base estimada de 2 millones de clientes, convertido en porcentaje (Google, nd)
Los porcentajes de aproximadamente 2 millones de clientes de Microsoft que se vieron potencialmente afectados por los
pedidos de FISA entre 2018 y el final de la primera mitad de 2021 se proporcionan en la Figura 7.15. El número de
clientes es una estimación deliberadamente baja, mientras que los datos de pedidos de FISA son proporcionados por el
Informe de pedidos de seguridad nacional de EE. UU. de Microsoft (Microsoft, 2021).

Capítulo 7 291
Figura 7.15: El volumen de pedidos FISA en busca de contenido, según lo informado en el Informe Nacional
de Pedidos de Seguridad de Microsoft, entre la primera mitad de 2018 (1S18) y la primera mitad de 2021
(1S21), dividido por una base estimada de 2 millones de clientes, convertido en porcentaje (Microsoft, 2021)
Como ilustran los datos de estas tres figuras, en los períodos de tiempo más recientes para los que tenemos
datos, la probabilidad estimada de materializar la amenaza de que las autoridades de EE. UU. usen órdenes FISA
para obtener acceso al contenido de los tres CSP de hiperescala con sede en EE. UU. está entre 0,0125 % y
0,05 %. Si tuviéramos un número exacto de usuarios activos, estos porcentajes probablemente serían aún más
pequeños. Por ejemplo, en un momento Microsoft reveló que tenía 20 millones de usuarios que usaban
activamente su servicio Teams (Spataro, 2019). Si usáramos esta base de usuarios como denominador en nuestro
cálculo, los porcentajes de los clientes de Microsoft afectados serían mucho menores (0,002495%). Si hiciéramos
ajustes similares a las bases de usuarios de Google y AWS en nuestros cálculos, sus respectivos porcentajes de
probabilidad serían más bajos que mis estimaciones.
Quizás se pregunte si estas probabilidades son buenas o malas. ¿Qué le decimos al CIO de la empresa alemana
que estamos asesorando? La respuesta realmente depende de dos cosas. En primer lugar, dado que el riesgo
es la combinación de probabilidad e impacto, el CIO debe discutir el impacto potencial con su asesor general y
equipo legal. Recuerde que algunas amenazas pueden tener una probabilidad muy baja, pero si se materializan,
el impacto puede ser alto. Aunque la probabilidad de que se presenten solicitudes de aplicación de la ley de EE.
UU. y órdenes FISA es muy baja, el CIO realmente necesita comprender el impacto potencial en su organización.
Una probabilidad del 0,0125 % de una posible multa máxima equivalente a 20 millones de euros o el 4 % de los
ingresos anuales podría seguir siendo un riesgo demasiado alto para las organizaciones que son extremadamente
adversas al riesgo. Algunos de los ejecutivos que conocí en Europa Occidental me dijeron que cualquier oportunidad
que la reputación de sus organizaciones pudiera verse empañada era demasiado alta. Dicho de otra manera, si
la probabilidad no era cero, era inaceptable para ellos. Por supuesto, las decisiones de riesgo deben tomarse
organización por organización.
Tenga en cuenta que imponer voluntariamente restricciones drásticas a la capacidad de las organizaciones,
industrias o grupos de países para competir o cumplir con sus estatutos de manera efectiva también tiene riesgos
y consecuencias asociados.
Hay costos de oportunidad por no tomar riesgos en la vida. En el caso del EEE y la computación en la nube, en lugar
de estar a la vanguardia de las nuevas tecnologías como lo han estado durante décadas, corren el riesgo de quedarse
atrás. Estas pequeñas probabilidades relacionadas con los pedidos de FISA están ralentizando la adopción de nuevas
tecnologías y, en consecuencia, ralentizando el progreso en todos los lugares donde se pueden aprovechar las nuevas
tecnologías.
El segundo factor a considerar al interpretar estas cifras de probabilidad es que los riesgos son relativos.
La mayoría de las organizaciones tienen recursos limitados, por lo que deben priorizar sus inversiones. Esto
también se aplica a la gestión del riesgo. El CIO de la empresa alemana debe combinar las solicitudes de orden
público de EE. UU. y los riesgos de órdenes FISA con todos los demás riesgos que su organización ha
identificado. Es probable que estos riesgos incluyan riesgos financieros, riesgos económicos, riesgos legales,
riesgos de recursos humanos, otros riesgos de ciberseguridad como ransomware y muchos otros. La clasificación
de Stack de cada amenaza por su probabilidad e impacto en la organización ayudará al CIO a identificar qué
riesgos debe priorizar la organización. Algunas organizaciones utilizan límites o umbrales (cualquier cosa por
encima de una puntuación de riesgo específica) para determinar qué riesgos se mitigarán y cuáles se aceptarán.
Si el riesgo de acceso legal del gobierno a los datos es un riesgo prioritario para la organización, entonces el
CISO, el equipo de seguridad y el equipo legal deben identificar una lista de posibles mitigaciones y sus costos
para la organización. La comunidad o el consejo de administración de riesgos de la empresa puede decidir si
mitigar el riesgo, tratar de transferirlo de alguna manera o aceptarlo. Esta decisión de gestión de riesgos debe
revisarse periódicamente para determinar si los cambios son prudentes en función de la nueva información o las circunstancias camb
Hay algunas organizaciones que están legalmente obligadas a evitar todas las formas de acceso no autorizado
a sus datos, incluidas las solicitudes de las agencias de inteligencia y las fuerzas del orden. Estas organizaciones
suelen tener inmunidad soberana. Estos incluyen agencias de aplicación de la ley, agencias de inteligencia,
agencias de seguridad nacional, brazos del ejército y organizaciones responsables de las economías de las
naciones como las reservas federales, los poderes judiciales, etc. También hay empresas del sector comercial
que deben proteger su propiedad intelectual, secretos comerciales e información de clientes más sensibles, o
se enfrentan a la extinción. Sin embargo, la gran mayoría de las organizaciones del sector público y privado con
las que he hablado a lo largo de los años no gastarán tiempo o recursos adicionales tratando de mitigar el
acceso del gobierno a los datos porque tienen riesgos de mayor prioridad para mitigar utilizando los recursos
que tienen. La mayoría de las organizaciones simplemente aceptan el riesgo de que el gobierno acceda a los
datos porque es mucho menor que otros riesgos a los que se enfrentan. Después de todo, rara vez ve informes
de noticias de que una empresa cerró después de recibir una solicitud de datos específicos en su poder para
una investigación criminal no relacionada con la empresa en sí, pero sí ve titulares casi todas las semanas sobre
ransomware que paraliza a las organizaciones y les cuesta millones.
Capítulo 7 293
A pesar de las probabilidades cercanas a cero asociadas con el acceso legal a los datos, es un riesgo que algunas
organizaciones aún optan por mitigar. Veamos lo que esto implica.
Mitigar el acceso del gobierno a los datos

Los controles de seguridad utilizados para mitigar el acceso legal del gobierno a los datos pueden o no ser también
efectivos para mitigar el acceso ilegal del gobierno a los datos y los escenarios de amenazas de inteligencia de
señales; es difícil determinar con tan poca información y datos disponibles públicamente sobre estas actividades.
Sin embargo, desde la perspectiva de una estrategia de seguridad cibernética, estos tres escenarios representan
esencialmente el mismo tipo de amenaza: la amenaza del acceso no autorizado a los datos. Para los profesionales
de la seguridad, esta es una construcción simple pero poderosa. Muchos de los mismos controles con los que ya
están familiarizados ayudarán a mitigar el acceso no autorizado a los datos, independientemente de quién intente acceder a ellos.
El CIO de la empresa alemana a la que hemos estado asesorando en este capítulo ahora comprende cuán baja es
la probabilidad de que el gobierno de EE. UU. acceda a los datos. El CIO está sorprendido de que las estimaciones
de probabilidad sean tan bajas, dada toda la prensa negativa y la preocupación que genera este tema en la UE.
Sin embargo, como medida de precaución, la compañía quiere tomar medidas adicionales para reducir aún más
esta probabilidad. A continuación, veremos una guía de alto nivel que ayudará a la empresa del CIO a mitigar aún
más el riesgo de que el gobierno de EE. UU. acceda a los datos cuando aprovechan
Servicios de CSP con sede en EE. UU.
Establecer y comprender el alcance

Es crucial ser específico sobre los datos que intenta proteger. Tratando de proteger algunos datos o todos
datos es un ejercicio teórico o académico. He discutido esto con muchos CISO y ejecutivos que
inicialmente se negaron a pasar de sus objeciones emocionales y teóricas a las soluciones del mundo real.
Repasarlos a través de los datos de los informes de transparencia y los cálculos de probabilidad asociados
generalmente ayudó a eliminar la emoción de estas conversaciones. Si realmente desea proteger los datos del
acceso no autorizado, identificar los datos específicos que deben protegerse es un primer paso crucial. Cuanto
menor sea el alcance, más posibilidades tendrá de éxito. Sin embargo, desarrollar un patrón repetible a partir de
este ejercicio que se pueda aplicar a otros conjuntos de datos más grandes es una buena práctica.
Identifique cómo estos datos de destino fluyen a través de su organización, incluso a través de su cadena de suministro.
Esto implica identificar dónde y cómo se transmiten, almacenan y procesan los datos de destino en su red y en las
redes de terceros que aprovecha su organización. Comprender estos flujos de datos le permite aplicar personas,
procesos y tecnologías para proteger y detectar intentos de acceso no autorizado y responder de la manera más
rápida y eficiente posible.
Por lo general, esta es una tarea desafiante con soluciones heredadas complicadas que se ejecutan en entornos de TI
grandes y complejos, pero no es posible proteger los datos de destino de manera efectiva sin comprender primero cómo
fluyen. Nuevamente, sea lo más específico posible al identificar todo el almacenamiento, las redes, las bases de datos y los
recursos informáticos que están involucrados en los flujos de datos de destino. Una vez que se comprendan bien los flujos
de datos de destino, puede desarrollar un plan para abordar cualquier brecha en la que los datos de destino no estén
debidamente protegidos.
Para las organizaciones que ya cuentan con prácticas efectivas de desarrollo de seguridad, es posible que este trabajo ya
se haya completado como parte del proceso de desarrollo de aplicaciones. Un primer paso muy efectivo en un ciclo de vida
de desarrollo de seguridad es el desarrollo de un modelo de amenaza. Un antiguo compañero de trabajo mío en Microsoft,
Adam Shostack, escribió un excelente libro sobre este tema que recomiendo leer: Threat Modeling: Designing for Security
(Shostack, 2014).
Establecer objetivos realistas

Una parte importante de la planificación es establecer objetivos. En este caso, el CIO ha establecido un objetivo realista
para mitigar el acceso del gobierno a los datos: garantizar que todos los accesos a los datos de destino sean aprobados
primero por los propios procesos de solicitud de acceso de la empresa. Para los gobiernos que potencialmente buscan
acceder a los datos de destino, esto significa asegurarse de que el único curso de acción que tienen es cruzar las puertas
de la empresa a la luz del día con una orden judicial válida para que el Asesor Jurídico y el equipo legal de la empresa
puedan gestionar sus solicitudes . Recuerde, el equipo legal de su organización y los asesores externos son las mejores
medidas de mitigación contra las solicitudes legales de datos. Su equipo legal debe asegurarse de que las órdenes judiciales
sean válidas y vinculantes, e impugnar las órdenes que sean demasiado amplias.
Sin embargo, no pueden administrar las solicitudes de acceso a datos de destino de las que no tienen conocimiento. Si las
solicitudes del gobierno van a los socios de la cadena de suministro de una organización en lugar de directamente a ellos,
el gobierno podría obtener acceso a los datos de destino sin darle a la organización ninguna oportunidad de oponerse a esa
acción. Esta es la razón por la que tantos CISO fuera de EE. UU. están preocupados por las solicitudes de aplicación de la
ley de EE. UU. que tienen órdenes de mordaza adjuntas y órdenes FISA emitidas por un tribunal secreto.
Aun así, los CISO y los ejecutivos que intentan mitigar un riesgo con una probabilidad del 0,025 % (o inferior) simplemente
negándose a utilizar los servicios de CSP con sede en EE. UU. pagan costos de oportunidad muy desproporcionados
porque sus organizaciones dejan de usar servicios en la nube que probablemente estén entre 5 y 10 años antes de lo que
posiblemente puedan lograr en sus entornos de TI locales heredados. Hablaré de esto con más profundidad en el Capítulo
12, Enfoques modernos para la seguridad y el cumplimiento.
Los profesionales de la seguridad no pueden evitar que los gobiernos realicen solicitudes legales de sus datos de destino,
pero pueden hacer todo lo posible para garantizar que dichas solicitudes vayan directamente a sus organizaciones en lugar
de a sus socios de la cadena de suministro.

Capítulo 7 295
En otras palabras, asegurar los datos de destino para que los socios de la cadena de suministro no puedan acceder a
ellos para cumplir con las demandas gubernamentales que puedan recibir obligará a los gobiernos que buscan datos a
solicitarlos directamente a su propietario/controlador. Este debería ser el objetivo principal de mitigar el riesgo de acceso
del gobierno a los datos.
Una consideración importante es si todos los proveedores en su cadena de suministro están dispuestos y son
capaces de impugnar las solicitudes legales de datos. Todos los CSP de hiperescala con sede en EE. UU. han
declarado públicamente que sus abogados revisan las solicitudes que reciben y se aseguran de que cumplan con la
letra de la ley y no se extralimiten. Sus negocios en la nube dependen de la confianza. Para ellos, perder la confianza
de sus clientes significa perder su participación en una industria de un billón de dólares en rápido crecimiento en sus primeros años.
Por lo tanto, están dispuestos a defender la privacidad de sus clientes desafiando las solicitudes cuando sea
apropiado hacerlo, pero es probable que no todos los proveedores de tecnología en la cadena de suministro de
una organización estén dispuestos y puedan resistir estas solicitudes legales. Si este es un riesgo que una
organización toma en serio, entonces debe elegir a sus proveedores teniendo esto en cuenta.
Planificación de controles de protección de datos

Ahora que hemos identificado los datos de destino que queremos proteger, entendemos cómo fluyen a través de
los sistemas de nuestra organización y los de nuestros socios de la cadena de suministro, y tenemos un objetivo
claro, podemos diseñar procesos y tecnologías, administrados por personas y sistemas, para restringir el acceso
a los datos de destino. Existen numerosos controles legales, administrativos y técnicos que podrían emplearse
para hacer esto. No reimprimiré NIST SP 80053 aquí. El resto de este libro está dedicado a examinar estrategias
de seguridad y algunas de ellas se pueden usar para proteger datos. Sin embargo, llamaré su atención sobre una
capacidad que considero el control definitivo para evitar el acceso no autorizado a los datos en la nube pública: el
cifrado del lado del cliente. Independientemente de dónde comenzaran mis conversaciones de asesoramiento
con los CISO y los ejecutivos, casi siempre terminaban con discusiones sobre el cifrado y las opciones de
administración de claves. Junto con algunos controles de apoyo, el cifrado del lado del cliente puede proteger sus
datos de destino en la nube de atacantes, CSP, socios de la cadena de suministro y gobiernos por igual. Sin
embargo, tiene sus propias limitaciones y costos de oportunidad que discutiré.
Cifrado del lado del cliente

El cifrado puede ayudar a mantener la confidencialidad e integridad de sus datos. Según los requisitos, el cifrado
también puede ayudar a las organizaciones a cumplir con algunas de sus obligaciones de cumplimiento.
Si el cifrado realmente puede ayudar con todas estas cosas, ¿por qué las organizaciones no han estado cifrando
todo en todas partes? Históricamente, el cifrado y la gestión de claves introdujeron fricciones en la puesta en
funcionamiento de los datos.
Dicho de otra manera, ha habido una tensión entre los beneficios de seguridad que brindan el cifrado y la administración
de claves y los requisitos operativos que la mayoría de las organizaciones tienen para sus datos.
Dado esto, la mayoría de las organizaciones que emplean el cifrado lo hacen con relativa moderación, tratando de equilibrar
los riesgos de seguridad con los riesgos operativos como los costos, la falta de experiencia y el interés comercial.
secuencias
El CIO de la empresa alemana a la que asesoramos está interesado en proteger sus datos de destino en la
nube de accesos no autorizados, incluidos los intentos de acceso no autorizados por parte de los propios CSP.
AWS, Google y Microsoft han desarrollado impresionantes capacidades de administración de claves y encriptación para
usar con sus servicios en la nube. Quieren ayudar a sus clientes a proteger los datos que están en tránsito y en reposo.
Han adoptado enfoques ligeramente diferentes para estos desafíos, pero el denominador común es que han tratado de
hacer que el uso del cifrado y la gestión de claves sea lo más sencillo posible. Han diseñado sistemas que pueden realizar
operaciones de encriptación y desencriptación ultrarrápidas que ayudan a proteger los datos de millones de clientes a
escalas masivas.
Para proteger los datos en reposo, existen dos opciones generales que ofrecen estos CSP: cifrado del lado del servidor y
cifrado del lado del cliente. El CSP administra el cifrado del lado del servidor después de que el cliente haya transferido sus
datos al servicio. Por ejemplo, cuando un cliente guarda datos nuevos en un servicio de almacenamiento en la nube, está
protegido por Transport Layer Security (TLS) a medida que se traslada desde su origen al servicio de almacenamiento en
la nube. Una vez que ingresa al servicio de almacenamiento en la nube, se puede emplear el cifrado del lado del servidor
para protegerlo. El servicio de almacenamiento en la nube es responsable de implementar adecuadamente los algoritmos
de cifrado y descifrado utilizados y de administrar las claves. El cliente trae los datos y los servicios de CSP los cifran y
luego los descifran a medida que los clientes acceden a ellos. La complejidad del cifrado, descifrado y gestión de claves se
abstrae del cliente. Dicho de otra manera, el cliente ha delegado la responsabilidad del cifrado y la gestión de claves al CSP.
El CIO de la empresa alemana a la que asesoramos se apresura a señalar que cuando se usa el cifrado del
lado del servidor, los CSP tienen acceso a las claves utilizadas para los procesos de cifrado y descifrado
porque las están administrando . Esto es exacto, pero los CSP han diseñado e implementado servicios de
administración de claves respaldados por módulos de seguridad de hardware (HSM). Los HSM están
diseñados para dificultar o imposibilitar la eliminación de material clave de ellos, incluso por parte de los
administradores del sistema. Estos HSM suelen ser a prueba de manipulaciones, lo que significa que si
alguien intentara entrar físicamente en uno de ellos, sería obvio para cualquiera que inspeccione el HSM.
Dada la forma en que están diseñados los HSM, el acceso físico no permitiría acceder fácilmente al material
clave. Al hacer esto, los CSP mitigan el riesgo de amenazas internas al material clave y se ganan la confianza de sus clientes.
Sin embargo, el CIO alemán no quiere usar el cifrado del lado del servidor y deja que su CSP administre las claves en su
nombre.
Capítulo 7 297
Recuerde, están tratando de mitigar un riesgo que ya es pequeño: quieren opciones de mitigación que resulten en un
riesgo casi nulo de acceso no autorizado a sus datos de destino.
Este es un escenario en el que el cifrado del lado del cliente puede ayudar. Con este enfoque, antes de que los datos se
transmitan a cualquier lugar, primero la aplicación cliente los cifra. La aplicación cliente que se ejecuta en el entorno de TI
local del cliente gestiona las operaciones de cifrado y descifrado, así como la recuperación y el uso de claves para estos
fines. Esto significa que el desarrollador de la aplicación, en este caso el cliente del CSP, es responsable de implementar
algoritmos de encriptación, administrar claves y realizar operaciones de encriptación y desencriptación.
Aprovechar el cifrado del lado del cliente significa que el cliente, no el CSP, es responsable del cifrado y la gestión de
claves.
Debido a que el cliente puede decidir dónde y cómo se usarán sus claves, y él mismo realiza todas las operaciones de
cifrado y descifrado, puede optar por no compartir nunca sus claves o datos de texto simple con su CSP. Permítanme
proporcionar un escenario de ejemplo. Un cliente tiene una aplicación ejecutándose en su propio centro de datos local
que procesa datos y luego los almacena. El cliente quiere aprovechar los muchos beneficios de los servicios de
almacenamiento en la nube, pero no quiere que el CSP tenga acceso a los datos que almacenan en la nube. Pueden usar
el cifrado del lado del cliente para lograr esto. Después de que la aplicación procese los datos, debe prepararlos para el
almacenamiento. La aplicación puede generar claves de cifrado o recuperarlas de la propia infraestructura de administración
de claves local del cliente , como un HSM. La aplicación utiliza estas claves para cifrar los datos que va a almacenar en la
nube. Una vez que los datos se cifraron en el centro de datos local del cliente, la aplicación transfiere los datos cifrados al
servicio de almacenamiento del CSP.
Ahora, una copia cifrada de los datos originales se encuentra en el servicio de almacenamiento en la nube. Los datos de
texto no cifrado y las claves de cifrado nunca se transfirieron fuera del centro de datos local del cliente. Debido a que el
CSP no tiene acceso a los datos de texto claro originales ni a las claves, no hay riesgo de que puedan acceder a los datos
utilizando la copia cifrada almacenada en su servicio de almacenamiento en la nube.
Hay algunas formas diferentes en que se puede aprovechar el cifrado del lado del cliente en un escenario de
almacenamiento como este. Estas son algunas de las opciones que tiene el cliente en este escenario de ejemplo. Tenga
en cuenta que esta no es una lista exhaustiva de opciones:
• En lugar de ejecutar la aplicación que realiza el cifrado en el centro de datos local, podría ejecutarse en una máquina
virtual (VM) que se ejecuta en la nube. Cuando la aplicación lo necesita, puede volver al centro de datos local a
través de una conexión VPN o una conexión dedicada para recuperar claves para realizar operaciones de cifrado
y descifrado, después de lo cual destruye las claves en la memoria de la máquina virtual. El CSP aún no tiene
acceso a datos o claves en texto claro.

• En lugar de ejecutar la infraestructura clave en el centro de datos local, se puede ejecutar en máquinas
virtuales en la nube. Estas máquinas virtuales pueden ser administradas por el cliente o por un tercero de
confianza, como un proveedor o una agencia no comercial, que brinde servicios de infraestructura clave.
El CSP aún no tiene acceso a datos o claves en texto claro.
• En lugar de aprovechar una infraestructura de gestión de claves por sí mismos, el cliente puede delegar parte
de esta responsabilidad al CSP. Por ejemplo, AWS CloudHSM es un servicio que permite a los clientes
aprovisionar su propia instancia de HSM de inquilino único en la nube que está validada por FIPS. El
CSP administra el hardware y el cliente es responsable de administrar la mayoría de los otros aspectos
de esta infraestructura por sí mismo, incluidas las copias de seguridad. El cliente obtiene los beneficios
de usar un HSM sin los costos y la complejidad de comprar y mantener su propio hardware. El CSP no
puede acceder al material clave en el HSM porque está diseñado específicamente para evitarlo.
• En lugar de aprovisionar y administrar la infraestructura clave por sí mismos, el cliente puede delegar esto
completamente al CSP. Todos los CSP ofrecen soluciones de almacén de claves completamente
administradas respaldadas por HSM. Estos servicios de administración de claves están integrados en
muchos de los otros servicios de los CSP para permitir operaciones de cifrado y descifrado transparentes
a escala en la nube a medida que los datos se mueven de un servicio a otro. El CSP asegura y administra las claves.
Existen algunas opciones que permiten a los clientes importar material de claves desde sus propias
infraestructuras de gestión de claves a los servicios de claves gestionados del CSP, lo que otorga al
cliente más control sobre la durabilidad y la vida útil de las claves.
Todas estas opciones brindan a los clientes cierta flexibilidad en la forma en que mitigan el riesgo de acceso no
autorizado a los datos. Sin embargo, el cifrado del lado del cliente no es una panacea; tiene algunas limitaciones
que deben considerarse cuidadosamente. La confidencialidad y la integridad que proporciona el cifrado del lado
del cliente tienen un costo. Las organizaciones que adoptan este enfoque deben tener la experiencia técnica para
gestionar sus propias operaciones de cifrado y descifrado a nivel de aplicación, además de gestionar sus propias
infraestructuras clave. Esto no es tan divertido como parece; Nunca conocí a nadie involucrado en la gestión de
HSM que deseara hacerlo. También hay que preocuparse por la integridad de los datos: si hay un error en el
código de cifrado del lado del cliente o en la gestión de las claves, los datos de la organización podrían perderse
para siempre. Es una gran responsabilidad para las organizaciones que eligen administrar todos los detalles por
sí mismas. Las organizaciones deben adquirir bibliotecas y módulos de criptografía validados en lugar de
desarrollar los suyos propios. Además , el cifrado del lado del cliente generalmente presenta costos más altos.
Mover datos entre los centros de datos locales y la nube para operaciones de cifrado y descifrado generalmente
tiene costos de transferencia asociados. Los HSM tampoco son económicos de adquirir o administrar.
Capítulo 7 299
En el escenario de almacenamiento que describí, el cifrado del lado del cliente es relativamente sencillo. El cifrado del
lado del cliente también se puede usar con bases de datos que lo admitan, pero esto es mucho más complejo que un
escenario de almacenamiento simple. El cifrado de datos a nivel de campo para evitar el acceso no autorizado a datos
confidenciales y al mismo tiempo preservar la indexación de la base de datos y la funcionalidad de búsqueda requiere
planificación y experiencia.
Además, el cifrado del lado del cliente no se puede usar con todos los servicios en la nube. Por ejemplo, aprovechar
los servicios completamente administrados en la nube generalmente significa que el CSP necesita procesar datos
de texto simple y, posteriormente, no puede procesar datos cifrados sin acceso a las claves. Hasta que se adopten
ampliamente el cifrado homomórfico u otras soluciones que permitan el procesamiento de datos cifrados, el cifrado
del lado del cliente no será una opción útil para todos los escenarios.
Algunas de las organizaciones a las que asesoré, que tenían requisitos de protección de datos muy estrictos,
comenzaron su viaje a la nube aprovechando el cifrado del lado del cliente. Inicialmente, lo vieron como la mejor
opción para mitigar el riesgo de acceso no autorizado a los datos en la nube, pero durante un período de años, a
medida que se sintieron más cómodos con la forma en que se diseñaron y operaron los servicios en la nube, con
las capacidades de administración de identidad y acceso en la nube, y con las capacidades de monitoreo y
auditoría, comenzaron a usar los HSM proporcionados por su CSP y, en algunos casos, las soluciones de
almacenamiento de claves completamente administradas del CSP . Muchos de estos clientes concluyeron que el
uso de HSM administrados parcialmente o completamente en la nube mitigó los mismos riesgos que el cifrado del
lado del cliente, pero sin la complejidad y los costos adicionales.
Esto concluye esta breve introducción al cifrado del lado del cliente. Si está interesado en una inmersión más
profunda en el cifrado del lado del cliente y el cifrado del lado del servidor, mire este video que grabé sobre el
tema, Seminario web de seguridad de AWS : la clave para el cifrado efectivo en la nube, disponible en https://
www.youtube.com/watch?v=78qFKr7WBI.
Una nota final sobre el cifrado y la gestión de claves. ¿ Sabía que puede ayudar a cumplir con los requisitos de
residencia de datos? El cifrado y la gestión eficaz de claves pueden ayudar a reducir la superficie de ataque de
una organización. En cambio, reduzca el desafío de proteger todos los datos de la organización donde sea que
estén, durante décadas, a solo proteger las claves utilizadas para cifrarlos y descifrarlos. Por lo general, es mucho
más fácil proteger las claves porque la superficie de ataque y el tamaño de las claves son mucho más pequeños que
protegiendo todos los datos de texto claro en sí. Esta superficie de ataque reducida también puede ayudar a su
organización a cumplir con los requisitos de residencia de datos. El proceso de emplear un cifrado fuerte
correctamente implementado transforma los datos en algo que se parece al ruido aleatorio. Esto significa que los
datos cifrados ya no son los datos de texto sin cifrar originales y nunca volverán a serlo sin las claves de descifrado.
Dado esto, ¿no debería permitirse que la versión cifrada de los datos, que se asemeja a un ruido aleatorio, se
transmita y almacene en cualquier lugar? Si las claves de cifrado/descifrado nunca salen de su país o región de
origen, tampoco lo hacen los datos originales en texto claro, independientemente de adónde viajen los datos
cifrados, ¿verdad? Tantos profesionales de la seguridad con los que hablé sobre la residencia de datos lucharon
con este concepto. Muchos de ellos se aferraron a la idea de que la ubicación física de sus datos los hacía más
seguros. Esa es una de las cosas geniales de las matemáticas: funcionan igual en todas partes del mundo.
Dejando a un lado los argumentos sobre las nacientes capacidades de la computación cuántica, si el cifrado fuerte
implementado correctamente protege la confidencialidad y la integridad de los datos en Alemania, también los
protege cuando cruzan las fronteras de los Estados Unidos. Tenga esto en cuenta cuando considere los requisitos
de residencia de datos de su organización para no pagar un costo de oportunidad excesivo por una mitigación,
como la residencia de datos, que tiene poco o ningún valor de seguridad.
En este punto, el CIO de la empresa alemana a la que hemos estado asesorando ahora comprende mejor la
probabilidad y el impacto del acceso legal a los datos por parte del gobierno de EE. UU. y algunas de las formas
en que se puede mitigar. La empresa ahora tiene mejor información para tomar mejores decisiones.
Conclusión
Para muchos de los ejecutivos con los que hablo sobre el acceso del gobierno a los datos, una vez que entienden
algunos de los matices y los riesgos asociados, se sienten mucho más cómodos utilizando proveedores de
servicios y empresas de tecnología con sede en EE. UU. También están mejor preparados para preguntar a los
proveedores fuera de los EE. UU. en sus cadenas de suministro actuales si están sujetos a la jurisdicción de los
EE. UU., de la misma manera que lo están los proveedores de los EE. UU. Este ejercicio les ayuda a comprender
los riesgos actuales del acceso del gobierno a los datos que probablemente han estado aceptando durante años
o décadas. Algunos de los ejecutivos a los que he asesorado todavía quieren mitigar este riesgo para asegurarse
de que sus propios equipos y procesos legales se utilicen para gestionar las solicitudes de las fuerzas del orden.
El cifrado y la gestión de claves pueden ser muy eficaces para mitigar el acceso no autorizado a los datos, ya sean
atacantes o gobiernos que intenten acceder a ellos. Por supuesto, también hay muchas otras posibles mitigaciones.
Estos son temas que trataré en otros capítulos.
El tema del acceso del gobierno a los datos ha ido evolucionando, especialmente en Europa occidental. La
narrativa allí ha evolucionado desde las demandas de residencia de datos hasta la necesidad de soberanía de
datos y el imperativo de soberanía digital. Las demandas de residencia de datos de muchos gobiernos se han
satisfecho con proveedores con sede en EE. UU. que construyen centros de datos en numerosos países del mundo.
Capítulo 7 301
Algunos de los países que ahora tienen centros de datos operados por proveedores con sede en EE. UU. dentro de sus
fronteras, que cumplen con los estrictos requisitos de seguridad y cumplimiento de esos países, comenzaron a presentar
un argumento diferente; los datos son más valiosos que el petróleo y su país no puede ceder el control de este recurso
crítico a los EE. UU. Ven esto como una amenaza a la soberanía económica de su país y, por lo tanto, argumentan,
deben construir sus propios servicios nacionales en la nube para contrarrestar esta amenaza. La incertidumbre que ha
introducido la decisión legal de Schrems II, combinada con el potencial de grandes multas de GDPR, ha resultado en
mucha fricción para las organizaciones en el EEE que contemplan la adopción de nuevas tecnologías.
Para muchos ejecutivos, CISO y equipos de seguridad que son responsables de proteger los datos de las organizaciones
del sector público o del sector privado, esta narrativa en evolución puede ser una distracción, pero no pueden ignorarla
porque otros ejecutivos de su organización que lean estos titulares cuestionarán la estrategia de seguridad cibernética
de su organización usando esta lente . Esta es otra gran razón para tener una estrategia de ciberseguridad bien pensada.
Con él, los CISO podrán responder preguntas sobre cómo están gestionando el riesgo del acceso del gobierno a los
datos, utilizando mitigaciones que realmente funcionan en lugar de invertir en la residencia de datos y otros mecanismos
politizados que equivalen a un teatro de seguridad.
Esto concluye nuestro examen en profundidad del acceso del gobierno a los datos. Hemos pasado la mayor parte de la
primera mitad de este libro examinando las amenazas. Ahora, cambiaremos nuestro enfoque a las estrategias de
ciberseguridad. En el próximo capítulo de este libro, exploraremos los ingredientes para una estrategia de ciberseguridad exitosa.
Resumen
Espero que este capítulo ayude a poner el acceso del gobierno a los datos en una perspectiva útil. Casi todas las
organizaciones fuera de los EE. UU. que he asesorado a lo largo de los años querían discutir este tema antes de estar
dispuestas a discutir cualquier otra cosa con un proveedor de tecnología con sede en los EE. UU., pero una vez que
discutimos algunos de los matices que compartí en este capítulo, se sintieron mucho más cómodos con la capacidad de
su organización para administrar los riesgos asociados . Recuerde, ser específico acerca de las amenazas es la clave
para administrar el riesgo.
• Hay tres escenarios diferentes relacionados con el acceso del gobierno a los datos que a menudo se
combinado:
• El escenario de inteligencia de señales: las agencias gubernamentales recopilan inteligencia interceptando
y analizando las comunicaciones y las señales electrónicas, empleando potencialmente el criptoanálisis.

• El escenario de acceso ilegal del gobierno a los datos: una agencia gubernamental roba datos de una
organización o un proveedor en su cadena de suministro, en lugar de obtener una orden judicial
válida para obligarlo; el espionaje militar y el espionaje económico son motivaciones típicas.
• El escenario de acceso legal del gobierno a los datos: una agencia de inteligencia o de aplicación de la
ley obtiene una orden judicial válida que obliga a una organización o proveedor en su cadena de
suministro a proporcionar pruebas específicas que están en su poder para una investigación criminal.
• Los diversos informes de transparencia, informes de solicitudes de aplicación de la ley e informes de solicitudes
de seguridad nacional proporcionados por los proveedores nos brindan información sobre el riesgo que
representa el acceso legal del gobierno a los datos. Hay muy poca información actual y fidedigna disponible
en los otros dos escenarios.
• El cifrado y la gestión eficaz de claves son controles importantes para mitigar estas tres amenazas y otros tipos
de acceso no autorizado a los datos. El cifrado del lado del cliente permite a las organizaciones cifrar datos
confidenciales antes de colocarlos en la nube, manteniendo las claves y los datos de texto simple en las
instalaciones. Sin las claves, nadie puede acceder a los datos.

almacenado en la nube.
• La Ley CLOUD no es una versión actualizada de la Ley PATRIOTA. La Ley PATRIOTA ha expirado.
• Muchos países del mundo tienen MLAT con los Estados Unidos con el fin de cooperar en asuntos penales,
incluida la búsqueda e incautación de pruebas almacenadas en su país. Francia, Alemania, Suecia, la UE y
muchos otros países han firmado estos tratados con los EE. UU. durante las últimas dos décadas. Estos
acuerdos recíprocos han sido el mecanismo principal para las solicitudes de aplicación de la ley de datos
almacenados en el extranjero. Se informó que el tiempo promedio para completar una solicitud de MLAT es
de 10 meses.
• El propósito de la Ley CLOUD es acelerar la producción de evidencia en el extranjero en investigaciones
criminales. No amplía el alcance de las solicitudes de aplicación de la ley ni permite la recopilación masiva
de datos. Proporciona garantías adicionales sobre los MLAT para los países que firman Acuerdos Ejecutivos
de la Ley CLOUD con los EE. UU., como lo ha hecho el Reino Unido.
• El riesgo es la combinación de la probabilidad y el impacto de una amenaza específica. Muchos asesores
generales y equipos jurídicos de empresas y organizaciones del sector público ya procesan cierto volumen
de solicitudes de aplicación de la ley y deben ser consultados en cuanto a su impacto.

• En julio de 2020, el TJUE invalidó la decisión de adecuación del RGPD que sustentaba el Escudo de
Privacidad UEEE.UU. El TJUE expresó su preocupación por la FISA, específicamente la Sección 702, en su
decisión.
Capítulo 7 303
• Utilizando los datos disponibles de los informes de transparencia publicados por los principales proveedores con sede
en EE. UU., la probabilidad de que el gobierno de EE. UU. solicite datos en la nube suele ser una fracción del 1 %.
Apilar la clasificación de este riesgo con los otros riesgos que administran las organizaciones puede ayudar a
determinar si se deben invertir recursos para mitigar esta amenaza.
Referencias
• Amazonas. (2018). Informe de solicitud de información de Amazon. Amazonas. Obtenido de https://
d1.awsstatic.com/certifications/Information_Request_Report_June_2018.pdf
• Amazonas. (2021). Informe de solicitud de información de Amazon. Amazonas. Obtenido de https://

d1.awsstatic.com/Information_Request_Report_December_2021_bia.pdf
• Amazonas. (Dakota del Norte). Solicitudes de información de aplicación de la ley. Obtenido de Amazon: https://
www.amazon.com/gp/help/customer/display.html?nodeId=GYSDRGWQ2C2CRYEF
• Manzana. (Dakota del Norte). Solicitudes de cuenta de privacidad. Obtenido de Apple: https://www.apple.com/
legal/transparencia/cuenta.html
• Bola, J. (2013, 10 25). La NSA monitoreó las llamadas de 35 líderes mundiales después de que un funcionario
estadounidense entregó los contactos. Obtenido de The Guardian: https://www.theguardian.com/world/2013/
oct/24/nsasurveillanceworldleaderscalls
• Business Insider. (2021, 30 de julio). Amazon ha recibido una multa récord de 887 millones de dólares por violar las
normas de privacidad de datos en Europa. Obtenido de Insider: https://www.businessinsider.com/
amazoneufinedataprivacygdprluxembourgeuropeanunion20217
• CHRISTOPHER BING, JS (2019, 30 01). Dentro del Equipo de Hackeo Secreto de Mercenarios Estadounidenses de
los Emiratos Árabes Unidos . Obtenido de Reuters: https://www.reuters.com/investigates/special report/usa
spyingraven/
• Cohen, J. (9 de septiembre de 2022). Las multas récord de GDPR son gotas en el balde para Big Tech. Obtenido de
PCMag: https://uk.pcmag.com/socialmedia/142547/record settinggdprfinesaredropsinthebucketforbigtech?
amp=1
• Servicio de Investigación del Congreso. (2021). Requisitos de transferencia de datos de la UE y leyes de inteligencia
de EE. UU.: comprensión de Schrems II y su impacto en el escudo de privacidad UEEE. UU. Del congreso
Servicio de Investigación.
• Servicio de Investigación del Congreso. (2021). Ley de vigilancia de inteligencia extranjera (FISA): una descripción
general. Servicio de Investigación del Congreso.
• Facultad de Derecho de Cornell. (Dakota del Norte). Cuarta Enmienda. Obtenido de Instituto de Información Legal:
https://www.law.cornell.edu/wex/fourth_amendment
• Facultad de Derecho de Cornell. (Dakota del Norte). Causa probable. Obtenido de Instituto de Información Legal:
https://www.law.cornell.edu/wex/probable_cause
• Departamento del Interior, Gobierno de Australia. (2021, 12 15). Acuerdo de la Ley CLOUD entre
Australia y EE. UU . Obtenido del Departamento de Asuntos Internos del Gobierno de Australia: https://
www.homeaffairs.gov.au/aboutus/ourportfolios/nationalsecurity/lawful
accesotelecomunicaciones/australiaestadosunidoscloudactacuerdo
• Comisión Europea. (2019, 02 05). Pruebas electrónicas: acceso transfronterizo a pruebas electrónicas.
Obtenido de Comisión Europea: https://ec.europa.eu/info/policies/justice and
fundamentalrights/criminaljustice/eevidencecrossborderaccess
electronicevidence_es
• EWING, P. (2014, 05 22). Gates: Ciberespías franceses apuntan a EE. UU. Obtenido de Politico: https://
www.politico.com/story/2014/05/franceintelectualpropertytheft107020
• Gidda, M. (2013, 21 de agosto). Edward Snowden y los archivos de la NSA: línea de tiempo. Obtenido
de The Guardian: https://www.theguardian.com/world/2013/jun/23/edwardsnowdennsa
archivoslínea de tiempo
• Google. (Dakota del Norte). Informe de transparencia de Google. Obtenido de Google: https://
transparenciareport.google.com/userdata/overview
• James Regan, MJ (2015, 23 de junio). La NSA espió a los presidentes franceses: WikiLeaks. Obtenido de
Reuters: https://www.reuters.com/article/usfrancewikileaks/nsaspiedon
presidentesfranceseswikileaksidUSKBN0P32EM20150623
• Julie Gordon, SS (2018, 12 07). Estados Unidos acusa al director financiero de Huawei de encubrir
sanciones contra Irán; audiencia aplazada. Obtenido de Reuters: https://www.reuters.com/article/
ususachina huawei/usaccuseshuaweicfoofiransanctionscoveruphearingadjourned
idUSKBN1O60FY
• Mark Mazzetti, AG (2019, 03 21). Una nueva era de guerra: cómo los mercenarios de
Internet luchan por gobiernos autoritarios. Obtenido de New York Times: https://www.nytimes.
com/2019/03/21/us/politics/governmenthackersnsodarkmatter.html
• Mehul Srivastava, RS (2019, 05 14). NSO de Israel: el negocio de espiar tu iPhone.

Obtenido de Financial Times: https://www.ft.com/content/7f2f39b2733e11e9
bf5c6eeb837566c5
• Meta. (Dakota del Norte). Meta Centro de Transparencia. Obtenido de Meta: https://transparencia.
fb.com/data/governmentdatarequests/?source=https%3A%2F%2Ftransparencia.
facebook.com%2Fpeticionesdedatosgubernamentales
Capítulo 7 305
• Microsoft. (2021). Informe de órdenes de seguridad nacional de EE. UU. Microsoft.
• Microsoft. (Dakota del Norte). Informe de solicitudes de aplicación de la ley. Obtenido de Microsoft: https://www.
microsoft.com/enus/corporateresponsibility/lawenforcementrequestsreport
• Archivos Nacionales. (Dakota del Norte). La Declaración de Derechos: ¿Qué dice? Obtenido
de Archivos Nacionales: https://www.archives.gov/foundingdocs/billofrights/whatdoes
decirlo
• Servicio Central de Seguridad de la Agencia Nacional de Seguridad. (Dakota del Norte). Inteligencia de señales.
Obtenido del Servicio de Seguridad Central de la Agencia de Seguridad Nacional: https://www.nsa.gov/Signals
Inteligencia/
• Servicio Central de Seguridad de la Agencia Nacional de Seguridad. (Dakota del Norte). Publicación del acuerdo
UKUSA. Obtenido del Servicio de Seguridad Central de la Agencia de Seguridad Nacional: https://www.nsa.gov/
reportajes/documentosdesclasificados/ukusa/
• Agencia de Seguridad Nacional/Servicio Central de Seguridad. (Dakota del Norte). Ley de Vigilancia de Inteligencia
Extranjera de 1978 (FISA). Obtenido de la Agencia de Seguridad Nacional/Servicio de Seguridad Central:

https://www.nsa.gov/SignalsIntelligence/FISA/
• Pablo, K. (2019, 12 10). Senadores estadounidenses amenazan a Facebook y Apple con regulación de encriptación.
Obtenido de Reuters: https://uk.reuters.com/article/ususaencryption facebook/ussenatorsthreatenfacebook

applewithencryptionregulation
idUKKBN1YE2CK
• Peter Swire, JD (2016, 11 15). Un Estudio de Caso de Asistencia Legal Mutua: Estados Unidos y Francia.
Obtenido de Peterswire.net: http://peterswire.net/wpcontent/uploads/
estudiodecasodeasistencialegalmutuaEE.UU.Francia.pdf
• Reuters. (2021, 09 24). El director financiero de Huawei y EE. UU. llegan a un acuerdo sobre los cargos. Obtenido de usted
Tubo: https://www.youtube.com/watch?v=LbxekyZWx1o
• Richard A. Clarke, MJ (2013, 12 12). LIBERTAD Y SEGURIDAD EN UN MUNDO EN CAMBIO.
Obtenido de Obamawhitehouse.archives.gov: https://obamawhitehouse.archives.
gov/sites/default/files/docs/20131212_rg_final_report.pdf
• Rubín, GT (2019, 11 22). Punt on Patriot Act establece un nuevo impulso de los oponentes.
Obtenido de Wall Street Journal: https://www.wsj.com/articles/puntonpatriotactsetsup
nuevoempujeporoponentes11574418600
• Shostack, A. (2014). Modelado de amenazas: diseño para la seguridad. Wiley.
• Smith, B. (2017, 10 23). DOJ actúa para frenar el uso excesivo de las órdenes de confidencialidad. Ahora es el turno del
Congreso. Obtenido de Microsoft Sobre los problemas: https://blogs.microsoft.com/onthe
issues/2017/10/23/dojactscurboverusesecrecyordersnowcongressturn/
• Spataro, J. (2019, 11 19). 5 atributos de los equipos exitosos. Obtenido de Microsoft 365:
https://www.microsoft.com/enus/microsoft365/blog/2019/11/19/5attributes
equiposexitosos/
• El Parlamento Europeo y El Consejo De La Unión Europea. (2016, 27 04). REGLAMENTO (UE) 2016/679
DEL PARLAMENTO EUROPEO Y DEL CONSEJO. Obtenido de EURLex: https://eurlex.europa.eu/
legalcontent/EN/TXT/PDF/?ur
i=CELEX:32016R0679&from=ES
• IMPRENTA DEL GOBIERNO DE LOS ESTADOS UNIDOS. (2000). TRATADO CON FRANCIA DE
ASISTENCIA JURÍDICA MUTUA EN MATERIA PENAL. Obtenido del Congreso de los Estados Unidos:
https://www.congress.gov/106/cdoc/tdoc17/CDOC106tdoc17.pdf
• IMPRENTA DEL GOBIERNO DE LOS ESTADOS UNIDOS. (2004). TRATADO DE ASISTENCIA

JURÍDICA MUTUA CON ALEMANIA. Obtenido de Congreso de los Estados Unidos: https://www.congress.
gov/108/cdoc/tdoc27/CDOC108tdoc27.pdf
• IMPRENTA DEL GOBIERNO DE LOS ESTADOS UNIDOS. (2006, 10 28). ACUERDO DE

ASISTENCIA JURÍDICA MUTUA CON LA UNIÓN EUROPEA. Obtenido del Congreso de los
Estados Unidos: https://www.congress.gov/109/cdoc/tdoc13/CDOC109tdoc13.pdf
• Congreso de los Estados Unidos. (2018, 03 21). DIVISIÓN V—LEY DE LA NUBE. Recuperado de Justicia.
gobierno: https://www.justice.gov/criminaloia/cloudactresources
• Departamento de Justicia de los Estados Unidos. (2019, 10 03). Acuerdo entre el Gobierno de los Estados
Unidos de América y el Gobierno del Reino Unido de Gran Bretaña e Irlanda del Norte sobre Acceso
a Datos Electrónicos con el Fin de Contrarrestar Delitos Graves.
Obtenido de Departamento de Justicia de los Estados Unidos: https://www.justice.gov/ag/
página/archivo/1207496/descargar#Acuerdo%20entre%20el%20Gobierno%20de%20
los%20Estados%20Unidos%20de%20América%20y%20el%20Gobierno%20de%20el%20
Reino%20Unido%20de%20Gran%20Gran Bretaña%20e%20Irlanda%20delNorte%20en%20
Acceso
• Departamento de Justicia de los Estados Unidos. (2019, 10 07). Declaración conjunta que anuncia la
negociación entre Estados Unidos y Australia de un acuerdo de la Ley CLOUD del Fiscal General de
los Estados Unidos, William Barr, y el Ministro del Interior, Peter Dutton. Obtenido del Departamento
de Justicia de los Estados Unidos: https://www.justice.gov/opa/pr/jointstatementanounceunited
estadosyaustralianegociaciónnubeactacuerdonosotros
Capítulo 7 307
• Departamento de Justicia de los Estados Unidos. (2019, 10 03). EE. UU. y el Reino Unido firman un histórico
acuerdo de acceso a datos transfronterizos para combatir a los delincuentes y terroristas en línea.
Obtenido del Departamento de Justicia de los Estados Unidos: https://www.justice.gov/opa/pr/usanduksign
históricoacuerdodeaccesoadatostransfronterizocombatecriminalesyterroristas
• Departamento de Justicia de los Estados Unidos. (Dakota del Norte). Asistencia Legal Mutua en Materia
Penal. Obtenido del Departamento de Justicia de EE. UU.: https://findit.state.gov/search?utf8=%E2%9C%93
&afiliado=dos_stategov&sort_by=&query=%22Asistencia+Legal+Mutual+en+Crim
asuntos+inales%22
• GOBIERNO DE EE.UU. (Dakota del Norte). Índice AZ de departamentos y agencias gubernamentales de EE. UU. Obtenido de
GOBIERNO DE EE. UU.: https://www.usa.gov/federalagencies
• WikiLeaks. (2015, 07 08). Todos los Hombres del Canciller. Obtenido de WikiLeaks: https://
wikileaks.org/nsaalemania/
• WikiLeaks. (2015, 07 04). Molestando a Brasil. Obtenido de WikiLeaks: https://wikileaks.

org/nsabrasil/
• WikiLeaks. (2015, 29 de junio). Espionaje Elíseo. Obtenido de WikiLeaks: https://wikileaks.

org/nsafrancia/
• WikiLeaks. (2015, 31 de julio). Objetivo Tokio. Obtenido de WikiLeaks: https://wikileaks.

org/nsajapan/
• Wikipedia. (Dakota del Norte). Programa de ilegales. Obtenido de Wikipedia: https://en.wikipedia.

org/wiki/Illegals_Program
• Wikipedia. (Dakota del Norte). Inteligencia de señales por alianzas, naciones e industrias.
Obtenido de Wikipedia: https://en.wikipedia.org/wiki/Signals_intelligence_by_alliances,_
naciones_e_industrias

8
Ingredientes para un éxito
Estrategia de Ciberseguridad
No hay duda de que las empresas de hoy, más que nunca, necesitan estrategias de ciberseguridad efectivas.
Sin embargo, una buena estrategia no es en sí misma garantía de éxito. Hay varios ingredientes que son
necesarios para que un programa de ciberseguridad tenga éxito. Este capítulo describirá en detalle cómo es
una estrategia de ciberseguridad y cada uno de los ingredientes necesarios para el éxito.
Comencemos con una pregunta fundamental que debemos responder antes de discutir las estrategias de
ciberseguridad en detalle: ¿qué queremos decir realmente cuando decimos “estrategia de ciberseguridad”?
¿Qué es una estrategia de ciberseguridad?

Las organizaciones que tienen una cultura de seguridad súper fuerte esencialmente tienen la ciberseguridad
integrada . Para todos los demás, hay estrategia. En mi experiencia, los términos "estrategia" y "táctica" son
poco conocidos en el mundo de los negocios. La estrategia de una persona es la táctica de otra persona.
Una vez trabajé con un vicepresidente corporativo que me decía que estaba hablando de tácticas cuando
explicaba nuestra estrategia. A lo largo de mi carrera, he estado en reuniones en las que las personas han
hablado entre sí porque una persona está discutiendo estrategias y la otra está discutiendo tácticas.
Además, los profesionales de seguridad y cumplimiento a veces usan el término "estrategia" cuando se
refieren a marcos, modelos o estándares. Hay muchos de estos en la industria y muchas organizaciones los
utilizan, por ejemplo, estándares ISO, estándares NIST, OWASP Top 10, CIS Benchmarks, STRIDE, marcos
de gestión de riesgos, SOC 2, PCI, HIPAA, Cloud Security
Alliance Cloud Controls Matrix, la perspectiva de seguridad del marco de adopción de la nube de AWS, el
pilar de seguridad del marco de buena arquitectura de AWS y muchos más.
310 Ingredientes para una estrategia de ciberseguridad exitosa
Todos estos pueden ser herramientas útiles para las organizaciones que buscan mejorar sus posturas de
seguridad, cumplir con las regulaciones y demostrar que cumplen con los estándares de la industria.
No estoy proponiendo una nueva definición de diccionario del término "estrategia", pero sí quiero explicar a qué me refiero
cuando analizo las estrategias de seguridad cibernética en este libro. En mi opinión, hay al menos dos insumos críticos
para una estrategia de ciberseguridad:
• Los activos de alto valor de cada organización.
• Los requisitos, amenazas y riesgos específicos que se aplican a cada organización, informados por la industria en la
que se encuentran, el(los) lugar(es) del mundo donde hacen negocios y las personas asociadas con cada
organización.
Los activos de alto valor (HVA) también se conocen como "joyas de la corona". Hay muchas definiciones para
estos términos. Pero cuando los uso, me refiero a que la organización fallará o se verá gravemente afectada
si la confidencialidad, la integridad o la disponibilidad del activo se ven comprometidas. Los HVA rara vez son
las computadoras que usan los trabajadores de la información de la organización. Sin embargo, he visto a
tantas organizaciones centrarse en la seguridad de los sistemas de escritorio como si fueran HVA. Dada la
importancia de los HVA, sería fácil centrarse en ellos y excluir los activos de menor valor. Pero tenga en cuenta
que los atacantes suelen utilizar activos de menor valor como punto de entrada para atacar HVA. Por ejemplo,
los antiguos entornos de desarrollo y prueba que nunca se retiraron correctamente no suelen ser HVA. Pero a
menudo se descubre que son una fuente de compromiso.
Una de las primeras cosas que debe hacer un CISO cuando obtiene el trabajo es identificar los HVA de la organización.
Esto puede ser más desafiante de lo que parece, ya que las joyas de la corona pueden no ser obvias para las personas
que no poseen experiencia específicamente relacionada con el negocio que están apoyando.
Entrevistar a miembros del Csuite y miembros de la junta directiva puede ayudar a identificar los activos que realmente
harían que el negocio fracasara o se viera gravemente afectado.
Trabajar hacia atrás desde los objetivos de la organización también puede ayudar a identificar sus HVA. A medida que los
equipos de seguridad realizan este análisis, deben estar preparados para algunos matices que inicialmente no eran obvios.
Por ejemplo, ¿podría la empresa cumplir sus objetivos sin los sistemas de energía, agua, calefacción, aire acondicionado
y seguridad de vida? Según la empresa y el tipo de edificio que utilice, si no hay ascensores disponibles, ¿tiene algún
sentido dejar que los empleados y los clientes entren por la puerta principal? Los clientes pueden estar dispuestos a subir
algunos tramos de escaleras, pero ¿estarían dispuestos a subir 40 tramos de escaleras si fuera necesario? Probablemente
no.
Capítulo 8 311
Si esta interrupción se mantuvo durante días, semanas o meses, ¿cuánto tiempo podría sobrevivir el negocio?
¿Dónde están los sistemas de control para estas funciones? ¿Y cuándo fue la última vez que se evaluó la postura
de seguridad de estos sistemas? Identificar los HVA de una organización no significa que los CISO puedan ignorar
todo lo demás. Comprender qué activos son realmente HVA y cuáles no ayuda a los CISO a priorizar sus recursos
limitados y centrarse en evitar eventos de extinción para la organización.
Una vez que el CISO ha identificado las joyas de la corona de su organización, el siguiente paso es asegurarse de
que la comunidad interna de partes interesadas (TI, legal, adquisiciones y otros), el Csuite y la junta directiva
entiendan y estén de acuerdo con esa lista. Esta claridad será muy útil cuando llegue el momento de solicitar más
recursos o recursos diferentes de los que la organización ha aprovechado en el pasado. Cuando la organización
necesita tomar decisiones difíciles sobre la reducción de recursos, la claridad en torno a los HVA ayudará con las
decisiones basadas en el riesgo. El tiempo y el esfuerzo dedicados a poner a la comunidad de interesados senior
en sintonía harán que la vida del CISO sea más fácil en el futuro.
Conseguir la aceptación de la lista de joyas de la corona puede ser fácil en algunas organizaciones, pero los CISO
deben estar preparados para defender su lista. Algunas partes interesadas querrán que sus activos estén en la
lista incluso cuando no se consideren joyas de la corona, mientras que otros querrán que sus activos se eliminen
de la lista para evitar un posible escrutinio y trabajo adicionales. Se recomienda encarecidamente utilizar una
metodología estructurada, o al menos definir principios o un sistema de puntuación que se utilice para determinar
qué es y qué no es una joya de la corona.
La segunda entrada crítica para una estrategia de seguridad cibernética son los requisitos, amenazas y riesgos específicos.
que se aplican a la organización, informados por la industria en la que se encuentran, los lugares del mundo donde
hacen negocios y las personas asociadas con ellos. Esta entrada ayuda a ampliar el alcance de los requisitos del
programa de seguridad cibernética. Por ejemplo, la industria y/o la ubicación en la que hacen negocios pueden
tener requisitos de cumplimiento normativo que deben cumplir, o pueden enfrentar fuertes multas o revocar su
licencia comercial. Tenga en cuenta que la mayoría de las organizaciones no pueden identificar todas las posibles
amenazas y riesgos para ellas. Eso requeriría omnisciencia y es una limitación natural de un enfoque basado en
el riesgo.
Después de publicar miles de páginas de inteligencia sobre amenazas cuando trabajé en Microsoft (Microsoft
Corporation, 20072016), puedo decirles que existen amenazas globales que tienen el potencial de afectar a todos,
pero también existen amenazas específicas de la industria y amenazas regionales. El uso de inteligencia de
amenazas creíble para informar la estrategia ayudará a los CISO a priorizar las capacidades y los controles, lo que
es especialmente útil si sus recursos son limitados. Intentar proteger todo como si tuviera el mismo valor para la
organización es una receta para el fracaso. Los CISO deben hacer concesiones, y es mejor si lo hacen conociendo
las amenazas específicas que se aplican a la industria y la región del mundo donde hacen negocios.
Esto no significa que los CISO puedan ignorar todas las demás amenazas, pero identificar las amenazas de mayor
riesgo para las joyas de la corona de su organización les ayudará a concentrar los recursos en los lugares más importantes.
La mayor parte de la primera mitad de este libro está dedicada a ayudarlo a comprender el panorama de amenazas
y cómo ha evolucionado en las últimas dos décadas. Proporcioné inmersiones profundas en las tendencias de
divulgación de vulnerabilidades, la evolución del malware, incluido el ransomware, e información sobre las amenazas
basadas en Internet, como el phishing, los ataques de descarga oculta y los ataques DDoS. También brindé información
sobre los gobiernos como amenazas con un examen del acceso del gobierno a los datos. Los CISO y los equipos de
seguridad necesitan fuentes creíbles de inteligencia sobre amenazas para mantenerse al tanto de las últimas tácticas,
técnicas y procedimientos que utilizan los atacantes.
Sin las dos entradas que he descrito aquí, los CISO se quedan implementando las mejores prácticas y los estándares
de la industria que se basan en el modelo de amenazas de otra persona. Estos pueden ser útiles para mover a las
organizaciones en la dirección correcta, pero por lo general no se basan en los HVA de las organizaciones individuales
y las amenazas específicas de las que deben preocuparse. El uso de mejores prácticas y estándares de la industria que
no estén informados por estas dos entradas hará que sea más probable que haya brechas críticas.
En este punto, es posible que se pregunte cómo es una estrategia de ciberseguridad. La Figura 8.1 presenta una
estrategia de ciberseguridad:
Figura 8.1: Un ejemplo ilustrativo de una estrategia de ciberseguridad

Capítulo 8 313
Los HVA son centrales y están respaldados por las otras partes de la estrategia. Los fundamentos de la
ciberseguridad incluyen las capacidades fundamentales que respaldan un programa de seguridad exitoso,
como la gestión de vulnerabilidades y la gestión de identidades, entre otras. Tal vez recuerde que discutí la
importancia de los fundamentos de la ciberseguridad en el Capítulo 1. ¿Recuerda a los sospechosos
habituales de la ciberseguridad? Permítanme proporcionar un breve repaso aquí porque usaremos estos
conceptos para evaluar las estrategias de seguridad cibernética que examinamos en el próximo capítulo.
Los fundamentos de la seguridad cibernética son las partes de una estrategia que se enfoca en mitigar los sospechosos habituales
de la seguridad cibernética, o las cinco formas en que las empresas se ven comprometidas inicialmente. Los sospechosos
habituales de ciberseguridad son:
• Vulnerabilidades sin parches •
Configuraciones incorrectas de seguridad
• Credenciales débiles, filtradas y robadas

Las estrategias de ciberseguridad deben estar informadas por los sospechosos habituales de ciberseguridad y ser
eficaces para mitigarlos; esto es lo que hacen los fundamentos de ciberseguridad. Considero que estos conceptos
son ingredientes críticos de estrategias efectivas de ciberseguridad. Las estrategias que no se centran en los
fundamentos y, por lo tanto, no abordan los sospechosos habituales de la ciberseguridad deben complementarse
con otras estrategias que sí lo hagan, o el enfoque tendrá lagunas que los atacantes pueden aprovechar.
Las capacidades avanzadas de ciberseguridad son inversiones que las organizaciones deben hacer a medida que
se vuelven muy competentes en los fundamentos. Si su organización no es realmente buena en los fundamentos,
entonces ese es el lugar en el que deben invertir primero antes de invertir en capacidades avanzadas de
ciberseguridad. Invertir en los fundamentos de la ciberseguridad proporcionará el mejor retorno de la inversión para
la mayoría de las organizaciones.
Para las organizaciones que son realmente buenas en los fundamentos de la ciberseguridad, las capacidades
avanzadas son la segunda línea de defensa. Es probable que, independientemente de lo buenos que sean en la
gestión de vulnerabilidades, la gestión de identidades y la capacitación en seguridad cibernética para su personal,
no podrán mantenerse al día con el volumen de amenazas o evitar la fuga de credenciales, o simplemente
cometerán un error en algún momento del camino. Aquí es donde las capacidades avanzadas pueden ayudar.
Diseñados correctamente, pueden ayudar a prevenir el compromiso inicial o detectarlo con la suficiente rapidez para
que los procesos de respuesta automáticos y manuales interrumpan o detengan el ataque. Las capacidades
avanzadas pueden ayudar a reducir los tiempos de permanencia de los atacantes en los entornos de sus víctimas,
reduciendo así el daño potencial y el costo de recuperación.
Otros ingredientes para una estrategia exitosa

Hay un montón de trabajo relacionado con la gestión que debe realizarse para garantizar que el CISO, el equipo de
seguridad y el resto de la organización puedan ejecutar de manera efectiva una estrategia de ciberseguridad. Esta sección
describe algunos de los ingredientes que le dan a una estrategia la mejor oportunidad de éxito.
Por ejemplo, los CISO que les dicen a las empresas que respaldan: “no, no pueden hacer eso”, ya no tienen una gran
demanda. Los equipos de seguridad deben alinearse con los objetivos comerciales de sus organizaciones, o no tendrán
éxito. Echemos un vistazo más de cerca a este ingrediente.
Alineación de objetivos comerciales

Conocí a muchos CISO que tenían dificultades en sus funciones. Algunos de ellos simplemente no recibieron el apoyo
adecuado de sus organizaciones. Es fácil encontrar grupos de ejecutivos que piensan que las amenazas a la seguridad
cibernética son exageradas y que todo lo que hace su CISO es un impuesto sobre lo que están tratando de lograr . Para
estas personas, la seguridad cibernética es solo otra iniciativa que debería respaldarlos para obtener recursos. Después
de todo, la empresa no llegará a ese próximo gran hito de ingresos a través de un centro de costos, ¿verdad?
No es raro trabajar con ejecutivos que no entienden las amenazas de seguridad cibernética que enfrenta su organización
y que realmente no tienen tiempo para prestar atención. La mayoría de los CISO deben trabajar con otros ejecutivos para
hacer las cosas, incluso si esos ejecutivos no se dan cuenta de que tienen un destino compartido con el CISO; cuando el
CISO falla, todos fallan. Pero los mejores CISO que he conocido tienden a prosperar en esos entornos.
Ya sea que un CISO trabaje en un entorno como el que describí, o que tenga la suerte de trabajar con personas que se
preocupan por tener éxito, para tener éxito, los CISO deben alinearse con el negocio que respaldan. Los CISO que no
entienden ni aceptan los objetivos de las organizaciones a las que apoyan generan fricciones. Hay mucha fricción que los
líderes senior están dispuestos a tolerar antes de exigir un cambio. Comprender profundamente el negocio y cómo
funciona les brinda a los CISO ilustrados el conocimiento y la credibilidad necesarios para respaldar verdaderamente a
sus organizaciones.
Dicho de otra manera, los CISO “puristas” que intentan proteger los datos de forma aislada de las personas, los procesos
comerciales y las tecnologías en los que se basa su organización para tener éxito solo están haciendo una parte del
trabajo para el que fueron contratados.
Una estrategia de ciberseguridad solo tendrá éxito si realmente respalda el negocio. Desarrollar una estrategia que ayude
a mitigar los riesgos que más preocupan al equipo de seguridad podría darle al equipo la satisfacción de tener un plan
cerrado que dificultará las cosas para los atacantes.

para tener éxito.
Capítulo 8 315
Pero si esa estrategia también dificulta que el negocio sea competitivo y ágil, entonces el equipo de seguridad debe
hacerlo mejor.
La mejor manera de demostrarles a sus compañeros de Csuite que está allí para ayudarlos es conocer las partes
del negocio que administran, cuáles son sus prioridades y ganarse su confianza. Nada de esto sucederá en su
Centro de operaciones de seguridad (SOC), por lo que tendrá que pasar tiempo en su mundo, ya sea en la planta
de una fábrica, en un almacén, en un camión o en una oficina.
Camine una milla en sus zapatos y les resultará más fácil seguir su consejo y abogar por usted cuando sea
importante.
Por último, recuerde que el trabajo del CISO es descubrir, comunicar, administrar y mitigar el riesgo para el negocio,
no decidir cuál es el apetito por el riesgo de la organización. La junta directiva y la alta dirección han estado
gestionando el riesgo de la organización desde su fundación. Han estado gestionando todo tipo de riesgos, incluidos
riesgos financieros, riesgos económicos, riesgos de recursos humanos, riesgos legales y muchos otros. Los riesgos
de ciberseguridad pueden ser el tipo de riesgo más nuevo que se han visto obligados a gestionar, pero si el CISO
puede aprender a comunicar los riesgos de ciberseguridad de la misma manera que lo hacen las otras partes de la
empresa, la empresa hará lo correcto para sus clientes y accionistas o pagará el precio, pero esa es la decisión de
la empresa, no la del CISO.
Dicho esto, la rendición de cuentas, la responsabilidad y el empoderamiento van de la mano. Muchos CISO
enfrentan la dura realidad de que son responsables de mitigar los riesgos aceptados por el negocio, pero no están
facultados para realizar los cambios necesarios o implementar contramedidas. En pocas palabras, el trabajo de un
CISO es difícil. Esto podría ayudar a explicar por qué los mandatos de los CISO suelen ser tan cortos en comparación con
los de otros ejecutivos.
Tener una visión clara y compartida de dónde encaja la ciberseguridad en la estrategia comercial más amplia de
una organización no solo es importante dentro de los niveles superiores de una organización; la organización en su
conjunto debe tener una postura clara sobre su visión, misión e imperativos para su programa de seguridad
cibernética. Echaremos un vistazo a esto a continuación.
Visión, misión e imperativos de la ciberseguridad

Tomarse el tiempo para desarrollar y documentar una visión, declaración de misión e imperativos para el programa
de seguridad cibernética puede ser útil para los CISO. Una visión compartida que comunique cuál es el estado
óptimo futuro para la organización desde una perspectiva de seguridad cibernética puede ser una herramienta
poderosa para desarrollar una cultura corporativa de apoyo. Puede inspirar confianza en el equipo de ciberseguridad
y el futuro de la organización. También puede generar entusiasmo y buena voluntad hacia el equipo de seguridad
que será útil en el curso de su trabajo.
De manera similar, una declaración de misión bien escrita puede convertirse en un mantra cultural positivo para las
organizaciones . Una buena declaración de misión puede comunicar lo que el equipo de seguridad está tratando de
lograr y, al mismo tiempo, demostrar cómo el equipo de seguridad está alineado con el negocio, sus clientes y
accionistas. La declaración de la misión ayudará a comunicar los objetivos del equipo de seguridad a medida que se
reúne y trabaja con otras partes de la organización.
Finalmente, los imperativos comerciales son los principales objetivos que el equipo de ciberseguridad emprenderá
durante un período de 2 o 3 años. Estos objetivos deben ser lo suficientemente ambiciosos como para que no se
puedan lograr en un solo año fiscal. Los imperativos respaldan la estrategia y están alineados con los objetivos
comerciales más amplios. Cuando la estrategia no está alineada con objetivos comerciales más amplios, esto puede
aparecer como un imperativo que está fuera de lugar: una clavija cuadrada en un agujero redondo. ¿Por qué la
empresa apoyaría una gran meta de varios años que no está alineada con sus objetivos? Este debería ser un
mensaje para el CISO para realinear la estrategia y repensar los imperativos. Estos objetivos plurianuales se
convierten en la base de los proyectos en los que se embarca el grupo de ciberseguridad. Un imperativo puede
lograrse mediante un solo proyecto o puede requerir múltiples proyectos. Recuerde que un proyecto tiene una fecha
de inicio, una fecha de finalización y un presupuesto definidos.
No confunda esto con un programa que no necesariamente tiene una fecha de finalización y podría financiarse
perpetuamente. Los programas pueden y deben contribuir a los imperativos del grupo.
Desarrollar una visión, una declaración de misión y los imperativos para el programa de seguridad cibernética no
siempre es fácil ni directo. La visión no puede llevarse a cabo sin el apoyo de las partes interesadas fuera del grupo
de seguridad cibernética, y convencerlos del valor del programa puede llevar mucho tiempo. Las recompensas
futuras de este trabajo, para el CISO y el grupo de seguridad cibernética en general, generalmente hacen que el
esfuerzo valga la pena. A continuación, analizaremos brevemente cómo asegurar este soporte, como uno de los
ingredientes importantes de una estrategia de seguridad cibernética exitosa.
Alto ejecutivo y apoyo a la junta

Asegurarse de que los altos ejecutivos y la junta directiva entiendan y respalden la estrategia de seguridad cibernética
de la organización es un paso importante para un programa de seguridad exitoso. Si los altos ejecutivos entienden la
estrategia y participaron en su desarrollo y aprobación, deberían mostrar más propiedad y apoyo para que avance.
Pero si no tienen una conexión con la estrategia, entonces las actividades que se ejecutan para apoyarla serán
potencialmente perturbadoras y desagradables. No entenderán por qué se están realizando cambios o por qué el
modelo de gobierno se comporta de la forma en que lo hace.

Capítulo 8 317
Dos de las preguntas importantes que los CISO deben hacer cuando se entrevistan para un nuevo
trabajo de CISO son a quién le reporta el rol y con qué frecuencia el CISO se reunirá con la junta
directiva o el Comité de Auditoría de la Junta. Si el CISO no se reúne con la junta trimestralmente o dos
veces al año, es una señal de alerta. Podría ser que el rol al que informa el CISO se reúna con la junta en su lugar.
Pero a menos que ese rol esté impregnado de la estrategia y las operaciones diarias, deberían compartir o
delegar el trabajo de reunirse con la junta al CISO. Esto le da al CISO experiencia de primera mano en la
discusión de prioridades con la junta. También permite a los miembros de la junta obtener sus actualizaciones
directamente del CISO y hacerles sus preguntas directamente. Dudaría mucho en aceptar un trabajo de
CISO en el que el rol no se reúna directamente con la junta al menos un par de veces al año.
Esta experiencia es importante y demuestra que el CISO es un miembro legítimo del Csuite de la
organización. Si el CISO no tiene la oportunidad de pedir ayuda a la junta con sus pares, incluido el director
ejecutivo, esa es una razón más por la que sus pares realmente no necesitan apoyarlo. Agregar una capa
de gestión entre el CISO y la junta puede ser una táctica que la alta gerencia usa para retrasar, influir o
disuadir al CISO de avanzar con su programa de seguridad. También puede brindar refugio a los CISO que
no tienen la perspicacia comercial o la madurez corporativa para interactuar directamente con la junta.
Pero si el equipo de gestión ejecutiva realmente apoya al CISO y la estrategia de seguridad cibernética,
deberían agradecer la oportunidad de que el CISO obtenga la ayuda que necesita lo más rápido posible sin
instituir más burocracia. Además, el equipo ejecutivo ya debería saber lo que el CISO le dirá a la junta si se
está tomando en serio sus responsabilidades.
Por supuesto, la historia nos ha enseñado que esto no siempre es así en lo que respecta a la ciberseguridad.
Si el CISO tiene éxito en obtener la aprobación direccional de la Junta Directiva sobre la estrategia de
seguridad cibernética, esto facilitará que la junta entienda por qué el equipo de seguridad está haciendo lo
que está haciendo. También facilitará que el CISO obtenga ayuda cuando sea necesario e informe los
resultados contra la estrategia. No pretendo que esto sea algo fácil de hacer. Las primeras veces que me
reuní con juntas directivas fue como conocer a los personajes de una novela de Agatha Christie o del juego
Clue. Todos los miembros de la junta que he conocido han sido muy exitosos profesionalmente. Algunos
son humildes acerca de sus logros, mientras que otros afirman sus logros para influir en los demás. Siempre
parece haber al menos un miembro de la junta que dice tener experiencia en seguridad cibernética, que
quiere hacer preguntas difíciles y dar consejos al CISO sobre seguridad cibernética. Pero si el CISO puede
comunicar de manera efectiva una visión basada en datos de los resultados contra la estrategia de seguridad
cibernética, la misma estrategia que aprobó la junta, estas conversaciones pueden ser muy útiles para todas
las partes interesadas. Además, los resultados de las auditorías internas y externas generalmente brindan
a las juntas cierta confianza en que el CISO está haciendo su trabajo de manera efectiva.
Después de hablar con ejecutivos de literalmente miles de organizaciones en todo el mundo acerca de la
ciberseguridad, puedo decirles que existen diferencias reales en la cantidad de riesgo que las organizaciones
están dispuestas a aceptar. Además de obtener el apoyo de los altos ejecutivos y la junta, es importante tener
una buena comprensión de su apetito por el riesgo, como veremos a continuación, ya que esto podría tener
un impacto significativo en la estrategia de seguridad cibernética.
Comprender el apetito por el riesgo

Algunas organizaciones se encuentran en industrias hipercompetitivas donde la innovación, la velocidad y la agilidad
son las principales prioridades; estas organizaciones tienden a estar dispuestas a aceptar más riesgos cuando se
enfrentan a decisiones de seguridad y cumplimiento que potencialmente las ralentizarán o impedirán su capacidad
para competir. Para estas empresas, si no asumen riesgos calculados, no estarán en el negocio el tiempo suficiente
para tomar decisiones en el futuro.
Otras organizaciones con las que he hablado son muy adversas al riesgo. Eso no significa que necesariamente se
muevan lentamente, pero exigen más certeza al tomar decisiones. Están dispuestos a tomarse el tiempo para
comprender realmente los factores y los matices en las decisiones basadas en el riesgo en un esfuerzo por tomar
la mejor decisión posible para su organización. Por supuesto, también hay organizaciones en el espectro entre
estos dos ejemplos.
Los CISO que entienden el apetito por el riesgo de la alta gerencia en sus organizaciones pueden ayudarlos a tomar
mejores y más rápidas decisiones. A lo largo de los años, he visto a muchos CISO decidir desempeñar el papel de
"el adulto en la sala" y tratar de dictar cuánto riesgo debe aceptar la organización. En la mayoría de los casos, este
no es el trabajo del CISO. Proporcionar contexto y datos para ayudar a la empresa a tomar decisiones informadas
basadas en el riesgo es una función que deben realizar los CISO. A veces, también tienen que educar a los
ejecutivos y miembros de la junta que no entienden los riesgos de ciberseguridad. Pero encuentro útil tener siempre
en cuenta que, en las organizaciones establecidas, las suites ejecutivas administraban muchos tipos de riesgos
para la organización mucho antes de que los riesgos de ciberseguridad se volvieran relevantes para ellos. Tenga en
cuenta que esto podría ser diferente para las empresas emergentes o en organizaciones donde el CISO también
tiene una gran experiencia en el negocio que respaldan; en estos escenarios, se puede esperar que el CISO tome
decisiones de riesgo para la organización de manera más directa. Pero en todos los casos, comprender cuánto
riesgo está dispuesta a aceptar la organización en el curso normal de los negocios es importante para los CISO.
El apetito de riesgo de la organización se reflejará en su modelo de gobierno y sus prácticas de gobierno. En

muchos casos, las organizaciones que aceptan más riesgos para moverse más rápido optimizarán sus prácticas de
gobierno para minimizar la fricción y los bloqueos. Las organizaciones que desean adoptar un enfoque meticuloso
para la toma de decisiones generalmente implementarán más controles de gobierno para garantizar que las
decisiones se transmitan completamente a través de los procesos apropiados.
Capítulo 8 319
Por esta razón, es importante que los CISO validen su comprensión del apetito por el riesgo de su
organización en lugar de hacer suposiciones al respecto. Aquí es donde su conocimiento del negocio
y las prioridades de sus pares ayudarán.
Además de conocer las prioridades comerciales, es importante tener una idea realista de las capacidades y
el talento técnico actuales de la organización. Discutiremos eso a continuación.
Visión realista de las capacidades de ciberseguridad y el talento

técnico actuales
Muchos de los CISO que conozco aspiran a tener un equipo de seguridad cibernética de clase mundial que
diseñe, implemente y opere controles sofisticados y efectivos. Sin embargo, ser honestos consigo mismos
sobre su situación actual es el mejor punto de partida.
Toda la industria ha estado sufriendo una grave escasez de talento en ciberseguridad durante más de una
década. Este problema está empeorando a medida que más y más organizaciones se dan cuenta de que
deben tomarse en serio la ciberseguridad o sufrir posibles sanciones por incumplimiento y consecuencias
negativas para la reputación. Los recientes ataques de ransomware de alto perfil refuerzan esta realidad.
Evaluar el talento que tiene actualmente un equipo de seguridad ayuda a los CISO, así como a los CIO, a
identificar brechas críticas en la experiencia. Por ejemplo, si un equipo de seguridad no tiene suficiente
personal en un área crítica, como la gestión de vulnerabilidades o la respuesta a incidentes, los CIO y CISO
deben saberlo lo antes posible . Si tiene personas que no están capacitadas en algunos de los hardware,
software o procesos de los que son responsables o que se espera que usen, identificar esos vacíos es el
primer paso para abordarlos. También ayuda a los CIO y CISO a identificar áreas de crecimiento profesional
para las personas del equipo de seguridad y detectar posibles futuros líderes. La polinización cruzada del
personal entre equipos o funciones ayudará a desarrollarlos en formas que serán potencialmente útiles en el futuro.
La clave es que los CIO y CISO sean lo más realistas posible en sus evaluaciones para que tengan una
visión fundamentada del talento en la organización. No permita que las aspiraciones de grandeza pinten una
imagen inexacta del talento que tiene la organización. Esto facilitará la priorización del tipo de talento
requerido y brindará a los reclutadores de la organización una mejor oportunidad de atraer al nuevo talento
adecuado.
La cartografía, o hacer un inventario de sus capacidades actuales de ciberseguridad, es otro ejercicio

importante. Los resultados informarán el desarrollo de los imperativos de seguridad cibernética que discutí
anteriormente, además de ayudar a identificar brechas críticas en las capacidades. También puede ayudar a
identificar la inversión excesiva en capacidades. Por ejemplo, se descubre que la organización adquirió tres
sistemas de administración de identidades y solo uno de ellos está realmente implementado.
Esto sucede cuando la organización no tiene suficientes escáneres de vulnerabilidades para realizar un trabajo
competente de escaneo y parcheo de la infraestructura en un tiempo razonable.
En la mayoría de los entornos de TI grandes y complejos, esta no será una tarea fácil. Puede resultar relativamente
fácil obtener una lista de derechos del departamento de adquisiciones o un inventario de software implementado de
TI. Pero saber que se ha implementado un dispositivo, una pieza de software o un conjunto de capacidades en
particular solo responde parte de la pregunta que el CISO debe responder. Comprender realmente la madurez de la
implementación y operación de esas capacidades es igual de importante, pero generalmente es mucho más difícil de
determinar. El hecho de que un producto de administración de identidades esté en producción no significa que todas
sus capacidades se hayan implementado o habilitado, el producto se está administrando activamente y los datos que
produce están siendo consumidos por cualquier persona.
Descubrir estos detalles puede ser un desafío, y medir su impacto en su estrategia puede ser demasiado difícil de
contemplar de manera realista. Pero sin estos detalles, es posible que no pueda identificar con precisión las brechas
en las capacidades de protección, detección y respuesta, y las áreas donde

se ha producido una sobreinversión.
Si los CIO y CISO pueden obtener una visión precisa del talento y las capacidades de seguridad cibernética actuales
que tienen, les resulta mucho más fácil y menos costoso administrar de manera efectiva los programas de seguridad
cibernética para sus organizaciones.
En mi experiencia, puede haber muchos conflictos y fricciones en las organizaciones cuando los equipos de seguridad
cibernética y los equipos de cumplimiento no trabajan bien juntos. Exploremos esta dinámica a continuación.
Programa de cumplimiento y alineación del marco de control

He visto equipos de ciberseguridad y cumplimiento en conflicto entre sí por marcos y configuraciones de control.
Cuando esto sucede, tiende a haber una desconexión entre la estrategia de ciberseguridad y la estrategia de
cumplimiento dentro de la organización. Por ejemplo, el CISO podría decidir que el equipo de seguridad cibernética
adoptará NIST 80053 como un marco de control con el que se miden. Si el equipo de cumplimiento está midiendo el
cumplimiento con ISO/IEC 27001, esto puede dar lugar a una conversación tras otra sobre marcos de trabajo y
configuraciones de control.
Algunas organizaciones resuelven estas diferencias de manera rápida y eficiente, mientras que otras luchan por
armonizar estos esfuerzos.
Un área común de desalineación entre los equipos de ciberseguridad y cumplimiento es cuando difieren los controles
en un estándar interno y un estándar de la industria. Los estándares internos suelen estar informados por los riesgos
y controles específicos que son más aplicables a cada organización.

Capítulo 8 321
Pero las diferencias entre un estándar interno y un estándar de la industria pueden ocurrir cuando el estándar
interno es más nuevo que el estándar de la industria o viceversa. Por ejemplo, el estándar de la industria establece
que una política de bloqueo de cuenta debe establecerse en un máximo de cinco entradas de contraseña
incorrectas. El equipo de ciberseguridad sabe que este control es un "teatro de seguridad" en un entorno que
impone una política de contraseñas seguras y especialmente en sistemas que tienen MFA habilitado. Pero para
cumplir con el estándar de la industria, es posible que se vean obligados a activar la política de bloqueo de
cuentas, lo que permite a los atacantes bloquear cuentas en cualquier momento que lo deseen con un ataque de denegación de servic
He visto a profesionales del cumplimiento discutir con los CISO sobre la eficacia de tales estándares de control
anticuados , quienes simplemente intentan cumplir con éxito con un estándar de la industria sin considerar que
en realidad aumentan el riesgo para toda la organización. Incluso he visto a algunos de estos profesionales de
cumplimiento, en el curso de su trabajo, afirmar que pueden aceptar el riesgo en nombre de toda la organización
en lo que respecta a tales decisiones, lo que rara vez es el caso, si es que alguna vez lo es.
La realidad es que la industria y los estándares regulados suelen tardar años en desarrollarse, refinarse, aprobarse
y publicarse. Posteriormente, a menudo van a estar atrasados en términos de riesgos y mitigación de riesgos.
Se debe reconocer y reconocer que tanto el cumplimiento como la seguridad son importantes para las
organizaciones. El cumplimiento está impulsado por la regulación de la responsabilidad, y la seguridad está
impulsada por la prevención, detección y respuesta. Los CISO deben fomentar la normalización y la alineación de
los marcos aplicados para la seguridad y el cumplimiento. Los profesionales de cumplimiento deben reconocer
que cualquier organización que coloque el cumplimiento como una prioridad eventualmente se verá comprometida
porque la industria y los estándares regulados casi siempre se basan en el modelo de amenaza de otra persona.
El grupo de seguridad cibernética y el grupo de cumplimiento deben trabajar juntos para encontrar formas de
cumplir con los estándares y al mismo tiempo proteger, detectar y responder a las amenazas modernas. Estas
disciplinas diferentes, pero superpuestas, deben coordinarse con el objetivo común de ayudar a administrar el
riesgo para la organización. Como mencioné anteriormente, la estrategia de seguridad cibernética debe estar
informada por los HVA de la organización y los riesgos específicos que les preocupan. El equipo de cumplimiento
es la segunda línea de defensa diseñada para garantizar que el equipo de seguridad cibernética esté haciendo su
trabajo de manera efectiva al comparar sus controles con los estándares internos, de la industria y/o regulados.
Pero deben estar preparados para evaluar la eficacia de los controles donde hay diferencias o conflictos, en lugar
de exigir ciegamente que se cumpla un estándar.
Por lo general, la decisión de aceptar más riesgos mediante el cumplimiento de un estándar de la industria con
fecha, por ejemplo, debe tomarla una junta de gestión de riesgos o la comunidad interna más amplia de partes
interesadas en lugar de una sola persona o grupo.
Los equipos de auditoría interna y externa son la tercera línea de defensa que ayuda a mantener la honestidad tanto
del equipo de seguridad cibernética como del equipo de cumplimiento mediante la auditoría de los resultados de su
trabajo. Nadie gana cuando estos equipos luchan por los marcos y estándares de control, especialmente cuando los
marcos o estándares en cuestión se basan en el modelo de amenaza de otra persona, como casi siempre ocurre con
la industria y los estándares regulados. Algunas organizaciones intentan resolver este problema haciendo que el CISO
informe a la organización de cumplimiento. Esto podría funcionar para algunas organizaciones que se encuentran en
industrias fuertemente reguladas.
Sin embargo, en pocas palabras, la ciberseguridad y el cumplimiento son disciplinas diferentes. El cumplimiento se
enfoca en demostrar que la organización está cumpliendo con éxito los estándares internos, de la industria y/o
regulados. La ciberseguridad se enfoca en proteger, detectar y responder a las amenazas de ciberseguridad de hoy
en día . Juntos, ayudan a la organización a gestionar el riesgo. Voy a discutir el cumplimiento como una estrategia de
seguridad cibernética en detalle en el Capítulo 9, Estrategias de seguridad cibernética.
A continuación, hablaremos sobre la importancia de que la ciberseguridad y la TI mantengan una relación feliz y
productiva entre sí.
Una relación efectiva entre ciberseguridad y TI

En mi experiencia, los CISO que tienen una buena relación de trabajo con las organizaciones de TI de su negocio
suelen ser más felices y efectivos en su trabajo. Una relación ineficaz con TI puede hacer que la vida de un CISO sea
miserable. También es cierto que los CISO pueden hacer que los trabajos de los CIO y VP de las disciplinas de TI
sean frustrantes. He conocido a tantos CISO que tienen relaciones de trabajo subóptimas con los departamentos de
TI de su organización. He visto a muchos grupos de seguridad cibernética y organizaciones de TI interactuar como el
agua y el aceite, cuando la única forma de tener éxito es trabajar juntos. Después de todo, tienen un destino
compartido. ¿Entonces, cuál es el problema? Bueno, en pocas palabras, en muchos casos, el cambio es difícil. Es
fácil para los CIO interpretar el ascenso de los CISO como un subproducto de sus propias deficiencias, ya sea que
esto sea correcto o no. Los CISO representan el cambio y muchos de ellos son líderes del cambio.
Además, creo que esta dinámica puede desarrollarse por al menos algunas razones. La forma en que se organizan
estos grupos puede ser una de ellas. Las dos formas más comunes que he visto integrados en los grupos de
seguridad cibernética, que suelen ser mucho más nuevos que los departamentos de TI en organizaciones grandes y
maduras, son las siguientes:
• El CISO informa al CIO o al CTO en TI y comparte los recursos de TI para realizar el trabajo.
• El CISO informa fuera de TI al CEO, la junta directiva, legal, cumplimiento, el CFO o una oficina de
"transformación". Hay dos sabores de este modelo:
Capítulo 8 323
• El CISO tiene sus propios recursos de ciberseguridad, pero necesita recursos de TI para obtener
trabajo hecho.
• El CISO tiene sus propios recursos de ciberseguridad y TI y puede hacer el trabajo independientemente de TI.
Históricamente, el escenario en el que el CISO informa a la organización de TI ha sido muy común.
Pero esta línea de presentación de informes ha ido evolucionando con el tiempo. Las estimaciones varían, pero creo que menos del
50 % de los CISO que conocí recientemente reportan a TI. Una de las razones de este cambio en las líneas de informes es que, con
demasiada frecuencia, los CIO priorizan las prioridades de TI sobre la ciberseguridad.
En muchos casos, la ciberseguridad se trata como cualquier otro proyecto de TI, ya que debe hacer cola con otros proyectos de TI y
competir con ellos por los recursos para hacer las cosas. Los CISO frustrados lograrían convencer a su jefe de que la ciberseguridad
no era solo otro proyecto de TI, o se verían obligados a escalar. No hay ganadores con tales escaladas, y mucho menos el CISO. En
muchos casos, el CISO se queda con un CIO que está resentido con él y lo ve como un impuesto a la organización de TI.
Muchos CIO tardaron años en darse cuenta de que cada proyecto de TI tiene requisitos de seguridad. Dejar de priorizar o ralentizar
las iniciativas de seguridad cibernética significa que cada proyecto de TI que dependa de las capacidades de seguridad cibernética
se retrasará o necesitará una excepción para eludir estos requisitos. Este último tiende a ser mucho más común que el primero.
Cuando los directores ejecutivos y otros ejecutivos comenzaron a perder sus trabajos y los directores de las juntas rindieron cuentas
debido a las filtraciones de datos, consultores externos aconsejaron a muchas organizaciones que sus CI SO informaran al director
ejecutivo o directamente a la junta directiva. De esta manera, la ciberseguridad no perdería prioridad sin que las personas más
importantes se involucren en la toma de esas decisiones de riesgo.
Se presenta un nuevo desafío cuando el CISO reporta fuera de TI al CEO, la junta directiva u otra parte de la empresa. ¿Dónde
conseguirá el CISO el personal de TI necesario para hacer las cosas? Cuando el CISO informaba a TI, probablemente era más fácil
obtener acceso a los recursos de TI, incluso si tenían que hacer cola. Los CISO que se encuentran fuera de la organización de TI
solo tienen algunas opciones. Pueden obtener recursos de TI y convertirse en sus clientes, o deben contratar sus propios recursos de
TI.
Convertirse en un cliente de TI parece que podría facilitar las cosas para los CISO, pero solo cuando tienen una buena relación con
TI que conduce a resultados positivos. De lo contrario, podría no ser lo suficientemente diferente del modelo en el que el CISO
informa a TI.
Por conveniente que suene contratar sus propios recursos, existen desafíos con este enfoque. Por ejemplo, el control de cambios
puede volverse más complejo porque TI no es el único grupo de personas que puede realizar cambios en el entorno. Muchas veces,
esto da como resultado que los ingenieros de TI vean a los ingenieros de ciberseguridad realizar cambios en su entorno compartido
y viceversa.
Usar el doble de recursos para garantizar que las cosas se hagan a tiempo es una forma de abordar este
problema. Pero la mayoría de las organizaciones pueden encontrar mejores usos para sus recursos.
He visto un mejor enfoque en acción. Cuando los CISO, CIO y CTO tienen respeto mutuo por los estatutos de los
demás y se apoyan sinceramente, el trabajo es más fácil, las cosas se hacen de manera más eficiente y los mejores
talentos son más fáciles de atraer y retener para todos. En lugar de una relación definida por la disputa de recursos o
las afirmaciones de autoridad, los CISO deben tener relaciones de trabajo buenas y efectivas con sus departamentos
de TI para garantizar que puedan hacer su trabajo. Construir tales relaciones no siempre es fácil, o incluso posible,
pero creo que este es un ingrediente fundamental para una estrategia de seguridad cibernética exitosa. Idealmente,
estas relaciones se convierten en una cultura de seguridad de la que se beneficia toda la organización.
En cuanto al tema de la cultura, el último ingrediente para una estrategia de seguridad cibernética exitosa que
analizaré en este capítulo es una cultura de seguridad sólida. Esta cultura implica que todos en la organización
entiendan su papel para ayudar a mantener una buena postura de seguridad para proteger a la organización de
compromisos. Hablemos de ello con un poco más de detalle en la siguiente y última sección de este capítulo.
Cultura de seguridad
El consultor de gestión y escritor Peter Drucker dijo que "la cultura se come la estrategia en el desayuno". Estoy de
acuerdo de todo corazón. Las organizaciones que logran integrar la seguridad en sus culturas corporativas están en
una posición mucho mejor para proteger, detectar y responder a las amenazas modernas. Por ejemplo, cuando todos
en la organización entienden cómo es un ataque de ingeniería social y están atentos a tales ataques, el trabajo del
equipo de seguridad cibernética es mucho más fácil y les da una mayor probabilidad de éxito. Compare esto con los
entornos de trabajo en los que los empleados reciben constantemente phishing con éxito y las vulnerabilidades se
explotan constantemente porque los empleados hacen doble clic en los archivos adjuntos de los correos electrónicos
de remitentes desconocidos. En estos entornos, el equipo de ciberseguridad dedica gran parte de su tiempo y
esfuerzo a reaccionar ante las amenazas que se han producido. Una sólida cultura de seguridad ayuda a reducir la
exposición a amenazas, disminuir los tiempos de detección y respuesta y, por lo tanto, reducir los daños y costos
asociados.
La cultura trasciende la formación. Una cosa es que los empleados reciban una capacitación de seguridad única o
anual con fines de cumplimiento, pero otra muy distinta es que los conceptos y llamados a la acción que los empleados
aprenden en la capacitación sean sostenidos y reforzados constantemente por todos los empleados y el entorno de
trabajo en sí. Esto no debería limitarse a los trabajadores de información de primera línea. Los desarrolladores, el
personal de operaciones y el personal de infraestructura de TI se benefician de una cultura en la que se incluye la seguridad.
Capítulo 8 325
Una cultura de seguridad puede ayudar a los empleados a tomar mejores decisiones en ausencia de un gobierno
o una guía clara.
Una nota sobre la gamificación de la capacitación en seguridad cibernética: he visto buenos resultados cuando las
organizaciones cambian parte de su capacitación en seguridad cibernética de la lectura y los videos a experiencias
más interactivas. Por ejemplo, he facilitado "días de juego" y "simulaciones de seguridad ejecutiva" enfocadas en
ayudar a las organizaciones a aprender sobre el modelado de amenazas y la seguridad en la nube. He visto a
muchos grupos de ejecutivos y equipos de seguridad adoptar estas sesiones y brindar comentarios entusiastas.
Los CISO tienen más posibilidades de éxito cuando todos en sus organizaciones los ayudan. Animo a los CISO,
con la ayuda de otros ejecutivos, a invertir parte de su tiempo y recursos en fomentar una cultura de seguridad, ya
que sin duda generará dividendos.
Resumen
En este capítulo, discutimos qué es una estrategia de seguridad cibernética y algunos de los ingredientes que
le dan a una estrategia la mejor oportunidad de éxito. Revisamos brevemente los fundamentos de la
ciberseguridad y los sospechosos habituales de la ciberseguridad en este capítulo. También introduje los
activos de alto valor (HVA) y otros conceptos a los que me refiero con frecuencia en el resto de este libro.
Hay al menos dos entradas críticas para una estrategia de seguridad cibernética: los HVA de su organización y los
requisitos, amenazas y riesgos específicos que se aplican a su organización, informados por la industria en la que
se encuentra, los lugares del mundo donde hace negocios y las personas asociadas con la organización. Si la
confidencialidad, la integridad o la disponibilidad de un HVA se ven comprometidas, la organización fracasará o se
verá gravemente afectada. Por lo tanto, es fundamental identificar los HVA y priorizar la protección , detección y
respuesta para ellos. Esto no da permiso a los equipos de seguridad para ignorar por completo otros activos. Clarity
on HVA ayuda a los equipos de seguridad a priorizar y evitar eventos de extinción para sus organizaciones.
Hay cinco formas en que las organizaciones se ven comprometidas inicialmente ; Los llamo los sospechosos
habituales de ciberseguridad. Son vulnerabilidades sin parchear, configuraciones incorrectas de seguridad,
credenciales débiles, filtradas y robadas, ingeniería social y amenazas internas. Ya sea que el atacante sea un
proveedor de malware comercial o un estadonación, las formas en que intentarán comprometer inicialmente los
entornos de TI de sus víctimas se limitan a los sospechosos habituales de ciberseguridad. Ser muy competente en
los fundamentos de ciberseguridad que mitigan los sospechosos habituales de ciberseguridad hace que sea mucho
más difícil para los atacantes, ya sea un estadonación que intenta robar propiedad intelectual o un extorsionador.
Se requiere una estrategia de ciberseguridad para el éxito, pero no es suficiente por sí sola. Los ingredientes para
una estrategia exitosa incluyen:
• Alineación de objetivos comerciales
• Visión, misión e imperativos de la ciberseguridad
• Alto ejecutivo y apoyo a la junta
• Comprensión del apetito por el riesgo de la organización
• Una visión realista de las capacidades de ciberseguridad y el talento técnico actuales
• Programa de cumplimiento y alineación del marco de control
• Una relación efectiva entre ciberseguridad y TI
• Cultura de seguridad
Hemos dedicado los primeros ocho capítulos de este libro a analizar las amenazas, la información de fondo y el
contexto que nos ayudarán a examinar algunas estrategias populares de ciberseguridad. En los próximos tres
capítulos, examinaremos numerosas estrategias diferentes, profundizaremos en un ejemplo de implementación
de una de ellas y analizaremos cómo medir la eficacia de las estrategias de ciberseguridad.
Referencias
• Corporación Microsoft. (20072016). "Informe de inteligencia de seguridad de Microsoft". microsoft
Corporación. Obtenido de www.microsoft.com/sir.

9
Estrategias de Ciberseguridad
Cada empresa debe tener una estrategia de ciberseguridad, y el CISO de cada organización debe poder
articularla. Ya sea que su organización tenga una estrategia o no, espero que este capítulo provoque alguna
reflexión y proporcione algunas herramientas útiles. En este capítulo, cubriremos una muestra de las
estrategias de seguridad cibernética que se han empleado durante las últimas dos décadas, que incluyen:
• Estrategia de Protección y Recuperación
• Estrategia de protección de terminales
• Estrategia de Control Físico y Autorizaciones de Seguridad
• Cumplimiento como estrategia de seguridad
• Estrategia centrada en la aplicación
• Estrategia centrada en la identidad
• Estrategia centrada en datos
• Estrategias centradas en ataques
• Confianza Cero
• Una breve mirada a DevOps
Comencemos discutiendo qué estrategia es el enfoque adecuado para su organización.
Introducción
Discutí algunos de los ingredientes para una estrategia de seguridad cibernética exitosa en el Capítulo 8, Ingredientes
para una estrategia de seguridad cibernética exitosa. Estos incluyen lo que considero un ingrediente crítico, los
sospechosos habituales de ciberseguridad, es decir, las cinco formas en que las organizaciones se ven comprometidas inicialmente.
328 Estrategias de Ciberseguridad
He dedicado la mayor parte de los capítulos anteriores de este libro a analizar las amenazas más comunes
que suelen preocupar a los CISO y los equipos de seguridad, incluidas las vulnerabilidades, los exploits, el
malware, el ransomware, las amenazas basadas en Internet como los ataques de phishing y el acceso
gubernamental a los datos. En este capítulo, combinaré todos estos conceptos en un examen de algunas de
las estrategias de seguridad cibernética que he visto empleadas en la industria durante las últimas dos
décadas. Probablemente haya visto algunos de estos antes y tal vez haya usado algunos de ellos. Mi objetivo
para este capítulo no es mostrarle un montón de estrategias para que pueda seleccionar una para usar. Mi
objetivo es brindarle un marco para determinar la eficacia de las estrategias de seguridad cibernética, incluidas
las estrategias que no discutiré en este capítulo pero que podría encontrar en su carrera. En otras palabras,
espero enseñarles a pescar en lugar de darles una estrategia única que sé que solo ayudará a una fracción de
las organizaciones que la utilizan.
La estrategia correcta para su organización es aquella que ayuda a mitigar los riesgos más importantes para
su organización. El riesgo es relativo; por lo tanto, ninguna estrategia puede ser una panacea para todas las
organizaciones. Resistiré la tentación de simplemente decirle que use el marco de ciberseguridad NIST (NIST,
nd), ISO/IEC 27001 (ISO, nd), o cualquiera de los otros excelentes marcos disponibles. Es probable que su
organización ya haya adoptado uno o más de estos marcos, lo cual es inevitable para las organizaciones de
escala empresarial desde una perspectiva de Gobernanza, Riesgo y Cumplimiento (GRC) ; es decir, su
organización debe demostrar que está haciendo lo que hace el resto de la industria, o será visto como un caso
atípico. Los marcos de GRC generalmente están diseñados para ayudar a aislar a las organizaciones de la
responsabilidad después de un incidente y, posteriormente, muchas organizaciones les dan prioridad. Sin
embargo, el ritmo de las violaciones de datos no se ha ralentizado, a pesar de la cantidad de excelentes
marcos disponibles. Por ejemplo, el Consejo Europeo de Protección de Datos (EDPB) publicó un informe
sobre los resultados del Reglamento General de Protección de Datos (GDPR) después de los primeros nueve
meses de aplicación de GDPR . Casi 65.000 notificaciones de violación de datos se presentaron ante el EDPB en esos primeros n
La gran mayoría de estas organizaciones probablemente cumplían con sus propias políticas de seguridad, lo
que ilustra la diferencia entre ciberseguridad y cumplimiento. Esta es probablemente la punta del iceberg, pero
nos da alguna indicación de que las organizaciones, tanto grandes como pequeñas, necesitan ayuda con la
estrategia de seguridad cibernética.
Capítulo 9 329
El número total de casos notificados por las SA de 31 países del EEE es de 206.326. Se
pueden distinguir tres tipos diferentes de casos, a saber, casos basados en quejas, casos
basados en notificaciones de violación de datos y otros tipos de casos. La mayoría de los casos
están relacionados con quejas, en particular 94.622, mientras que 64.684 se iniciaron sobre la
base de una notificación de violación de datos por parte del controlador”. (Consejo Europeo de
Protección de Datos , 2019)
En este capítulo, le daré una visión ligeramente contraria que pretende ser motivo de reflexión.
Si su organización ya tiene una estrategia de seguridad cibernética y utiliza marcos de la
industria, este capítulo le dará algunas preguntas que debe hacerse sobre la efectividad de su
estrategia actual. Si su organización no tiene una estrategia de seguridad cibernética que pueda
articular, este capítulo le dará algunas ideas sobre algunas de las estrategias que otras
organizaciones han usado, sus ventajas y desventajas, y una forma de medir su efectividad potencial.
Como vio en el Capítulo 8, Ingredientes para una estrategia de seguridad cibernética exitosa, donde describí qué
es una estrategia de seguridad cibernética, estoy simplificando deliberadamente las descripciones de estas
estrategias. He hablado con algunos CISO que tenían estrategias de ciberseguridad increíblemente densas que
pocas personas en su organización podían comprender o repetir por completo. Mantener la estrategia simple de
entender hace que sea más fácil para la comunidad de partes interesadas y las personas que hacen el trabajo
comprender la estrategia y explicarla a sus equipos (repetirla). Si la estrategia requiere un anillo decodificador
secreto o el conocimiento de un estándar industrial técnico específico para comprender, es poco probable que las
partes interesadas de alto nivel que no tienen experiencia en seguridad cibernética lo entiendan y realmente
confíen en él. Es probable que solo haya unos pocos equipos dentro del grupo de TI y ciberseguridad que sean
responsables de comprender y ejecutar la estrategia completa. Puede reservar la versión supercomplicada de la
estrategia, con superposiciones para GRC, desarrollo de productos, reclutamiento, programas educativos locales
de ciberseguridad, planificación de la sucesión y otros componentes, para las partes interesadas que necesitan y
aprecian todos esos detalles y ambiciones.
Independientemente de cuán sofisticada sea una estrategia de seguridad cibernética, su éxito depende de los ingredientes
que describí en el Capítulo 8 y, lo que es más importante, qué tan bien aborda los fundamentos de la seguridad cibernética.
Es importante medir el rendimiento de una estrategia a lo largo del tiempo para que se puedan hacer ajustes para
mejorarla. Veamos a continuación cómo medir la eficacia.
Medición de la eficacia de las estrategias de ciberseguridad

Permítame volver a familiarizarlo con dos conceptos que introduje en el Capítulo 1 y mencioné
nuevamente en el Capítulo 8. Vamos a utilizar estos dos conceptos para medir la eficacia potencial
de las estrategias que examinamos.
Recuerde que las cinco formas en que las organizaciones se ven comprometidas inicialmente, llamadas los sospechosos
habituales de ciberseguridad, son:
• Vulnerabilidades sin parchear
• Configuraciones incorrectas de seguridad
• Credenciales débiles, filtradas o robadas
Una vez que un entorno de TI se ha visto comprometido inicialmente, existen muchas, muchas tácticas, técnicas y
procedimientos (TTP) que los atacantes pueden usar para moverse lateralmente, robar credenciales, comprometer la
infraestructura, permanecer persistentes, robar información, destruir datos e infraestructura, etc.
La mayoría de estos TTP existen desde hace años. Ocasionalmente, la industria verá atacantes empleando enfoques
novedosos. Mitigar los sospechosos habituales de la ciberseguridad es lo que yo llamo los fundamentos de la
ciberseguridad. Las organizaciones que se enfocan en ser realmente buenas en los fundamentos de la ciberseguridad
hacen que sea mucho más difícil para los atacantes tener éxito. Centrarse en las cosas que hacen todos los atacantes
para comprometer inicialmente los entornos, los sospechosos habituales de ciberseguridad, es un requisito difícil para
cualquier estrategia o combinación de estrategias que emplean las organizaciones.
Dicho de otra manera, si la estrategia de seguridad cibernética de una organización no incluye ser excelente en los
fundamentos de seguridad cibernética, se está preparando para el fracaso. ¿Por qué? Sabemos que el 99,9% de los
compromisos exitosos comienzan con los sospechosos habituales de ciberseguridad. Si eso es cierto, ¿por qué su
organización usaría una estrategia que al menos no mitiga estos vectores de ataque? ¿Por qué usaría una estrategia que
sabe que tiene lagunas y que los atacantes han usado durante décadas para atacar a otras organizaciones? Recuerde la
analogía del submarino que usé en la sección del prefacio de este libro. ¿Por qué zarparías en un submarino que sabes
que tiene fallas en el casco? ¿Tendría la confianza suficiente para sumergirse cientos de pies bajo la superficie del océano
en ese submarino y permitir que se acumulara una presión inmensa en cada milímetro cuadrado de ese casco? Eso suena
temerario, ¿verdad? Aún así, habrá algunas organizaciones que estarán dispuestas a asumir grandes riesgos para poder
competir en industrias competitivas y de rápido movimiento.

Capítulo 9 331
Aquí es donde algunos de los ejecutivos que conocí sintieron que debían elegir entre la seguridad cibernética y
moverse rápido. Pero moverse rápido y la ciberseguridad no son mutuamente excluyentes; esta no es una
elección que tengan que hacer, ya que pueden obtener eficacia de ciberseguridad Y velocidad, agilidad y
escalabilidad comercial si tienen una estrategia que les permita hacerlo. Invertir en enfoques que deliberadamente
no logran abordar las formas más comunes en que las organizaciones se ven comprometidas es una tontería.
Además, si un entorno ya está comprometido, la organización aún debe centrarse en los fundamentos de la
seguridad cibernética para evitar que más atacantes se afiancen, evitando así que los atacantes que ya habitan
el entorno vuelvan a entrar , si alguna vez pueden ser expulsados de él. Independientemente de la estrategia
que emplee una organización, debe incorporar los fundamentos de la ciberseguridad.
Una vez que una organización perfecciona su capacidad para administrar los fundamentos de la ciberseguridad
y establece una base sobre la cual puede construir, entonces tiene sentido invertir en capacidades avanzadas
de ciberseguridad, capacidades que ayudarán a la organización cuando no pueda administrar perfectamente los
fundamentos de la ciberseguridad con el tiempo. Su estrategia necesita una base sólida, incluso si tiene
capacidades de ciberseguridad avanzadas, porque las plataformas en las que se basan estas capacidades
avanzadas para obtener información y su propia seguridad pueden verse socavadas por vulnerabilidades sin
parches, configuraciones incorrectas de seguridad, ingeniería social, amenazas internas y contraseñas débiles, filtradas y robadas.
Ser excelente para abordar todos los fundamentos de la ciberseguridad en los entornos de producción y
desarrollo/prueba es un requisito para implementar y operar con éxito capacidades avanzadas de ciberseguridad
en su entorno de TI. Por ejemplo, si una organización no tiene un plan para encontrar y corregir las
vulnerabilidades de seguridad y las configuraciones incorrectas en el hardware y el software que implementan
como parte de sus capacidades avanzadas de ciberseguridad, no deberían molestarse en implementarlas
porque, con el tiempo, solo aumentarán la superficie de ataque de la organización.
Quizás se pregunte por qué debe invertir en capacidades avanzadas de ciberseguridad si su organización es
realmente buena en los fundamentos de la ciberseguridad. Porque tienes que planear para el fracaso. Debe
suponer que la organización será violada; no se trata de si ocurrirá, solo de cuándo y con qué frecuencia
sucederá. Esta filosofía de “asumir incumplimiento” es importante por al menos dos razones. En primer lugar, la
historia nos ha enseñado que la planificación para lograr una protección 100 % perfecta para grandes entornos
de TI locales durante un período sostenido de tiempo es una ambición sumamente optimista. Las personas de
su organización y cadena de suministro cometerán errores, y algunos de ellos estarán relacionados con la
seguridad.
Por ejemplo, sus aplicaciones, ya sea que el desarrollo se realice internamente o a través de proveedores, tendrán
errores. Algunos de estos errores serán vulnerabilidades de seguridad. Algunas de estas vulnerabilidades serán
explotables. Es necesario planificar para esta eventualidad. Debe planificar los errores que cometen los
administradores que conducen a errores de configuración de la seguridad. Debe planificar el escenario en el que
los proveedores de confianza en su cadena de suministro se ven comprometidos o se vuelven malévolos. Esta es
un área donde los equipos rojos pueden basar la estrategia en la realidad, ya que se especializan en aprovechar
suposiciones poco realistas.
La segunda razón por la que las organizaciones deben adoptar una filosofía de "asumir una infracción" es que da
permiso a sus equipos de seguridad para pensar en algunas preguntas clave que los equipos de seguridad que
creen que pueden lograr una protección 100% efectiva, para siempre, nunca se hacen. Por ejemplo, ¿cómo sabrían
cuando han sido comprometidos? ¿Qué harán cuando se vean comprometidos? Estas son preguntas que muchos
equipos de seguridad nunca se hacen porque no quieren, o no pueden, adoptar una filosofía de "asumir una
infracción".
Algunas culturas corporativas no tolerarán el fracaso, por lo que la idea de que planean para el fracaso no tiene
sentido para ellas; es como admitir que no son lo suficientemente buenos para hacer su trabajo. En otras
organizaciones, los altos ejecutivos no apoyarán un plan para el fracaso. He conocido a muchos ejecutivos que no
entienden que están en un submarino bajo una presión inmensa, rodeados de maldad.
Algunos de los ejecutivos con los que he hablado creen que están en una batalla que se puede ganar. Creen que si
son lo suficientemente inteligentes, contratan a las personas adecuadas y compran las capacidades de protección
adecuadas, ganarán la batalla. Pero la ciberseguridad es un viaje, no un destino. No tiene un comienzo y un final
como lo tiene una batalla. Es constante, como la presión sobre el casco de un submarino. La planificación para el
fracaso es la antítesis de su visión del mundo, por lo que se niegan a apoyar a los CISO que saben que necesitan
adoptar un enfoque más moderno de la ciberseguridad. Esta es una de las razones por las que, cuando trabajé
como asesor de seguridad cibernética, siempre traté de pasar tiempo con las partes interesadas de la estrategia de
seguridad cibernética además del CISO y el equipo de seguridad. Muy a menudo, el equipo de seguridad entiende
todo lo que he escrito aquí, pero uno o dos ejecutivos o miembros de la junta tienen puntos de vista desinformados.
Las capacidades avanzadas de ciberseguridad son la parte de su estrategia que lo ayudarán a identificar, proteger,
detectar, responder y recuperar (NIST, sin fecha). Esta es la parte de su estrategia que ayuda a aumentar e
identificar las deficiencias en los fundamentos de la ciberseguridad. Los necesita a ambos para que la estrategia
tenga éxito. El componente de activos de alto valor (HVA) de la estrategia reconoce la importancia de los HVA.
Como mencioné en el Capítulo 8, si la confidencialidad, la integridad o la disponibilidad de un HVA se ven
comprometidas, esto generalmente significa que la propia organización fracasará.
Capítulo 9 333
El compromiso sostenido de un HVA podría ser un evento de extinción para una empresa (Ashford,
2016) y hacer que las organizaciones del sector público vuelvan a usar lápices, papel y los procesos
que usaban antes de invertir en TI.
La planificación e inversión en seguridad específicamente enfocada en HVA, además de los fundamentos de

ciberseguridad y las capacidades avanzadas de ciberseguridad, ayudará a las organizaciones a administrar el
riesgo de sus activos más importantes.
Figura 9.1: Ilustración de una estrategia de ciberseguridad
Independientemente de los HVA de las organizaciones y de las capacidades avanzadas de ciberseguridad en

las que decidan invertir (que es muy variable entre organizaciones), todo el modelo de estrategia que he
descrito aquí se basa en la base que proporcionan los fundamentos de la ciberseguridad. Sin una base sólida,
una estrategia fallará con el tiempo. Cualquier estrategia de seguridad cibernética que persiga una empresa
debe centrarse como mínimo en los fundamentos de la seguridad cibernética. Dado esto, voy a presentar un
método simple para ayudar a determinar la eficacia potencial de una estrategia al estimar qué tan bien incorpora
los fundamentos de ciberseguridad y mitiga los sospechosos habituales de ciberseguridad.
Estimaré la eficacia potencial de las estrategias de seguridad cibernética que examinamos utilizando un sistema de puntuación
simple. Llamo a este sistema el sistema de puntuación de los fundamentos de la ciberseguridad (CFSS). Este sistema asigna
una puntuación entre 0 y 10 para cada uno de los sospechosos habituales de ciberseguridad, en función de qué tan bien la
estrategia mitiga el riesgo. Las puntuaciones más altas significan que la estrategia es más eficaz para mitigar cada sospechoso
habitual de ciberseguridad en particular. Por ejemplo, una puntuación de 20 significa que la estrategia mitiga por completo el
riesgo asociado con un sospechoso habitual de ciberseguridad específico. Una puntuación baja, como una puntuación de 1,
por ejemplo, significa que la capacidad de la estrategia para mitigar el riesgo es relativamente baja. El CFSS incluye una
puntuación separada para cada uno de los cinco sospechosos habituales de ciberseguridad, como se muestra en la Tabla 9.1:
Sospechoso habitual de ciberseguridad Puntaje
Vulnerabilidades sin parchear 020
Configuraciones incorrectas de seguridad 020
Credenciales débiles, filtradas y robadas 020
Ingeniería social 020
Amenaza interna 020
Tabla 9.1 Resumen CFSS
El total de los cinco puntajes es el puntaje total de CFSS para la estrategia. El puntaje total CFSS más bajo posible para una
estrategia es 0, mientras que el más alto es 100. Por ejemplo, como se muestra en la Tabla 9.2, digamos que tenemos una
estrategia llamada "XYZ" y estimamos puntajes para las cinco medidas en el CFSS.
Cuando sumamos las puntuaciones individuales, obtenemos una puntuación total de CFSS de 23 de los 100 puntos posibles:
Ejemplo de estrategia XYZ Puntaje
Amenaza interna 1
Tabla 9.2: Un ejemplo del CFSS
El objetivo es encontrar una estrategia que nos dé una puntuación perfecta de 100, aunque es probable que esto sea más
una aspiración que una probabilidad. Pero este tipo de sistema de puntuación nos brinda una forma de estimar la capacidad
de una estrategia para mitigar las cinco formas en que las organizaciones se ven comprometidas inicialmente, así como una
forma de comparar estrategias en los fundamentos de ciberseguridad.

Capítulo 9 335
Potencialmente, este enfoque puede ayudarnos a identificar una combinación de estrategias que nos brinde una
puntuación perfecta, o una puntuación alta, en los sospechosos habituales de ciberseguridad si ninguna estrategia única lo hace.
Finalmente, también puede ayudarnos a determinar dónde están las brechas en una estrategia que una organización
está utilizando actualmente. Si sabe dónde están las debilidades o las brechas, entonces puede desarrollar un plan para
abordar estas deficiencias.
Antes de comenzar a medir estrategias utilizando este marco, quiero señalar un par de riesgos ocultos al utilizar este
tipo de calificación. Como la mayoría de los enfoques basados en el riesgo, se basa en la suposición de que los CISO y
los equipos de seguridad podrán estimar con precisión el nivel de riesgo e identificar mitigaciones efectivas. En mi
experiencia, he visto a algunos CISO sobrestimar sus capacidades y su habilidad para mitigar los riesgos de manera
efectiva, al mismo tiempo que subestiman los riesgos mismos y la efectividad de los fundamentos de la ciberseguridad.
Un segundo riesgo es que este enfoque asume que los cinco sospechosos habituales de ciberseguridad son igualmente
importantes para la organización . Sin embargo, es importante reconocer que dado que cada organización es diferente,
las mitigaciones pueden tener diferentes valores para diferentes organizaciones.
Ahora que tenemos en mente un concepto de estrategia de seguridad cibernética y un sistema de puntuación para
ayudarnos a determinar la eficacia relativa de los diferentes enfoques, examinemos numerosas estrategias de seguridad
cibernética con más detalle.
Estrategias de ciberseguridad
Como mencioné en el Capítulo 8, Ingredientes para una estrategia de seguridad cibernética exitosa, algunos de los
profesionales de seguridad cibernética con los que me he reunido tienen una reacción negativa cuando se usa el término
“estrategia” en un contexto de seguridad cibernética. Esta es una palabra que se puede usar en al menos algunas formas
diferentes. Los profesionales de seguridad y cumplimiento a veces usan el término "estrategia" cuando se refieren a
marcos, modelos o estándares. Expliqué a qué me refiero cuando uso este término, en detalle, en el Capítulo 8,
Ingredientes para una estrategia de ciberseguridad exitosa. Si aún no ha leído ese capítulo , le recomiendo que lo lea
porque proporciona mucho contexto que no repetiré aquí.
Verá que uso los términos marco, enfoque y modelo indistintamente a lo largo de todos los capítulos. Siéntase libre de
asociar cualquier término que tenga más sentido para usted cuando use cualquiera de estos términos.
La siguiente lista contiene muchas de las estrategias que he visto en uso durante las últimas dos décadas en la industria.
Examinaré cada una de estas estrategias en detalle y proporcionaré una puntuación CFSS estimada para cada una. Los
puntajes de CFSS que proporciono son mis propias opiniones subjetivas y están sujetos a mis propias suposiciones y
sesgos. Le proporciono un poco de contexto sobre por qué cada Sospechoso habitual de seguridad cibernética se
calificó de la manera que lo fue para que pueda comprender mi enfoque y estar de acuerdo o en desacuerdo con él.
Lo invito a pensar en su propio puntaje CFSS estimado para cada una de estas estrategias:
• Control físico y autorizaciones de seguridad como estrategia
• Cumplimiento como estrategia de seguridad
• Estrategia centrada en el ataque
• Estrategia de confianza cero
Mientras revisamos estas estrategias, incluso si su organización no utiliza ninguna de ellas, pregúntese si los proveedores
de su cadena de suministro utilizan alguna de ellas. Si no conoce las estrategias que están utilizando para administrar
el riesgo para sus organizaciones y sus clientes, es posible que desee preguntarles cómo están mitigando los
sospechosos habituales de ciberseguridad. Esto es lo mínimo que deberían estar haciendo por sí mismos y por sus
clientes. Muchas empresas ya usan cuestionarios de seguridad, algunos de los cuales tienen cientos de preguntas, para
tener una mejor idea de si las políticas de seguridad de los proveedores potenciales cumplen con sus estándares. En
estos casos, podría ser valioso agregar algunas preguntas sobre la estrategia a estos cuestionarios para medir la
madurez de seguridad del proveedor.
Finalmente, ¡examinemos algunas estrategias de ciberseguridad!
Estrategia de protección y recuperación

Comencemos con una estrategia relativamente antigua que llamo la Estrategia de Protección y Recuperación. También
se conoce como estrategia de seguridad perimetral . Como dice el cliché, por lo general se describe que tiene una capa
exterior dura y un centro blando, a veces pegajoso. Esta analogía se usa a menudo porque una vez que se penetran las
defensas del perímetro de una organización, poco o nada impide que los atacantes se muevan lateralmente en el
entorno y permanezcan persistentes indefinidamente. La organización se queda tratando de recuperar los datos
originales y el entorno de TI, generalmente con un éxito mixto. Se considera una estrategia pasada de moda según los
estándares actuales, pero encuentro que un número sorprendente de organizaciones aún se aferran a ella.
Como sugiere el nombre, el enfoque de esta estrategia es evitar que los atacantes tengan éxito invirtiendo en tecnologías
de protección como firewalls, zonas desmilitarizadas (DMZ), servidores proxy y microsegmentación. Volvamos a 2003
para ver un gran ejemplo de por qué esta estrategia se volvió tan popular.
Capítulo 9 337
En 2003, ya se habían producido ataques masivos de gusanos en Internet, como Code Red y Nimda. El riesgo
de tales ataques ya no era teórico, como muchas personas habían argumentado en ese momento. La industria
apenas comenzaba a comprender que el software tenía vulnerabilidades y que algunas de ellas eran explotables.
En ese momento, trabajaba en el equipo de respuesta a incidentes de seguridad orientado al cliente de Microsoft.
Muchas de las organizaciones a las que ayudé culparon a Microsoft por no hacer más para proteger Windows de
tales ataques.
Había una creencia generalizada entre los clientes empresariales de que si reemplazaban Microsoft Windows
con otro sistema operativo, entonces estarían seguros. Eran los fabricantes del sistema operativo más utilizado
del mundo y, posteriormente, atrajeron mucha atención de los investigadores de seguridad legítimos y de los
atacantes por igual. Por supuesto, ahora, todos estos años después, creo que todos entienden que todos los
proveedores tienen vulnerabilidades en su software y hardware. Si todavía tiene alguna duda al respecto, vuelva
a leer el Capítulo 3, Uso de tendencias de vulnerabilidad para reducir riesgos y costos. En 2003, la mitigación del
riesgo que planteaban las vulnerabilidades sin parchear era el cortafuegos. Cuando Microsoft activó el Firewall
de Windows de manera predeterminada en Windows XP Service Pack 2, se esperaba que esto evitaría la
explotación de vulnerabilidades en los servicios y aplicaciones de Windows que escuchan en la red.
Firewall de Windows, junto con otras mitigaciones de seguridad, incluidas las actualizaciones automáticas,
mitigaron con éxito los ataques masivos de gusanos de la época. Muchas organizaciones de escala empresarial
ya tenían firewalls corporativos en el perímetro de sus redes en 2003. Pero la mayoría de ellos tenían excepciones
para todo el tráfico que iba y venía de los puertos 80 y 443 para que el tráfico HTTP y HTTPS pudiera fluir
libremente; estos son los llamados "puertos de derivación de cortafuegos universales". Durante los años
siguientes , las empresas que aún no tenían DMZ las implementaron para imponer un mejor control sobre el
tráfico de red que llega y se dirige a Internet.
Esta evolución en la estrategia de seguridad fue un paso importante y efectivo para la industria. Pero en algún
punto del camino, los beneficios originales de la seguridad perimetral se distorsionaron. En última instancia, se
suponía que la seguridad del perímetro proporcionaría a las organizaciones dos cosas. Primero, protegió los
recursos que se suponía que eran privados del acceso público. En segundo lugar, bloquear el tráfico de red
entrante anónimo a los servicios vulnerables que escuchan en la red dio a las organizaciones más tiempo para
probar e implementar actualizaciones de seguridad. Pero la idea de que los firewalls, las DMZ y la segmentación
de la red podrían proporcionar de alguna manera una solución a largo plazo para la gestión de vulnerabilidades o
los otros cuatro sospechosos habituales de ciberseguridad, de 5 a 10 años antes de que se incorporaran
capacidades de capa de aplicación en algunos de estos productos, fue un error.
La suposición subyacente de la estrategia de protección y recuperación es que la organización podrá

implementar y operar tecnologías y procesos de protección adecuados. Si estos fallan, entonces la recuperación
es su plan. Debido a que la organización será tan buena en protección, realmente no necesita invertir en
capacidades de detección y respuesta. La mayoría de las organizaciones que adoptaron este enfoque también
invirtieron en capacidades de respaldo y recuperación, pero no necesariamente por motivos de seguridad; más
bien, estas capacidades mitigaron el riesgo de pérdida de datos. Cuando finalmente fracasó su estrategia de
protección , sus capacidades de copia de seguridad y recuperación fueron su respaldo. Entonces, aunque
estos dos componentes no estaban necesariamente destinados a ser parte de una estrategia coherente de
seguridad cibernética, se implementaron con tanta frecuencia en entornos empresariales que se complementan
muy bien. Si la suposición de que la organización puede protegerse a sí misma de manera efectiva el 100 %
del tiempo, para siempre, resulta ser falsa, entonces pueden restaurar desde la copia de seguridad.
Este enfoque se caracteriza por inversiones principalmente en protección perimetral y de red, así como respaldo y
recuperación. Los profesionales con experiencia en redes podrían extender su experiencia al dominio de la seguridad.
Esto tenía mucho sentido ya que casi el 100% de los ataques ocurrieron usando redes. Para muchas empresas, sus
grupos de redes ampliaron el alcance de sus estatutos para incluir seguridad de red, DMZ y administración de
firewalls.
La Estrategia Proteger y Recuperar tiene algunas ventajas. Tecnologías y disciplinas como TCP/
IP, enrutamiento y conmutación, configuración de firewall y operaciones son áreas que cuentan con una fuerza
laboral capacitada en comparación con otras disciplinas de seguridad, como la seguridad de aplicaciones, la
ingeniería inversa de malware o los equipos rojos y azules. Debido a que es una estrategia relativamente madura,
existe un ecosistema de proveedores y consultoría muy bien desarrollado que tiene décadas de experiencia apoyándolo.
Una fuerza laboral capacitada y este ecosistema hacen de esta estrategia una opción natural para las organizaciones
que se limitan a utilizar principalmente personal de TI y proveedores con los que ya tienen contratos comerciales
para la ciberseguridad.
Por supuesto, esta estrategia también tiene algunas desventajas. La historia ha demostrado que se trata de una
mala estrategia de ciberseguridad. Algunos de ustedes pueden estar en desacuerdo con mi descripción de esta
estrategia, pero no pueden estar en desacuerdo con que, literalmente, en cada infracción importante que apareció
en los titulares en los últimos 20 años, la organización víctima había estado utilizando este enfoque de alguna
manera. La razón por la que este enfoque ha fallado una y otra vez es que su suposición subyacente es
profundamente defectuosa. La suposición de que la organización nunca se verá comprometida porque tendrá un 100
% de éxito en protegerse a sí misma es tremendamente optimista. Hoy en día, las empresas que no invierten en
capacidades de detección y respuesta, además de capacidades de protección y recuperación, podrían considerarse negligentes.
Capítulo 9 339
Reducir el tiempo entre el compromiso y la detección se considera un mantra moderno de ciberseguridad que la
estrategia de protección y recuperación no fue diseñada para adoptar. Posteriormente, las organizaciones que utilizan
esta estrategia pueden tener períodos muy largos entre el compromiso inicial y la detección, a veces cientos de días o
años. Esta estrategia no reconoce que los atacantes tienen una ventaja desproporcionada sobre los defensores; los
defensores necesitan ser perfectos el 100% del tiempo, lo cual es una aspiración poco realista, mientras que los
atacantes solo necesitan ser buenos o afortunados una vez.
Esta estrategia se basa en que los desarrolladores, administradores, proveedores, socios y usuarios no cometan errores
ni tomen decisiones de poca confianza que puedan generar compromisos. Pero como hemos visto durante décadas, los
usuarios, sin saberlo, traerán amenazas a través de capas de defensas perimetrales. Sin capacidades de detección y
respuesta, una vez que se penetra en una organización, los atacantes generalmente pueden persistir indefinidamente,
lo que hace que la recuperación sea una aspiración y costosa.
La buena noticia es que muchas de las organizaciones que usaron la Estrategia de Protección y Recuperación en el
pasado han madurado su enfoque con el tiempo. Todavía emplean esta estrategia, pero la usan en combinación con
otras estrategias. También han actualizado las tecnologías y los productos en los que confían. Hoy en día, los firewalls
de próxima generación van mucho más allá del filtrado de puertos TCP y UDP y pueden realizar una inspección profunda
de paquetes. Pero una pregunta que estas organizaciones aún deben considerar es si sus socios comerciales y socios
de la cadena de suministro aún emplean esta vieja estrategia. Durante muchos años, los atacantes se han dirigido a
socios y proveedores pequeños y menos maduros para obtener acceso a las infraestructuras y los datos de sus grandes
clientes. Pequeñas firmas legales, firmas de marketing y publicidad, e incluso vendedores de calefacción y aire
acondicionado, han sido objeto de este propósito. Muchas pequeñas empresas como estas, en países de todo el mundo,
todavía usan la Estrategia de Protección y Recuperación. En muchos casos, no han invertido en experiencia en
seguridad cibernética relativamente costosa que podría ayudarlos a modernizar sus enfoques.
Puntuación CFSS
¿Qué tan bien mitiga la estrategia Proteger y Recuperar los sospechosos habituales de la ciberseguridad? La tabla 9.3
contiene mis estimaciones de puntuación CFSS:
Fundamentos de ciberseguridad Puntuación (020)
Amenaza interna 0
Puntuación total de CFSS (máx. = 100) 25
Cuadro 9.3: Estimación de la puntuación del CFSS para la estrategia de protección y recuperación
Como habrás deducido de mi descripción de esta estrategia, aunque tiene algunos beneficios, no aborda muy bien los
fundamentos de la ciberseguridad.
Para vulnerabilidades sin parches, le di a esta estrategia 10/20. Esta puntuación refleja que los cortafuegos y la
segmentación pueden dificultar que los atacantes y el malware accedan a las vulnerabilidades explotables que escuchan
en los puertos de la red. Si el tráfico de la red no puede llegar al puerto del servicio vulnerable, entonces no se puede
explotar la vulnerabilidad. Pero esta mitigación no es una condición permanente para una vulnerabilidad explotable. Tan
pronto como un administrador cambia la regla para el filtro de firewall que bloquea el puerto, la vulnerabilidad podría
potencialmente volverse explotable instantáneamente, sin que el administrador lo sepa. Por lo general, los filtros
bloquearán el tráfico entrante no solicitado a un puerto, pero permitirán el tráfico entrante resultante del tráfico saliente
legítimo en el mismo puerto. En las condiciones adecuadas, el servicio o la aplicación podrían verse tentados a realizar
una conexión saliente a un destino bajo el control de los atacantes. Los cortafuegos solo brindan mitigación temporal a
las vulnerabilidades sin parchear, lo que les da a los equipos de administración de vulnerabilidades más tiempo para
encontrar y reparar las vulnerabilidades. El software vulnerable debe desinstalarse del sistema (lo que no se puede hacer
fácilmente para la mayoría de los componentes del sistema operativo) o debe parchearse. La estrategia de protección y
recuperación no se centra en la gestión de vulnerabilidades. Lo mismo es cierto para las configuraciones incorrectas de
seguridad. Esta estrategia no nos ayuda a mitigar por completo estos dos sospechosos habituales de ciberseguridad: lo
mejor que puede hacer es retrasar la explotación. Por esta razón, le di puntos parciales en estos
dos áreas
Esta estrategia no hace nada para abordar las credenciales débiles, filtradas o robadas o la amenaza interna. Por lo tanto,
ambos recibieron una puntuación de cero.
Finalmente, asigné calificaciones parciales a la capacidad de esta estrategia para mitigar la ingeniería social. Los
cortafuegos y las DMZ pueden filtrar las conexiones según las URL y las direcciones IP. Pueden evitar que los usuarios
que son engañados para hacer clic en enlaces maliciosos se conecten a servidores maliciosos conocidos y sitios no
autorizados. El tráfico saliente se puede bloquear y marcar, así como las respuestas entrantes a dicho tráfico saliente. El
desafío ha sido mantenerse al día con los atacantes que usan sistemas comprometidos en todo el mundo para albergar
ataques complejos de múltiples componentes y cambiar constantemente las fuentes y los destinos de los ataques. La
historia nos ha enseñado que este enfoque no mitiga los ataques de ingeniería social de manera muy efectiva.
Capítulo 9 341
Esto se debe a que todavía depende de los usuarios y administradores para tomar decisiones de confianza sólidas, lo
que siempre ha sido un desafío. No obstante, le di calificaciones parciales de ingeniería social por lo que
puede hacer
Con un puntaje total de CFSS de 25 de 100 posibles, claramente, esta estrategia debe usarse en combinación con
otras estrategias para abordar realmente los fundamentos de la seguridad cibernética, así como proporcionar una
base sobre la cual una empresa pueda construir. Muchas organizaciones ya han llegado a esta conclusión y han
desarrollado sus enfoques. Pero es probable que algunas de las organizaciones más pequeñas en su cadena de
suministro aún usen esta estrategia porque carecen de la experiencia y los recursos para evolucionar. ¿Cuántas
pequeñas empresas y consultores independientes todavía confían en los cortafuegos integrados en sus puntos de
acceso inalámbrico para su protección?
Resumen de la estrategia de protección y recuperación

El puntaje total de CFSS para esta estrategia es 25/100. Debe utilizarse en combinación con otras estrategias.
ventajas:
• Gran ecosistema de proveedores para ayudar a las organizaciones a implementar y operar

• Mano de obra relativamente numerosa y capacitada con años de experiencia
Desventajas:
• La historia ha demostrado que esta es una mala estrategia; no invertir en detección y recuperación
capacidades da a los atacantes una ventaja innecesaria
• Los atacantes tienen una ventaja desproporcionada sobre los defensores porque los defensores deben ser
perfecto
• Se basa en que los desarrolladores, administradores y usuarios no cometan errores ni tomen decisiones de
poca confianza que lleven a un compromiso: las personas traen amenazas a través del perímetro y las
propias defensas basadas en el host.
• Una vez penetrados, los atacantes pueden persistir indefinidamente, lo que hace que la recuperación sea una aspiración porque
de la falta de inversión en capacidades de detección y respuesta
Ahora, examinemos una estrategia que no se centre en el perímetro de la red.
Estrategia de protección de puntos finales

A continuación, analizaré otra estrategia relativamente antigua, la estrategia de protección de puntos finales . Esto es lo
que yo llamo una estrategia de “proxy”. La idea aquí es que los puntos finales, como computadoras personales,
dispositivos móviles, algunos tipos de dispositivos IoT, etc., se utilicen para procesar, almacenar y transmitir datos.
Por lo tanto, si protegemos estos puntos finales, estamos, por delegación, protegiendo los datos, que es el punto
central de la protección de datos. Dicho de otra manera, los datos se verán comprometidos si los terminales/
dispositivos están comprometidos, por lo que los terminales deben estar protegidos. Érase una vez, muchas
organizaciones utilizaron esta estrategia por sí mismas para proteger sus activos. La suposición subyacente es
que la protección de puntos finales y dispositivos es un proxy eficaz para proteger los datos de la organización.
La estrategia de protección de endpoints se caracteriza por inversiones en tecnologías de protección de host como
inventario de activos y soluciones de gestión de vulnerabilidades, soluciones antimalware, monitoreo de integridad de
archivos, firewalls basados en host, listas blancas de aplicaciones, protecciones de navegadores web, administración de
dispositivos móviles, administración de configuración empresarial, endurecimiento de endpoints, administración de
dispositivos IoT, detección y respuesta de endpoints (EDR) y detección y respuesta extendidas (XDR), entre muchos
otros. Muchas de estas capacidades ya están integradas en los sistemas operativos Windows y Linux, pero eso no impide
que los proveedores de protección de puntos finales ofrezcan mejores implementaciones de estas características que
normalmente tienen capacidades integradas de administración y generación de informes.
¿Qué es un punto final? Resulta que hay muchas definiciones posibles. En primer lugar, es importante
comprender que los diferentes fabricantes de sistemas operativos permiten diferentes niveles de acceso al
sistema a proveedores de software independientes (ISV) de terceros , lo que puede tener un gran impacto en la
capacidad de sus soluciones. Los proveedores que venden soluciones de protección de terminales tienen sus
propias definiciones que respaldan sus propuestas de valor específicas. Esta solía ser una lista corta de los
principales proveedores de antivirus, pero en los últimos años, la lista ha crecido y los proveedores se han vuelto mucho más diverso
Actualmente, cuento con más de 20 proveedores diferentes que comercializan activamente soluciones de plataforma de
protección de puntos finales. Estos incluyen (en orden alfabético): BitDefender, BlackBerry Cylance, Check Point, Cisco,
CrowdStrike, Cybereason, ESET, Fortinet, FSecure, Kaspersky, Malwarebytes, Mic rosoft, Palo Alto Networks, Panda
Security, SentinelOne, Sophos, Symantec, Trellix, Trend Micro, VMware Carbon Black y Webroot. Hay muchos otros
proveedores en este espacio, incluidos proveedores regionales en China, entre otros.
Algunos de estos proveedores cuentan con laboratorios de antivirus con décadas de experiencia, mientras que otros
aprovechan las adquisiciones de empresas de seguridad y las innovaciones de otras áreas para intentar revolucionar el
mercado de la protección de endpoints. Muchos proveedores incluyen capacidades de análisis, respuesta y nube como parte de
sus soluciones.
Habiendo trabajado en un laboratorio antimalware y en un equipo de respuesta a incidentes de seguridad, aprecio este
enfoque. Los puntos finales son donde ocurre la mayor parte de la acción durante una violación de datos.
No importa qué tan buenos sean los productos de los proveedores de firewall e IDS, simplemente no tienen el mismo
punto de vista que el dispositivo de punto final típicamente tiene.

Capítulo 9 343
Puedes ver a los peces mucho mejor cuando estás en la pecera que mirando desde afuera . Las soluciones instaladas
directamente en los puntos finales permiten el monitoreo continuo y una variedad de acciones automatizadas cuando se
activan los factores desencadenantes. Los motores de análisis de protección de puntos finales son algunas de las hazañas
de programación más impresionantes del mundo. Estos motores están diseñados para desempaquetar numerosos
formatos de compresión y ofuscación de archivos que pueden anidar los atacantes, en entornos informáticos virtuales que
simulan sistemas operativos reales, a fin de determinar si los archivos son

malicioso casi en tiempo real.
Las amenazas pueden estar basadas en archivos, macros, secuencias de comandos, virus polimórficos, virus de arranque,
rootkits, etc., en diferentes sistemas operativos y sistemas de archivos. Por supuesto, tienen muchas más funciones,
como heurística, análisis de comportamiento, protecciones del navegador, filtrado de direcciones IP maliciosas y mucho,
mucho más. Cuando profundiza en la funcionalidad de algunas de estas soluciones de protección de puntos finales y
considera lo difícil que es desarrollarlas y mantenerlas actualizadas, son súper impresionantes.
Sin embargo, la ingeniería por sí sola no es suficiente. Estas soluciones son tan buenas como los laboratorios de
investigación y respuesta que las cuidan y alimentan. Mantener masas críticas de grandes investigadores, analistas y
personal de apoyo es una función importante que brindan estos proveedores. La combinación de una ingeniería
impresionante y un laboratorio de investigación y respuesta de clase mundial es la clave para seleccionar un proveedor
eficaz de protección de endpoints. El gran ecosistema de proveedores que describí anteriormente es muy positivo. Esto
se debe a que crea una competencia saludable y estos proveedores se mantienen honestos entre sí al apoyar las pruebas
de terceros (avtest.org y avcomparatives.org, entre otros) y las conferencias de la industria (Conferencia internacional
anual de Virus Bulletin (Virus Bulletin, sin fecha)) donde discuten cómo gobernar su industria, entre otras cosas.
Pero, por supuesto, este enfoque también tiene desafíos. La historia nos ha enseñado que la estrategia de protección de
endpoints , por sí sola, es insuficiente. ¿Alguna de las víctimas de violaciones masivas de datos que han aparecido en los
titulares en los últimos 10 años no ha estado ejecutando soluciones de protección de puntos finales? En primer lugar,
depender de un paciente para diagnosticarse y curarse a sí mismo es un enfoque optimista. Una vez que la base
informática confiable de un sistema se ha visto comprometida, ¿cómo pueden las soluciones de protección de endpoints
usarla de manera confiable para detectar amenazas en el sistema y limpiarlas? Las soluciones de protección de puntos
finales han sido el objetivo de los atacantes y su malware durante décadas. Una de las primeras cosas que hacen muchas
familias de malware después de comprometer inicialmente un sistema es deshabilitar o subvertir la solución de protección de punto final.
Aquí es donde los servicios de atestación remota pueden ayudar, pero según mi experiencia, pocas organizaciones
utilizan dichos servicios debido a su complejidad. Algunos proveedores utilizan la virtualización y otras técnicas para
proteger sus soluciones de los atacantes. Pero tenga la seguridad de que los atacantes continuarán investigando formas
de subvertir las soluciones de protección de puntos finales.

El campo de juego nunca está nivelado en este juego. Los atacantes pueden comprar todas las soluciones de endpoint
disponibles en el mercado y probar su malware y herramientas, antes de atacar con ellos, para asegurarse de que
ninguna solución pueda detectarlos o limpiarlos. Los proveedores de protección de terminales no tienen la misma ventaja.
Pero, más fundamentalmente, ¿se puede realmente confiar en que el paciente se cure a sí mismo? Algunas
organizaciones limpiarán los sistemas comprometidos con soluciones de punto final y les permitirán continuar
ejecutándose en producción, mientras que otras tienen políticas para aplanar y reconstruir cualquier sistema que haya
sido comprometido. La virtualización ha hecho esto más fácil y la nube, como discutiré en detalle más adelante, lo hace
aún más fácil y efectivo. Pero la clave de este enfoque sigue siendo la detección precisa de amenazas.
Tenga en cuenta que aunque el objetivo al que aspiran todas estas soluciones es detectar, bloquear y, si es necesario,
limpiar el 100 % de las amenazas, esto no es realista. Los objetivos internos de los laboratorios de investigación y
respuesta suelen ser más realistas y alcanzables. Por ejemplo, la detección del 100 % de las amenazas en el
"zoológico" (su biblioteca privada de malware) es probablemente un objetivo común entre estos proveedores. Pero los
objetivos de detección de amenazas emergentes podrían ser del 80 %. Después de todo, los laboratorios de investigación
y respuesta necesitan tiempo para obtener muestras de amenazas, procesarlas e implementar las protecciones
adecuadas para sus clientes, especialmente cuando los atacantes utilizan la automatización masiva para generar millones de ellas constantem
¿Te embarcarías en un submarino que tuviera como objetivo mantener el 80% del agua fuera del casco?
Probablemente no. Pero como escribí en el Capítulo 4, La evolución del malware, si no usa la protección de endpoint
porque no protege el endpoint del 100 % de las amenazas, entonces no está protegiendo los endpoints de los millones
de amenazas contra las que las soluciones de protección de endpoint sí protegen.
Puntuación CFSS
Veamos cómo la estrategia de protección de endpoints ayuda a las organizaciones a abordar los fundamentos de la
ciberseguridad. La tabla 9.4 contiene mis estimaciones de puntuación CFSS. Recuerde que estas son solo estimaciones
basadas en mi experiencia y no reflejan el estado del arte en la protección de endpoints.

Capítulo 9 345
Siéntase libre de desarrollar sus propias estimaciones si cree que estoy muy equivocado con las mías:
Amenaza interna 10
Tabla 9.4: Estimación de la puntuación CFFS para la estrategia de protección de endpoints
Le di a esta estrategia la máxima puntuación por mitigar las vulnerabilidades sin parchear y las malas configuraciones
de seguridad . La combinación de inventario, escaneo, actualización, fortalecimiento y monitoreo puede ser muy efectiva.
Para credenciales débiles, filtradas y robadas, calculé que la protección de endpoints mitigaba 15/20. Las organizaciones
que usan estaciones de trabajo de acceso seguro o estaciones de trabajo de acceso privilegiado (puntos finales
reforzados para ataques que buscan específicamente credenciales de administrador en caché) como parte de su
estrategia de puntos finales pueden mitigar este tipo de amenaza en gran medida, pero no completamente.
Las soluciones de protección de endpoints también pueden ayudar a mitigar parcialmente la ingeniería social, así como
las amenazas internas, al dificultar que los usuarios y administradores cometan algunos de los errores comunes y las
decisiones de poca confianza que conducen al compromiso, pero no mitigarán por completo a los internos malintencionados.
Aunque la estrategia de protección de endpoints es insuficiente por sí misma, sería difícil imaginar una estrategia de
ciberseguridad empresarial exitosa que no la usara en combinación con otras estrategias.
Parece que la industria está de acuerdo con esta evaluación, ya que cada vez más organizaciones con las
que he hablado han adoptado o planean adoptar Orquestación, Automatización y Respuesta de Seguridad.
(SOAR) soluciones. Algunos proveedores describen a SOAR como un paso evolutivo en la protección de puntos finales
en el sentido de que combina la funcionalidad de una pila de capacidades diferentes, incluida la protección y respuesta
de puntos finales.
Resumen de la estrategia de protección de endpoints

El puntaje total de CFSS para esta estrategia es 75/100. Debe utilizarse en combinación con otras estrategias.
ventajas:
• Visibilidad y control superiores que se ejecutan en el punto final
• Gran ecosistema de proveedores para ayudar con décadas de experiencia
• Investigación constante de amenazas, respuesta y tecnologías en evolución para adelantarse a los atacantes
Desventajas:
• La historia ha demostrado que esta es una mala estrategia en sí misma, ya que no evitó que muchos de los principales
violaciones de datos que han estado en los titulares.
• Los usuarios se resisten a los sistemas que son demasiado restrictivos o afectan la productividad; los individuos traen
amenazas a través de sus propias defensas en muchos casos. Este enfoque solo puede mitigar parcialmente los
errores o las decisiones de poca confianza que los desarrolladores, administradores y usuarios toman y que conducen
al compromiso.
• La velocidad es un factor. Los procesos de gestión de vulnerabilidades relativamente lentos y complicados dan una ventaja
a los atacantes. Las organizaciones que tienen una buena estrategia de endpoint pero implementan actualizaciones
de seguridad y otras protecciones aceptan más riesgos con relativa lentitud.
• Las suites de protección de puntos finales tienen un historial de rendimiento inconsistente y objetivos de rendimiento
aspiracionales. Es posible que las organizaciones que no comprendan los objetivos internos de los proveedores de
protección de endpoints no comprendan completamente los riesgos asociados.
• La gestión de la seguridad de los endpoints se basa en capacidades de gestión e inventario

de activos precisas y oportunas . Esto ha sido notoriamente difícil en entornos locales. lo haré
discuta cómo la nube hace esto más fácil más adelante.
• Muchas organizaciones permiten que los empleados utilicen equipos portátiles, equipos de escritorio y dispositivos móviles
personales no administrados o parcialmente administrados, lo que se conoce como la estrategia Traiga su propio
dispositivo (BYOD) . Posteriormente, es posible que no se comprenda completamente el riesgo asociado con la
transmisión, el almacenamiento y el procesamiento de datos corporativos en estos dispositivos.
• Es posible que el enrutamiento, la conmutación, el almacenamiento, la IoT y otros dispositivos de hardware no estén integrados en
la estrategia de protección de endpoints de una organización , pero debería serlo.
Esa es la estrategia de protección de puntos finales. Ahora, pasemos a las estrategias de seguridad que implican el control
físico y las autorizaciones de seguridad.

Capítulo 9 347
Control físico y habilitaciones de seguridad como estrategia de

seguridad
Veo el uso generalizado de esta próxima estrategia, especialmente por parte de organizaciones del sector
público. Llamo a esta estrategia la Estrategia de Control Físico y Autorizaciones de Seguridad . Como
probablemente pueda deducir por el nombre, se basa en tener el control físico de la infraestructura utilizada para
transmitir, almacenar y procesar datos, así como la clasificación de datos y las autorizaciones de seguridad
asociadas. La idea detrás de esta estrategia es que no todos los datos tienen el mismo valor relativo para la
organización que los controla. Al clasificar los datos en diferentes categorías que reflejan el valor relativo de los
datos, podemos garantizar que los datos más valiosos estén protegidos de manera acorde con ese valor.
Hay muchos esquemas de clasificación de datos diferentes en uso en los sectores público y privado; muchas
organizaciones han desarrollado sus propios esquemas de clasificación de datos. No tenemos que mirar más
allá del gobierno federal de los EE. UU. para ver un gran ejemplo de un esquema de clasificación de datos que
se ha implementado a gran escala. La Orden Ejecutiva 13526 (Oficina de Publicaciones del Gobierno de los
Estados Unidos , 2009) define un sistema de tres niveles para clasificar la información de seguridad nacional.
Define esos tres niveles como alto secreto, secreto y confidencial. Otro ejemplo similar es la clasificación de
seguridad del gobierno del Reino Unido para proveedores externos (Oficina del Gabinete del Reino Unido, 2013).
También define tres clasificaciones que indican la sensibilidad de la información. Estas categorías incluyen Alto
secreto, Secreto y Oficial. Hay muchos otros ejemplos de esquemas de clasificación de datos.
Las políticas de clasificación de datos como estas pueden dictar las personas, los procesos y las tecnologías
que deben emplearse para manejar los datos en cada categoría. Como tal, el número y la naturaleza de las
categorías en los esquemas de clasificación de datos que adoptan las organizaciones pueden tener un gran
efecto en las culturas, prácticas de reclutamiento, inversiones en TI y presupuestos de las organizaciones, entre otras cosas.
Aquí es donde las autorizaciones de seguridad pueden convertirse en un factor. Para algunas organizaciones,
para que el personal tenga acceso a la información que ha sido clasificada en una categoría específica, ese
personal debe tener una autorización de seguridad vigente que permita el acceso a la información en esa
categoría. Por ejemplo, si alguien no tiene una autorización que permita el acceso a datos clasificados como
secretos, entonces no se le debe otorgar acceso a información clasificada como secreta. Para obtener una
autorización de seguridad, puede haber verificaciones de antecedentes involucradas, algunas de las cuales son
mucho más profundas y complicadas que otras.
Por ejemplo, algunas autorizaciones de seguridad requieren una verificación de antecedentes penales. Otras verificaciones
de antecedentes más profundas requieren una verificación de antecedentes penales, una verificación de antecedentes
laborales y una verificación de puntaje de crédito financiero , además de que el solicitante proporcione referencias
personales, quienes serán entrevistados como parte del proceso de verificación de antecedentes. Algunas autorizaciones
de seguridad tienen requisitos de ciudadanía específicos. Algunas autorizaciones tienen un proceso único por el que pasan
los solicitantes, mientras que otras autorizaciones deben renovarse periódicamente. Algunos proveedores de tecnología
brindan a sus clientes información sobre las verificaciones de antecedentes a las que someten a sus empleados. Microsoft
es un ejemplo; han publicado una descripción general de la gestión de personal (Microsoft Corporation, 2023).
Tal vez se pregunte por qué los empleadores simplemente no realizan todos estos controles periódicamente como algo
normal. Diferentes países y jurisdicciones tienen leyes laborales locales y reglamentos estatutarios que protegen la
privacidad y los derechos de los empleados. Por ejemplo, en los EE. UU., demasiadas verificaciones de crédito pueden
reducir el puntaje de crédito de una persona. Permitir que los empleadores instituyan procedimientos administrativos que
potencialmente impacten negativamente a los empleados actuales o potenciales no está bien. Tenga en cuenta que
muchos esquemas de clasificación de datos no requieren autorizaciones de seguridad, ya que están diseñados para
proporcionar simplemente una manera para que el personal que maneja los datos comprenda cómo deben manejarse.
Desde una perspectiva de seguridad, las organizaciones que se toman en serio este enfoque esencialmente intentan crear
un sistema cerrado para sus datos que tenga un alto nivel de garantía de seguridad. Las personas que manejan datos,
especialmente datos confidenciales, serán examinadas para minimizar la probabilidad de que tengan intenciones maliciosas
o que puedan ser fácilmente sobornadas o chantajeadas para violar las políticas de su organización.
Este concepto de aseguramiento también se extiende a sus procesos y tecnología. Por ejemplo, algunas organizaciones
tienen políticas que dictan que los datos solo serán transmitidos, almacenados y procesados por hardware y software que
hayan pasado por sus procesos de certificación. Todos los demás dispositivos electrónicos nunca se permiten en sus
entornos locales. Esto incluye cualquier cosa que tenga un cable de alimentación o una batería.
Los procesos comerciales que utilizan estos empleados examinados para operar sus sistemas certificados están
cuidadosamente diseñados para garantizar la auditabilidad y garantizar que participen varias personas, para que todos
sean honestos. Las suposiciones subyacentes que hacen que este sistema cerrado funcione son que la organización tiene
un control de extremo a extremo de toda su infraestructura y que su cadena de suministro está sujeta a autorizaciones de
seguridad y procesos de certificación. Numerosos proveedores de TI de confianza participan en este tipo de cadenas de
suministro en países de todo el mundo.
La esencia de esta estrategia se remonta a décadas, si no siglos, cuando ha sido muy empleada por militares y
organizaciones de seguridad nacional en todo el mundo. Por supuesto, ha habido fallas en la seguridad nacional a lo largo
de la historia, lo que nos dice que este enfoque no es infalible. En los tiempos modernos, este modelo ha ido evolucionando.
Capítulo 9 349
Funciona bien a pequeña escala, pero se vuelve cada vez más difícil de administrar a medida que se amplía. A medida
que sus operaciones escalaban, se hizo más difícil para estas organizaciones administrar toda su TI internamente. Los
tipos de organizaciones que utilizan este modelo enfrentan los mismos recursos de TI y desafíos de reclutamiento que
otras industrias.
Posteriormente, muchos de ellos han subcontratado gran parte de su TI para hacer frente a estos desafíos. En muchos
casos, esto significa que los contratistas que utilizan para administrar su TI tienen acceso físico a los centros de datos
y servidores que procesan sus datos.
Más específicamente, en el curso de su trabajo, estos contratistas tienen acceso a los sistemas operativos e hipervisores
que se ejecutan en esos servidores, las cargas de trabajo virtualizadas y los datos en esas cargas de trabajo. Pero la
organización propietaria de los datos debe mantener su sistema cerrado para proteger los datos, esa es su estrategia.
Debido a que los contratistas tienen acceso potencial a datos clasificados, requieren las mismas autorizaciones de
seguridad que el personal regular de la organización. Los centros de datos del contratista y la infraestructura de TI en
ellos también deben pasar por los procesos de certificación de la organización. Dado que todo esto es complicado y
muy costoso de lograr, para que sea económicamente viable, los contratos entre estas organizaciones y contratistas
calificados tienden a ser de muy largo plazo, a veces de 10, 20 o incluso 30 años de duración. Este modelo de
proveedor de servicios gestionados es la forma en que la TI se ha subcontratado a estas organizaciones durante los
últimos 20 años o más. Por supuesto, hay un montón de ventajas y desventajas en el uso de proveedores de servicios
administrados; Me referiré a algunos de estos más adelante.
Para recapitular, el enfoque de la estrategia de autorizaciones de seguridad y control físico es la garantía de seguridad
del hardware y el software, y las verificaciones periódicas de antecedentes del personal y los administradores del centro
de datos . Se caracteriza por inversiones en personas, procesos y tecnologías que ayudan a mantener la seguridad
física, la garantía y la confianza en el carácter del personal y los administradores del centro de datos. La clasificación
de datos también suele desempeñar un papel fundamental para ayudar a proteger los datos más importantes. Este
enfoque tiene numerosos beneficios. Algunos gobiernos literalmente tienen cientos de años de práctica usando este
tipo de estrategia. Sin embargo, puede ayudar a mitigar parcialmente las amenazas internas mediante la identificación
de candidatos y personal potencialmente riesgosos que podrían tener acceso a datos confidenciales. La verificación o
certificación de terceros de la confiabilidad del hardware y el software contribuye a la garantía de seguridad y ayuda a
demostrar la diligencia debida. Existe un gran ecosistema de proveedores para ayudar a las organizaciones que desean
seguir este tipo de estrategia.
Por supuesto, esta estrategia también tiene algunas desventajas y limitaciones importantes. Primero, la clasificación de
datos es un desafío para la mayoría de las organizaciones. El uso de la clasificación de datos puede ser muy útil para
las organizaciones que desean asegurarse de que sus datos más confidenciales estén protegidos adecuadamente.
Tratar todos los datos como si tuvieran el mismo valor relativo para la organización es la forma más costosa de
administrar los datos. Pero los esquemas de clasificación de datos son notoriamente difíciles de implementar con
éxito en organizaciones grandes. En mi experiencia, las organizaciones que tienen más éxito con las clasificaciones
de datos son aquellas organizaciones donde la seguridad está profundamente arraigada en la cultura. Las
organizaciones militares y paramilitares, las fuerzas del orden, los departamentos de defensa nacional y las
agencias de inteligencia son algunos ejemplos de organizaciones en las que la clasificación de datos está
profundamente arraigada en la cultura, las personas, los procesos y las tecnologías de apoyo. Para estas
organizaciones, normalmente existe literalmente un riesgo para la vida humana si la clasificación de datos no se administra correctame
Muchas organizaciones comerciales han intentado y fallado, algunas veces, en instituir esquemas de clasificación
de datos. El desafío típico para estas organizaciones es encontrar una forma de clasificar los datos que no dificulte
o imposibilite el trabajo de los trabajadores de la información. Las organizaciones que permiten que las mismas
personas que crean los datos clasifiquen los datos generalmente terminan con grandes cantidades de datos
sobreclasificados o subclasificados, según las consecuencias para los empleados. Por ejemplo, en organizaciones
militares, la subclasificación de datos podría tener graves consecuencias, como la pérdida de la vida y/o cargos
penales. Los datos en estas organizaciones tienden a sobreclasificarse porque es mejor prevenir que curar a los
trabajadores; rara vez se meten en problemas por sobreclasificar los datos, a pesar de los inmensos costos
adicionales cuando todos en una gran organización hacen esto habitualmente.
En organizaciones donde no hay consecuencias de vida o muerte o preocupaciones de seguridad nacional, los
datos pueden subclasificarse más fácilmente, lo que facilita que los trabajadores de la información realicen su
trabajo. Los ejecutivos de algunas de estas organizaciones creen que las reglas no se aplican a ellos y exigen
acceso ad hoc a cualquier información que necesiten, independientemente de cómo se clasifique o por qué. Esta
es una de las razones por las que a menudo son el objetivo de esquemas de Business Email Compromise y otros
ataques de ingeniería social. Pueden obtener acceso a cualquier dato y, a menudo, están exentos de los
inconvenientes controles de seguridad que mitigan tales ataques. Una receta para el desastre que a menudo se realiza.
Por supuesto, en ninguno de estos escenarios, donde los datos están subclasificados o sobreclasificados, la
clasificación de datos cumple su promesa. Algunas organizaciones comerciales y del sector público deciden no
instituir esquemas de clasificación de datos porque sus intentos anteriores de hacerlo fracasaron o no lograron
los objetivos deseados. En cambio, estas organizaciones han llegado a la conclusión de que la clasificación de
datos es demasiado compleja y costosa para que valga la pena. Para ellos, es más fácil y efectivo tratar todos
sus datos como si tuvieran el mismo valor. Algunos de ellos emplearán esquemas de clasificación de datos muy
simples y menos formales al marcar algunos documentos y datos como confidenciales o solo internos.
Pero los requisitos de protección de datos son los mismos para todos sus datos.
Capítulo 9 351
Tenga en cuenta que en muchas organizaciones, el único sistema que normalmente almacena, procesa y transmite los datos de
todas las clasificaciones es el correo electrónico. Es relativamente raro que las organizaciones tengan dos sistemas de correo
electrónico separados: un sistema de correo electrónico para datos no clasificados y otro para datos clasificados. Posteriormente ,
los datos de todas las clasificaciones pueden terminar en correos electrónicos, lo que puede convertirse en una fuente de fuga de datos.
La residencia de datos suele ser un requisito para las organizaciones que adoptan esta estrategia de seguridad. Es decir, requieren
que todos los centros de datos que procesan y almacenan sus datos deben estar ubicados en un país o jurisdicción específica.
Por ejemplo, todos los datos de un departamento del gobierno federal deben permanecer dentro de las fronteras nacionales del
país. Hay algunas razones diferentes para los requisitos de residencia de datos, pero la más común citada es que la residencia de
datos proporciona una mejor seguridad para los datos y que la organización requiere soberanía de datos, que probablemente no
tendrán dentro de las fronteras de otro país. Para mantener su sistema cerrado, no pueden arriesgarse a colocar un centro de
datos en una ubicación sobre la que otro gobierno tiene control soberano.
La residencia de datos no mitiga ninguno de los sospechosos habituales de ciberseguridad. Esto se debe a que el 99 % de los
ataques ocurren de forma remota a través de la red, independientemente de la ubicación física del centro de datos.
A los atacantes no les importa dónde se encuentra físicamente el centro de datos porque eso no es una mitigación efectiva para la
gran mayoría de los ataques.
Esta es la razón por la que muchas organizaciones que adoptan la estrategia de autorizaciones de seguridad y control físico
poner “brechas de aire” en sus redes. Dicho de otra manera, sus redes no están conectadas directamente a Internet. He visto
organizaciones intentar lograr espacios de aire de varias maneras. Algunos simplemente no obtienen conectividad a Internet de un
ISP. Algunos usan diodos de datos que están certificados para permitir que el tráfico de red fluya solo en una dirección. Algunas
organizaciones llaman a una red "sin aire" cuando está detrás de una DMZ con reglas de firewall muy específicas. Con el tiempo,
puede ser increíblemente difícil lograr y mantener una red con un verdadero espacio de aire . La ubicuidad de los dispositivos
móviles, los dispositivos IoT y los equipos de oficina comunes, como las fotocopiadoras que quieren llamar a casa con información
de inventario y servicio, hace que sea un desafío mantener una red desconectada. Algunas organizaciones mantienen dos redes,
una para información clasificada y otra para información no clasificada.
Los trabajadores de la información en estos entornos suelen tener dos computadoras en sus escritorios, una conectada a cada
una de estas redes. Algunas de las organizaciones que utilizan redes airgapped requieren que todos los dispositivos móviles,
computadoras portátiles y dispositivos electrónicos se guarden en casilleros en la puerta principal de sus instalaciones. He visitado
muchos de estos tipos de instalaciones en todo el mundo a lo largo de los años, asesorando a clientes del sector público.
Las organizaciones que logran y mantienen redes airgapped pueden hacer que sea mucho más difícil para los
atacantes aprovechar los sospechosos habituales de ciberseguridad para comprometer inicialmente sus redes.
Sin embargo, como han demostrado el ataque de Stuxnet y tantos otros ataques a redes airgapped a lo largo
de los años , no es un desafío insuperable. Además, la residencia de datos es mucho menos efectiva que otros
controles disponibles que ayudan a mitigar los riesgos que estas organizaciones tienen en mente con sus
requisitos de residencia de datos. El cifrado y la gestión eficaz de claves son los principales entre estos controles,
como lo discutí en el Capítulo 7, Acceso gubernamental a los datos. Al aprovechar las tecnologías modernas de
encriptación y administración de claves, las organizaciones pueden lograr una protección de datos muy sólida al
tiempo que ponen en funcionamiento los datos para que puedan ayudarlos a tomar mejores decisiones más rápido.
Quizás el mayor desafío para la estrategia de control físico y autorizaciones de seguridad es que el mundo ha
cambiado en algunos aspectos clave, todo lo cual hará que esta estrategia sea más difícil de seguir y menos
efectiva a medida que pase el tiempo. Las organizaciones que actualmente usan estrategias como esta están
siendo desafiadas de varias maneras.
Por ejemplo, la mayoría de las organizaciones de hoy quieren aprovechar el aprendizaje automático y la
inteligencia artificial. Tendrán el desafío de hacer esto de una manera escalable en sus entornos de TI acreditados
en las instalaciones, con brechas de aire o a través de los centros de datos de sus proveedores de servicios
administrados tradicionales. Para mantenerse al día con sus adversarios, muchos de los cuales no están sujetos
a los mismos procesos de certificación y acreditación, las organizaciones tendrán que cambiar la forma en que
adquieren y operan los servicios de TI. Para hacer esto, tendrán que renunciar a parte del control de extremo a
extremo que han tenido durante décadas. Sus sistemas cerrados tendrán que evolucionar. Para algunas de estas
organizaciones, este tipo de cambio es muy difícil porque inicialmente es incómodamente diferente de cómo han
hecho la gobernanza, el riesgo y el cumplimiento durante las últimas décadas. Esto no significa que tengan que
conformarse con un entorno de TI menos seguro, pero sí deben reevaluar cómo mitigar los riesgos que les
preocupan en un mundo en el que no poseen la infraestructura de principio a fin. El aumento de los costos de TI
en las instalaciones para mantener el statu quo, frente a un tsunami tras otro de innovación en la nube, significa
que las organizaciones que emplean este tipo de estrategia evolucionarán con éxito o se volverán cada vez más
irrelevantes.
Puntuación CFSS
Miremos la Tabla 9.5 : ¿qué tan bien ayuda la estrategia de autorizaciones de seguridad y control físico a abordar
los fundamentos de la seguridad cibernética? Estimaré puntajes para dos sabores de esta estrategia, uno con
una red con espacio de aire y otro sin una red con espacio de aire. Como verá, esto hace una gran diferencia en
términos de puntajes.
Capítulo 9 353
Amenaza interna 10
Cuadro 9.5: Estimación de la puntuación del CFSS para la estrategia de autorización de seguridad y
control físico con una red con espacio de aire
Ninguno de los atributos de esta estrategia, como la clasificación de datos, las autorizaciones de seguridad o el
control de extremo a extremo del hardware certificado, ayudan a mitigar por completo las vulnerabilidades sin
parches, las configuraciones incorrectas de seguridad y las contraseñas débiles, filtradas o robadas. Al igual que
la estrategia de protección y recuperación, una red aislada puede dar a los equipos de seguridad más tiempo para
abordar estos sospechosos habituales de ciberseguridad, pero aún deben abordarse. Las credenciales débiles,
filtradas y robadas son más difíciles de usar si no hay acceso de red remoto a la red de destino. Si el principio de
privilegio mínimo se aplica de manera precisa y consistente, esto puede dificultar el acceso no autorizado a datos confidenciales.
Como mencioné anteriormente en este capítulo, la clasificación de datos y las autorizaciones de seguridad pueden
ayudar a mitigar las amenazas internas, en particular las internas malintencionadas. Pero no mitiga por completo
a los usuarios y administradores que cometen errores o toman malas decisiones de confianza que conducen a
compromisos. Debido a esto, le di calificaciones parciales por amenazas internas e ingeniería social. Este enfoque
parece estar optimizado para mitigar el acceso ilegal del gobierno a los datos, como el espionaje militar y
económico. Para muchas de las organizaciones que he asesorado que usan esta estrategia, este es definitivamente
un riesgo real para ellas, quizás su riesgo de mayor prioridad. Pero claramente, este no es el único riesgo de alta
prioridad que necesitan mitigar.
He visto organizaciones que usan esta estrategia sin implementar una red de espacios de aire. Sin la red air
gapped, confiar en la clasificación de datos, las autorizaciones de seguridad y el hardware certificado de extremo
a extremo es mucho menos efectivo para abordar los fundamentos de la ciberseguridad:

Amenaza interna 10
Cuadro 9.6: Estimación de la puntuación del CFSS para la estrategia de control físico y autorizaciones de seguridad
sin una red airgapped
Para mitigar realmente los sospechosos habituales de ciberseguridad, ya sea que se use o no
una red airgapped , este enfoque debe usarse en combinación con otras estrategias de
ciberseguridad. Me he reunido con muchas organizaciones que ya saben esto y han estado
buscando estrategias complementarias durante años. Pero las culturas de muchas de estas
organizaciones les dificultan adoptar nuevos enfoques y tecnologías; para acuñar una frase,
tienen un enfoque glacial en una era de calentamiento global absoluto. Internet y la nube han
democratizado la TI, brindando a todos capacidades que antes no tenían. El desafío para las
organizaciones que han utilizado esta estrategia durante años o décadas es adaptar su enfoque
actual lo suficientemente rápido, todo para permitirles mitigar una mayor cantidad de adversarios con buenos recurs
Resumen de la estrategia de autorizaciones de seguridad y control físico

La puntuación total estimada de CFSS para esta estrategia, utilizando redes con espacios de aire, es 55/100. Para las
organizaciones que usan esta estrategia, pero sin una red airgapped efectiva, mi estimación del puntaje total de CFSS
es 20/100. Mi conclusión es que esta estrategia debe usarse junto con otras estrategias de ciberseguridad para abordar
completamente los fundamentos de la ciberseguridad.
ventajas:
• Los militares y los gobiernos tienen cientos de años de práctica utilizando enfoques similares
• Las redes airgapped pueden ayudar a mitigar parcialmente algunos de los sospechosos habituales de ciberseguridad
• Ayuda a mitigar parcialmente la amenaza interna, incluido el acceso ilegal del gobierno a los datos, al
dificultando el éxito de los infiltrados maliciosos
• La verificación/certificación de hardware por parte de terceros contribuye a la garantía de seguridad y
ayuda a demostrar la debida diligencia
• Tiene un gran ecosistema de proveedores para ayudar a las organizaciones que siguen este enfoque
Desventajas:
• Los costos enormes suelen estar asociados con el tipo de infraestructura certificada que suele
aprovechado con este enfoque

Capítulo 9 355
• La suposición subyacente de que la residencia de datos proporciona una mayor seguridad no es válida
• Dado que la mayoría de los ataques se perpetran de forma remota sin acceso físico al hardware e independientemente de la
ubicación física de los datos, el éxito de este enfoque depende en gran medida de los espacios de aire de la red para
mitigar parcialmente los sospechosos habituales de ciberseguridad.
• Los datos en entornos altamente restrictivos y con brechas de aire pueden ser más difíciles de poner en funcionamiento
• No mitiga por completo la amenaza interna porque se enfoca en mitigar a los internos malintencionados, lo que no incluye los
errores que cometen los internos no malintencionados que conducen a resultados de seguridad deficientes.
• Da a los atacantes una ventaja porque pueden usar nuevas tecnologías más rápido que los defensores
Ahora, avancemos y consideremos cómo algunas organizaciones utilizan el cumplimiento como una estrategia de seguridad.
El cumplimiento como estrategia de seguridad

El cumplimiento y la ciberseguridad son dos disciplinas diferentes que se superponen ligeramente. El cumplimiento generalmente
se enfoca en probar que una organización cumple con los requisitos definidos en los estándares regulados, de la industria y/o
internos. El cumplimiento puede ser útil de muchas maneras, la principal de ellas sería para fines de seguro de ciberseguridad y
demostrar la debida diligencia para limitar la responsabilidad. Esto es diferente de la ciberseguridad, que se enfoca en identificar,
proteger, detectar, responder y recuperar (NIST, nd). Pero he visto a muchas organizaciones fusionar estas diferentes disciplinas
porque se superponen, como se ilustra en la figura 9.2. He visto ilustraciones similares en las que el cumplimiento es un subconjunto
de la ciberseguridad o viceversa. Creo que se pueden presentar argumentos a favor de todos estos enfoques. El enfoque que han
adoptado algunas organizaciones con las que he discutido esto es rotar los dos círculos en la Figura 9.2 uno encima del otro y fingir
que son lo mismo.
Eso no quiere decir que las organizaciones no puedan alinear sus esfuerzos para lograr tanto el cumplimiento como la
ciberseguridad. Esto es lo que la mayoría de las organizaciones deben hacer, pero muchas no lo hacen.
Figura 9.2: Las disciplinas de cumplimiento y seguridad se superponen pero son diferentes
Descubrí que hay una variedad de razones por las que las organizaciones combinan el cumplimiento y la
ciberseguridad. Primero, algunas normas reguladas tienen sanciones por incumplimiento o multas asociadas
con ellas. Esto proporciona un incentivo para que las organizaciones demuestren que cumplen con estos
estándares e inviertan en programas de cumplimiento. Pero dado que la mayoría de las organizaciones tienen
limitaciones de recursos, muchas de ellas creen que se ven obligadas a decidir si utilizar sus recursos en
cumplimiento o ciberseguridad. En algunos casos, las organizaciones terminan usando esta estrategia porque su
organización de cumplimiento bien intencionada y con buenos recursos funciona en exceso. Es decir, extienden
sus esfuerzos más allá de demostrar que cumplen con los estándares aplicables, para realizar funciones que
normalmente vería realizar un equipo de seguridad. No hay nada de malo en esto per se, pero debemos
reconocer que su área de especialización y el centro de gravedad de su programa es el cumplimiento. Algunas
de las organizaciones que he visto usar esta estrategia lo hacen simplemente porque su programa de
cumplimiento es más antiguo y más maduro que su programa de ciberseguridad; han tenido obligaciones de
cumplimiento durante años o décadas en su industria, y la ciberseguridad es una inversión relativamente nueva para ellos.
La suposición subyacente de esta estrategia es que cumplir con las obligaciones de cumplimiento es suficiente
para proteger los datos de la organización. Posteriormente, la atención se centra en cumplir con las obligaciones
de cumplimiento normativo, industrial e interno de la organización, y demostrarlo en las auditorías.
Estos pueden incluir estándares como PCI, HIPAA, GDPR, estándares NIST, estándares ISO o los estándares
internos de seguridad de TI de una organización, entre otros. Esta estrategia se caracteriza por inversiones en
personas, procesos y tecnologías que ayudan a las organizaciones a cumplir con sus obligaciones de
cumplimiento. Esto generalmente se manifiesta como conjuntos de control bien definidos y procesos repetibles
que se auditan periódicamente.
Esta estrategia puede ser muy ventajosa, saludable y positiva para las organizaciones que no cuentan con una
estrategia de ciberseguridad o prácticas de gobierno maduras. La mayoría de los estándares relacionados con
la seguridad regulados que se han instituido en las industrias proporcionan un conjunto mínimo de requisitos que
las organizaciones deben trabajar para lograr. Los pasos que las organizaciones normalmente deben tomar para
que su gobierno, infraestructura y operaciones de TI estén en forma para ser auditados por primera vez contra
un estándar de la industria pueden mejorar drásticamente su postura de seguridad y su programa general de
seguridad cibernética. Las organizaciones no deben subestimar el esfuerzo y el cambio potencial relacionado
con el cumplimiento de los estándares regulados y los estándares de la industria. Este esfuerzo generalmente
se recompensa con una seguridad mucho mejor que la que tenían al principio, así como con una base que
potencialmente pueden ampliar y seguir construyendo.
El desafío para muchas organizaciones es reconocer que la mayoría de los estándares relacionados con la
seguridad regulados son requisitos mínimos, no algún tipo de certificación que signifique que no pueden ser
comprometidos.
Capítulo 9 357
Aunque muchas organizaciones requieren el cumplimiento normativo, no es suficiente para proteger sus sistemas y datos
de las amenazas modernas. Aquí es donde el cumplimiento como estrategia de seguridad tiende a fallar. La historia nos
ha enseñado que esta es una mala estrategia. No hay escasez de ejemplos de organizaciones grandes y bien financiadas
que cumplieron con los estándares regulados pero fueron incumplidos de todos modos. Piense en todas las instituciones
financieras, minoristas y restaurantes que cumplieron con los estándares regulados de sus industrias, pero que de todos
modos fueron incumplidos. Piense en todas las organizaciones de la industria de la salud en todo el mundo que
trabajaron arduamente para cumplir con los estrictos estándares regulados de protección de datos de la industria y
perdieron el control de los datos de los pacientes ante los atacantes. Mis propios datos personales se han visto
comprometidos varias veces en filtraciones de datos en todas estas industrias durante los últimos 15 años. Esto no
significa que las normas reguladas relacionadas con la seguridad carezcan de valor. Como mencioné, son muy positivos
para muchas, muchas organizaciones. Prefiero usar mi tarjeta de crédito en un restaurante que intente cumplir con PCI
DSS que en uno que no lo haga.
Los estándares relacionados con la seguridad regulados son insuficientes por sí mismos. Hay al menos un par de
razones para esto. En primer lugar, los estándares como estos suelen tener un alcance definido, como la información del
titular de la tarjeta de crédito o la información del paciente. Los conjuntos de control para admitir estos estándares están
diseñados para la infraestructura y los datos que se encuentran en el ámbito definido. Pero, ¿qué pasa con los otros
HVA que tienen las organizaciones? Si la organización utiliza sus recursos limitados para abordar solo el alcance
auditado y sujeto a sanciones, es probable que no esté prestando suficiente atención a otras HVA y su infraestructura
más amplia. La segunda razón por la que los estándares regulados son insuficientes es que rara vez siguen el ritmo del
panorama de amenazas o los avances tecnológicos. Esto tiene más que ver con la lentitud con la que se pueden adoptar
las normas en las industrias y su impacto económico que con los propios organismos de normalización. La implementación
de requisitos de estándares relacionados con la seguridad actualizados para millones de minoristas y restaurantes de
todo el mundo lleva años. Posteriormente, las organizaciones generalmente necesitan una estrategia de ciberseguridad
más amplia que abarque el cumplimiento pero complemente sus deficiencias de manera material. En pocas palabras,
las empresas deben hacer ambas cosas.
Puntuación CFSS
Las estimaciones de mi puntaje CFSS para el cumplimiento como estrategia de seguridad revelan que esta estrategia
puede mitigar parcialmente todos los sospechosos habituales de ciberseguridad. Recuerde, el objetivo es encontrar una
estrategia o combinación de estrategias que nos proporcione una puntuación total perfecta de 100/100 CFSS.
Posteriormente, esta estrategia deberá usarse en combinación con otras estrategias para abordar completamente los
sospechosos habituales de ciberseguridad:

Amenaza interna 10
Tabla 9.7: Estimación de la puntuación CFSS para el cumplimiento como estrategia de seguridad
Le di a esta estrategia calificaciones parciales en general porque puede ayudar a las organizaciones a mitigar todas estas
amenazas, pero generalmente se usa con un alcance limitado y se adapta lentamente a los cambios en el panorama de
amenazas. Esta estrategia puede crear y crea una base, aunque incompleta, sobre la que muchas organizaciones pueden
construir con enfoques complementarios.
Resumen de cumplimiento como estrategia de seguridad

La puntuación total estimada del CFSS para esta estrategia es 50/100. Esta estrategia puede ser muy beneficiosa para las
organizaciones como punto de partida para una estrategia de ciberseguridad más amplia. Las organizaciones que integran sus
requisitos de cumplimiento en una estrategia de ciberseguridad más holística pueden reducir potencialmente la complejidad y
los costos y lograr una mejor seguridad.
ventajas:
• Puede ser muy positivo para las organizaciones que no tienen una estrategia de seguridad o tienen prácticas de gobierno
inmaduras
• La verificación/certificación de terceros por parte de los auditores es valiosa para demostrar la diligencia debida.
• Gran ecosistema de proveedores y firmas de auditoría para ayudar
• Puede reducir la complejidad y los costos, y lograr una mejor seguridad cuando se integra con los esfuerzos de seguridad
cibernética
• Cumplir con algunos estándares regulados, como GDPR, por ejemplo, puede ayudar a las organizaciones
lograr una mejor protección de datos
Desventajas:
• La historia ha demostrado que esta es una mala estrategia ya que muchas organizaciones que cumplieron con
las normas se violaron de todos modos.
• Por lo general, se basa en equipos de cumplimiento y auditoría, así como en auditores externos, para arbitrar la postura
de seguridad de la organización.
Capítulo 9 359
• Se enfoca en implementar conjuntos de control especificados en estándares regulados con un

alcance que normalmente no incluye todos los HVA.
• Solo alcanza los requisitos mínimos especificados por los reglamentos cuando se publicaron por última vez;
rara vez refleja los riesgos y mitigaciones de hoy en día.
• Los atacantes tienen una ventaja desproporcionada sobre los defensores. Esto se debe a que pueden tener
una visibilidad completa de los conjuntos de control necesarios para cumplir, y esos conjuntos de control
rara vez siguen el ritmo de los cambios en el panorama de amenazas.
• En algunos casos, el cumplimiento normativo utiliza recursos que, de otro modo, podrían utilizarse para
una ciberseguridad más eficaz.
Ahora, echemos un vistazo a la estrategia centrada en la aplicación.
Estrategia centrada en la aplicación

Esta es otra estrategia de proxy. Las aplicaciones procesan, almacenan y transmiten datos. Si protegemos la
aplicación, entonces mediante proxy, estamos protegiendo los datos. Este enfoque se enfoca en proteger las
aplicaciones al reducir la cantidad de vulnerabilidades en ellas y la gravedad de esas vulnerabilidades.
También se esfuerza por hacer que las vulnerabilidades que quedan inevitablemente en las aplicaciones sean
realmente difíciles , si no imposibles, de explotar. Estos son los mismos principios que sustentan el marco de mejora
de la vulnerabilidad que introduje en el Capítulo 3, Uso de tendencias de vulnerabilidad para reducir riesgos y
costos. Una suposición subyacente de este enfoque es que es mucho menos costoso corregir errores y mitigar
vulnerabilidades antes de que una aplicación se lance a producción. Esto implica inversiones en personas, procesos
y tecnologías, que pueden incluir modelos de amenazas, ciclos de vida de desarrollo de seguridad, herramientas de
análisis de código estático y dinámico, pruebas de penetración, administración de dispositivos móviles, administración
de aplicaciones móviles, recompensas por errores y otros.
Soy un gran creyente en esta estrategia; después de todo, ¿navegaría en un submarino en el que alguien perfora
agujeros en el casco desde el interior? Este sigue siendo un riesgo subestimado, ya que muchas empresas aún no
parecen seleccionar proveedores o soluciones en función de sus prácticas de desarrollo de seguridad.
Dirigí las comunicaciones de marketing para Security Development Lifecycle (SDL) de Microsoft (Microsoft
Corporation, nd) durante varios años y vi cómo podía ayudar a los equipos de desarrollo de primera mano.
Sin embargo, no es necesario tener una organización de desarrollo masiva como Microsoft para beneficiarse de
esta estrategia.
Como dice el refrán, una marea alta levanta todos los barcos. Los CISO, los equipos de seguridad, los profesionales de
cumplimiento y las organizaciones de desarrollo pueden ayudar a elevar la marca de la marea de seguridad para su
organización con el tiempo mediante la implementación de educación, políticas y procesos de desarrollo de seguridad
respaldados por herramientas y automatización, para ayudar a mejorar la calidad del software desarrollado internamente y
adquirido de terceros. Por ejemplo, exigir que cada aplicación desarrollada internamente requiera un modelo de amenaza,
antes de que los desarrolladores escriban cualquier código, puede ayudar a mejorar el diseño y mitigar las posibles
vulnerabilidades. De manera similar, requerir un análisis de código estático en etapas específicas del desarrollo puede
ayudar a reducir la cantidad y la gravedad de las vulnerabilidades que llegan a la producción. Las organizaciones que no
hacen cumplir los requisitos de seguridad en cada fase del proceso de desarrollo suelen pagar un precio más alto por esta
decisión, una vez que se han implementado sus aplicaciones.
Pero como todas las otras estrategias, esta también tiene inconvenientes y limitaciones. Las mismas funciones,
herramientas, IDE, bibliotecas de desarrollo y marcos (C++, JRE, .NET, etc. ) del sistema operativo que se utilizan para
proteger las aplicaciones también pueden ser una fuente persistente de vulnerabilidades. El Java Runtime Environment
(JRE) fue un ejemplo perenne durante muchos años. Ahorra mucho tiempo y dinero a los equipos de desarrollo, pero el
costo de oportunidad es que su aplicación podría heredar vulnerabilidades que necesitan parchearse en el propio JRE. El
tiempo entre el descubrimiento de vulnerabilidades en estos marcos y su reparación representa un riesgo para los usuarios
de sus aplicaciones.
Otro inconveniente de esta estrategia con el que he visto lidiar a las organizaciones en numerosas ocasiones es que,
aunque menos vulnerabilidades y vulnerabilidades de menor gravedad son métricas medibles, son difíciles de traducir en
valor comercial. Argumentar que los ataques no ocurrieron debido a la inversión en seguridad de aplicaciones puede ser
un argumento difícil para los CISO y las organizaciones de desarrollo.

líderes de zación para hacer y otros ejecutivos para entender. Lo que parece sentido común para
Los CISO y los equipos de gestión de vulnerabilidades pueden permanecer confusos para otras partes interesadas.
Como escribí en el Capítulo 3, Uso de tendencias de vulnerabilidad para reducir riesgos y costos, el uso de datos de su
programa de administración de vulnerabilidades para proporcionar visibilidad sobre el estado del entorno puede ayudarlo a
defender la seguridad de las aplicaciones. Intentar reducir a cero la cantidad de vulnerabilidades sin parchear y usar datos
para ayudar a otros ejecutivos a comprender el progreso en relación con este objetivo y los costos asociados, puede
ayudarlos a comprender por qué es importante evitar que se introduzcan nuevas vulnerabilidades en el entorno a través de
aplicaciones internas y de terceros.

Capítulo 9 361
Puntuación CFSS
Dicho todo esto, veamos cómo puntúa la estrategia centrada en la aplicación en el CFSS:
Amenaza interna 10
Tabla 9.8: Estimación de la puntuación CFSS para la estrategia centrada en la aplicación
Le di a esta estrategia la máxima puntuación por su capacidad para mitigar las vulnerabilidades sin parches y las
configuraciones incorrectas de seguridad. Me doy cuenta de que esto es un poco optimista para la mayoría de las
organizaciones, pero hay algunos escenarios en los que esto podría ser posible. Le di a esta estrategia calificaciones
parciales por su capacidad para mitigar amenazas internas, ingeniería social y credenciales débiles, filtradas o robadas. Por
ejemplo, el diseño de aplicaciones que requieran MFA y brinden capacidades ricas de registro y auditoría puede ayudar a
mitigar parcialmente estas amenazas.
Resumen de la estrategia centrada en la aplicación

Todas las organizaciones pueden beneficiarse de este enfoque. Sin embargo, por sí mismo, su puntaje total estimado CFSS
es 70/100. Recomiendo que las organizaciones adopten esta estrategia y la subsidien con otros enfoques que ayudarán a
abordar por completo todos los fundamentos de la ciberseguridad.
ventajas:
• Puede reducir el número y la gravedad de las vulnerabilidades en el software que la organización
adquiere y desarrolla internamente.
• Puede reducir los costos de mantenimiento, minimizar las interrupciones del negocio y mejorar de manera medible
seguridad de la aplicación.
• Aprovecha las mitigaciones integradas en los sistemas operativos, IDE, bibliotecas de desarrollo y marcos (C++,
JRE, .NET, etc.) y contenedores. Esto reduce la complejidad, los costos y el esfuerzo de los equipos de desarrollo
al tiempo que mejora potencialmente la seguridad.
• Amplio ecosistema de proveedores existente para ayudar.

Desventajas:
• Depende de los desarrolladores para producir un código fuente libre de vulnerabilidades o imposibilitar que se
exploten las vulnerabilidades; la historia nos enseña que esto es optimista
• Sujeto a vulnerabilidades en los sistemas operativos, IDE, bibliotecas de desarrollo, marco
obras y contenedores, entre otras tecnologías
• El ROI empresarial puede ser un desafío para comunicarse de manera efectiva
Adelante ahora, a la estrategia centrada en la identidad.
Estrategia centrada en la identidad

Recordará que uno de los sospechosos habituales de ciberseguridad es una credencial débil, filtrada y robada. Las
credenciales y los activos que protegen han sido moneda de cambio para los atacantes durante décadas.
Muchas personas reutilizan contraseñas en aplicaciones, sistemas y servicios. Cuando uno de ellos se ve comprometido
y se roban las credenciales, los atacantes prueban inmediatamente esas credenciales en otros sistemas y servicios a
través de Internet, como los principales portales de banca en línea, sitios de comercio electrónico, redes sociales, etc.
Durante mucho tiempo, la industria ha querido desaprobar las contraseñas en favor de mejores métodos de autenticación
y utilizar datos de los sistemas de autenticación y autorización para tomar mejores decisiones de acceso a los recursos.
Estos conceptos son fundamentales para la estrategia centrada en la identidad .
Aunque el concepto de identidad y prueba de su identidad es antiguo, la estrategia centrada en la identidad

es una estrategia relativamente nueva que ganó popularidad rápidamente. La idea detrás de esta estrategia es que
durante la mayoría de las violaciones de datos exitosas, en algún momento, los atacantes usarán credenciales legítimas.
Hay un dicho en la industria de la ciberseguridad, "los atacantes no entran, inician sesión". ¿Cómo podemos usar esto a
nuestro favor para proteger, detectar y responder a los ataques? Bueno, los procesos de autenticación y autorización
pueden potencialmente generar algunos metadatos útiles. Por ejemplo, si podemos determinar la ubicación aproximada
de la que proviene una solicitud de autenticación o autorización, podríamos calcular un nivel de confianza en su
legitimidad. De manera similar, si podemos comparar algunos atributos clave de la solicitud con las características de
solicitudes anteriores de la misma cuenta, esto también podría ayudarnos a tener cierto nivel de confianza de que la
solicitud era legítima. Hay una gran cantidad de metadatos como este que pueden ayudar a las organizaciones a
proteger, detectar y responder a los ataques.
Aquí hay una lista parcial de tales datos:
• Fuerza de la credencial utilizada para la solicitud (protocolos antiguos versus protocolos nuevos)
• Ubicación y datos temporales:
• Ubicación de origen de la solicitud

Capítulo 9 363
• Hora del día de la solicitud
• Tiempo entre solicitudes de diferentes ubicaciones: ¿es imposible viajar entre esas ubicaciones
en el tiempo entre las solicitudes?
• Confiabilidad del dispositivo del que proviene la solicitud:
• ¿Cuenta con certificado digital vigente instalado por la organización?

• ¿Es un dispositivo administrado por la empresa o un dispositivo personal no administrado?
• ¿Está instalada la última versión del sistema operativo en el dispositivo?
• ¿La versión del hardware o del sistema operativo tiene una vulnerabilidad conocida sin parchear?
¿habilidades?
• Comportamiento del usuario:
• ¿Cuántas veces ingresó el usuario credenciales incorrectas?
• ¿Cuándo fue la última vez que se solicitó al usuario la autenticación multifactor?

(MFA) y cuál fue el resultado?
La suposición subyacente de esta estrategia es que las organizaciones pueden proteger mejor los datos, detectar
compromisos y responder más rápido al proteger mejor las identidades utilizadas para acceder a los datos y al
usar metadatos de identidad para buscar indicadores de compromiso. El enfoque de este enfoque es proteger
las credenciales utilizadas para acceder a los datos de la organización, especialmente las credenciales de las
cuentas privilegiadas, como los administradores. Los equipos de respuesta a incidentes, los expertos forenses
y los equipos rojo y azul saben que las credenciales de cuentas privilegiadas son como el oro para los atacantes.
Cuando trabajé en el equipo de respuesta ante incidentes informáticos (CIRT) de Microsoft, el modus operandi
de los atacantes era muy consistente; Una vez que los atacantes comprometieron inicialmente un entorno de TI
utilizando uno de los sospechosos habituales de ciberseguridad, en cuestión de segundos, sus scripts se
estaban ejecutando, tratando de recopilar las credenciales almacenadas en caché en el sistema comprometido.
Usarían esas credenciales para moverse lateralmente por el entorno si pudieran, buscando más credenciales
almacenadas en caché en el camino. Encontrar credenciales almacenadas en caché para cuentas privilegiadas
facilitó mucho más que los atacantes penetraran en el entorno aún más profundo y luego obtuvieran acceso a
más recursos y datos. Si los atacantes pudieran filtrar una copia del Microsoft Active Directory de la víctima,
realizarían un ataque fuera de línea, usando tablas arcoíris y/u otras herramientas para obtener acceso a más
credenciales con relativa rapidez (Wikipedia, sin fecha). Una vez que los atacantes llegaron a esta etapa, la
recuperación era aspiracional. Conocí a numerosas organizaciones a lo largo de los años que se encontraron en este escenario.
Algunos de ellos decidieron "compartir" su entorno de TI con los atacantes porque la recuperación era demasiado
costosa y requería muchos recursos.
Otros decidieron reconstruir su infraestructura desde cero o usaron el compromiso como impulso para comenzar
de nuevo en la nube. Dado que los atacantes intentan recolectar credenciales de manera rutinaria, muchas
organizaciones se enfocan en proteger las credenciales y usan metadatos de identidad para acelerar la detección.
La estrategia centrada en la identidad se caracteriza por inversiones en MFA, haciendo cumplir el principio de
privilegio mínimo, tecnologías de gestión de identidad, bóveda de credenciales y prácticas de higiene, y
detectando credenciales que se están utilizando indebidamente (los ataques PasstheHash y Golden Ticket
son ejemplos). Por ejemplo, para contrarrestar los ataques a Microsoft Active Directory, Microsoft ha tomado
numerosas medidas para dificultar el éxito de los atacantes. Además de las mejoras de ingeniería en sus
productos, han publicado una guía sobre cómo fortalecer Active Directory (Microsoft Corporation, 2021).
También publicaron una gran cantidad de contenido sobre lo que se conoce como "Bosque rojo" o
Entorno administrativo de seguridad mejorado (ESAE), que recientemente se reemplazó con una
estrategia de acceso privilegiado más nueva (Microsoft Corporation, 2022). Estos tipos de arquitecturas
ayudan a proteger las credenciales de cuentas privilegiadas y dificultan mucho el acceso de los atacantes a ellas.
Pero estas arquitecturas y configuraciones avanzadas no son para los débiles de corazón.
Cumplir y mantener los requisitos de estos entornos puede ser un desafío. El uso de estaciones
de trabajo de acceso privilegiado (PAW) junto con cuentas e interfaces de acceso privilegiado
requiere autodisciplina administrativa para gobernar y operar TI en un entorno tan estrictamente controlado.
Sin embargo, proteger las credenciales en un entorno distribuido local nunca ha sido fácil.
El espacio de la identidad se ha disparado en las últimas dos décadas. Hay proveedores que se especializan
en administración de acceso, acceso privilegiado, control de identidad y varias otras áreas. Algunos proveedores
que venden tecnologías que admiten una estrategia centrada en la identidad llaman a la identidad el "nuevo
perímetro" para resaltar la importancia de proteger las credenciales y la higiene de las mismas. También es
importante tener en cuenta que la identidad juega un papel central en la computación en la nube, así como en Zero Trust.
estrategias en las que se aprovechan muchos de los mismos conceptos. Discutiré este tipo de estrategia más
adelante en el capítulo. Hay varios proveedores en el espacio de la identidad que pueden ayudar a que la
protección de las credenciales sea más fácil y brindar acceso a metadatos valiosos para acelerar la detección
de anomalías. Algunos de los proveedores que he visto que las organizaciones aprovechan incluyen BeyondTrust,
CyberArk, Google, Microsoft, Okta, Ping Identity y otros.
Capítulo 9 365
Puntuación CFSS
¿ Cómo califica la estrategia centrada en la identidad en el CFSS? No aborda por completo ninguno de los
fundamentos de la ciberseguridad:
Amenaza interna 10
Tabla 9.9: Estimación de la puntuación CFSS para la estrategia centrada en la identidad
Esta estrategia no mitiga las vulnerabilidades sin parches ni las configuraciones incorrectas de seguridad. Pero
algunas vulnerabilidades y configuraciones incorrectas de seguridad requieren acceso autenticado para ser explotadas.
Las organizaciones que se enfocan en hacer cumplir el principio de privilegio mínimo y practican una buena higiene
de credenciales pueden hacer que la explotación confiable de vulnerabilidades y configuraciones incorrectas sea
mucho más difícil y "limitar el radio de explosión". Posteriormente, le di a esta estrategia calificaciones parciales
para estos dos fundamentos de ciberseguridad. No podría darle la máxima puntuación por mitigar las credenciales
débiles, filtradas y robadas porque las aplicaciones heredadas tienden a pasar desapercibidas con esta estrategia;
Por lo general, MFA no se puede implementar en todas partes y los metadatos no siempre estarán disponibles. De
manera similar, este enfoque puede ayudar a mitigar parcialmente la amenaza interna mediante la implementación
de modelos JustinTime (JIT) y JustEnoughAdministration (JEA) , almacenamiento de credenciales y otras
mitigaciones. La ingeniería social se puede mitigar parcialmente con MFA y privilegios mínimos, entre otros
controles, pero no se puede mitigar por completo. Estoy seguro de que algunos lectores le darían a esta estrategia
una puntuación más alta que la mía. Utilice sus propias estimaciones cuando esté justificado.
Resumen de la estrategia centrada en la identidad

Esta estrategia debe usarse en combinación con otras estrategias para mitigar por completo los sospechosos
habituales de ciberseguridad. Aunque no obtuvo una puntuación particularmente alta, sin duda es un enfoque
valioso, moderno y complementario para mejorar las capacidades de protección, detección y contención. Sin
embargo, eso podría estar subestimando la importancia de la identidad en una estrategia moderna de ciberseguridad.
La identidad seguirá siendo fundamental para una estrategia de seguridad cibernética efectiva, ayudando a abordar los
fundamentos de la seguridad cibernética y brindando capacidades avanzadas. Las inversiones en esta área pueden pagar grandes
dividendos para los CISO.
ventajas:
• Se enfoca en mejorar la gobernanza y las tecnologías con un historial históricamente pobre
• Un gran ecosistema de proveedores para ayudar
• Puede ayudar a administrar el riesgo relacionado con contraseñas débiles, filtradas y robadas
• MFA se está volviendo omnipresente
• La solidez de una credencial, la ubicación de un intento de inicio de sesión, la confiabilidad del dispositivo y los
controles de MFA pueden ayudar a generar confianza en la legitimidad de la autenticación.

peticiones
• Puede identificar rápidamente anomalías de autenticación/autorización
• Puede agregar fricción a los procesos de autenticación/autorización, lo que lo hace más difícil
para que los atacantes se infiltren
• Puede reforzar los esfuerzos de contención y dificultar que los atacantes se muevan lateralmente y
contener el "radio de explosión" de algunos ataques
Desventajas:
• Tradicionalmente, los sistemas de identidad federada han sido complejos, costosos y difíciles de gobernar y
administrar; En pocas palabras, la identidad siempre ha sido un desafío en la TI de las grandes empresas.
entornos.
• Las aplicaciones heredadas pueden ser difíciles de gobernar y asegurar mediante una estrategia moderna
centrada en la identidad . Por lo general, hay muchas más aplicaciones heredadas que aplicaciones
modernas en entornos de TI empresariales grandes, complejos y maduros.
• Por lo general, MFA no se implementa en todas partes, lo que deja brechas y oportunidades para los atacantes.
• Puede ser complicado, lento y costoso de implementar completamente en la empresa

entornos locales.
A continuación, veamos una estrategia que ha resurgido en popularidad: la estrategia centrada en datos.
Estrategia centrada en datos

La estrategia centrada en datos ha ido creciendo en popularidad por varias razones, incluidas numerosas filtraciones
de datos de alto perfil, revelaciones sobre programas gubernamentales de recopilación de datos, el aumento drástico
de la frecuencia de los ataques de ransomware y el riesgo cada vez mayor de robo de propiedad intelectual.
Capítulo 9 367
También hay cada vez más demandas regulatorias que tienen como objetivo ayudar a proteger la privacidad del
consumidor y tienen importantes multas por incumplimiento asociadas, como GDPR, por ejemplo. Además, debido
a los desafíos que discutimos con la estrategia de protección y recuperación, la estrategia de protección de
endpoints, la estrategia centrada en aplicaciones, la popularidad de BYOD, los entornos de TI y el surgimiento de
IoT, algunas organizaciones han decidido dejar de usar estrategias que se basan únicamente en proxies para
proteger sus datos. En lugar de confiar en la seguridad que brindan los firewalls, los puntos finales y las aplicaciones,
su estrategia es proteger los datos, sin importar dónde se encuentren.
Ya sea que sus datos estén dentro de su perímetro, se acceda a ellos desde un dispositivo administrado o sean
procesados por una aplicación que cumpla con sus requisitos de desarrollo de seguridad, los datos aún deben
protegerse . Algunos CISO asumen que no se puede confiar plenamente en los puntos finales y que los datos
pueden moverse de formas inesperadas sin su conocimiento. Quieren asegurarse de que, incluso en escenarios
en los que no tienen el control de sus datos, aún estén protegidos.
Aquí es donde la estrategia centrada en datos puede ayudar. Hay varias suposiciones subyacentes para este
enfoque. Primero, los datos, no los sistemas que los procesan, transmiten o almacenan, son los HVA. En lugar de
centrarse en la seguridad del hardware y el software que maneja los datos, la atención debe centrarse en los datos
en sí. Otra suposición es que los datos se moverán sin la aprobación o el conocimiento de la organización y, por lo
tanto, deben protegerse, independientemente de dónde se encuentren. Algunos CISO llegan a suponer que algunos
de los sistemas que procesan sus datos están comprometidos y que los datos deben protegerse en un entorno
comprometido. Finalmente, las organizaciones aún requieren que sus datos se puedan compartir adecuadamente
dentro de su organización y con socios autorizados, como firmas externas de fabricación, marketing, relaciones
públicas y abogados. Es decir, aunque los datos deben estar seguros, deben ser accesibles y utilizables interna y
externamente. El objetivo de esta estrategia es proteger los datos dondequiera que se transmitan, procesen y
almacenen, preferiblemente para siempre, pero durante un período de tiempo razonablemente largo. Este enfoque
se caracteriza por inversiones en tecnologías de cifrado y administración de claves, prevención de pérdida de datos
(DLP) y, potencialmente, clasificación de datos.
Un ejemplo simplificado de esto son los archivos PDF encriptados, que pueden ser leídos por usuarios autorizados,
pero el contenido no se puede copiar ni pegar. Un ejemplo más complicado son las soluciones extremas centradas
en datos que ofrecen las plataformas blockchain que implementan mecanismos de protección de datos como parte
de los datos en sí.
El corazón de esta estrategia es el cifrado y la gestión de claves; si los datos se cifran en todas partes todo el
tiempo, el área de superficie de ataque se puede reducir drásticamente. Por ejemplo, en lugar de tratar de proteger
todos los archivos, dondequiera que estén actualmente y en el futuro, para siempre, el cifrado puede ayudar a que
esto sea más manejable.
El cifrado y la gestión de claves pueden ayudar a mantener la confidencialidad e integridad de los datos que
protege. Cifrar grandes cantidades de archivos reduce la superficie de ataque al cambiar el enfoque de proteger
todos estos archivos a proteger potencialmente una cantidad mucho menor de claves de cifrado. Si se emplea un
cifrado sólido y correctamente implementado, el enfoque principal puede pasar de la seguridad de los archivos
cifrados a la gestión de las claves que se utilizan para cifrarlos y descifrarlos. Por supuesto, si el propietario de los
datos no tiene acceso a los archivos cifrados, no podrá descifrarlos y los datos se perderán, por ejemplo, cuando
los archivos cifrados se vuelvan a cifrar durante un ataque de ransomware. Esto significa que no debemos ser
arrogantes con nuestros datos solo porque están encriptados. Sin embargo, las propiedades matemáticas del
cifrado fuerte implementado correctamente pueden ayudar a reducir el riesgo.
Además de reducir la superficie de ataque, el cifrado gana tiempo a las organizaciones. Es decir, los datos cifrados
correctamente tienen el mismo aspecto que el ruido aleatorio y, sin las claves para descifrar los datos, los atacantes
probablemente tardarán muchos años en descifrar una parte de los datos. La confidencialidad e integridad de los
datos se conservan durante ese tiempo. Pero aún es prudente suponer que los datos cifrados tienen una vida útil
finita. Rotar periódicamente las claves y volver a cifrar los datos puede ayudar a extender esta vida útil, pero en
algún momento, los algoritmos o las longitudes de clave utilizadas ya no brindarán la protección adecuada frente a
las nuevas tecnologías y los avances en el criptoanálisis. Por ejemplo, durante varios años, ha habido esfuerzos en
toda la industria para desarrollar algoritmos de encriptación seguros cuánticos o poscuánticos que puedan usarse
para preservar la confidencialidad e integridad de los datos después de que las computadoras cuánticas se
conviertan en una realidad. Se requiere un enfoque reflexivo para administrar el cifrado, el descifrado y las claves;
esta no es una solución de "configúrelo y olvídese" para la protección de datos.
Tal vez se pregunte, dado que existen varios tipos de cifrado desde hace milenios, si el cifrado y la gestión de claves
son tan potentes, ¿por qué las organizaciones no siempre han cifrado todo, en todas partes? ¿Por qué ha habido
tantas violaciones de datos que involucran datos no cifrados? Tradicionalmente, ha habido una tensión entre
asegurar la información y hacerla operativa . Permítanme darles un ejemplo de esta tensión. Usaré un escenario
completamente ficticio, donde hay consecuencias de vida o muerte por el acceso no autorizado a la información:
un programa de protección de testigos.
En este escenario ficticio, la lista de testigos que el programa protege está escrita a mano en papel. La lista no ha
sido digitalizada de ninguna manera; sólo existe en el papel. Ninguna persona ha visto nunca la lista completa, ya
que partes de la lista son administradas por administradores de programas separados y están compartimentadas
físicamente. La lista se coloca en un archivador a prueba de fuego que tiene una cerradura de combinación y
barras de acero bloqueadas en sus cajones. Las llaves de estos candados se entregan a distintos funcionarios del
programa, lo que requiere que todos ellos estén presentes para abrir el archivador.
Capítulo 9 369
El archivador está en una bóveda, en un área segura en medio de la jefatura de policía, rodeado de policías
en servicio, con guardias armados en la única entrada fortificada del edificio las 24 horas del día. Por
supuesto, el edificio cuenta con un amplio sistema de seguridad, que incluye videovigilancia , trampas para
hombres y puntos de acceso con llave de tarjeta. La bóveda solo se puede abrir siguiendo un protocolo
específico que requiere la participación de dos altos funcionarios policiales adicionales, bajo condiciones
específicas.
Espero que esté de acuerdo en que la lista en este escenario se ha asegurado de una manera que mitiga
muchos riesgos potenciales y que el acceso no autorizado a la lista requeriría medidas extraordinarias.
Ethan Hunt de Misión Imposible podría violar todos estos controles, pero estoy seguro de que estará de
acuerdo en que sería difícil para la mayoría de las personas. Sin embargo, una consecuencia adicional de
estos controles es que se ha obstaculizado el acceso legítimo y autorizado a la lista, lo que lo convierte en un
proceso complicado y lento. En este escenario, dado que puede haber consecuencias de vida o muerte por
el acceso no autorizado, el acceso está diseñado deliberadamente para que sea lento, engorroso y meticuloso.
Sin embargo, si hubiera una emergencia o alguna otra necesidad de acceso rápido o acceso repetitivo a la
lista, este proceso frustraría esas necesidades.
En otro escenario ficticio, una empresa que se especializa en brindar asesoramiento en tiempo real sobre el
comercio de acciones tiene un desafío diferente. Esta empresa cerrará si no puede acceder a la información,
procesarla y brindar valiosos consejos a su gran base de clientes casi en tiempo real. La información que
tiene normalmente pierde su valor en cuestión de minutos. Los controles de seguridad son importantes para
la empresa, ya que tiene competidores y reguladores muy agresivos que quisieran comprender cuál es el
secreto de su éxito. Sin embargo, si los controles de seguridad obstaculizan la distribución de información
casi en tiempo real dentro de la empresa o a sus clientes, la empresa no cumplirá sus promesas a sus
clientes y cerrará en un mercado hipercompetitivo. Esta empresa prioriza deliberadamente la velocidad y la
agilidad sobre la seguridad. Si no lo hace, no estará en el negocio por mucho tiempo.
Estos dos escenarios demuestran la tensión entre la necesidad de seguridad de los datos y la necesidad de
hacer operativa la información, que tradicionalmente ha desafiado a las organizaciones. Combine esta tensión
con el hecho de que el cifrado y la administración de claves han requerido tradicionalmente experiencia
específica, relativamente difícil de encontrar y costosa, y esto comienza a explicar por qué las organizaciones
simplemente no han cifrado todos sus datos, todo el tiempo.
Debido a esta tensión y los desafíos tradicionales asociados con el cifrado, muchas organizaciones deciden
cifrar solo sus datos más confidenciales. Esto reduce la complejidad y los costos, al mismo tiempo que
garantiza que sus datos más valiosos estén protegidos. Para hacer esto, muchas organizaciones han
adoptado esquemas de clasificación de datos para identificar y proteger de manera más efectiva los datos de alto valor.
Pero como mencioné anteriormente en este capítulo, las políticas de clasificación de datos son notoriamente
difíciles de implementar y cumplir para las organizaciones. Muchas de las organizaciones con las que he
hablado, particularmente aquellas que intentaron implementar políticas de clasificación de datos y fallaron,
concluyeron que es más eficiente tratar todos los datos como si tuvieran el mismo valor. Para ellos, este enfoque
es menos complicado y menos costoso que tratar de identificar consistentemente el valor relativo de conjuntos
de datos individuales y aplicar diferentes conjuntos de control de seguridad basados en ese valor. Pero estas
organizaciones aún enfrentan el desafío de administrar el cifrado y la administración de claves.
¿No sería genial si los CISO no tuvieran que hacer estas concesiones? Es decir, podrían tenerlo todo: seguridad
de datos sin concesiones, las capacidades operativas que permiten a las organizaciones moverse rápidamente,
la capacidad de compartir datos cuando sea necesario y una mejor visibilidad y control. ¿ Quién no querría eso?
Esto es lo que la estrategia centrada en datos busca permitir. En lugar de solo administrar la seguridad del
hardware y el software que maneja los datos, asegure los datos mismos mediante el cifrado, la administración
de claves, la autenticación y la autorización. En un mundo donde las violaciones de datos se han vuelto
comunes, esta estrategia puede proporcionar una línea de defensa efectiva cuando la mayoría de los otros
mecanismos de protección fallan. Además, si las funciones de cifrado y descifrado requieren autenticación y
autorización, los metadatos generados a partir de estas actividades pueden proporcionar información útil sobre
dónde están los datos y quién intenta acceder a ellos.
Desde un alto nivel, las tecnologías utilizadas para respaldar estas capacidades incluyen bibliotecas o
aplicaciones de cifrado del lado del cliente o del lado del servidor, infraestructuras de clave pública (PKI),
sistemas de identidad federada con capacidades de autorización, así como capacidades de registro e informes.
Un buen ejemplo de un servicio que combina todos estos componentes es Azure Rights Management (Azure
RMS) (Microsoft Corporation, 2022). Déjame darte un ejemplo de cómo funciona este servicio, desde un alto
nivel.
Una empresa necesita proteger la información confidencial para que no caiga en las manos equivocadas, pero
debe compartirla con su bufete de abogados externo de una manera que aún proteja la confidencialidad y la
integridad de los datos. Cifran el archivo con Azure RMS y le asignan una política que define quién está
autorizado para abrir y descifrar el archivo. Envían el archivo al bufete de abogados por correo electrónico
usando Microsoft 365. Cuando el personal del bufete de abogados intenta abrir el archivo, se les solicita que
ingresen sus credenciales de Azure Active Directory. Dado que también es un usuario corporativo de Microsoft
365 y tiene una identidad federada configurada con la cuenta de la empresa, cuando ingresan sus credenciales,
Azure Active Directory los autentica y lee la política para determinar qué tipo de acciones pueden realizar con el
archivo. La política permite que el bufete de abogados abra el archivo, lo descifre y lo lea. Si el archivo se reenvía
a alguien que no tiene esos permisos, no podrá abrirlo ni descifrarlo.
Capítulo 9 371
Mientras tanto, la empresa puede rastrear de qué parte del mundo provienen las solicitudes de autenticación para
abrir el archivo, qué credenciales se usaron en las solicitudes de autenticación, intentos fallidos y exitosos de abrir
el archivo, etc. Muy genial. Hablaré sobre otras capacidades geniales que ofrece la nube en el Capítulo 12,
Enfoques modernos para la seguridad y el cumplimiento.
Es posible que haya notado que el único componente crítico que permite el escenario de ejemplo que describí es
la identidad. Se requiere una estrategia de identidad, como la estrategia centrada en la identidad que describí
anteriormente en este capítulo, para que esta estrategia centrada en los datos tenga éxito. Sin capacidades de
autenticación y autorización, la estrategia centrada en datos no es escalable.
DLP también se puede emplear en una estrategia centrada en datos. DLP puede ser una herramienta poderosa
para ayudar a evitar que los datos salgan de una organización de forma no autorizada, incluido el robo y la fuga de
datos malintencionados y no malintencionados. DLP puede monitorear los datos que se mueven a través de la red,
el correo electrónico, las unidades USB y otros medios extraíbles. Pero el cifrado cada vez más ubicuo puede
dificultar que DLP logre una visibilidad completa. Además, las infracciones de las políticas de DLP rara vez tienen
consecuencias para los empleados y ejecutivos que las infringen; esto proporciona pocos incentivos para prestar
atención a las políticas relacionadas con DLP. Finalmente, DLP solo puede ralentizar a los infiltrados
malintencionados mientras roban información, no detenerlos por completo. Casi siempre encontrarán una manera
de sacar información de contrabando de un entorno de TI, como usar la cámara de su teléfono móvil para tomar
una foto directamente de la pantalla de una estación de trabajo segura, por ejemplo. Sin embargo, DLP, combinado
con la estrategia de autorización de seguridad y control físico (una red aislada en una instalación que aplica una
política que prohíbe todos los dispositivos electrónicos externos, incluidos los teléfonos móviles, ha eliminado
físicamente los puertos USB y periféricos de las computadoras de la instalación y registra a los empleados cuando
entran y salen de la instalación), tiene muchas más posibilidades de prevenir el robo de datos. Pero pocas
organizaciones ajenas a las encargadas de la seguridad nacional imponen este tipo de controles
Puntuación CFSS
Quizás inesperadamente, la estrategia centrada en datos no obtiene una gran puntuación CFSS por sí sola.
Después de todo, si la infraestructura subyacente utilizada para el cifrado, la gestión de claves, la autenticación,
la autorización , el registro, la DLP y otras funciones se ven comprometidas mediante uno o más de los
sospechosos habituales de ciberseguridad, los atacantes pueden obtener acceso a los datos antes de que se
cifren, o podrían obtener acceso a las credenciales o las claves de descifrado.
Proteger los datos es una mitigación poderosa, pero requiere que los componentes que lo hacen posible también
estén protegidos:
Amenaza interna 15
Tabla 9.10: Estimación de la puntuación CFSS para la estrategia centrada en datos
Le di a este enfoque calificaciones parciales para vulnerabilidades sin parches y configuraciones incorrectas de seguridad
porque puede proteger la confidencialidad e integridad de los datos, mientras que los equipos de administración de
vulnerabilidades escanean y actualizan los sistemas; al igual que la Estrategia de Protección y Recuperación, este enfoque
puede dar a los equipos de gestión de vulnerabilidades más tiempo para hacer esto.
También puede proteger los datos durante un período de tiempo después de la explotación de vulnerabilidades y
errores de configuración . Pero no evita que los atacantes destruyan los datos o los cifren ellos mismos usando
ransomware. Fundamentalmente, no evita que los atacantes aprovechen las vulnerabilidades de la infraestructura,
se muevan lateralmente, recopilen credenciales, persistan y recopilen datos antes de que se cifren en navegadores
web y clientes de correo electrónico, etc. Por supuesto, la mayoría de las credenciales en Microsoft Active Directory
y otros servicios de directorio modernos están cifradas, pero ese no es el enfoque de la estrategia centrada en datos.
No ofrece nada nuevo para proteger las contraseñas, ya que se basa en sistemas de identidad e identidades
federadas. Posteriormente, le di 0 de 20 por contraseñas débiles, filtradas y robadas.
Esta estrategia puede mitigar algunas formas de ingeniería social cuando se usa con el principio de privilegio mínimo
y una separación significativa de funciones. Esto también se aplica a las amenazas internas. Los datos cifrados
pueden permanecer confidenciales, incluso cuando los administradores cometen errores que conducen a resultados
de seguridad deficientes, pero existen límites. Los infiltrados maliciosos tendrán potencialmente más dificultades con
una separación significativa de funciones que limite su acceso a material clave. Por lo tanto, le di calificaciones
parciales tanto a la ingeniería social como a la amenaza interna.
Capítulo 9 373
Resumen de la estrategia centrada en datos

A pesar de su puntaje CFSS relativamente bajo, soy un fanático de la estrategia centrada en datos. Aunque no mitiga los
sospechosos habituales de ciberseguridad por sí mismo, actúa como una capacidad avanzada, proporcionando una
importante capa adicional de protección y detección. Las operaciones de cifrado y descifrado autenticadas y autorizadas
pueden ser muy eficaces para proteger los datos. El uso de los metadatos que describí también puede ser muy útil para
los equipos de seguridad. Para los CISO que intentan proteger todo como si tuviera el mismo valor para la organización
(lo que puede ser una receta para el desastre), puede ser muy útil reducir drásticamente el área de superficie de ataque
en la que deben concentrarse.
Para muchas organizaciones, la clasificación de datos puede ayudar a determinar qué conjuntos de datos deben enfocarse
en proteger. Pero la clasificación de datos es notoriamente difícil de implementar y cumplir. Los enfoques modernos para
el cifrado y la gestión de claves hacen que sea mucho más fácil y menos costoso cifrar todo todo el tiempo, especialmente
en la nube.
ventajas:
• Reduce potencialmente el área de superficie para proteger centrándose en los datos en el punto final, el correo
electrónico, la red, los servidores proxy y en la nube.
• Puede ayudar a proteger datos, detectar violaciones de datos y responder a incidentes más rápido de lo que
tradicionalmente es posible.
• El cifrado moderno y correctamente implementado puede proteger eficazmente los datos del acceso no autorizado
durante períodos relativamente prolongados. Esta vez puede ser útil, ya que los equipos de seguridad pueden
concentrarse en los fundamentos de ciberseguridad y otras capacidades avanzadas con más confianza.
• El cifrado puede ayudar a que la destrucción de datos sea más sencilla; destruir las llaves efectivamente destruye
los datos que protegen.
• DLP puede ser una herramienta poderosa para ayudar a evitar que los datos salgan de una organización y ayudar a
detectar la fuga de datos.
Desventajas:
• Muchas organizaciones encuentran que las políticas y tecnologías de clasificación de datos son difíciles de
implementar y usar de manera consistente a lo largo del tiempo. Posteriormente, muchas organizaciones han
intentado y no han logrado clasificar los datos de manera significativa.
• La administración de claves puede ser un desafío para algunas organizaciones. Una PKI local no es para los débiles
de corazón y requiere experiencia técnica. Una PKI fallida puede tener implicaciones desastrosas; la nube lo
hace mucho más fácil.

• Muchas organizaciones finalizan las comunicaciones cifradas para inspeccionar los datos y aplicar políticas de
DLP a medida que se mueven. El aumento del uso del cifrado para los datos en tránsito y en reposo ha
hecho que sea más difícil que DLP sea efectivo.
• Hacer cumplir las infracciones de la política de DLP puede ser un desafío para algunos CISO; ¿ Con qué
frecuencia se reprende a un alto ejecutivo por violar las políticas de DLP? Muchas organizaciones no hacen
cumplir adecuadamente las infracciones de políticas cuando DLP las marca.

• Se basa en una estrategia de identidad sólida y en la implementación de la identidad federada, que pueden
ser un desafío para diseñar, implementar, operar y gobernar.
Pasando a la siguiente estrategia de seguridad cibernética que discutiré, la estrategia centrada en el ataque.
Estrategia centrada en el ataque

La idea detrás de la estrategia centrada en el ataque es que las formas en que los equipos de seguridad protegen los
sistemas, detectan los compromisos y responden a los atacantes deben estar informadas por los TTP que los atacantes
realmente usan. Dicho de otra manera, comprender cómo operan los atacantes y planificar las defensas en torno a
eso hace que esas defensas sean más efectivas. La suposición subyacente de este enfoque es que obligar a los
atacantes a tener éxito varias veces durante los intentos de intrusión hace que sea mucho más difícil para ellos y
reduce los tiempos de detección y recuperación. El enfoque de este enfoque es comprender cómo operan los atacantes
y hacer que cada táctica y cada técnica que utilizan sean ineficaces. Reducir el retorno de la inversión de los atacantes
al aumentar el tiempo, el esfuerzo y los costos asociados con su ataque obligará a los atacantes a repensar o
abandonar su ataque. Este enfoque se caracteriza por inversiones en numerosas áreas para bloquear o impedir a los
atacantes en cada etapa de su ataque.
Dos ejemplos consumados de este enfoque son Intrusion Kill Chain de Lockheed Martin (Eric M. Hutchins, Michael J.
Cloppert y Rohan M. Amin, Ph.D.) y MITRE ATT&CK® (MITRE).
Ambos enfoques complementarios se basan en los pasos que toman los atacantes para atacar a sus víctimas y las
tácticas, técnicas y procedimientos específicos que utilizan. Por ejemplo, el método Intrusion Kill Chain define siete
fases o etapas durante un ataque: Reconocimiento, Armonización, Entrega, Explotación, Instalación, Comando y
Control, y Acciones sobre objetivos (Eric M. Hutchins, Michael J. Cloppert y Rohan M. Amin, Ph.D). Los atacantes
podrían usar algunas o todas estas fases en sus ataques. Sabiendo esto, las organizaciones pueden superponer sus
defensas para detectar, negar, interrumpir, degradar, engañar y destruir en cada etapa del ataque (Eric M. Hutchins,
Michael J. Cloppert y Rohan M. Amin, Ph.D.). Esto hará que sea mucho más difícil para los atacantes tener éxito
porque potencialmente deben vencer múltiples capas de defensas, diseñadas específicamente en torno a su modus
operandi.
Capítulo 9 375
De manera similar, MITRE ATT&CK® está diseñado para ser una base de conocimiento de los TTP de los atacantes. Durante
la última década, este marco ha ido evolucionando. MITRE lo describió de esta manera en un documento técnico de 2020,
ATT&CK se enfoca en cómo los adversarios externos comprometen y operan dentro de las
redes informáticas de información. Se originó a partir de un proyecto para documentar y
categorizar tácticas, técnicas y procedimientos (TTP) adversarios posteriores al compromiso
contra sistemas Microsoft Windows para mejorar la detección de comportamiento malicioso.
Desde entonces, ha crecido para incluir Linux y macOS, y se ha expandido para cubrir el
comportamiento que conduce al compromiso de un entorno, así como dominios centrados
en la tecnología, como dispositivos móviles, sistemas basados en la nube y sistemas de control industrial”.
(Strom, Applebaum, Miller, Nickels, Pennington y Thomas, 2020).
Hoy en día, ATT&CK se puede usar de varias maneras diferentes, incluidas las siguientes (Strom, Applebaum,
Miller, Nickels, Pennington y Thomas, 2020):
• Emular a los adversarios
• Ejercicios del equipo rojo/equipo azul
• Desarrollo de análisis de comportamiento
• Identificar brechas en las capacidades defensivas
• Evaluaciones de madurez del Centro de operaciones de seguridad (SOC)
• Enriquecimiento de la inteligencia sobre ciberamenazas (CTI)
Al igual que Intrusion Kill Chain, ATT&CK busca definir las tácticas (pasos desordenados u objetivos) que los atacantes
pueden tomar o quieren lograr en sus ataques, y las acciones específicas (técnicas y subtécnicas) que usan para lograr cada
táctica. Las tácticas en este marco incluyen reconocimiento , desarrollo de recursos, acceso inicial, ejecución, persistencia,
escalada de privilegios, evasión de defensa, acceso de credenciales, descubrimiento, movimiento lateral, recopilación,
comando y control, exfiltración e impacto.
Este marco proporciona una lista de las técnicas específicas que se sabe que los atacantes han utilizado en cada una de las
tácticas definidas. Por ejemplo, en la táctica de Reconocimiento, el paso de un ataque en el que los atacantes están
investigando su(s) objetivo(s), el marco proporciona actualmente 10 técnicas que los atacantes utilizan para realizar esta
investigación. Una de esas 10 técnicas es "Recopilar información de la organización de víctimas".

Actualmente, esta técnica tiene 4 subtécnicas asociadas, como "Relaciones comerciales", por ejemplo.
Esta subtécnica indica que los atacantes pueden recopilar información sobre las relaciones
comerciales que tienen sus objetivos, para evaluar si estas relaciones pueden aprovecharse en sus
ataques de alguna manera. El marco también proporciona ejemplos de procedimientos que los
atacantes pueden usar en cada subtécnica, junto con consejos de mitigación y detección.
Déjame darte otro ejemplo. Digamos que un atacante ha logrado el compromiso inicial de una red y ahora
quiere moverse lateralmente. Por supuesto, los defensores quieren que eso sea difícil o imposible. Según
ATT&CK, la táctica de movimiento lateral tiene 9 técnicas. Para los defensores, saber que hay 9 técnicas
es útil porque pueden tratar de implementar mitigaciones para cada una. Una de esas técnicas es el
phishing interno; los atacantes podrían decidir utilizar el phishing selectivo aprovechando el propio sistema
de correo electrónico de la organización víctima, para engañar a los trabajadores de la información
específicos para que revelen información y credenciales que permitan al atacante moverse lateralmente.
ATT&CK proporciona ejemplos de procedimientos que atacantes específicos han utilizado en el pasado
para hacer esto, así como recomendaciones de mitigación y detección. Esta técnica en particular no tiene
ninguna subtécnica asociada.
Comprender las tácticas, cada técnica y cada subtécnica ayuda a los defensores a diseñar e implementar
capas de capacidades que hacen que lograr cada táctica sea mucho más difícil o imposible.
El número de tácticas, técnicas y subtécnicas puede cambiar potencialmente con el tiempo cuando se
descubren nuevas. Posteriormente, ATT&CK es un marco vivo que continuará actualizándose . De acuerdo
con las preguntas frecuentes en su sitio web, planean actualizarlo dos veces al año (MITRE ATT&CK®, nd).
Es posible que haya notado que las tácticas definidas en ATT&CK son similares a los pasos definidos en el
enfoque Intrusion Kill Chain, pero un poco más detallados. MITRE incluye la siguiente pregunta y respuesta
en las preguntas frecuentes de su sitio web:
“¿Cuál es la relación entre ATT&CK y Lockheed Martin Cyber Kill Chain®?
ATT&CK y Cyber Kill Chain son complementarios. ATT&CK se encuentra en un nivel de definición más
bajo para describir el comportamiento del adversario que Cyber Kill Chain. Las tácticas ATT&CK no están
ordenadas y es posible que no todas ocurran en una sola intrusión porque los objetivos tácticos del
adversario cambian a lo largo de una operación, mientras que Cyber Kill Chain usa fases ordenadas para
describir objetivos adversarios de alto nivel”. (MITRE ATT&CK®, sin fecha)
Naturalmente, ha habido esfuerzos para combinar estos dos marcos. Un ejemplo es The Unified Kill Chain
que “…extiende y combina modelos existentes, como Cyber Kill Chain® de Lockheed Martins y ATT&CK™
for Enterprise de MITRE” (Pols, 2022).
Capítulo 9 377
A medida que ATT&CK ha evolucionado, se ha convertido en un enfoque muy popular para los equipos de
ciberseguridad. Este enfoque tiene mucho sentido para mí porque puede usarse para mitigar los sospechosos habituales
de ciberseguridad y también proporcionar capacidades avanzadas. La industria de la ciberseguridad se ha unido en
torno a este marco, con numerosos proveedores que ofrecen productos, servicios y ofertas de servicios profesionales
para apoyar a las organizaciones que desean adoptarlo.
Veamos cómo puntúa la estrategia centrada en el ataque usando el CFSS.
Puntuación CFSS
La estrategia centrada en el ataque tiene la puntuación CFSS más alta de todas las estrategias individuales que he
examinado en este capítulo. De hecho, mis estimaciones de cuán capaz es de abordar todos los fundamentos de
ciberseguridad le otorgan una puntuación casi perfecta, como se muestra en la Tabla 9.11:
Amenaza interna 20
Tabla 9.11: Estimación de la puntuación CFSS para la estrategia centrada en el ataque
La razón por la que este enfoque obtiene tan buenos resultados es que se centra en las formas en que los atacantes
comprometen inicialmente los entornos de TI y los métodos y herramientas que utilizan después del compromiso inicial.
Es decir, cubre todas las bases. La razón por la que no le di un 100/100 perfecto es que la ingeniería social es casi
imposible de mitigar por completo en las empresas. Tarde o temprano, alguien cometerá un error o una mala decisión
de confianza que conducirá a un resultado de seguridad subóptimo.
A pesar de los mejores esfuerzos de la industria para educar a los trabajadores de la información, ejecutivos y
administradores de TI , y diseñar software y hardware para dificultar el éxito de los ataques de ingeniería social, los
datos sugieren que los atacantes confían en él tanto como siempre. En un entorno en el que las mitigaciones para los
sospechosos habituales de la ciberseguridad están bien gestionadas, los atacantes se ven obligados a recurrir a la
única táctica que saben que tiene más posibilidades de éxito: la ingeniería social.
Continuarán confiando en los humanos para cometer errores y tomar malas decisiones de confianza, como sugiere la
investigación que proporcioné en el Capítulo 4, La evolución del malware .

Resumen de la estrategia centrada en el ataque

La estrategia centrada en el ataque obtuvo una puntuación CFSS muy alta. Puede ayudar a los CISO y sus equipos a
centrarse en los fundamentos de la ciberseguridad. Esta estrategia también es capaz de ayudar a los equipos de seguridad
a ir más allá de los fundamentos e implementar cuidadosamente capacidades avanzadas de ciberseguridad y ayudar a
proteger sus HVA. Dicho esto, para la mayoría de las organizaciones que tienen recursos limitados, no es fácil ni
económico diseñar, adquirir, implementar, operar y admitir capas y capas de capacidades de ciberseguridad. Muchas
organizaciones que aspiran a utilizar este enfoque se dan cuenta de que no tienen la experiencia técnica o el presupuesto
para realmente adoptarlo a largo plazo.
Dependiendo de la estrategia o estrategias anteriores que una organización haya aprovechado, es posible que solo haya
invertido en protección, pero no necesariamente en detección y respuesta. Posteriormente, si comienzan a utilizar la
estrategia centrada en ataques, es probable que aumenten la inversión en capacidades de detección y respuesta.
ventajas:
• Potencialmente nivela el campo de juego entre atacantes y defensores ya que ambos están bajo
soportar los TTP de los atacantes
• Obliga a los atacantes a tener éxito varias veces en lugar de solo una o dos veces, lo cual es
cuántas de las otras estrategias de ciberseguridad están diseñadas
• Diseñado para ayudar a detectar intrusiones lo antes posible en el ataque, a fin de reducir el tiempo y los costos de
remediación y recuperación
• Un vasto ecosistema de proveedores para ayudar
Desventajas:
• Este enfoque requiere que la mayoría de las organizaciones aumenten las inversiones en detección y re
capacidades de respuesta, lo que suele aumentar la complejidad y los costos.
• Por lo general, depende de la tecnología de múltiples proveedores para trabajar en conjunto para proteger, detectar y
responder a las amenazas. Esto podría requerir experiencia técnica en tecnologías de múltiples proveedores, lo
que podría no ser un requisito realista para muchas organizaciones con

recursos limitados y talento técnico.
• Debido a todas las capas que requiere este enfoque, puede ser un desafío diseñar,
implementar y operar.
• Esta puede ser una estrategia relativamente costosa de seguir.
A continuación, veamos una estrategia que actualmente es extremadamente popular en la industria, Zero Trust.
Capítulo 9 379
Confianza cero
Una de las suposiciones subyacentes de todas las estrategias que he discutido en este capítulo es que una vez
que un usuario o sistema ha autenticado el acceso al entorno de TI, entonces es de confianza. La popularidad
de esta conveniente capacidad se evidencia por la ubicuidad de los requisitos de Single SignOn (SSO) entre
las empresas. Es interesante que esta suposición sea tan antigua como las estrategias más antiguas que he
examinado. Esta suposición no ha cambiado mucho desde que las empresas comenzaron a adquirir sus
primeras PC. Algunos argumentarán que esta suposición es una de las razones por las que la industria ha visto
tantas filtraciones de datos durante décadas. Creo que es justo decir que los campeones del modelo Zero Trust
estarían de acuerdo con esto. Aunque muchos consideran que este enfoque es nuevo, fue concebido por
primera vez hace casi 20 años por un grupo de CISO, según la tradición de la industria.
El concepto detrás de este enfoque es que todos los recursos, incluidos los que se encuentran dentro del perímetro,
debe ser desconfiado. Esto tiene mucho sentido en un mundo donde cada vez menos infraestructura de TI y
cada vez menos trabajadores de la información están detrás de los cortafuegos corporativos. Por ejemplo, la
explosión en curso de dispositivos IoT debería superar fácilmente la cantidad de PC y servidores de escritorio
en los centros de datos, de la misma manera que los dispositivos móviles los han eclipsado drásticamente en
los últimos 15 años. Además, como mencioné en mi examen de la estrategia de protección y recuperación, la
historia nos ha enseñado que el enfoque de seguridad perimetral de la vieja escuela, en sí mismo, es un fracaso
porque se ha demostrado que sus suposiciones subyacentes son tremendamente optimistas. Recordará que
una de esas suposiciones era que los equipos de seguridad podían lograr una protección perfecta, para siempre,
y no requerían inversiones en capacidades de detección y respuesta.
Si asumimos que no se puede confiar en todo el tráfico de la red, los sistemas, los dispositivos y los usuarios,
independientemente de si se encuentran detrás de un perímetro empresarial, esto podría cambiar el enfoque
de un equipo de seguridad de manera sustancial. Autenticar y autorizar aplicaciones, conexiones de red,
dispositivos y usuarios para cada operación que intentan, en lugar de solo en el momento del primer acceso,
puede dificultar que los atacantes comprometan inicialmente un entorno, se muevan lateralmente, permanezcan
persistentes y obtengan acceso a datos confidenciales. No confíes y verifica siempre.
Sin embargo, por sí solo, la aplicación de un principio de diseño que requiere autenticación y autorización casi
constantes para usuarios, sistemas y dispositivos no aborda las vulnerabilidades sin parches, las configuraciones
incorrectas de seguridad, la ingeniería social o las amenazas internas no maliciosas. Recuerde el cliché, "los
atacantes no entran, inician sesión". Si un atacante tiene credenciales válidas, ¿qué ayuda realmente a mitigar
la autenticación cada vez que intenta acceder a un recurso? Este enfoque requiere una fuerte verificación de
identidad y que el principio de privilegio mínimo se aplique religiosamente, al igual que algunas de las otras
estrategias que he discutido.
En consecuencia, Zero Trust necesita muchos otros elementos para convertirse en una estrategia de seguridad
cibernética completa.
Combine el rigor de la autenticación y autorización casi constantes con las capacidades de la estrategia
centrada en la identidad que mencioné anteriormente, y este enfoque puede ayudar a tomar mejores decisiones
de autenticación y autorización en tiempo real. Este enfoque también podría beneficiarse de muchas de las
capacidades de la estrategia de protección de puntos finales para proporcionar la visibilidad y el control
necesarios en los puntos finales. Algunos proveedores están resucitando e integrando capacidades de tipo
Control de acceso a la red (NAC) y Protección de acceso a la red (NAP) en sus ofertas de productos Zero
Trust para garantizar que los puntos finales cumplan con las políticas corporativas, como estar completamente
parcheado y ejecutando protección antimalware actualizada , entre otros requisitos. Dicho de otra manera,
estas capacidades permiten a la empresa tratar sus propios terminales como no confiables, manteniéndolos
desconectados de la red corporativa interna hasta que demuestren que deben ser confiables al cumplir con los estándares de segu
De hecho, Zero Trust podría tomar prestado algo de todas las estrategias que analicé en este capítulo para
abordar todos los fundamentos de ciberseguridad y agregar capacidades avanzadas. Esto es de hecho lo que
ha estado sucediendo. Casi todos los proveedores de ciberseguridad hoy en día ofrecen algún tipo de Zero Trust
producto o línea de productos para apoyar a las organizaciones que quieren adoptar el concepto de tratar todo
como si no fuera de confianza. Buscar en Google "Zero Trust security" resultó en 334,000,000 resultados.
Dado que hay tanto interés en el concepto, pero el concepto en sí se puede implementar de muchas maneras,
los proveedores y otras partes interesadas, como los gobiernos, brindan sus propias visiones de lo que significa
Zero Trust y cómo se debe implementar. Aquí hay unos ejemplos.
Servicios web de Amazon (https://aws.amazon.com/security/zerotrust/):
Zero Trust es un modelo de seguridad centrado en la idea de que el acceso a los datos no
debe realizarse únicamente en función de la ubicación de la red. Requiere que los usuarios y
los sistemas demuestren firmemente sus identidades y confiabilidad, y aplica reglas de
autorización detalladas basadas en la identidad antes de permitirles acceder a aplicaciones,
datos y otros sistemas. Con Zero Trust, estas identidades a menudo operan dentro de redes
conscientes de la identidad altamente flexibles que reducen aún más el área de superficie,
eliminan las rutas innecesarias a los datos y proporcionan barreras de seguridad externas
sencillas”. ( Servicios web de Amazon, 2022).

Capítulo 9 381
Cisco (https://www.cisco.com/c/en/us/solutions/collateral/enterprise/designzone
security/ztframeworks.html):
La seguridad no es una talla única para todos y Zero Trust es más que la segmentación de la red.
Para ayudar a comprender la arquitectura, Cisco la ha dividido en tres pilares:
• Seguridad de usuarios y dispositivos: garantizar que se pueda confiar en los usuarios y dispositivos cuando acceden
a los sistemas, independientemente de su ubicación
• Seguridad de la red y la nube: proteja todos los recursos de la red en las instalaciones y en el
nube y garantizar un acceso seguro para todos los usuarios conectados
• Seguridad de datos y aplicaciones: prevención del acceso no autorizado dentro de los entornos de las aplicaciones,
independientemente de dónde estén alojadas” (Cisco, 2022)
Google (https://storage.googleapis.com/pubtoolspublicpublicationdata/pdf/43231.
pdf):
La iniciativa BeyondCorp de Google avanza hacia un nuevo modelo que prescinde de una red corporativa privilegiada.
En cambio, el acceso depende únicamente del dispositivo y las credenciales del usuario, independientemente de la
ubicación de la red del usuario, ya sea una ubicación empresarial, una red doméstica, un hotel o una cafetería. Todo
el acceso a los recursos de la empresa está totalmente autenticado, totalmente autorizado y totalmente encriptado
según el estado del dispositivo y las credenciales del usuario. Podemos hacer cumplir el acceso detallado a diferentes
partes de los recursos de la empresa. Como resultado, todos los empleados de Google pueden trabajar con éxito
desde cualquier red y sin la necesidad de una conexión VPN tradicional a la red privilegiada.
La experiencia del usuario entre el acceso local y remoto a los recursos de la empresa es prácticamente idéntica,
aparte de las posibles diferencias en la latencia”. (Ward, R., Beyer, B., 2014).
Microsoft (https://www.microsoft.com/enus/security/business/zerotrust):
Definición de confianza cero
En lugar de asumir que todo lo que está detrás del firewall corporativo es seguro, el modelo Zero Trust asume la violación y
verifica cada solicitud como si se originara en una red abierta. Independientemente de dónde se origine la solicitud o a qué
recurso acceda, Zero Trust nos enseña a "nunca confiar, siempre verificar". Cada solicitud de acceso se autentica, autoriza
y cifra por completo antes de conceder el acceso. Se aplican principios de microsegmentación y acceso con privilegios
mínimos para minimizar el movimiento lateral. Se utilizan análisis e inteligencia enriquecidos para detectar y responder a
anomalías en tiempo real”. (Corporación Microsoft, 2022).
La Casa Blanca Orden ejecutiva sobre la mejora de la ciberseguridad de la nación (https://www.

whitehouse.gov/briefingroom/presidentialactions/2021/05/12/executiveorderon
improveingthenationscybersecurity/ ):
Capítulo 9 383
…el término “Arquitectura Zero Trust” se refiere a un modelo de seguridad, un conjunto de
principios de diseño de sistemas y una estrategia coordinada de administración de sistemas y
ciberseguridad basada en el reconocimiento de que las amenazas existen tanto dentro como
fuera de los límites de la red tradicional. El modelo de seguridad Zero Trust elimina la confianza
implícita en cualquier elemento, nodo o servicio y, en cambio, requiere una verificación
continua de la imagen operativa a través de información en tiempo real de múltiples fuentes
para determinar el acceso y otras respuestas del sistema. En esencia, una arquitectura de
confianza cero permite a los usuarios acceso total, pero solo al mínimo que necesitan para
realizar su trabajo. Si un dispositivo se ve comprometido, Zero Trust puede garantizar que se
contenga el daño. El modelo de seguridad Zero Trust Architecture asume que una infracción
es inevitable o que probablemente ya se ha producido, por lo que constantemente limita el
acceso solo a lo que se necesita y busca actividad anómala o maliciosa. Zero Trust Architecture
incorpora un monitoreo de seguridad integral; controles de acceso granulares basados en
riesgos; y la automatización de la seguridad del sistema de manera coordinada en todos los
aspectos de la infraestructura para centrarse en proteger los datos en tiempo real dentro de un entorno de amenazas d
Este modelo de seguridad centrado en los datos permite que se aplique el concepto de acceso
con privilegios mínimos para cada decisión de acceso, donde las respuestas a las preguntas
de quién, qué, cuándo, dónde y cómo son fundamentales para permitir o denegar el acceso a
los recursos según la combinación de servidor [sic]”.
La última definición que proporcioné de la Orden Ejecutiva 14028 publicada por la Casa Blanca tiene un impacto en
el mundo real. Zero Trust se menciona once veces en esa Orden Ejecutiva, que instruye a las ramas del gobierno de
los EE. UU. a implementar Zero Trust para mejorar su ciberseguridad. Al hacer esto, esta Orden Ejecutiva también
instruyó a todos los proveedores de TI y ciberseguridad en el mundo que ya venden productos y servicios al gobierno
de los EE. UU., o aspiran a hacerlo, para respaldar esta definición de Zero Trust o elementos de esta. Como
mencioné en el Capítulo 6, Los roles que juegan los gobiernos en la seguridad cibernética , cuando el organismo de
estándares y consumidor de TI más grande del mundo establece requisitos, toda la industria presta atención, ya que
todos quieren su parte de ese negocio. Sin embargo, quedan muchas preguntas sobre cómo implementar dicha
arquitectura, especialmente a escalas masivas sugeridas por

Orden Ejecutiva 14028.
¿ Cómo calificamos Zero Trust usando el CFSS?
Puntuación CFSS
Dada la cantidad de descripciones y definiciones de Zero Trust, no estoy seguro de poder darle una sola
puntuación CFSS. Parece que la puntuación es una función de la implementación específica utilizada. Por
ejemplo, ¿cómo aborda este enfoque las vulnerabilidades sin parchear? El simple aumento de la frecuencia de
los eventos de autenticación y autorización para un usuario, sistema o dispositivo no hace nada para mitigar
este sospechoso habitual de ciberseguridad. Sin embargo, si extiende este principio a los puntos finales, los
trata como si no fueran de confianza y obliga a que se parcheen por completo antes de obtener acceso a los
recursos corporativos, entonces podría mitigar casi por completo la amenaza que representan las
vulnerabilidades sin parchear . Este enfoque también podría reducir drásticamente la escala y el alcance de su
programa de administración de vulnerabilidades porque los puntos finales tendrían que escanearse a sí mismos
en busca de actualizaciones de seguridad faltantes e instalarlas antes de obtener acceso a la red. Lograr que
los terminales hagan ese trabajo en lugar de un programa centralizado de administración de vulnerabilidades
puede ayudar a reducir la presión sobre el programa y al mismo tiempo reducir el riesgo para la empresa. El
equipo de gestión de vulnerabilidades podría reducir la frecuencia de análisis de los sistemas que realizan sus
propios parches, tal vez semanal o mensualmente, para identificar los sistemas que no se actualizan como se esperaba.
Por supuesto, confiar en los terminales para probar su propia integridad está plagado de desafíos. ¿ Los puntos
finales no son de confianza o no? ¿Confiamos en ellos lo suficiente como para decirnos si son lo suficientemente
seguros para conectarse a la red corporativa? ¿No significaría Zero Trust que se requiere algún tipo de servicio
de atestación remota que se ejecute en hardware separado de los puntos finales para determinar si los puntos
finales cumplen con los estándares de seguridad? ¿Dónde trazamos la línea? Parece que la respuesta a esta
pregunta se deja a cada organización y proveedor individual. Si somos honestos entre nosotros, Zero Trust aún
requiere que las organizaciones confíen en un montón de tecnologías para probar si se debe confiar en otras
tecnologías. Entonces, en este caso, "cero" no significa ninguno.
Capítulo 9 385
Google ofrece un punto de vista interesante aquí:
Una de las palabras de moda más utilizadas en ciberseguridad hoy en día es, sin duda, “Zero Trust”.
Se ha utilizado para describir una amplia gama de enfoques y productos, lo que genera cierta
confusión sobre el término en sí y lo que realmente significa. Algunos intentos de explicar o
simplificar la confianza cero afirman que "la confianza cero significa no confiar en nada" o "la
confianza cero se trata de brindar acceso seguro sin una VPN". Esta sabiduría convencional es
mayormente incorrecta y limitante. En el centro de un enfoque de confianza cero se encuentra la
idea de que la confianza implícita en cualquier componente individual de un sistema interconectado
complejo puede crear riesgos de seguridad significativos. En cambio, la confianza debe
establecerse a través de múltiples mecanismos y verificarse continuamente. Si bien el acceso del
usuario final es un dominio al que se puede aplicar este modelo para obtener mejoras de seguridad
significativas, se puede aplicar con la misma facilidad a dominios como el proceso de extremo a
extremo de ejecutar sistemas de producción y proteger las cargas de trabajo en la infraestructura
nativa de la nube”. (Brewer, E. y Venables, P., 2021).
Mi conclusión es que no puedo proporcionar una puntuación CFSS para Zero Trust. No es una estrategia de
ciberseguridad, es un principio o filosofía de diseño que se puede aplicar con la prudencia que sea necesaria. Podría
aplicarse a los mecanismos utilizados para mitigar todos los Sospechosos Habituales de Ciberseguridad o no aplicarse en absoluto.
Buscar suposiciones de confianza implícitas en los modelos de amenazas puede generar mejoras positivas en las
posturas de seguridad de muchas organizaciones. No creo que haya ninguna duda al respecto. Por ejemplo, podría
desafiar a algunos desarrolladores a intentar diseñar aplicaciones de comercio electrónico capaces de realizar
transacciones en sistemas que se supone que están comprometidos. El resultado debería ser mejor que asumir que el
sistema nunca se verá comprometido, ¿verdad?

Sin embargo, el éxito de este enfoque dependerá de su implementación. Por ejemplo, mencioné que algunos
proveedores están usando NAC/NAP en sus soluciones Zero Trust . La razón por la que NAC/NAP fracasó la primera
vez que se hicieron populares en la industria es por la horrible experiencia de usuario que imponían a los usuarios.
Todos los usuarios de VPN que se conectaron a su oficina, donde se implementaron NAC/NAP , tuvieron la misma
experiencia temida en un momento u otro; solo querían revisar sus correos electrónicos, descargar una presentación u
obtener acceso rápido a alguna información, solo para ser puestos en cuarentena y obligados a descargar e instalar
lentamente actualizaciones de seguridad, firmas antivirus, soportar reinicios, etc. A pesar de las ventajas positivas de
asegurarse de que los sistemas se parchearan antes de conectarse a la red corporativa, la experiencia del usuario se
degradaba tanto que los usuarios evitaban conectarse a la red durante todo el tiempo que podían. Cuando finalmente
tuvieron que conectarse a la red, la experiencia del usuario fue aún peor debido a la acumulación de actualizaciones que
requería el sistema. Esto tuvo el efecto opuesto en la seguridad de lo que se pretendía. Aquellos proveedores que
ofrecen Zero Trust
las soluciones que aprovechan este mismo enfoque están condenadas al mismo destino. Los usuarios solo lidiarán con
una sobrecarga en su trabajo diario antes de que intenten evitarlo activamente o solucionarlo.
La experiencia del usuario no debería ser peor en entornos con implementaciones de Zero Trust , debe ser mejor. Es
probable que este factor decida la efectividad y el destino de Zero Trust.
¡Hemos cubierto bastante terreno! Concluyamos nuestra revisión de las estrategias de seguridad cibernética resumiendo
lo que hemos estado discutiendo.
Resumen de estrategias de ciberseguridad

Hemos revisado varias estrategias populares de ciberseguridad. Estas estrategias incluyen:
• Estrategia de Control Físico y Autorizaciones de Seguridad
• El cumplimiento como estrategia de ciberseguridad
• Estrategia centrada en el ataque
También discutimos Zero Trust, que concluí que no era una estrategia de la misma manera que las demás.
en la lista están.
Capítulo 9 387
En la Tabla 9.12 se proporciona un resumen de mis estimaciones de puntuación CFSS para estas estrategias . Como
puede ver, le di a la estrategia centrada en el ataque la puntuación CFSS estimada más alta. En mi opinión, es la única
estrategia que tiene el mayor potencial para ayudar a las organizaciones a abordar los fundamentos de la ciberseguridad,
mitigar los sospechosos habituales de la ciberseguridad y, potencialmente, ayudar a implementar capacidades avanzadas:
Débil,
Vulnerable sin Error de filtrado, sto len
La seguridad cibernética parchear configuración de seguridad creden Social es Persona enterada Total
Estrategia idades Uraciones ciales ingenieria amenaza Puntaje
Proteger y 10 10 0 5 0 25
Estrategia de recuperación
Estrategia de 20 20 15 10 10 75
protección de terminales
Control Físico y 10 10 15 10 10 55
Seguridad
Liquidaciones
Estrategia
El cumplimiento 10 10 10 10 10 50
como ciberseguridad
Estrategia
Aplicar 20 20 10 10 10 70
Centrado en la ción
Estrategia
centrado en la identidad 5 5 15 10 10 45
Estrategia
Centrado en datos 5 5 0 15 15 40
Estrategia
Centrado en el ataque 20 20 20 15 20 95
Estrategia
Tabla 9.12: Resumen de estimación de puntuación CFSS

La realidad es que la mayoría de las organizaciones con las que me he reunido usan una combinación de algunas de estas
estrategias . Por ejemplo, sería audaz para una empresa no tener una estrategia de seguridad perimetral y una estrategia de
seguridad de punto final, incluso cuando la industria ofrece tecnologías más nuevas y brillantes. Muchas organizaciones tienen
algunos requisitos de cumplimiento normativo a los que deben prestar atención. Puede ser útil para aquellas organizaciones que
ya usan algunos de estos enfoques reconciliar deliberada y cuidadosamente dónde ha habido inversión excesiva y falta de
inversión, y dónde existen brechas actualmente. Esta es otra ventaja que tiene la estrategia centrada en el ataque sobre estas
otras estrategias y combinaciones de ellas: la inversión y el análisis de brechas están integrados directamente en ella. Discutiré
esto con más detalle en el Capítulo 11, Medición del desempeño y la efectividad.
Es posible que no esté de acuerdo con mis estimaciones de puntaje CFSS para algunas o todas estas estrategias. Eso es bueno.
Lo animo a usar el CFSS para realizar sus propias estimaciones de calificación para todos los enfoques que examiné en este
capítulo y otros que no cubrí. Todos los profesionales de la seguridad tienen diferentes experiencias, lo que podría llevarlos a
calificar una o más de estas estrategias más alto o más bajo que yo. Francamente, esto es de esperar ya que nunca he conocido
a un profesional de la seguridad que no tenga una opinión. A pesar de esto, la mayoría de las organizaciones no tienen una
estrategia de ciberseguridad que sus CISO u otros ejecutivos puedan articular. Mi objetivo para este capítulo es provocar un
pensamiento crítico sobre las formas en que las organizaciones han abordado la seguridad cibernética y tal vez ofrecer un
espejo para que los CISO y los equipos de seguridad lo miren.
Ahora, veamos un enfoque potencialmente útil que es diferente, en algunos aspectos importantes, de los enfoques más clásicos
discutidos en este capítulo.
DevOps y DevSecOps
DevOps representa un cambio en la forma en que las organizaciones han abordado tradicionalmente el desarrollo y la
implementación de aplicaciones. Tradicionalmente, los desarrolladores y el personal de operaciones se administraban como
disciplinas separadas que rara vez trabajaban juntas. Los desarrolladores escribían el código según las especificaciones y
cuando querían implementarlo, "lo tiraban por la borda" al equipo de operaciones. A veces, el equipo de operaciones encontraba
problemas al implementar la aplicación, por lo que la devolvía al equipo de desarrollo con los problemas que impedían una
implementación exitosa. Los desarrolladores y las operaciones repetirían este proceso, normalmente a un ritmo lento y frustrante.
Debido a que estos grupos solo se comunicaban entre sí periódicamente, los desarrolladores a menudo carecían del contexto
operativo y ambiental que los ayudaría a desarrollar aplicaciones que pudieran implementarse y operarse en un entorno de TI
real. De manera similar, los equipos de operaciones a menudo no tenían los detalles técnicos de la aplicación para ayudarlos a
realizar implementaciones exitosas.

Capítulo 9 389
El ciclo de retroalimentación entre los equipos era lento, lo que generaba retrasos en los hitos, ciclos de desarrollo
lentos y problemas de calidad.
DevOps intenta abordar estos desafíos integrando estrechamente a los desarrolladores y al personal de operaciones.
Pueden intercambiar comentarios de manera más eficiente y rápida cuando trabajan juntos día tras día. El personal
de operaciones puede informar las opciones de diseño y funcionalidad que toman los desarrolladores mientras
desarrollan la aplicación. Los desarrolladores pueden obtener comentarios constantes sobre la viabilidad y
compatibilidad de sus ideas del personal de operaciones. Esto puede conducir a ciclos de desarrollo e implementación
más rápidos, aplicaciones de mejor calidad, menos reelaboración y equipos más felices.
DevOps generalmente incluye conceptos como pruebas continuas, integración continua (CI), entrega continua (CD),
implementación continua y monitoreo continuo del rendimiento. Esto va más allá de las tecnologías, los servicios y
los productos que respaldan estos conceptos porque la mayoría de las organizaciones deben realizar cambios
significativos en sus filosofías, culturas y procesos de desarrollo para adoptar DevOps.
DevSecOps es DevOps con el reconocimiento explícito de que la seguridad debe estar integrada en las filosofías,
culturas, procesos y tecnologías de soporte para que este enfoque tenga éxito.
Algunos argumentan que el "Sec" en DevSecOps es gratuito porque DevOps no se puede hacer correctamente sin
incorporar seguridad en él. Estoy de acuerdo de todo corazón. Si su organización actualmente está haciendo DevOps
y ha decidido que evolucionará hacia un enfoque DevSecOps más adelante, entonces es probable que ya esté
haciendo DevOps mal. Recuerde, alguien dijo recientemente que "la cultura se come la estrategia para el desayuno
". Es por eso que DevOps es potencialmente tan poderoso y transformador para las organizaciones de TI.
El valor de DevOps se amplía cuando se utiliza junto con contenedores y/o computación en la nube. Por ejemplo,
dado que la infraestructura es código en la nube, la infraestructura se implementa, configura y admite mediante
código. Esto significa que el aprovisionamiento y la gestión de la infraestructura en la nube pueden beneficiarse de
las virtudes de DevOps. Los desarrolladores pueden especificar el hardware, el software y la configuración de la
infraestructura en el código que escriben, informados por los requisitos y la retroalimentación continua proporcionada
por los equipos de operaciones. Este enfoque permite a las organizaciones aprovisionar infraestructura más rápido
que los enfoques tradicionales y prácticamente a cualquier escala deseada.
Desde una perspectiva de seguridad, DevOps ofrece un modelo poderoso para construir e implementar aplicaciones
e infraestructura. Aquí es donde el concepto de canalización de CI/CD es útil. La canalización generalmente maneja
funciones como verificar el código en un repositorio, la construcción automatizada, las pruebas automatizadas y la
implementación del código probado en producción. La canalización en sí puede estar compuesta por una combinación
de herramientas, productos y servicios de uno o varios proveedores. Algunas organizaciones que han adoptado
DevOps implementan todas las aplicaciones y toda la infraestructura a través de una canalización de CI/CD.
Dicho de otra manera, nada entra en sus entornos de producción a menos que pase por una tubería. Hacer cumplir
políticas de canalización como esta puede ofrecer a las organizaciones al menos algunas ventajas frente a los enfoques
heredados. Por ejemplo, cuando se requiere que las aplicaciones y la infraestructura pasen por una canalización y la
canalización tiene verificaciones automatizadas para garantizar que se cumplan los estándares normativos, de la industria
y de seguridad interna , entonces todo lo que llega a la producción está en este buen estado conocido.
Esta garantía hace posibles los entornos de corta duración al permitir que la infraestructura se descarte y se vuelva a
implementar en un buen estado conocido, cada pocas horas. Si esa infraestructura se ve comprometida, los atacantes
solo tendrán el control de ese activo durante un tiempo relativamente corto antes de que se elimine y se reemplace. Esto
puede dificultar que los atacantes se establezcan en un entorno y permanezcan persistentes. También puede ayudar a
reducir drásticamente la cantidad de trabajo de los equipos de gestión de vulnerabilidades. En lugar de realizar
constantemente inventarios de sistemas, escanearlos en busca de vulnerabilidades de seguridad, parchearlos y
reiniciarlos, pueden escanear y parchear la cantidad relativamente pequeña de "imágenes doradas" utilizadas para
implementaciones de infraestructura. Cuando se descarta y reemplaza una infraestructura de corta duración, la nueva
infraestructura se basa en la imagen dorada actualizada. Verificar el estado de los parches de una infraestructura de corta
duración es menos trabajo para los equipos de administración de vulnerabilidades y menos disruptivo para el negocio.
Existen ventajas similares para los equipos de cumplimiento, así como

como auditores internos y externos.
Por supuesto, DevOps no es una panacea. Las canalizaciones de DevOps y CI/CD mal hechas pueden ser malas para
las organizaciones. Hasta la fecha, la mayoría de las organizaciones con las que he hablado de DevOps solo lo usan en
partes de su entorno de TI, y el resto de la organización todavía está encadenada a modelos heredados.
Los desarrolladores pueden enamorarse de las canalizaciones de CI/CD. Por ejemplo, los desarrolladores que adoptan
canalizaciones de CI/CD pueden terminar dedicando más tiempo a desarrollar herramientas y automatización para sus
canalizaciones que a trabajar en aplicaciones e infraestructura. Las organizaciones también pueden terminar con
demasiadas canalizaciones de CI/CD. Como era de esperar, algunos atacantes ven a las víctimas potenciales cambiar a
DevOps y usar canalizaciones de CI/CD, por lo que apuntan a la infraestructura de la canalización en sí; Las canalizaciones
de CI/CD podrían terminar convirtiéndose en HVA para algunas organizaciones y requerir más rigor de seguridad de lo
que inicialmente estaban preparados.
Creo que las ventajas de seguridad y no relacionadas con la seguridad de las canalizaciones de DevOps y CI/CD superan
cualquier desafío que presenten. Esta es la razón por la cual toda la industria se ha estado moviendo hacia este modelo
y continuará haciéndolo por muchos años más.

Capítulo 9 391
Resumen
Los CISO y los equipos de seguridad deben seleccionar la estrategia de seguridad cibernética de su organización
en función de qué tan bien aborda los fundamentos de seguridad cibernética, como la barra mínima. Sin examinar
cómo su estrategia mitiga todos los sospechosos habituales de ciberseguridad, podrían estar arrullándose con una
falsa sensación de seguridad. El CFSS puede ayudar a los equipos de seguridad a determinar qué tan bien sus
estrategias actuales o futuras abordan los fundamentos de la ciberseguridad.
De las estrategias examinadas en este capítulo, la estrategia centrada en el ataque se consideró la estrategia
más capaz de mitigar los sospechosos habituales de ciberseguridad y habilitar capacidades avanzadas de
ciberseguridad. La estrategia de protección de endpoints y la estrategia centrada en aplicaciones completaron
las tres estrategias principales en esta evaluación, pero deberán usarse en combinación con otras estrategias
para abordar completamente los fundamentos de ciberseguridad.
El enfoque Zero Trust tiene el potencial de elevar la línea de flotación de seguridad para toda la industria.
Pero cómo se implementa este enfoque y la experiencia de usuario que impone determinará su eficacia y su
destino.
DevOps es un enfoque holístico que conduce a cambios en las filosofías, culturas y procesos de desarrollo
de las organizaciones que lo adoptan. Este es el destino al que muchas organizaciones aspiran llegar. Es
posible que este enfoque no sea tan beneficioso para los entornos de TI heredados, donde las estrategias
de ciberseguridad más tradicionales que examiné podrían usarse durante la transición a arquitecturas
modernas, como la nube.
Eso completa mi examen de las estrategias de ciberseguridad. En el próximo capítulo, profundizaremos en

un ejemplo de implementación de la estrategia que tuvo el puntaje total estimado CFSS más alto, la estrategia
centrada en el ataque.
Referencias
• Servicios web de Amazon. (2022). Confianza cero en AWS. Obtenido de: https://aws.amazon.
com/security/ceroconfianza/
• Ashford, W. (3 de agosto de 2016). Una de cada cinco empresas afectadas por ransomware se ve obligada
a cerrar, según muestra un estudio. Obtenido de ComputerWeekly: https://www.computerweekly.com/
news/450301845/Una de cada cinco empresas afectadas por ransomware se ven obligadas a cerrar
programas de estudio
• Brewer, E., Venables, P. (25 de agosto de 2021). Un sistema Zero Trust unificado y probado con Be
yondCorp y BeyondProd. Obtenido de: https://cloud.google.com/blog/products/
seguridaddeidentidad/aplicacióndeconfianzaceroalosserviciosdeaccesoyproduccióndelusuario
• Cisco. (27 de junio de 2022). Guía de arquitectura de marcos de confianza cero. Obtenido de: https://
www.cisco.com/c/en/us/solutions/collateral/enterprise/designzonesecurity/
ztframeworks.html
• Hutchins, EM, Cloppert, MJ, Amin, RM Ph.D. (Dakota del Norte). Defensa de redes informáticas basada
en inteligencia informada por análisis de campañas adversarias y cadenas de eliminación de intrusos.
Obtenido de Lockheed Martin: https://lockheedmartin.com/content/dam/lockheedmartin/
rms/documents/cyber/LMWhitePaperIntelDrivenDefense.pdf
• Consejo Europeo de Protección de Datos. (2019). Primer resumen sobre la implementación del RGPD y
los roles y medios de las autoridades nacionales de supervisión. Bruselas: datos europeos
Junta de Protección.
• Corporación Microsoft. (2 de septiembre de 2022). Acceso privilegiado: Estrategia.

Obtenido de Microsoft: https://learn.microsoft.com/enus/security/compass/privileged
estrategia de acceso
• Corporación Microsoft. (Dakota del Norte). Ingeniería de seguridad de Microsoft. Obtenido de Microsoft
Corporación: https://www.microsoft.com/enus/securityengineering/sdl/
• Corporación Microsoft. (2022). Adopte la seguridad proactiva con Zero Trust. Obtenido de Microsoft
Corporation: https://www.microsoft.com/enus/security/business/zero
confianza/
• MITRE ATT&CK®. (Dakota del Norte). MITRE ATT&CK Preguntas frecuentes.

Obtenido de MITRE ATT&CK®: https://attack.mitre.org/resources/faq/
• INGLETE. (Dakota del Norte). MITRE ATT&CK. Obtenido de MITRE ATT&CK®: https://attack.mitre.
org/
• Strom, BE, Applebaum, A., Miller, DP, Nickels, KC, Pennington, AG y Thomas, CB
(2020). MITRE ATT&CK®: Diseño y Filosofía. Corporación MITRE
• NIST. (Dakota del Norte). Marco de ciberseguridad. Obtenido de NIST: https://csrc.nist.gov/

Projects/cybersecurityframework/nistcybersecurityframeworkaquick
guía de inicio
Capítulo 9 393
• NIST. (Dakota del Norte). Marco de ciberseguridad. Obtenido de NIST: https://www.nist.gov/

marco cibernético
• Consultoría PA. (Dakota del Norte). Diodo de datos de puerta de roble. Obtenido de PA Consulting: https://www.
paconsulting.com/services/buildbrandsproductsandservices
• Pols, Paul. (Octubre 2022). La cadena de muerte unificada. Recuperado de: https://www.
unifiedkillchain.com/assets/TheUnifiedKillChain.pdf
• La Casa Blanca. (Mayo 2021). Orden Ejecutiva para Mejorar la Ciberseguridad de la Nación.
Obtenido de: https://www.whitehouse.gov/briefingroom/presidential
acciones/2021/05/12/ordenejecutivaparamejorarlaciberseguridaddelasnaciones/
• Oficina del Gabinete del Reino Unido. (mayo de 2018). Clasificaciones de seguridad del gobierno.
Obtenido de GOV.UK: https://assets.publishing.service.gov.uk/government/uploads/system/uploads/
archivo adjunto_datos/archivo/715778/mayo2018_GobiernoSeguridadClasificaciones2.
pdf
• Oficina de Publicaciones del Gobierno de los Estados Unidos. (29 de diciembre de 2009). Orden
Ejecutiva 13526 del 29 de diciembre de 2009. Obtenido de GovInfo: https://www.govinfo.gov/content/pkg/
DCPD200901022/pdf/DCPD200901022.pdf
• Boletín de Virus. (Dakota del Norte). Boletín de Virus. Obtenido de Virus Bulletin: https://www.
virusbulletin.com/
• Ward, R., Beyer, B., (diciembre de 2014). BeyondCorp, un nuevo enfoque para la seguridad empresarial.
Obtenido de: https://storage.googleapis.com/pubtoolspublicpublication

datos/pdf/43231.pdf
• Wikipedia. (Dakota del Norte). Mesa arcoíris. Obtenido de Wikipedia: https://en.wikipedia.org/

wiki/Rainbow_table
• Corporación Microsoft. (6 de enero de 2023). Visión general de la gestión de personal.

Obtenido de Microsoft Corporation: https://learn.microsoft.com/enus/compliance/assurance/
aseguramientorecursoshumanos?view=o365worldwide
• Corporación Microsoft. (31 de mayo de 2017). Mejores prácticas para proteger Active
Directory. Obtenido de Microsoft: https://learn.microsoft.com/enus/windowsserver/
identity/ad ds/plan/securitybestpractices/bestpracticesforsecureactivedirectory

10
Implementación de la estrategia
En el capítulo anterior, analicé numerosas estrategias de ciberseguridad. En este capítulo, tomaré una de
esas estrategias e ilustraré cómo se puede implementar en un entorno de TI real. El objetivo es tomar lo
teórico y hacerlo un poco más real para ti. Proporcionaré algunos consejos y trucos que he aprendido en
mi carrera a lo largo del camino.
En este capítulo cubriremos lo siguiente:
• ¿Qué es Intrusion Kill Chain?
• Algunas formas en que se puede modernizar el modelo tradicional de Kill Chain
• Factores a considerar al planificar e implementar este modelo
• Diseño de conjuntos de control de seguridad para soportar este modelo
Dado que el marco MITRE ATT&CK® también es popular, muy útil y complementario a Intrusion Kill
Chain, señalaré algunas de las áreas en las que es útil.
Introducción
Tal vez recuerde del último capítulo que la estrategia centrada en ataques obtuvo la puntuación total estimada
más alta del sistema de puntuación de fundamentos de seguridad cibernética (CFSS) . Obtuvo una puntuación
casi perfecta con 95 puntos de 100 posibles. Obtuvo una puntuación tan alta porque aborda casi por completo
todos los fundamentos de ciberseguridad, con la excepción de la ingeniería social, que en realidad no se puede
mitigar por completo.
Dos ejemplos populares de marcos centrados en ataques utilizados por profesionales de la seguridad en
la industria incluyen Intrusion Kill Chain (Hutchins, Cloppert, Amin, nd) y el modelo MITRE ATT&CK®
(MITRE, nd).
396 Implementación de la estrategia
En este capítulo, proporcionaré un ejemplo de cómo se puede implementar una estrategia centrada en el ataque.
El modelo en el que me centraré es el marco Intrusion Kill Chain del que fue pionero Lockheed Martin. He
descubierto que los profesionales de la seguridad aman u odian este modelo. De hecho, tuve la oportunidad de
hacer un par de implementaciones de gran presupuesto, así que tengo experiencia de primera mano con él.
Mientras contemplaba estas implementaciones, me di cuenta de que una Intrusion Kill Chain probablemente
podría implementarse de varias maneras diferentes. Describiré una forma en que se puede implementar este
marco, reconociendo plenamente que hay otras formas en que se puede implementar y que la mía podría no ser
la mejor.
El marco Intrusion Kill Chain se basa en el documento de Lockheed Martin IntelligenceDriven

Computer Network Defense informado por análisis de campañas adversarias y Intrusion Kill Chains.
(Hutchins, Cloppert, Amin, sin fecha). En mi opinión, este documento es de lectura obligada para todos los
profesionales de la ciberseguridad. Algunos de los conceptos en este documento pueden parecer convencionales
o incluso anticuados ahora, pero cuando se publicó por primera vez, introdujo conceptos e ideas que cambiaron
la industria de la seguridad cibernética. Algunos podrían argumentar que este modelo ha visto sus mejores días
y que ahora hay mejores enfoques disponibles, como el modelo MITRE ATT&CK. Esto no es del todo cierto, ya
que ATT&CK pretende complementar el enfoque de Intrusion Kill Chain. Según MITRE:
¿Cuál es la relación entre ATT&CK y Lockheed Martin Cyber Kill Chain®?
ATT&CK y Cyber Kill Chain son complementarios. ATT&CK se encuentra en un nivel de definición
más bajo para describir el comportamiento del adversario que Cyber Kill Chain. Las tácticas
ATT&CK no están ordenadas y es posible que no todas ocurran en una sola intrusión porque los
objetivos tácticos del adversario cambian a lo largo de una operación, mientras que Cyber Kill
Chain usa fases ordenadas para describir los objetivos adversarios de alto nivel”. (MITRE, sf)
Además, tenga en cuenta que la puntuación CFSS sugiere que la estrategia centrada en el ataque puede mitigar
casi por completo los sospechosos habituales de ciberseguridad. Independientemente de lo que digan los
campeones o los detractores de este enfoque, el Capítulo 9, Estrategias de seguridad cibernética, le proporcionó
el método CFSS para decidir su eficacia potencial por sí mismo. Recomiendo hacer uso de esta herramienta
ante opiniones dispares sobre estrategias de ciberseguridad. Además, tenga en cuenta que este enfoque se
puede utilizar en entornos de TI locales, en entornos de nube y en entornos híbridos. Otro punto fuerte de este
enfoque es que es tecnológicamente neutral, lo que significa que no se limita a una tecnología o proveedor
específico. Esto significa que puede ser utilizado por la mayoría de las organizaciones ahora y en el futuro a
medida que evolucionan sus estrategias de TI.
Capítulo 10 397
Sin embargo, sí creo que existe una estrategia de ciberseguridad mejor y más moderna para entornos en la nube.
Hablaré de esto en el Capítulo 12, Enfoques modernos para la seguridad y el cumplimiento.
¿Qué es una cadena de eliminación de intrusos?

Una Intrusion Kill Chain son las etapas o fases que se pueden utilizar en los ataques de los atacantes. Las fases
proporcionadas en el documento de Lockheed Martin incluyen:
• Reconocimiento
• Armamento
• Entrega
• Explotación
• Instalación
• Comando y Control (C2)
• Acciones sobre Objetivos
Aunque probablemente pueda saber por el nombre de cada una de estas fases lo que abarcan, permítame
resumirlas rápidamente. Tenga en cuenta que esto se basa en mi propia interpretación del artículo de
Lockheed Martin, y son posibles otras interpretaciones.
Los atacantes seleccionan su objetivo en la fase de Reconocimiento (Hutchins, Cloppert, Amin, nd).
Ciertamente, muchos atacantes seleccionan objetivos de manera oportunista, muchas veces por
coincidencia, como lo demuestra todo el malware básico presente en Internet.
Los atacantes de amenazas persistentes avanzadas (APT, por sus siglas en inglés ) dedican tiempo y esfuerzo
a investigar a quién deben apuntar en función de sus motivaciones para el ataque. Es probable que dediquen
tiempo en esta fase a descubrir el espacio de direcciones IP que utiliza su objetivo, el hardware y el software que
utilizan, los tipos de sistemas que tienen, cómo funciona la empresa u organización, qué proveedores están en
su cadena de suministro y quién trabaja allí. Pueden usar una variedad de herramientas para realizar esta
investigación, incluidas herramientas técnicas para realizar búsquedas de nombres DNS, escaneos de rangos
de direcciones IP, los sitios web donde la organización anuncia vacantes que generalmente incluyen calificaciones
técnicas basadas en el hardware y el software que utilizan, entre muchos otros.
Una vez que los atacantes han seleccionado su objetivo y tienen cierta comprensión de dónde se
encuentran en Internet y las tecnologías que utilizan, entonces descubren cómo van a atacar a la víctima.
Esta fase se llama Armonización (Hutchins, Cloppert, Amin, nd). Por ejemplo, según su investigación sobre
el objetivo, ven que utilizan productos de Adobe.
Por lo tanto, planean intentar comprometer inicialmente el medio ambiente explotando vulnerabilidades
potencialmente sin parches para Acrobat Reader, por ejemplo. Para hacer esto, construyen un archivo .pdf
con formato incorrecto que es capaz de explotar una vulnerabilidad particular (CVE ID) cuando la víctima lo
abre. Por supuesto, este ataque solo funcionará si la vulnerabilidad que están usando no ha sido reparada en el objetivo.
ambiente.
Ahora que los atacantes han decidido cómo van a intentar comprometer inicialmente el entorno del objetivo y
han construido un arma para hacer esto, a continuación tienen que decidir cómo entregarán su arma al
objetivo. En la fase de entrega, deciden si van a enviar el archivo .pdf con formato incorrecto como un archivo
adjunto de correo electrónico, usarlo como parte de un ataque de abrevadero, colocarlo en unidades USB y
arrojarlo al estacionamiento de la organización, y así sucesivamente.
Una vez que el arma ha sido entregada a una posible víctima, los atacantes necesitan una forma de activar
el arma. En nuestro ejemplo de .pdf malicioso, el atacante espera que la víctima intente abrir el archivo mal
formado para que su exploit se ejecute en el sistema de la víctima. Esta fase se llama acertadamente la fase
de Explotación (Hutchins, Cloppert, Amin, nd). Si el sistema de la víctima no está parcheado para la
vulnerabilidad específica que el exploit está diseñado para aprovechar, entonces el exploit del atacante se
ejecutará con éxito.
Cuando se ejecuta el exploit del atacante, podría descargar más malware en el sistema de la víctima o
descomprimir malware de su interior. Por lo general, esto le dará al atacante acceso remoto al sistema de la
víctima. Esta fase se llama Instalación (Hutchins, Cloppert, Amin, nd).
Una vez que los atacantes han instalado con éxito sus herramientas en el sistema de la víctima, pueden
enviar comandos a sus herramientas o al propio sistema. Los atacantes ahora controlan el sistema total o
parcialmente, y potencialmente pueden ejecutar código arbitrario de su elección en el sistema de la víctima.
Esta fase del ataque es la fase de Comando y Control (C2) (Hutchins, Cloppert, Amin, nd).
Podrían intentar penetrar aún más en el entorno al intentar comprometer más sistemas.
Las acciones en los objetivos es la fase final de la cadena de eliminación de intrusos. Ahora que los
atacantes controlan uno o más sistemas comprometidos, persiguen sus objetivos. Como discutí en el
Capítulo 1, Introducción , sus motivaciones podrían incluir ganancias, espionaje económico, espionaje
militar, notoriedad, venganza y muchos otros. Ahora, están en condiciones de lograr los objetivos
específicos para satisfacer su motivación. Pueden robar propiedad intelectual, permanecer persistentes
para recopilar información, intentar un ataque cinético para dañar físicamente las operaciones de sus víctimas, destruir sistem
Capítulo 10 399
Tenga en cuenta que he escrito que estas son fases en un ataque que los atacantes
pueden usar en los ataques. No escribí que cada una de las fases siempre se usa en los
ataques. Este es un matiz que algunos de los detractores de este marco suelen pasar por
alto. A menudo argumentan que los atacantes no tienen que usar las siete fases que se
enumeran en el documento de Lockheed Martin. Solo usan las fases que tienen que usar.
Por lo tanto, el modelo tiene fallas y no debe usarse. Admito que nunca he entendido este
argumento, pero lo escucho a menudo cuando discuto este marco. Es útil tener en cuenta
el propósito previsto de este marco: dificultar el éxito de los atacantes. Además, ¿recuerda
el consejo que le di en el Capítulo 4, La evolución del software malicioso, sobre las
afirmaciones de omnisciencia? Este argumento se basa en la omnisciencia. Nunca
sabremos qué hacen todos los atacantes. Porque no sabemos qué harán los atacantes
en el presente o en el futuro, debemos estar preparados para proteger, detectar y

responder a lo que decidan hacer. Es decir, debemos basarnos en la realidad de que los
atacantes pueden usar cualquiera de estas fases”.
Por ejemplo, algunos entornos ya están comprometidos, lo que facilita que los atacantes en el presente y potencialmente en el
futuro penetren en el entorno de la víctima sin pasar por las primeras tres o cuatro fases. Eso no significa que un atacante no haya
superado con éxito estas fases en un ataque anterior, y no significa que los atacantes no las usarán en el
futuro. No sabemos lo que depara el futuro y no controlamos a los atacantes. No somos omniscientes
u omnipotente. Sabemos que los atacantes siempre usarán al menos una de estas fases, tienen que hacerlo.
Posteriormente, los defensores deben estar preparados, independientemente de las fases que utilicen los atacantes.
Esta es una diferencia entre el marco Intrusion Kill Chain y el marco ATT&CK que
se señala a menudo. ATT&CK proporciona tácticas que los atacantes pueden usar o no. Estas tácticas son diferentes de los pasos
o etapas ordenadas en la cadena de eliminación de intrusos. A pesar de esta diferencia, ambos tienen la misma limitación en el
sentido de que no pueden usarse para predecir el futuro. Proporcionan formas de visualizar los pasos que los atacantes podrían
tomar en sus ataques y organizar las defensas a su alrededor. La cantidad y el orden de esos pasos no se pueden predecir debido
a la gran cantidad de combinaciones y permutaciones de los estados de los entornos de TI y las elecciones que pueden hacer los
atacantes. Debates animados entre los miembros del equipo de seguridad sobre qué enfoque utilizar es probablemente un buen
uso del tiempo.

Sin embargo, aquellos que argumentan que ninguno de estos enfoques debe usarse sin ofrecer una
estrategia viable de ciberseguridad no están siendo útiles. La clave para utilizar cualquiera de estos
enfoques es medir el rendimiento de las inversiones en capacidad de seguridad cibernética que elija
realizar y realizar cambios cuando sea prudente. El uso de cualquiera de estos enfoques o ambos juntos
aún requiere que mida la eficacia de su implementación particular. Este es el tema del Capítulo 11,
Medición del desempeño y la eficacia.
Saber cómo podría ser la Intrusion Kill Chain completa del atacante puede ayudar a los defensores a
hacer mucho más difícil que los atacantes tengan éxito. Al aumentar significativamente el esfuerzo
requerido para que los atacantes tengan éxito, reducimos su retorno de la inversión y, potencialmente,
su determinación . Para hacer esto, los autores del artículo Intrusion Kill Chain sugieren que los defensores
usen una matriz de cursos de acción (Hutchins, Cloppert, Amin, nd). Esta matriz permite a los defensores
trazar un mapa de cómo planean detectar, negar, interrumpir, degradar, engañar y destruir los esfuerzos
del atacante en cada una de las siete fases de su Intrusion Kill Chain. Un ejemplo de esto se ilustra en la Figura 10.1.
Figura 10.1: Matriz de cursos de acción (Hutchins, Cloppert, Amin, nd)
Al superponer controles en esta matriz, el objetivo es hacer que sea mucho más difícil, o imposible, para
los atacantes progresar a través de su Intrusion Kill Chain. Se pueden incluir múltiples capacidades
complementarias en cada una de las celdas de la matriz. Detener a los atacantes tan pronto como sea
posible en su Intrusion Kill Chain reduce el daño potencial y el tiempo y los costos de recuperación
asociados. En lugar de que los atacantes tengan éxito después de vencer un firewall o un solo conjunto
de controles, deben superar las defensas en capas en la Matriz de cursos de acción para cada paso de su ataque.
Modernizando la Kill Chain

Una consideración antes de implementar este marco es si los defensores deben usar el marco original de
Intrusion Kill Chain o usar una versión actualizada del mismo. Hay varias formas de modernizar este
marco. El marco ATT&CK es un ejemplo de una cadena de eliminación de intrusos modernizada. En el
momento de escribir este artículo, la versión actual (ATT&CK versión 12.0) proporciona 14 tácticas en
lugar de las 7 etapas proporcionadas por el marco original de Intrusion Kill Chain.
Capítulo 10 401
Aunque las tácticas y las etapas son ligeramente diferentes, el concepto es el mismo: comprender cómo los atacantes
inicialmente comprometen y penetran los entornos de TI de la empresa permite a los defensores proteger, detectar y
responder mejor a esos ataques.
En esta sección, les daré algunas ideas sobre cómo se puede modernizar la Intrusion Kill Chain original.
Sin embargo, no tenga miedo de adoptar la noción de mejora iterativa basada en las experiencias de sus organizaciones
con este marco u otros.
Mapeo de los sospechosos habituales de ciberseguridad

Espero haber impartido la importancia de mitigar las cinco formas en que las organizaciones se ven inicialmente
comprometidas. El marco de Intrusion Kill Chain se puede modificar o reorganizar en torno a los sospechosos habituales
de ciberseguridad para garantizar que se mitiguen y facilitar la identificación de brechas en la postura de seguridad de
una organización. Esto se puede hacer de un par de maneras diferentes. En primer lugar, se pueden integrar en el marco
original de Intrusion Kill Chain. Es decir, los controles utilizados para mitigar los sospechosos habituales de ciberseguridad
se distribuyen en la matriz de cursos de acción como todos los demás controles. El desafío con este enfoque es que
puede dificultar la identificación de la inversión excesiva, la inversión insuficiente y las brechas en esas áreas específicas,
especialmente si su matriz es grande. Para compensar esto, se podría agregar una columna a la matriz donde se rastrean
los sospechosos habituales de ciberseguridad que cada control mitiga. Algunas filas no tendrán una entrada en esta
columna porque muchos controles serán capacidades avanzadas de ciberseguridad, no necesariamente enfocados en
los sospechosos habituales de ciberseguridad.
Otra forma de facilitar la tarea de garantizar que los sospechosos habituales de ciberseguridad se mitiguen por completo
es utilizar dos listas separadas. Haga un inventario de los controles que mitigan los sospechosos habituales de
ciberseguridad en una lista y todo lo demás en una matriz de cursos de acción separada. De esta manera, tendrá una
visibilidad completa y sin obstrucciones de los controles implementados para mitigar los sospechosos habituales de
ciberseguridad y todos los demás controles también. Esto podría significar que hay cierta duplicación de controles en
estas listas que hace que sea más complicado realizar un seguimiento de los cambios a lo largo del tiempo.
Prefiero el segundo enfoque, es decir, usar dos listas separadas. Me gusta la visibilidad clara de los controles que mitigan
los sospechosos habituales de ciberseguridad. Dicho de otra manera, una lista de controles centrados en proteger,
detectar y responder a los intentos de comprometer inicialmente un entorno de TI y otra lista de controles posteriores al
compromiso. Este enfoque facilita el seguimiento de los controles que representan la base de la estrategia. Sin embargo,
siéntase libre de usar cualquier enfoque u otro diferente que funcione mejor para su organización. Este es el enfoque que
utilizaré en el ejemplo proporcionado en este capítulo. Ya he hablado extensamente de los sospechosos habituales de
ciberseguridad y los fundamentos de ciberseguridad en otros capítulos. El ejemplo que proporcionaré aquí se centrará en
el componente de capacidades avanzadas de ciberseguridad de la estrategia.

Actualización de la matriz
Otra modificación a este enfoque que vale la pena considerar es si actualizar las fases y las acciones en la
Matriz de Cursos de Acción. Por ejemplo, la fase de reconocimiento de Intrusion Kill Chain se puede dividir en
dos fases separadas. Esta separación reconoce que hay potencialmente dos momentos diferentes en un intento
de intrusión cuando los atacantes normalmente realizan un reconocimiento. Antes del ataque, los atacantes
pueden pasar tiempo seleccionando su objetivo e investigando formas en las que podrían ser atacados. Después
de que uno de los sospechosos habituales de ciberseguridad se utiliza para comprometer inicialmente a la
víctima, los atacantes pueden realizar un reconocimiento nuevamente para mapear la red de la víctima y dónde
están los activos de alto valor (HVA) . La razón por la que puede ser útil separar estas dos fases es que las
herramientas, técnicas, tácticas y procedimientos utilizados por los atacantes pueden ser diferentes antes y
después del compromiso inicial. La actualización de la matriz reemplazando la fase de Reconocimiento con las
fases de Reconocimiento I y Reconocimiento II permitirá a los equipos de seguridad mapear diferentes controles
para detener a los atacantes en cada una de estas fases. Tenga en cuenta que, en ambos casos, los atacantes
pueden usar tácticas de reconocimiento no intrusivas o elegir
usar tácticas intrusivas de reconocimiento.
Este mismo tipo de modificación se ha implementado en el marco ATT&CK donde tienen tácticas de
Reconocimiento y Descubrimiento . El primero se enfoca en informar la orientación, mientras que el segundo se
enfoca en aprender sobre el entorno comprometido.
Otra posible actualización de las fases es eliminar la fase de Armamento . Eso puede parecer un cambio
significativo en el marco original, pero en mi experiencia, no cambia los controles que suelen usar los defensores.
Esta fase de un ataque es donde los atacantes, que ahora han decidido cómo van a atacar a la víctima, planean
reutilizar armas viejas o construir y/o comprar nuevas armas para usar en su ataque. La mayor parte de esta
actividad ocurre fuera de la vista de los defensores.
Posteriormente, muy pocas de las actividades del atacante en esta fase pueden verse influenciadas por los
controles disponibles para los defensores. Si los atacantes son arrogantes acerca de las fuentes de las que
obtienen las armas, los proveedores de inteligencia de amenazas o las fuerzas del orden podrían recibir
información sobre sus actividades y quizás sus intenciones. Esto podría ser útil si el arma es una vulnerabilidad
de día cero que la víctima prevista podría implementar soluciones para mitigar, pero, francamente, centrarse en
las otras fases del ataque probablemente tendrá un retorno de la inversión mucho mayor para los defensores,
ya que potencialmente tienen más visibilidad y control. La fase de Armamento es demasiado opaca para que la
mayoría de las organizaciones puedan influir de manera realista. Dicho de otra manera, los CISO generalmente
no tienen controles muy efectivos para la protección y detección antes de la fase de Entrega; Es importante
priorizar las inversiones en mitigaciones que tienen un valor claro y medible.
Capítulo 10 403
Esto también se refleja en el marco de ATT&CK. En la jerga de ATT&CK, este concepto de militarización
se llama desarrollo de recursos. Tiene menos técnicas (7) asociadas que cualquiera de las otras tácticas
del marco. La mitigación que ofrece ATT&CK para muchas de estas técnicas es “Esta técnica no se puede
mitigar fácilmente con controles preventivos ya que se basa en comportamientos realizados fuera del
alcance de las defensas y controles empresariales” (MITRE, sin fecha).
La matriz de cursos de acción se puede actualizar para incluir algunas acciones diferentes. Por ejemplo,
De stroy podría abandonarse en favor de algunas acciones más realistas, como Limitar y Recuperar. Usar
Límite como una acción reconoce que los defensores quieren dificultar o imposibilitar que los atacantes se
muevan libremente durante su ataque. Por ejemplo, limitar las opciones de entrega disponibles para los
atacantes y limitar el alcance de la infraestructura que pueden controlar los atacantes dificulta que los
atacantes tengan éxito. El uso de una acción de restauración ayuda a las organizaciones a planificar su
recuperación si todas las demás mitigaciones en capas en el modelo no funcionan como se esperaba.
Tanto para Limitar como para Restaurar, no todas las celdas de la matriz tendrán necesariamente controles
en ellas. Por ejemplo, es probable que no haya ningún control que ayude a recuperarse durante la fase de
reconocimiento I porque el entorno aún no ha sido atacado. Potencialmente, habrá varias celdas en la
matriz sin entradas; esto es de esperar. Un ejemplo de la Matriz de Cursos de Acción actualizada se ilustra en la Figura 10.2:
Figura 10.2: Un ejemplo de una Matriz de Cursos de Acción actualizada (Hutchins, Cloppert, Amin, nd)
Por supuesto, estas actualizaciones son completamente opcionales. La implementación del modelo
Intrusion Kill Chain original puede ser una forma efectiva para que muchas organizaciones mejoren su
postura de seguridad. Sugiero que antes de que los CISO se tomen en serio la implementación de este
modelo, dediquen un tiempo a pensar si alguna modificación al modelo original será ventajosa. Luego,
deben actualizar la Matriz de cursos de acción antes de seguir adelante con este modelo, ya que esto
ahorrará tiempo, gastos y reelaboraciones potencialmente frustrantes.
¿Cadena de eliminación de intrusos o ATT&CK?
Otra decisión a tomar es si utilizar el marco Intrusion Kill Chain o ATT&CK.
marco, o una combinación de estos enfoques. En mi experiencia, la cantidad relativamente pequeña de etapas de
alto nivel que ofrece Intrusion Kill Chain facilita que los equipos de estrategia y arquitectura visualicen ataques y
diseñen e implementen capas de defensa para ellos.
Además de ser un modelo más simple, creo que este enfoque está alineado con la forma en que los proveedores
de ciberseguridad tienden a comercializar y vender sus productos y servicios. Esto facilita el trabajo de los equipos
que negocian acuerdos con los proveedores de ciberseguridad, como los equipos de Adquisiciones y Asuntos Legales.
Por ejemplo, un proveedor de antimalware podría destacar los diversos beneficios de su producto, como altas tasas
de detección, bajas tasas de detección de falsos positivos y heurística avanzada. En el lenguaje de ATT&CK, el
mismo proveedor destacaría que tiene la mejor detección de inyección de lsass.exe en la industria. ¿Observe cómo
la altitud de estos beneficios es diferente?
Por último, descubrí que el marco Intrusion Kill Chain es más fácil de entender para las partes interesadas de alto
nivel. Esto incluye el liderazgo de TI, los equipos de liderazgo sénior (SLT) y los miembros de la junta directiva.
Recuerde un consejo que brindé en el Capítulo 8, Ingredientes para una estrategia exitosa de ciberseguridad:
obtener el apoyo de estas partes interesadas puede ser fundamental para el éxito de su estrategia. Si no pueden
entender la estrategia, es posible que no la respalden por completo. Descubrí que la taxonomía de ATT&CK con
tácticas, técnicas, subtécnicas, mitigaciones, detecciones, etc., es más difícil de entender para los miembros del SLT
y de la Junta Directiva. Esta es otra razón por la que tengo
encontró valioso el marco Intrusion Kill Chain: puede ser más fácil obtener soporte.
Donde he encontrado que el marco ATT&CK es más útil que Intrusion Kill Chain es en la validación y prueba de
control de seguridad, diseño y prueba de estrategias de detección empresarial, simulaciones de ataque, cualquier
lugar donde el conocimiento de las técnicas granulares que los atacantes podrían usar podría ser útil. El aspecto de
la base de conocimientos de ATT&CK es realmente útil en estos escenarios, pero Intrusion Kill Chain en gran
medida deja que los equipos de estrategia y arquitectura resuelvan estas cosas por sí mismos.
Posteriormente, aprovechar una combinación de estos enfoques puede tener sentido. Usar el marco Intrusion Kill
Chain para simplificar las cosas para las partes interesadas de estrategia, arquitectura, adquisiciones, legales y
otras, como SLT y miembros de las juntas, y usar ATT&CK para informar los detalles a los equipos de seguridad,
puede ser una combinación poderosa para algunas organizaciones.
Capítulo 10 405
Por supuesto, algunas organizaciones simplemente estandarizan el marco ATT&CK e intentan usarlo de manera
consistente en todas partes; este también es un gran enfoque. Cualquiera que sea la ruta que tome su organización,
recuerde que el mejor enfoque es el que tendrá más éxito para su organización, no para otra persona. Recuerde,
las mejores prácticas se basan en la amenaza de otra persona.
modelo.
Voy a mencionar una advertencia aquí. Ambos enfoques se pueden utilizar en la nube. La pregunta para los CISO
es, ¿puede su organización administrar dos estrategias de seguridad cibernética separadas: una para la nube y
otra para las instalaciones? ¿O debería usar la misma estrategia en ambos entornos para hacer las cosas más
simples y consistentes? En mi función como asesor de seguridad cibernética, encontré una cantidad sorprendente
de CISO que expresaron su preferencia por operar estrategias separadas para la nube y sus entornos locales.
Hablaré más sobre esto en el Capítulo 12, Enfoques modernos para la seguridad y el cumplimiento.
Empezando
Es probable que los entornos de TI existentes, especialmente aquellos que ya están bajo la administración de un
CISO, ya tengan implementados algunos controles de ciberseguridad. Si una estrategia centrada en el ataque y el
enfoque de cadena de eliminación de intrusos son nuevos para una organización, es probable que los controles
existentes se implementaron de una manera que no es necesariamente coherente con la Matriz de cursos de acción.
El mapeo de los controles de seguridad cibernética implementados actualmente a la Matriz de Cursos de Acción
ayudará a determinar dónde existen brechas potenciales entre las capacidades de seguridad cibernética
implementadas actualmente y una Matriz de Cursos de Acción completamente implementada. También puede
ayudar a identificar áreas de inversión excesiva y de inversión insuficiente. Por ejemplo, después de asignar sus
capacidades de ciberseguridad actuales a esta matriz, el equipo de seguridad se da cuenta de que ha invertido
mucho en capacidades que niegan la entrega de las armas del atacante, pero no han invertido nada que ayude a
detectar los intentos de entrega; de hecho, ahora se dan cuenta de que no han invertido lo suficiente en
capacidades de detección en toda Kill Chain. Este ejercicio de mapeo puede ayudar a exponer suposiciones
optimistas sobre las capacidades de seguridad de las organizaciones. Algunos profesionales de la seguridad llaman a este tipo de ejerc
Este ejercicio puede ser esclarecedor, pero también desafiante, especialmente en entornos grandes y complejos.
La mayoría de las organizaciones a las que he asesorado no tenían una lista completa y actualizada de
herramientas, productos, servicios y configuraciones útiles en un ejercicio como este. Incluso las organizaciones
que tienen inventarios de activos y bases de datos de administración de configuración a menudo encuentran que
sus datos están incompletos, desactualizados e inexactos. He visto estimaciones de la industria que sugieren que
el entorno de TI local promedio tiene un 20 % de activos y servicios no documentados, e incluso estimaciones más
altas en algunas industrias, como la atención médica. La experiencia me dice que estas estimaciones son bajas.
Algunas organizaciones intentan usar artefactos de adquisición para determinar qué compró su departamento
de TI, pero esto suele ser diferente de lo que realmente se implementó. Ante el desafío de obtener un inventario
preciso y actualizado de las capacidades de ciberseguridad que tienen en ejecución en su entorno, la mayoría
de las organizaciones comienzan con los datos que tienen y verifican manualmente lo que se ha implementado.
Esto no es necesariamente algo malo porque puede proporcionar una vista precisa y actual, pero también
incluye información cualitativa que no se puede representar desde una base de datos de inventario de activos.
Madurez de las capacidades actuales de ciberseguridad

He tenido la oportunidad de realizar este ejercicio de mapeo en algunos entornos de TI grandes y complicados.
Permíteme compartir algunas de las cosas que he aprendido, para ahorrarte algo de tiempo si te enfrentas al
mismo desafío.
A medida que asigne las capacidades de seguridad cibernética actuales a la Matriz de cursos de acción, un
factor a tener en cuenta es la madurez de la implementación de cada control o capacidad. Es decir, es posible
que un elemento de una lista de inventario de software no ofrezca ninguna pista sobre si el control se
implementó total o parcialmente. Comprender la madurez de la implementación de cada control es clave para
comprender realmente dónde existen brechas y dónde se ha producido una inversión insuficiente y excesiva.
Por ejemplo, una organización adquiere un conjunto de capacidades de seguridad cibernética de un proveedor
industrial de primer nivel. Esta suite es capaz de proporcionar varias funciones importantes, incluida la
supervisión de la integridad de los archivos, el análisis antimalware y la prevención de pérdida de datos para
equipos de escritorio y servidores. Al asignar capacidades a la matriz de cursos de acción, es fácil ver las
capacidades que la suite puede proporcionar e incluirlas todas en el inventario de las capacidades actuales de la organización.
Sin embargo, la pregunta es, ¿cuántas de las capacidades de la suite se han implementado realmente? Una
pregunta relacionada es, ¿quién es responsable de operar y mantener estos controles? Estas pueden ser
preguntas difíciles de responder en entornos de TI grandes y complicados. Sin embargo, sin descubrir la
verdad sobre la madurez de la implementación actual, la confianza del mapeo y la eficacia potencial de la
estrategia pueden verse socavadas. Recuerde la analogía del submarino que he usado a lo largo de este libro;
¿Estaría realmente interesado en zarpar en un submarino si no supiera realmente si todos los sistemas críticos
están en pleno funcionamiento? Probablemente no.
Muchas organizaciones aspiran a tener un equipo de ciberseguridad de clase mundial. Para respaldar esta
aspiración, un principio que algunos de ellos utilizan al evaluar y adquirir capacidades de ciberseguridad es
que solo quieren las mejores tecnologías. Es decir, solo quieren los mejores productos y no se conforman con
menos que eso. Para la mayoría de las organizaciones, esto es muy ambicioso porque atraer y retener talento
en ciberseguridad es un desafío para toda la industria.
Capítulo 10 407
La adopción de una filosofía de adquisición de "lo mejor de su clase" hace que este desafío de talento agudo sea aún más
difícil . Esto se debe a que potencialmente reduce la cantidad de personas que tienen experiencia con estas
implementaciones caras y relativamente raras "solo las mejores". Este enfoque también puede ser peligroso para las
organizaciones que son ricas en efectivo y creen que simplemente pueden comprar seguridad cibernética efectiva en lugar
de desarrollar una cultura en la que todos participen. La mayoría de las organizaciones que he visto con esta filosofía
terminan comprando un Ferrari y usando su cenicero. Simplemente no tienen los medios para diseñar, implementar, operar
y mantener solo lo mejor de su clase, por lo que solo usan una fracción de las capacidades disponibles. En algunos casos,
las organizaciones que se encuentran en este escenario sobreinvierten en un área mediante la adquisición de capacidades
iguales o similares, pero lo hacen mediante la adquisición de productos que pueden implementar y operar con éxito.
Realizar este ejercicio de mapeo en organizaciones que se han encontrado en este escenario puede ser especialmente
difícil. Esto se debe a que descubre verdades duras sobre ambiciones y suposiciones demasiado optimistas, así como
inversiones en ciberseguridad con rendimientos marginales. Sin embargo, este proceso puede ser un mal necesario para
las organizaciones que tienen el coraje de mirarse en el espejo y la voluntad de hacer cambios positivos y progresivos en
su postura de seguridad actual. No hay nada de malo en ser ambicioso y apuntar alto si la organización puede alcanzar
esas ambiciones de manera realista.
Puede ser un desafío cuantificar qué parte de una suite de seguridad cibernética o un conjunto de capacidades se ha
implementado con éxito. Un enfoque que probé, con resultados mixtos, es dividir la funcionalidad del conjunto de
capacidades en sus categorías constituyentes y usar un índice de madurez para cuantificar qué tan madura es la
implementación usando una escala entre 1 y 5, donde 5 es la más madura. Esto puede ayudar a determinar si se requiere
más inversión en un área en particular. En entornos grandes y complejos, es más fácil decirlo que hacerlo, y algunos
podrían preguntarse si vale la pena el tiempo y el esfuerzo mientras luchan por superarlo. Sin embargo, cuantos más
detalles tengan los equipos de seguridad sobre el estado actual de sus asuntos, más confianza tendrán para seguir
adelante con esta estrategia.
Omnipresencia de las capacidades actuales de ciberseguridad

Otro punto de datos que debe considerar recopilar a medida que mapea las capacidades de seguridad cibernética actuales
en la Matriz de cursos de acción es la omnipresencia de la implementación de cada control o capacidad.
Por ejemplo, un equipo de operaciones de servidor adquiere una herramienta que les ayuda a detectar y bloquear la
explotación de vulnerabilidades en los servidores en los que está instalada. ¿En cuántos servidores está realmente
instalada y ejecutándose esta herramienta? ¿Está instalado en todos los servidores que ejecutan Windows y diferentes
versiones de Linux? En algunos entornos de TI, no es seguro asumir que la herramienta se ejecuta en todos los servidores.
Determinar el porcentaje de servidores en los que se ejecuta realmente la herramienta lo ayudará a obtener una imagen
más precisa de las capacidades de ciberseguridad existentes.

En algunos entornos, diferentes equipos administran TI y toman decisiones de forma independiente. En

escenarios como este, la omnipresencia de las capacidades de ciberseguridad podría estar limitada a redes
específicas o partes específicas de la organización. Por ejemplo, si bien la empresa puede tener un inventario
total de 100 herramientas de seguridad, solo el 20 % de ellas se implementan en cualquier entorno de TI.
Es importante comprender esto para obtener inventarios precisos de capacidad de ciberseguridad. Incluir una
estimación del porcentaje de omnipresencia en su hoja de cálculo para cada capacidad puede ser muy útil para
algunas organizaciones.
¿Quién consume los datos?

Un principio que he encontrado útil para mapear las capacidades de seguridad actuales de un entorno de TI en
la Matriz de cursos de acción es que los datos generados por cada conjunto de control necesitan que alguien o
algo los consuma. Por ejemplo, un equipo de seguridad que realiza este mapeo descubre que el equipo de
administración de la red implementó capacidades IDS/IPS potencialmente poderosas que se incluyeron con un
dispositivo de red que adquirieron el año fiscal pasado. Aunque estas capacidades están habilitadas, descubren
que nadie en el equipo de administración de la red está monitoreando o revisando activamente las alertas de
este sistema y que el Centro de operaciones de seguridad (SOC) de la organización ni siquiera sabía que
existían. El resultado neto de estas capacidades es equivalente a no tenerlas en absoluto, ya que nadie consume
los datos que generan. Un humano no necesariamente tiene que consumir estos datos; los sistemas de
orquestación y automatización también pueden tomar acciones basadas en dichos datos. Sin embargo, si ni un
ser humano ni un sistema están consumiendo estos datos, entonces los equipos de seguridad realmente no
pueden incluir estas capacidades en sus mapeos de controles implementados actualmente.
a menos que se solucionen esas deficiencias.
A medida que los equipos de seguridad realizan este mapeo, para cada control que identifican, también deben
registrar quién o qué consume los datos que genera. Registrar el nombre de la persona que es el punto de
contacto para el consumo de estos datos pagará dividendos a los equipos de seguridad. Un punto de contacto
puede ser un administrador en el SOC o en el Centro de operaciones de red (NOC), un miembro del equipo de
respuesta a incidentes, un proveedor de servicios administrados o un proveedor. Esta información es valiosa
para generar confianza en las verdaderas capacidades de ciberseguridad de la organización. Sin embargo,
también es muy valioso para medir la eficacia de su estrategia, que discutiré en detalle en el Capítulo 11, Medición
del desempeño y la efectividad.
Capítulo 10 409
Figura 10.3: Ejemplo de Matriz de Cursos de Acción parcial (Hutchins, Cloppert, Amin,
nd), que incluye un índice de madurez, quién o qué va a consumir datos de cada control
y un punto de contacto (PoC)
Como se muestra en la Figura 10.3, a medida que se actualiza la Matriz de Cursos de Acción, se expande
rápidamente. He usado una hoja de cálculo para hacer este mapeo en el pasado. Admito que esta no es la forma
más elegante de realizar tales asignaciones. Un mapeo que hice fue de más de 120 páginas de controles en una
hoja de cálculo; navegar esa hoja de cálculo no fue muy divertido. Además, el uso de una hoja de cálculo no es la
herramienta más escalable y las capacidades de generación de informes son limitadas. Si tienes una herramienta
mejor, ¡úsala! Si no tiene una herramienta mejor, tenga la seguridad de que el ejercicio de mapeo se puede hacer
usando una hoja de cálculo o un documento. Sin embargo, cuanto más grande y complejo es el entorno, más
desafiante se vuelve el uso de estas herramientas.
Renovaciones de licencias de ciberseguridad

La mayoría del software y hardware que se obtiene de los proveedores tienen términos de licencia que incluyen
una fecha de vencimiento de las licencias. Cuando una licencia caduca, debe renovarse o el producto debe
retirarse del servicio. Otra actualización de la Matriz de cursos de acción a considerar, que puede ser muy útil, es
agregar una columna para realizar un seguimiento de la fecha de renovación del contrato para cada capacidad
enumerada. Si se toma el tiempo de hacer un inventario del software y el hardware utilizados para la seguridad
cibernética, registre también la fecha de vencimiento/renovación de cada elemento. Esto le dará una idea del
tiempo que tiene cada elemento de la lista antes de que caduque su licencia y sea necesario renovarla. Incrustar
esta información en el mapeo de control le dará visibilidad de la vida útil restante potencial para cada capacidad y
puede ayudar a recordar al equipo de seguridad cuándo comenzar a reevaluar la efectividad de cada producto y si
renovar o reemplazar las capacidades existentes.
Otra fecha similar que puede ser útil para rastrear es el final de la vida útil/fechas de soporte para productos; por lo general,
después de esta fecha, los fabricantes descartan los productos y ya no ofrecen actualizaciones de seguridad para ellos.
Con el tiempo, estos productos aumentan la superficie de ataque en los entornos de TI, ya que las vulnerabilidades en
ellos continúan divulgándose públicamente, incluso después de las fechas de finalización del soporte. El seguimiento de
estas fechas puede ayudarnos a evitar sorpresas. El seguimiento de estas fechas como parte de una matriz de cursos de
acción modificada es opcional.
Los CISO y los equipos de seguridad no deben depender de sus departamentos de Adquisiciones para marcar las fechas
de renovación por ellos; debería funcionar al revés. Muchos de los CISO con los que he hablado quieren tener visibilidad
de esta "lista de horizonte", cómo afecta sus presupuestos y las fechas clave de los hitos cuando se
hay que tomar decisiones. ¿Qué CISO no querría recibir un aviso por adelantado de que su red
IDS/IPS iba a ser apagado porque su licencia estaba a punto de caducar? Cuanto más tiempo de anticipación tengan
estas decisiones, menos sorpresas de última hora tendrán los equipos de seguridad. Además, cuando analice la medición
de la eficacia de esta estrategia en el próximo capítulo, verá que tener esta información al alcance de la mano puede ser
útil.
Por supuesto, esta actualización de la matriz es opcional. Las fechas de renovación se pueden rastrear en un documento
o base de datos por separado. Sin embargo, poder cruzar las referencias de las fechas de renovación y las capacidades
de seguridad cibernética en su mapeo debería ser algo que los CISO puedan hacer fácilmente. Necesitan tener suficiente
tiempo de anticipación para determinar si quieren mantener los productos y servicios que ya tienen en producción o
reemplazarlos.
Figura 10.4: Un ejemplo de Matriz de Cursos de Acción parcial (Hutchins, Cloppert, Amin, nd),
que incluye un índice de madurez, quién o qué va a consumir datos, un punto de contacto
(PoC) y la fecha de renovación para cada control
Implementando esta estrategia

Al final del proceso de mapeo, los CISO y los equipos de seguridad deberían tener un inventario mucho mejor de las
capacidades y controles de ciberseguridad que se han implementado, así como también cómo la organización consume
los datos de estos. Este es un excelente punto de partida para implementar el marco Intrusion Kill Chain. Sin embargo, no
subestime lo desafiante que puede ser para las organizaciones con entornos de TI grandes y complejos lograr esto.
Capítulo 10 411
Para algunas organizaciones, será más fácil dividir el trabajo de mapeo en proyectos más pequeños y más
realizables centrados en partes de su entorno, que tratar de mapear todo su entorno.
Avanzar con esta estrategia sin un mapeo actualizado y preciso puede conducir fácilmente a inversiones excesivas,
inversiones insuficientes y brechas en las capacidades de seguridad. Si bien esto se puede corregir con el tiempo,
es probable que lo haga más costoso y consuma más tiempo de lo necesario.
Figura 10.5: Un ejemplo de una parte de una matriz de cursos de acción actualizada (Hutchins, Cloppert,
Amin, nd) que contiene un mapeo de las capacidades actuales de ciberseguridad de una organización
He proporcionado un ejemplo de cómo se ven las dos primeras acciones en un conjunto actualizado de fases en la
Figura 10.5. Un mapeo real para una organización grande podría ser potencialmente mucho más grande, pero
quiero darle una idea de cómo se ve un mapeo. En un mapeo real, control_name serán los nombres de los
productos, servicios, características o funcionalidades específicos que detectan, niegan, interrumpen, etc. para cada
fase de un ataque. El campo Descripción pretende ser una breve descripción de lo que hace cada control. Sugiero
proporcionar más detalles en este campo de los que tengo aquí para que quede claro cuál es la función y el alcance
de cada control.
Hay un índice de madurez para cada control, que va de 1 a 5, donde 5 indica que la implementación es lo más
completa y funcional posible. Un índice de madurez de 1 o 2 indica que, si bien el producto o característica tiene
mucha funcionalidad, se ha implementado o se está operando relativamente poca. Este índice ayudará a informar
nuestras suposiciones sobre la eficacia actual de cada control en comparación con su potencial. Esto ayuda a
evitar la trampa de suponer que un control está funcionando con la máxima eficiencia cuando en realidad no está
completamente implementado o no se está operando o monitoreando activamente.
Color: codificar este campo o elementos de línea completos en función de este campo puede facilitar aún más la
comprensión de la madurez de cada control.
No he incluido una columna de "Persuasión" en la Figura 10.5, pero si lo hubiera hecho, contendría un porcentaje
que representa la cantidad estimada del entorno en el que está instalado y funcionando cada control .
Alternativamente, podría haber incluido dos columnas para la Omnipresencia, una que representa el extremo inferior
del rango de porcentaje estimado y una segunda para el extremo superior del rango.
Por ejemplo, 30 % en la columna baja y 50 % en la columna alta indica que el control está instalado y
funcionando entre el 30 % y el 50 % del entorno del alcance. Tener dos columnas le permitirá filtrar los datos
de maneras potencialmente más interesantes más adelante cuando esté analizando los datos y racionalizando
la Matriz de Cursos de Acción.
El consumidor de datos de cada acción es el grupo o departamento específico de la organización que utiliza
datos del control para detectar, denegar, interrumpir, degradar, etc. La PoC del Consumidor
La columna contiene los nombres de cada punto de contacto en el grupo o departamento que consume los
datos de cada control. Esto puede facilitar la verificación periódica de que los datos de cada control aún se
consumen según lo planeado. Después de todo, no tiene sentido implementar mitigaciones si nadie les está
prestando atención. Es probable que el tiempo, el esfuerzo y el presupuesto gastados en tales controles se
puedan usar de manera más efectiva en algún otro lugar de la organización.
Por último, la columna Fecha de renovación de cada acción proporciona visibilidad de la posible fecha de
caducidad de cada control. Hace esto para ayudar a minimizar posibles lapsos inesperados en el estado operativo
de cada control. Esto ayuda a evitar la revelación de que una mitigación que pensaba que estaba completamente
operativa en realidad se ha deshabilitado parcial o totalmente debido a una caducidad en la licencia o a que un
producto dejó de recibir soporte; estas sorpresas pueden quemar a los CISO y los equipos de seguridad.
Racionalización de la matriz: brechas, inversiones insuficientes y

inversiones excesivas
Sin un mapeo de las capacidades actuales de seguridad cibernética a la Matriz de Cursos de Acción, puede
ser muy fácil invertir demasiado o poco en productos de seguridad cibernética y tener brechas en las
capacidades de protección, detección y respuesta. ¿Qué quiero decir exactamente con inversiones excesivas,
inversiones insuficientes y brechas? Realizar un mapeo de las capacidades y controles de ciberseguridad
existentes en un marco de Intrusion Kill Chain puede ser mucho trabajo. Sin embargo, para algunos CISO,
puede resultar en una epifanía.
Identificando brechas
Realizado correctamente, este mapeo puede revelar áreas clave donde las organizaciones no han invertido
en absoluto: una brecha. Por ejemplo, en la figura 10.5, la fila Reconocimiento I no tiene ninguna entrada;
esto puede ser una clara indicación de que la organización tiene una brecha en su conjunto de control, lo que
podría hacer que esta fase de la Intrusion Kill Chain del atacante sea más fácil para ellos. No es raro que las
organizaciones no inviertan en esta área. Una brecha como esta es una clara oportunidad de mejora.
Capítulo 10 413
Identificación de áreas de inversión insuficiente

Las inversiones insuficientes en un área pueden ser más sutiles en la Matriz de Cursos de Acción. un bajoen
La inversión puede aparecer como un número relativamente pequeño de entradas para una actividad o fase en la matriz.
Aquí donde el índice de madurez, el porcentaje de omnipresencia y las descripciones pueden ayudar.
Una sola entrada en la matriz con un índice de madurez de 5 podría ser toda la inversión que se necesita para esa
acción. Pero una entrada con un índice de madurez de 5 y un porcentaje de penetración del 10 % podría ser una historia
diferente. La combinación del índice de madurez, el porcentaje de omnipresencia y la descripción deberían ayudar a
tomar esta determinación. Sin embargo, la descripción de la entrada debe ser lo suficientemente detallada para que el
equipo de seguridad entienda si la funcionalidad y el alcance de la capacidad realmente romperán las cadenas de
muerte de los atacantes o si se justifica una mayor inversión en esa área de la matriz . Es posible que se implemente el
control correcto, pero si solo se implementa parcialmente o funciona parcialmente, es posible que no sea suficiente para
romper una Kill Chain o ser efectivo en todos los escenarios. Una mayor inversión en la maduración de ese control o la
expansión donde opera podrían ser soluciones a este problema. Otra posible solución es invertir en un control diferente
para complementar la mitigación actual. Desde esta perspectiva, la Matriz de cursos de acción se convierte en un
documento importante para ayudar durante un incidente y es fundamental para las negociaciones sobre presupuestos y
recursos.
con ejecutivos no técnicos.
Identificación de áreas de sobreinversión

La inversión excesiva en áreas es un problema común que he visto sufrir tanto a organizaciones del sector público
como privado. Puede ocurrir lentamente con el tiempo o rápidamente a raíz de una violación de datos. En la Matriz de
Cursos de Acción, una inversión excesiva puede aparecer como muchas entradas en una o dos áreas que realizan
funciones iguales o similares. Por ejemplo, he visto organizaciones adquirir múltiples productos de gestión de acceso e
identidad (IAM) y no implementar ninguno de ellos por completo. Esto puede suceder por una variedad de razones. Por
ejemplo, es posible que no hayan sido realistas acerca de su capacidad para atraer y retener el talento necesario para
implementar estos productos.
Otro ejemplo es que después de una intrusión exitosa, no es raro que una organización víctima decida que es hora de
hacer una gran inversión en seguridad cibernética. Con un nuevo sentido de urgencia y exuberancia, no se toman el
tiempo para hacer un inventario de las capacidades actuales y su madurez antes de salir de compras.
Las fusiones y adquisiciones también pueden dejar a las organizaciones con inversiones excesivas en algunas áreas
de la matriz. De repente, después de una fusión, la organización tiene el doble de herramientas de ciberseguridad que
antes de la fusión. Realizar inventarios de capacidad de ciberseguridad puede ser especialmente desafiante después
de una fusión o adquisición reciente.

Finalmente, en pocas palabras, algunos vendedores son realmente buenos en su trabajo. He visto industrias enteras y
áreas geográficas donde todos han adquirido literalmente la misma solución SIEM o punto final durante los mismos 1
o 2 años fiscales. No hay nada de malo en esto, pero es poco probable que todos hayan comenzado con los mismos
entornos, talento comparable en ciberseguridad y las mismas fechas de renovación de licencias para sus productos
actuales. Cuando un buen vendedor tiene mucho éxito, este

a veces puede conducir a inversiones excesivas en las áreas.
Para las organizaciones que no han realizado antes un inventario de capacidades de seguridad cibernética usando una
Matriz de Cursos de Acción, un área en la que casi siempre parece haber una inversión excesiva es la intersección de
Denegación y Explotación en la Matriz de Cursos de Acción. Hay una buena razón para esto: detener a los atacantes
antes de que pasen este punto en su Kill Chain puede limitar su alcance de control y minimizar el daño y los costos de
recuperación. Esta es la etapa de los ataques a la que muchos profesionales de la seguridad también se refieren como
"a la izquierda del auge". En otras palabras, deténgalos antes de que completen con éxito la fase de Explotación de su
ataque y pasen a la fase de Instalación. Posteriormente, no es raro ver grandes inversiones excesivas en esta área en
entornos de TI empresariales.
En los últimos años, la intersección de Detectar y Explotar en la Matriz de Cursos de Acción también se ha abarrotado
ya que la industria realmente giró en torno al despliegue de capacidades de detección en lugar de confiar solo en las
capacidades de protección. No entre en pánico si la primera vez que completa una matriz de cursos de acción para
una organización, toda la matriz está relativamente vacía, excepto Detectar y Denegar para explotación. Puede ser
gratificante ver cómo cambia la expresión de un CISO demasiado confiado cuando ve la matriz de cursos de acción de
su organización por primera vez y se da cuenta de que ha estado invirtiendo demasiado en las mismas dos áreas
durante años. Esto es bastante típico la primera vez que se adopta esta estrategia centrada en el ataque. También
significa que hay muchas oportunidades de mejora.
Planificación de su implementación
Es importante identificar brechas, áreas con inversión insuficiente y áreas con inversión excesiva, ya que estas
informarán el plan de implementación. Con suerte, muchas de las áreas en las que la organización ya ha invertido no
requerirán cambios. Esto permitirá que los equipos de seguridad y TI se concentren en abordar las brechas y las
deficiencias en su postura de seguridad actual. En el momento en que estos equipos tengan un mapeo actualizado y
hayan identificado brechas, áreas de inversión insuficiente y áreas de inversión excesiva, pueden comenzar a planificar
el resto de su implementación.
¿En qué parte de la matriz de cursos de acción deben trabajar primero los equipos de seguridad? Para algunas
organizaciones , centrarse en abordar las brechas existentes ofrecerá el ROI potencial más alto. Sin embargo, hay
algunos factores a considerar, incluida la disponibilidad de presupuestos y talento en ciberseguridad. El objetivo
general es romper las Kill Chains de los atacantes.

Capítulo 10 415
Sin embargo, recuerde que hay algunas eficiencias en hacer esto tan pronto como sea posible en Kill Chain. Detener un ataque
antes de la Explotación e Instalación puede ayudar a minimizar costos y daños. Sin embargo, como mencioné con respecto a
la estrategia de protección y recuperación, la suposición de que los equipos de seguridad podrán hacer esto el 100 % del
tiempo es demasiado optimista y probablemente llevará a la organización al fracaso. Posteriormente, algunos de los CISO con
los que he discutido esto decidieron invertir un poco en cada parte de la matriz. Sin embargo, un presupuesto suficiente y la
disponibilidad de recursos pueden ser factores limitantes para este enfoque.
La mayoría de los CISO con los que he hablado tienen presupuestos limitados. Para aquellos que no lo hacen, por lo general
todavía están limitados por su capacidad para diseñar, implementar y operar nuevas capacidades rápidamente; la escasez de
talento en ciberseguridad afecta a toda la industria. La fecha de renovación de cada elemento de la matriz puede ayudar a
informar un cronograma utilizado para abordar las brechas y los problemas de inversión. La elección de no renovar las licencias
para productos menos efectivos en áreas de inversión excesiva podría ayudar a liberar parte del presupuesto que se puede
utilizar para abordar las brechas y las áreas de inversión insuficiente. No todas las organizaciones tienen inversiones excesivas,
y muchas tienen una inversión insuficiente crónica en toda la matriz. Para las organizaciones en esta categoría, puede ser útil
aprovechar tantos controles "gratuitos" en los sistemas operativos y entornos de desarrollo integrados como sea posible.
Por ejemplo, la aleatorización del diseño del espacio de direcciones (ASLR) y la prevención de ejecución de datos
(DEP) puede ayudar a que la fase de Explotación de un ataque sea más difícil de lograr e inconsistente.
ASLR es una característica de seguridad de la memoria que puede dificultar la explotación de vulnerabilidades para los
atacantes al aleatorizar las ubicaciones del espacio de direcciones. Esto dificulta que los atacantes predigan constantemente
las ubicaciones de memoria de las vulnerabilidades que desean explotar. Por lo general, ASLR debe usarse en combinación
con DEP (Matt Miller, 2010). DEP es otra función de seguridad de la memoria que evita que los atacantes utilicen páginas de
memoria destinadas a datos para ejecutar su código (Matt Miller, 2010).
Estas funciones están integradas en la mayoría de los sistemas operativos modernos de los principales proveedores en la
actualidad, aunque no todas las aplicaciones las aprovechan. Aún así, el uso cuidadoso de tales controles gratuitos o de bajo
costo puede ayudar a las organizaciones con presupuestos limitados a seguir esta estrategia.
Otra forma en que he visto a los CISO planificar su implementación es usar los resultados de los ejercicios y pruebas de
penetración del Equipo Rojo y el Equipo Azul. Las pruebas de penetración generalmente se enfocan en confirmar la efectividad
de los controles de seguridad que se han implementado, donde los ejercicios del Equipo Rojo se enfocan en superar y burlar a
los defensores. Esta es una forma directa de probar la eficacia de las personas, los procesos y las tecnologías que forman
parte de su implementación actual. Tan importante como identificar brechas, estos ejercicios pueden identificar controles y
mitigaciones que no están funcionando como se esperaba.

Estos ejercicios también pueden ayudar a informar los índices de madurez en su mapeo y ayudar a priorizar
elementos en su plan de implementación de una manera práctica, menos teórica. El marco ATT&CK también
puede ser muy útil para planificar simulaciones de ataques que revelen áreas de mejora e inversión posterior.
Finalmente, otra forma en la que he visto a los CISO decidir implementar marcos como este es invertir primero en
áreas de alto ROI. Lo hacen identificando dónde obtienen el mayor beneficio de su inversión. Esto se hace
mediante la identificación de controles que brindan mitigaciones en múltiples partes de la matriz. Por ejemplo, si el
mismo control potencialmente ayuda a romper las Kill Chains del atacante en las fases de Entrega, Explotación y
Comando y Control, priorizarán ese control sobre los controles que potencialmente solo rompen una fase de un
ataque (Hutchins, Cloppert, Amin, nd). Dicho de otra manera, buscan áreas donde puedan usar dos o tres
mitigaciones por el precio de una. Cuanto más detallada sea su matriz, más oportunidades podrán identificar.
Revisaré muchos de los factores que analicé en esta sección en el Capítulo 11, Medición del desempeño y la
efectividad.
Diseño de conjuntos de control

Con un mapeo actual del conjunto de control, brechas identificadas, áreas de inversión insuficiente, áreas de
inversión excesiva y un plan para abordar cuáles de estas áreas, los equipos de seguridad pueden comenzar a
diseñar conjuntos de control. Esta parte del proceso puede ser desafiante, pero también muy divertida.
¡Después de todo, diseñar controles para dificultar al máximo el éxito de los atacantes es divertido! Para algunas
personas, gastar dinero también es divertido, y existe la oportunidad de sentar las bases para hacerlo en este
ejercicio.
Hay más combinaciones y permutaciones de posibles conjuntos de control de las que puedo cubrir en este libro.
Esta sección tiene como objetivo brindarle más detalles sobre cada parte de la matriz de cursos de acción
actualizada que describí y provocar algunas reflexiones sobre las formas en que los equipos de seguridad podrían
diseñar conjuntos de control para su organización. Este no es un modelo que deba seguirse; en realidad es solo
un ejemplo de alto nivel. No recibí ningún pago promocional por ninguno de los productos o empresas que
mencioné en esta sección, y no los respaldo ni hago ningún reclamo o garantía sobre ellos o sus productos. Utilice
las empresas, los productos, los servicios y las características que cumplan con sus requisitos. Si desea
recomendaciones profesionales, le recomiendo consumir los informes y servicios de firmas de analistas de la
industria como Forrester y Gartner, entre otras.
Aquí es donde los consejos de CISO, las sociedades profesionales y las redes sociales cerradas pueden ser muy útiles.
Obtener informes de primera mano sobre la eficacia de las estrategias, productos y servicios directamente de otros
CISO puede ser muy útil.
Capítulo 10 417
Las firmas de analistas no pueden ser demasiado críticas públicamente con una empresa o sus productos, pero no he
conocido a muchos CISO que no estuvieran dispuestos a ser sinceros en conversaciones privadas a puertas cerradas.
Además, este es otro lugar donde el marco ATT&CK puede ayudar. Las mitigaciones enumeradas para cada técnica y
subtécnica bajo la táctica o tácticas equivalentes en el marco de ATT&CK pueden proporcionar muchas ideas para controles
efectivos. El uso de ATT&CK para este propósito puede ahorrar mucho tiempo a los equipos de seguridad en el diseño de
conjuntos de control. ATT&CK también puede informar las pruebas de estos conjuntos de control y simulaciones de ataque
para garantizar que todos funcionen como se espera.
Recordatorio: las etapas y acciones en la Matriz de Cursos de Acción modificada que cubriré en esta sección se ilustran en
la Figura 10.6. En otras palabras, le daré ideas sobre las capacidades de seguridad cibernética que se pueden usar para
llenar las celdas de la Figura 10.6.
Figura 10.6: Matriz de Cursos de Acción Modificada
Fase de ataque – Reconocimiento I

En esta fase de un ataque, los atacantes seleccionan sus objetivos, realizan investigaciones, mapean y prueban la presencia
en línea de su objetivo, y hacen lo mismo para las organizaciones en la cadena de suministro de su víctima prevista. Los
atacantes buscan respuestas a las preguntas básicas de qué, por qué, cuándo y cómo. Su investigación no se limita a
direcciones IP y puertos TCP/UDP abiertos; las personas, los procesos y las tecnologías son peones potenciales en sus
ataques.
El desafío para los defensores en esta etapa del ataque es que este tipo de actividades de reconocimiento se mezclan con
el tráfico de red legítimo, correos electrónicos, llamadas telefónicas, empleados, etc. Puede ser muy difícil identificar las
actividades de reconocimiento del atacante cuando no son anómalas.
Aún así, puede valer la pena invertir en capacidades de seguridad cibernética en esta etapa porque, como mencioné
anteriormente, romper las cadenas de muerte del atacante lo antes posible generalmente tiene el ROI más alto.
Categorizar las actividades de reconocimiento en grupos pasivos y activos (Sanghvi, Dahiya, 2013) puede ayudar a los
equipos de seguridad a decidir dónde son prácticas las inversiones. Por ejemplo, podría ser prohibitivamente costoso tratar
de identificar a los atacantes que realizan una investigación pasiva leyendo el sitio web de ofertas de trabajo de una
organización solo para identificar los tipos de hardware y software que utiliza.
Sin embargo, puede ser práctico detectar y bloquear las direcciones IP de los sistemas que buscan
vulnerabilidades en los firewalls corporativos. Muchas actividades de reconocimiento pasivo se pueden realizar
fuera de la vista de los defensores y, posteriormente, no generarán entradas de registro ni alertas que los
defensores puedan usar. Sin embargo, muchos proveedores de inteligencia de amenazas ofrecen servicios a
sus clientes que extraen sitios de redes sociales y mercados ilícitos, todo para buscar conversaciones en la web
oscura sobre sus rangos de direcciones IP, dominios, vulnerabilidades conocidas, credenciales para la venta y
ataques inminentes. Las actividades de reconocimiento activas tienden a interactuar directamente con las
víctimas y sus cadenas de suministro, lo que podría brindarles a los defensores una visión más directa de ellas.
Figura 10.7: Categorías de actividades de reconocimiento
Algunas capacidades de ciberseguridad que pueden ayudar en esta fase de un ataque incluyen:
• Los servicios de inteligencia de amenazas pueden ayudar a detectar actividades de reconocimiento pasivas,
lo que podría dar a los defensores avisos de vulnerabilidades conocidas en su postura defensiva y ataques
inminentes. Idealmente, esto puede darles algo de tiempo para abordar estas vulnerabilidades conocidas
y prepararse mejor para un ataque. Algunos ejemplos de proveedores de inteligencia de amenazas que
actualmente ofrecen tales servicios incluyen:
• Sombras digitales
• ojo de fuego
• kroll
• MarkMonitor
• Punto de prueba
• Muchas, muchas otras, incluidas firmas boutique más pequeñas
• Los cortafuegos de aplicaciones web (WAF) pueden detectar ataques a la capa de aplicación, como inyección SQL,
secuencias de comandos entre sitios, etc. Un WAF puede ayudar a detectar, denegar, interrumpir y degradar
los ataques a la capa de aplicación. Algunos ejemplos de WAF incluyen:
• Servicios web de Amazon
• Barracuda
• Llamarada en la nube
Capítulo 10 419
• F5
• Imperva
• Microsoft
• Oráculo
• Muchos, muchos otros
• Cortafuegos : existen al menos algunos tipos diferentes de cortafuegos. Los firewalls pueden detectar,
denegar, interrumpir y degradar algunas actividades activas de reconocimiento de red. Hay demasiados
ejemplos de proveedores que ofrecen productos de firewall para enumerar, pero algunos ejemplos incluyen:
• Barracudas
• Cisco
• Tecnologías de software de Check Point
• Redes de enebro Redes de Palo Alto

• pared sónica
• Las tecnologías de engaño pueden emplearse para engañar a los atacantes que realizan un reconocimiento
activo . Los sistemas de tecnología de engaño presentan los sistemas como la infraestructura legítima
del objetivo previsto o los proveedores en su cadena de suministro. Los atacantes dedican tiempo y
recursos a realizar el reconocimiento de estos sistemas en lugar de la infraestructura y los sistemas de
producción. Los ejemplos de proveedores de tecnología de engaño incluyen:
• Redes Attivo
• Redes ilusorias
• PacketViper
• Seguridad TrapX
• La automatización se puede combinar con inteligencia de amenazas y capacidades de detección para permitir
respuestas dinámicas a las actividades de reconocimiento. Por ejemplo, si un WAF o un firewall detecta
sondeos de direcciones IP maliciosas conocidas, se podría activar la automatización para ajustar
dinámicamente las listas de direcciones IP bloqueadas durante un período de tiempo, o la automatización
podría intentar degradar el reconocimiento y hacer perder el tiempo del atacante al permitir el tráfico de
red ICMP desde direcciones IP maliciosas y bloquear el tráfico TCP a los puertos 80, 443 y otros puertos abiertos.
Esto permitiría a los atacantes ver que los sistemas están en línea, pero no conectarse a los servicios
que se ejecutan en ellos. Este tipo de automatización puede ser más difícil de lograr en entornos locales
heredados , pero está integrado en la nube de forma predeterminada y es relativamente fácil de configurar.
Discutiré las capacidades de la nube con más detalle en el Capítulo 12, Enfoques modernos para la seguridad y el
cumplimiento.
Así es como se ve la Matriz de Cursos de Acción para la fase de Reconocimiento I basada en las capacidades que discutí en esta
sección. Por supuesto, esto es solo rascar la superficie de lo que es posible en esta fase, pero le brinda algunas ideas de cómo
podrían ser algunas acciones para esta primera etapa de un ataque.
Notará que no incluí ninguna entrada para la acción Restaurar. Dado que el reconocimiento generalmente no genera daños ni
compromisos, no hay nada que recuperar en esta etapa de un ataque.
Como mencioné, crear una matriz de cursos de acción usando Excel no es lo ideal, pero funciona. Sin embargo, las tablas que crea
este ejercicio son demasiado grandes para imprimirlas aquí, en un libro, y seguir siendo legibles. Posteriormente, proporcionaré
listas de controles de ejemplo para cada sección de una matriz de ejemplo. No incluyo controles para fases, como Restaurar, por
ejemplo, a menos que haya elementos en él. Para simplificar aún más las cosas, no incluyo ninguna de las modificaciones que
mencioné anteriormente porque son exclusivas de cada organización. Esta lista no pretende ser exhaustiva; proporciona ejemplos
de controles básicos que puede utilizar como punto de partida para desarrollar su propia matriz de cursos de acción. Como verá,
algunos de los elementos se repiten varias veces en la matriz de cursos de acción porque esos controles pueden desempeñar
varias funciones en la matriz.
Controles de ejemplo para Reconocimiento I

Los siguientes son ejemplos de controles que se pueden usar en la fase de Reconocimiento I:
• Tecnología de engaño: puede ayudar a detectar las actividades de reconocimiento y trucos del atacante.
a los atacantes para que dediquen tiempo a realizar reconocimientos en activos falsos en lugar de activos reales.
• Firewall de aplicaciones web (WAF): puede detectar ataques en la capa de aplicaciones, como inyección de SQL,
secuencias de comandos entre sitios, etc.
• Firewalls: pueden detectar sondeos de red y alguna actividad de reconocimiento.
• Servicios de reconocimiento de inteligencia de amenazas: pueden ayudar a detectar actividades de

reconocimiento pasivas , dando a los defensores aviso de vulnerabilidades conocidas en su postura defensiva.
y ataques inminentes.
Capítulo 10 421
• Automatización: use la automatización cuando se detecten actividades de reconocimiento, para ajustar las reglas del
cortafuegos y otros controles de manera que puedan negar, interrumpir, degradar o limitar las actividades.
Figura 10.8: Un resumen de ideas de control para la fase de Reconocimiento I
Información de ATT&CK
ATT&CK puede ser muy útil para identificar tipos específicos de técnicas de reconocimiento que los atacantes han estado
usando y posibles mitigaciones y métodos de detección para ellos. Bajo la táctica de Reconocimiento en la versión actual
de ATT&CK (v12.0) existen 10 técnicas (MITRE, 2020):
• Escaneo activo
• Recopilar información sobre el anfitrión de la víctima
• Recopilar información de identidad de la víctima
• Recopilar información de la red de víctimas
• Recopilar información sobre organizaciones de víctimas
• Phishing para obtener información
• Buscar fuentes cerradas
• Buscar bases de datos técnicas abiertas
• Buscar sitios web/dominios abiertos
• Buscar sitios web propiedad de las víctimas
Las primeras 9 de las técnicas enumeradas tienen múltiples subtécnicas asociadas con ellas. Por ejemplo, el escaneo
activo es una técnica que tiene 3 subtécnicas asociadas. Estos incluyen el escaneo de bloques de IP, el escaneo de
vulnerabilidades y el escaneo de listas de palabras (MITRE, 2020). La única mitigación enumerada para muchas de las
técnicas y subtécnicas es que “esta técnica no se puede mitigar fácilmente con controles preventivos, ya que se basa en
comportamientos realizados fuera del alcance de las defensas y controles de la empresa. Los esfuerzos deben centrarse
en minimizar la cantidad y la sensibilidad de los datos disponibles para terceros” (MITRE, 2020).
Los detalles completos sobre esta táctica ATT&CK están disponibles en: https://attack.mitre.org/tactics/TA0043/
Fase de ataque – Entrega

En este punto de un ataque, los atacantes ya han decidido a qué organización apuntar, han investigado un poco para ayudarlos
a ejecutar su ataque y, potencialmente, han realizado un escaneo de reconocimiento activo y sondeado la presencia en Internet
de la víctima prevista. Con base en esta información, también han pasado por alguna etapa o proceso de armamento en el que
adquirieron y/o construyeron armas que los ayudarán a comprometer inicialmente sus objetivos y permitir sus actividades ilícitas
después. Este proceso de armamentización generalmente ocurre fuera de la vista de los defensores. Sin embargo, como
mencioné en la fase de Reconocimiento I, los servicios de algunos proveedores de inteligencia de amenazas a veces pueden
obtener información sobre estas actividades.
Las armas del atacante pueden incluir personas, procesos y tecnologías. Con todo esto en la mano, los atacantes deben entregar
estas armas a sus objetivos; este es el objetivo de la fase de Entrega.
Los atacantes tienen una variedad de opciones para entregar sus armas a sus objetivos y a los proveedores en sus cadenas de
suministro. Algunos ejemplos de mecanismos de entrega incluyen archivos adjuntos de correo electrónico malicioso, direcciones
URL maliciosas en correos electrónicos, sitios web maliciosos que atraen la atención de las víctimas, información privilegiada
malintencionada, malware que se autopropaga como gusanos, dejar unidades USB maliciosas en las instalaciones de las
víctimas y muchos otros.
Algunas inversiones que pueden ayudar en esta fase de un ataque incluyen:
• Educación/capacitación: recuerde la investigación de inteligencia de amenazas que proporcioné en el Capítulo 4, La
evolución del malware. Está claro que los diferentes tipos de malware están de moda entre los atacantes, pero su
enfoque principal siempre ha sido la ingeniería social. Por lo tanto, educar a los trabajadores de la información y
capacitarlos para detectar ataques comunes de ingeniería social puede ser muy útil para detectar la entrega de las
armas del atacante. El desafío es que la capacitación en ingeniería social no es una actividad única, es una inversión
continua.
Cuando se detiene la capacitación, los empleados actuales comienzan a olvidar estas lecciones y los nuevos
empleados no se capacitan. Tenga en cuenta que la capacitación en sí debe mantenerse actualizada para que siga
siendo efectiva. La combinación de capacitación y simulaciones, como las simulaciones de phishing, puede ser una
forma eficaz de ayudar a los trabajadores de la información a detectar y denunciar la ingeniería social cuando la ven.
Algunas organizaciones simplemente no tienen una cultura que apoye la capacitación en ingeniería social que incluye
campañas de phishing simuladas y otros ataques de ingeniería social contra los empleados. Sin embargo, las
organizaciones que no realizan este tipo de capacitación pierden la oportunidad de dejar que sus empleados aprendan
de la experiencia y del fracaso.

Capítulo 10 423
Una cultura en la que todos tratan de ayudar al CISO es mucho más poderosa que aquellas en las que el
equipo de seguridad siempre reacciona ante decisiones desinformadas y de poca confianza que los
trabajadores de la información sin capacitación tomarán todos los días. A veces, los altos ejecutivos o sus
subordinados directos simplemente no quieren pasar vergüenza si toman una mala decisión en una
simulación de phishing. Estos ejecutivos necesitan controlar sus egos y su orgullo en la puerta cuando
vienen a trabajar, para que sus organizaciones tengan la mejor oportunidad de detectar y detener las tácticas
favoritas de los atacantes. Además, son los objetivos de Business Email Compromise (BEC), que se ha
convertido en un esfuerzo popular y rentable entre los atacantes.
Son las últimas personas que deberían obtener excepciones o evitar dicha capacitación.
• Microsoft Defender para Office 365: el correo electrónico es un vector importante para los ataques de ingeniería social.
El volumen de ataques basados en correo electrónico es relativamente grande en cualquier período de tiempo. Ofrecer
bandejas de entrada de correo electrónico a los trabajadores de la información sin una protección efectiva es preparar a la
organización para el fracaso. Los servicios basados en la nube como Microsoft Defender para Office 365 ayudan a vacunar a
todos sus usuarios al bloquear las amenazas a las que cualquiera de sus usuarios está expuesto. Los servicios de este
tamaño pueden identificar fácilmente las direcciones IP que las redes de bots y los atacantes utilizan para el correo no
deseado, el phishing y otros ataques basados en correo electrónico, y bloquearlos para todos sus usuarios.
Existen numerosas soluciones de terceros que se pueden utilizar como alternativas a Microsoft
Defender para Office 365 o complementarlo, incluyendo:
• Seguridad anormal
• Barracudas
• Tecnologías de software de Check Point

• Mímica
• Punto de prueba
• Muchos otros
• Tecnología engañosa: Soy un gran admirador de la tecnología engañosa. Esta tecnología va más allá de los
honeypots y las honeynets, y ofrece entornos completos que atraen a los atacantes, señalan su presencia y
les hacen perder el tiempo, lo que reduce el retorno de la inversión.
El uso de tecnología engañosa para presentar sistemas vulnerables a los atacantes, sistemas que son
infraestructura crítica o sistemas que almacenan o tienen acceso a datos potencialmente valiosos puede
desviar sus esfuerzos de los sistemas legítimos. La tecnología de engaño también puede ser eficaz para
detectar a personas internas malintencionadas que se sienten atraídas por el cebo que ofrecen.
• Paquetes de seguridad antimalware y de punto final: el software antimalware y otros tipos de software de
seguridad de punto final pueden detectar y bloquear los intentos de entrega de diferentes tipos de
armas cibernéticas. Como mencioné en el Capítulo 4, La evolución del malware, el software antimalware
no es opcional en un mundo donde la cantidad de archivos maliciosos supera a la de los archivos
legítimos. Algunos de los proveedores de seguridad antimalware y de punto final que ofrecen productos incluyen:
• Cilindro de moras
• Huelga multitudinaria
• Negro carbón
• FSecure
• Kaspersky
• McAfee
• Microsoft
• Trellix
• Trend Micro
• Muchos otros
• Tecnologías de protección del navegador web: bloquear el acceso a sitios web maliciosos conocidos y en
contenido seguro, así como escanear el contenido antes de que el navegador lo descargue, puede ayudar
a prevenir la exposición a ataques de descarga oculta, ataques de phishing, sitios de alojamiento de malware,
y otros ataques maliciosos basados en la web.
• Monitoreo de integridad de archivos (FIM): FIM puede ayudar a detectar, bloquear, interrumpir y
degradar la fase de entrega al mantener la integridad del sistema operativo y los archivos de la aplicación.
• IDS/IPS: varios proveedores ofrecen sistemas IDS/IPS, incluidos Cisco, Juniper Networks y
muchos otros.
• Entornos de corta duración: los sistemas que solo viven unas pocas horas pueden interrumpir y degradar la
capacidad del atacante para entregar sus armas, especialmente en escenarios de entrega de varias etapas
más complicados. La nube puede hacer que el aprovechamiento de entornos de corta duración sea
relativamente fácil; Hablaré más sobre este concepto en el Capítulo 12, Enfoques modernos de la seguridad y el cumplimiento.
• Restaurar: me he reunido con muchas organizaciones a lo largo de los años que confían en mecanismos de
bloqueo como el software antimalware para detectar y bloquear la entrega, pero reconstruirán los sistemas
si existe alguna posibilidad de que estén comprometidos. Si la entrega es exitosa, incluso si se bloquea la
explotación y la instalación, algunas organizaciones desean aplanar y reconstruir los sistemas o restaurar
los datos de las copias de seguridad para asegurarse de que todo esté en buen estado.
Capítulo 10 425
A continuación, veremos cómo se ve la matriz de cursos de acción para la fase de entrega en función de las capacidades que analicé
en esta sección.
Ejemplos de controles para Entrega

Los siguientes son ejemplos de controles que se pueden utilizar en la fase de entrega:
• Educación/capacitación: educación y capacitación de trabajadores de la información para detectar ingenieros sociales
ing ataques.
• Microsoft Defender para Office 365: detecta y bloquea la entrega de correo electrónico y archivos maliciosos.
• Tecnología de engaño: puede atraer atacantes y detectar la entrega de armas para engañar
activos.
• Suites antimalware: pueden detectar y bloquear la entrega de contenido malicioso desde el almacenamiento
multimedia, la red y a través de navegadores web.
• FIM: puede detectar y bloquear intentos de reemplazar archivos del sistema.
• IDS/IPS: puede detectar y potencialmente interrumpir o detener la entrega de contenido malicioso entregado
a través de la red.
• Política de prohibición de unidades USB: bloquear el montaje de USB y medios extraíbles en los sistemas puede evitar la entrega
de malware y otro contenido malicioso. Esto también puede ayudar a bloquear

exfiltración de datos.
• Tecnologías de protección del navegador web: algunos navegadores pueden bloquear a sus usuarios para que no visiten sitios
web maliciosos conocidos, evitando así que estén expuestos a phishing, exploits, malware y otros ataques basados en
Internet.
• Entornos de corta duración: los sistemas que se reemplazan cada pocas horas pueden hacer que el De
Fase de librea más dura para los atacantes.
• Tecnologías IAM: Hacer cumplir el principio de privilegio mínimo y separación significativa
de deberes puede ayudar a limitar la entrega de armas en un entorno de TI.
• Copias de seguridad: restaure desde copias de seguridad según sea necesario cuando no se pudo detener la entrega de armas.
• Imágenes y contenedores: reconstruir la infraestructura según sea necesario cuando la entrega de armas podría
no ser detenido.
Tenga en cuenta que las mismas ideas de control en la lista pueden aplicarse a Interrumpir y Degradar en la fase de
ataque de Entrega.
Figura 10.9: Un resumen de ideas de control para la fase de Entrega
Los ejemplos que proporcioné aquí son simples, pero espero que les den algunas ideas a los equipos de seguridad.
La combinación de capacidades en capas que rompen la fase de entrega, independientemente del vector de entrega, es clave.
La táctica de acceso inicial en el marco ATT&CK proporciona 9 técnicas con 10 subtécnicas que los atacantes han estado
utilizando para "ganar su punto de apoyo inicial dentro de una red" (MITRE, 2019):
• Compromiso de paso
• Aprovechar la aplicación de cara al público
• Servicios remotos externos
• Adiciones de hardware
• Suplantación de identidad:
• Subtécnica: archivo adjunto de pesca submarina
• Subtécnica: enlace de pesca submarina
• Subtécnica: Spearphishing vía servicio
• Replicación a través de medios extraíbles
• Compromiso de la cadena de suministro:
• Subtécnica: comprometer dependencias de software y herramientas de desarrollo
• Subtécnica: Compromiso de la cadena de suministro de software

Capítulo 10 427
• Subtécnica: comprometer la cadena de suministro de hardware
• Relación de confianza
• Cuentas válidas:
• Subtécnica: cuentas predeterminadas
• Subtécnica: cuentas de dominio
• Subtécnica: Cuentas locales
• Subtécnica: Cuentas en la nube
ATT&CK sugiere numerosas capacidades de mitigación y detección para hacer que estas técnicas sean más difíciles
o imposibles de confiar para los atacantes. Por ejemplo, para la técnica de explotación de aplicaciones de cara al
público, las mitigaciones incluyen aislamiento de aplicaciones, WAF, segmentación de red, gestión de cuentas
privilegiadas, actualización periódica de software y análisis de vulnerabilidades (MITRE, 2019).
Los detalles completos sobre esta táctica ATT&CK están disponibles en: https://attack.mitre.org/tactics/TA0001/
Fase de ataque – Explotación

Después de que los atacantes hayan entregado con éxito sus armas a sus objetivos, las armas deben activarse. A
veces, las fases de Entrega y Explotación ocurren en sucesión inmediata, como un ataque de descarga oculta. En
este escenario, generalmente se engaña a un usuario para que vaya a un sitio web malicioso a través de una URL
en un correo electrónico o contenido en línea. Cuando hacen clic en el enlace y su navegador web realiza la
resolución de nombres y carga la página, los scripts en la página maliciosa detectarán el sistema operativo y el
navegador y luego intentarán entregar vulnerabilidades para ese software. Si el software no está parcheado para las
vulnerabilidades para las que están diseñados esos exploits, los atacantes generalmente descargarán más malware
en el sistema, instalarán herramientas y continuarán con su Kill Chain. Las fases de Entrega y Explotación suceden
casi al mismo tiempo en este tipo de ataque. En otros ataques, como los ataques basados en correo electrónico, la
entrega puede ocurrir minutos, horas, días, semanas o incluso meses antes de que el usuario abra el correo
electrónico y haga clic en un archivo adjunto malicioso o en la URL de un sitio web malicioso. En este escenario, las
fases de Entrega y Explotación son distintas (Hutchins, Cloppert, Amin, nd).

Algunos atacantes buscan una gratificación instantánea, mientras que otros prefieren el método "bajo y lento".
Los defensores deben estar preparados para ataques en todo este espectro. No pueden asumir que las fases de
Entrega y Explotación ocurrirán siempre casi al mismo tiempo, pero deben estar preparados para tales escenarios.
Romper la fase de Explotación de Kill Chain del atacante es fundamental, porque si completa con éxito esta fase de
su ataque, podría tener un punto de apoyo en el entorno desde el cual puede penetrar más.
Después de esta fase en un ataque, manejar las defensas puede volverse más difícil para los defensores. Debido a que muchos
ataques están automatizados, las actividades posteriores a la fase de explotación pueden ocurrir muy rápidamente. Romper
las Kill Chains del atacante "a la izquierda del boom", como dice el refrán, es un objetivo prudente para los equipos de seguridad.
La mejor manera de evitar la explotación de vulnerabilidades sin parches y configuraciones erróneas de

seguridad (dos de los sospechosos habituales de ciberseguridad) es escanear todo todos los días. Escanear
todos los activos de TI todos los días ayuda a identificar dónde existen vulnerabilidades sin parches y
configuraciones incorrectas de seguridad en el entorno, lo que revela el riesgo residual para que pueda
mitigarse, transferirse o aceptarse conscientemente. Esto ayuda a los equipos de seguridad y remediación
a comprender si están excediendo los acuerdos de nivel de servicio (SLA) de remediación y aceptando más
riesgos de los que la organización planeó. Cuando un sistema con una vulnerabilidad Log4j sin parchear
aparece mágicamente en el entorno, escanear todo todos los días significa que se detecta dentro de las 24
horas posteriores a la aparición y se puede remediar adecuadamente. Además de escanear todo todos los
días, la siguiente lista le brinda algunos controles de ejemplo que se pueden usar para interrumpir las
actividades del atacante en la fase de explotación de un ataque. Con suerte, esto le dará algunas ideas
sobre cómo hacer que la fase de Explotación sea mucho más desafiante para los atacantes:
• Contenedorización y herramientas de seguridad de apoyo: el uso de tecnologías de contenedores como

Docker y Kubernetes tiene muchas ventajas, entre otras cosas porque ayuda a reducir el área de
superficie de ataque de los sistemas y las aplicaciones. Por supuesto, los contenedores también son
software y, en consecuencia, tienen sus propias vulnerabilidades. Hay proveedores que ofrecen
herramientas para ayudar a detectar y prevenir la explotación en entornos que aprovechan los
contenedores. Algunos ejemplos incluyen:
• Seguridad acuática
• Pasaje en la nube
• Illumio
• Sostenible
• Cerradura de la torcedura
• Otros
Capítulo 10 429
• Controles de IAM: Seguir estrictamente el principio de privilegio mínimo puede dificultar la explotación de
vulnerabilidades. A veces, el código del atacante se ejecuta bajo el contexto de la cuenta del usuario que lo
ejecutó, en lugar de bajo privilegios elevados. Limitar los privilegios de los usuarios puede dificultar que la
explotación tenga éxito o tenga el efecto deseado.
• Entornos de corta duración: los sistemas que solo viven unas pocas horas y se reemplazan por sistemas con parches
completos pueden dificultar mucho el éxito de la explotación.
Ejemplos de controles para Explotación

Los siguientes son ejemplos de controles que se pueden utilizar en la fase de Explotación:
• Conjuntos de programas antimalware: el antimalware puede detectar y bloquear la explotación de vulnerabilidades.
• Contenedorización y herramientas de seguridad de apoyo: los contenedores pueden reducir el área de superficie de
ataque y las herramientas de seguridad de apoyo pueden ayudar a detectar y prevenir la explotación.
• FIM: Puede detectar algunos intentos de explotación.
• Revisiones de registros: la revisión de varios registros del sistema puede revelar indicadores de explotación.
• ASLR: el ASLR de los sistemas operativos puede hacer que la explotación sea inconsistente o imposible.
• DEP: la DEP de los sistemas operativos puede hacer que la explotación sea inconsistente o imposible.
• Controles de IAM: Seguir estrictamente el principio de privilegio mínimo puede denegar la explotación en
algunos escenarios.
• Protección de aplicaciones de Microsoft Defender: abre sitios web y archivos que no son de confianza en contenedores
aislados habilitados para HyperV que están separados del sistema operativo host, para evitar que los sitios web
y los archivos maliciosos dañen el sistema o roben las credenciales.
• Entornos de corta duración: los sistemas que se reemplazan cada pocas horas pueden hacer exploita
ción más difícil.
• Tecnología de engaño: puede atraer a los atacantes y engañarlos para que ataquen correos electrónicos falsos.
ambientes
• Honeypots: pueden atraer a los atacantes y exponer los exploits que utilizan.
• Copias de seguridad: restaure a partir de copias de seguridad según sea necesario cuando no se pueda detener la explotación.
• Imágenes y contenedores: reconstruir la infraestructura según sea necesario cuando la explotación no pueda
ser detenido
En la figura se proporciona una ilustración resumida de los controles de ejemplo para la fase de explotación.
10.10.
Figura 10.10: Un resumen de ideas de control para la fase de Explotación
Dedicar tiempo a la superposición de controles para romper la fase de Explotación de la Kill Chain de un
atacante es un tiempo bien invertido. Se podría dedicar un capítulo entero de este libro a la explotación;
Solo he arañado la superficie aquí, pero animo a los CISO y a los equipos de seguridad a dedicar más
tiempo a investigar y considerar cómo implementar esta fase particular de este marco en su
entornos.
La táctica de ejecución en el marco de ATT&CK “consiste en técnicas que dan como resultado código
controlado por el adversario que se ejecuta en un sistema local o remoto” (MITRE, 2019). Esta táctica
tiene 13 técnicas con 21 subtécnicas asociadas (MITRE, 2019):
• Intérprete de scripts y comandos:
• Subtécnica: PowerShell
• Subtécnica: AppleScript
• Subtécnica: Consola de comandos de Windows
• Subtécnica: Unix Shell
• Subtécnica: Visual Basic
• Subtécnica: Python
• Subtécnica: JavaScript
• Subtécnica: Dispositivo de red CLI

Capítulo 10 431
• Comando de administración de contenedores
• Implementar contenedor
• Explotación para la ejecución del cliente
• Comunicación entre procesos:
• Subtécnica: Modelo de objetos componentes
• Subtécnica: intercambio dinámico de datos
• Subtécnica: Servicios XPC
• API nativa
• Tarea/trabajo programado:
• Subtécnica: En
• Subtécnica: Cron
• Subtécnica: Tarea Programada
• Subtécnica: Temporizadores Systemd
• Subtécnica: trabajo de orquestación de contenedores
• Ejecución sin servidor
• Módulos compartidos
• Herramientas de implementación de software
• Servicios del sistema:
• Subtécnica: Launchctl
• Subtécnica: Ejecución del Servicio
• Ejecución del usuario:
• Subtécnica: enlace malicioso
• Subtécnica: archivo malicioso
• Subtécnica: Imagen maliciosa
• Instrumentación de Administración Windows

ATT&CK ofrece 82 mitigaciones para estas técnicas y subtécnicas. Algunas de estas mitigaciones se
aplican a una sola técnica y otras se utilizan para mitigar múltiples técnicas. Las cinco mitigaciones
principales que aparecen con más frecuencia y, por lo tanto, tienen potencialmente el mayor retorno de
la inversión incluyen (MITRE, 2019):
• Id. de mitigación M1038: Prevención de ejecución, "Usar el control de aplicaciones cuando corresponda".
(15/82 = 18%)
• Id. de mitigación M1040: Prevención de comportamiento en Endpoint, "En Windows 10, habilite las reglas de
reducción de superficie de ataque (ASR) para prevenir..." (11/82 = 13 %)
• ID de mitigación M1026: Administración de cuenta privilegiada (9/82 = 11 %)
• ID de mitigación M1018: deshabilitar o eliminar función o programa (6/82 = 7 %)
• ID de mitigación M1042: Administración de cuentas de usuario (6/82 = 7 %)
Los detalles asociados con estas identificaciones de mitigación, junto con los detalles completos sobre la táctica de
ejecución de ATT&CK, están disponibles en: https://attack.mitre.org/tactics/TA0002/
Fase de ataque – Instalación

Simplemente explotar con éxito una vulnerabilidad no es el objetivo para la mayoría de los atacantes de hoy en día,
como lo fue en 2003. La notoriedad ha sido reemplazada por motivaciones mucho más serias y siniestras.
Una vez que los atacantes entregan con éxito sus armas y la explotación es exitosa, generalmente buscan expandir
su alcance de control en los entornos de sus víctimas.
Para ello, tienen a su disposición un abanico de opciones, como desempaquetar malware

o herramientas de control remoto desde el propio arma o descargarlas desde otro sistema.
bajo su control.
Más recientemente, “vivir de la tierra” ha vuelto a ganar popularidad entre los atacantes que buscan usar herramientas,
secuencias de comandos, bibliotecas y archivos binarios nativos y preinstalados con sistemas operativos y
aplicaciones . Esta táctica les permite penetrar aún más en entornos comprometidos, al tiempo que evaden a los
defensores que se enfocan en detectar la presencia de archivos específicos asociados con malware y explotación.
Tenga en cuenta que las tácticas de "vivir de la tierra" se pueden usar en varias fases de Kill Chain de un atacante,
no solo en la fase de instalación. Además, tenga en cuenta que, aunque se ha modernizado un poco, esta táctica es
tan antigua como yo y se basa en que el conocimiento de los defensores anteriores se pierde en el tiempo.
Capítulo 10 433
Cuando trabajé en el equipo de respuesta a incidentes de Microsoft en 2003, cada atacante "vivía de la tierra".
Vimos muchas tácticas creativas utilizadas por los atacantes en esos días. Una lección que aprendí fue que
eliminar todas las herramientas de soporte integradas en el sistema operativo, como ping.exe, tracert.exe y
muchas otras en las que confiaban los atacantes, los obligaba a traer más de sus propias herramientas.
Encontrar cualquiera de esas herramientas en sistemas en el entorno de TI admitido fue un indicador de compromiso.
Mientras tanto, el personal de soporte de escritorio y servidor podría descargar sus propias herramientas desde un
recurso compartido de red para solucionar problemas y eliminarlas cuando terminaran. Hoy en día, los atacantes son
más sofisticados y utilizan archivos binarios y bibliotecas del sistema que realmente no se pueden eliminar sin dañar
potencialmente el sistema operativo. Sin embargo, dejar a los atacantes con la menor cantidad posible de tierra para
vivir puede ayudar a los defensores en múltiples fases de un ataque.
Los atacantes también se basaron en muchos trucos para permanecer ocultos en un sistema. Por ejemplo, ejecutarían
componentes de su software de vigilancia o control remoto en el sistema de una víctima nombrándolo igual que un
archivo de sistema que los administradores esperarían que se ejecutara en el sistema pero ejecutándolo desde un
directorio ligeramente diferente. El archivo y el proceso parecían normales y la mayoría de los administradores no
notarían que se estaba ejecutando desde el directorio del sistema en lugar del directorio system32. Esta táctica era
tan común que desarrollé algunas herramientas de soporte populares para Windows que podrían ayudar a detectar
tales travesuras, incluidos Port Reporter, Port Reporter Parser y PortQry (Microsoft Corporation, sin fecha).
Estas herramientas todavía están disponibles en el Centro de descarga de Microsoft para su descarga gratuita, aunque
dudo que funcionen correctamente en los sistemas basados en Windows 11 hoy en día, ya que muchas API de
Windows han cambiado desde que desarrollé estas herramientas. Por supuesto, tenía que divertirme cuando desarrollé
estas herramientas; mi nombre aparece en los archivos de registro de Port Reporter y cuando el modificador oculto /
dev se ejecuta con Portqry.
Figura 10.11: Huevo de Pascua divertido con Portqry versión 2.0

Algunas de las capacidades que ayudarán a romper la fase de instalación de los ataques incluyen:
• Paquetes antimalware: el software antimalware puede detectar y bloquear los intentos de instalación de diferentes tipos
de armas. Mantenga las suites antimalware actualizadas; de lo contrario, ellos

pueden aumentar la superficie de ataque ellos mismos.
• FIM: Soy fanático de la FIM. Cuando funciona correctamente, puede ayudar a detectar intentos de instalación e,
idealmente, detenerlos. También puede ayudar a cumplir con las obligaciones de cumplimiento que tienen muchas
organizaciones. Las capacidades de FIM están integradas en muchas suites de protección de puntos finales y se
pueden integrar con SIEM. Algunos de los proveedores/productos de FIM que he visto en uso incluyen:
• McAfee
• Calificaciones
• Cable trampa
• Muchos otros
• Controles de IAM: adherirse al principio de privilegios mínimos puede dificultar la instalación

lación para tener éxito.
• Windows Device Guard: esto puede bloquear los sistemas Windows 10 para evitar que se ejecuten programas no
autorizados (Microsoft Corporation, 2017). Esto puede ayudar a prevenir la explotación y la instalación durante un
ataque.
• Control de acceso obligatorio, control de acceso basado en roles en sistemas Linux: estos controles ayudan a aplicar el
principio de privilegios mínimos y controlan el acceso a archivos y procesos, lo que puede dificultar o imposibilitar la
instalación.
Ejemplos de controles para la instalación

Los siguientes son ejemplos de controles que se pueden utilizar en la fase de instalación:
• Paquetes antimalware: el antimalware puede detectar y bloquear la instalación.
• FIM: puede detectar y prevenir cambios en los sistemas y archivos de aplicaciones.
• Revisiones de registros: la revisión de varios registros del sistema puede revelar indicadores de instalación.
• Entornos de corta duración: los sistemas que se reemplazan cada pocas horas pueden hacer que la instalación
lación más difícil.
• Windows Device Guard: puede dificultar la ejecución de programas no autorizados.
• Control de acceso obligatorio, control de acceso basado en funciones (RBAC), control de acceso basado en atributos
(ABAC): estos controles pueden dificultar la ejecución de programas no autorizados.
• Controles de IAM: si se sigue estrictamente el principio de privilegios mínimos, la instalación

mucho más difícil o imposible.
Capítulo 10 435
• Tecnología de engaño: puede atraer a los atacantes y engañarlos para que ataquen correos electrónicos falsos.
ambientes
• Copias de seguridad: restaure a partir de copias de seguridad según sea necesario cuando no se pueda detener la instalación.
• Imágenes y contenedores: reconstruya la infraestructura según sea necesario cuando la instalación no pueda
ser detenido
Tenga en cuenta que muchas de las mismas ideas de control en la lista pueden aplicarse a Denegar, Interrumpir y
Degradar en la fase de ataque de Instalación.
Figura 10.12: Resumen de ideas de control para la fase de instalación
Hay muchos otros controles que pueden ayudar a detectar, negar, interrumpir, degradar, engañar y limitar a los atacantes
durante la fase de instalación de su ataque. Si los atacantes tienen éxito en esta fase, la mayoría de las organizaciones no
dependerán del antimalware ni de los puntos de restauración basados en host para recuperarse; formatearán el sistema y
lo reconstruirán desde cero, utilizando imágenes o copias de seguridad. La nube hace que esto sea mucho más fácil, como
mencioné anteriormente, con entornos de corta duración, escalado automático y otras capacidades.
Hay tres tácticas en el marco de ATT&CK que potencialmente podrían incluirse en la etapa de instalación
de Kill Chains de los atacantes, dependiendo de cómo los equipos de seguridad quieran categorizarlas.
Estas tácticas son persistencia, escalada de privilegios y evasión de defensa. Miremos más de cerca
en dos de ellos.
La persistencia es una táctica donde “el adversario está tratando de mantener su punto de apoyo” (MITRE, 2019).
La táctica de escalada de privilegios es donde el "adversario está tratando de obtener permisos de nivel superior"
(MITRE, 2021). Entre las dos de estas tácticas, hay 71 técnicas y subtécnicas y 151 mitigaciones.
Existen 19 técnicas y 19 subtécnicas asociadas a la Persistencia (MITRE, 2019):
• Manipulación de cuentas:
• Subtécnica: Credenciales de nube adicionales
• Subtécnica: Roles adicionales en la nube
• Subtécnica: Permisos adicionales de delegado de correo electrónico
• Subtécnica: registro de dispositivos
• Subtécnica: claves autorizadas SSH
• Trabajos BITS
• Ejecución de inicio automático de inicio o inicio de sesión:
• Subtécnica: claves de ejecución del registro/carpeta de inicio
• Subtécnica: Paquete de autenticación
• Subtécnica: Proveedores de tiempo
• Subtécnica: Winlogon Helper DLL
• Subtécnica: Proveedor de soporte de seguridad
• Subtécnica: módulos y extensiones del kernel
• Subtécnica: Solicitudes Reabiertas
• Subtécnica: controlador LSASS •
Subtécnica: modificación de acceso directo
• Subtécnica: Monitores de puerto
• Subtécnica: Procesadores de impresión
• Subtécnica: entradas de inicio automático XDG
• Subtécnica: Configuración activa
• Subtécnica: elementos de inicio de sesión
• Scripts de inicialización de arranque o inicio de sesión:
• Subtécnica: Script de inicio de sesión (Windows)
• Subtécnica: gancho de inicio de sesión
• Subtécnica: secuencia de comandos de inicio de sesión en red
• Subtécnica: RC Scripts
• Subtécnica: elementos de inicio

Capítulo 10 437
• Extensiones del navegador
• Compromiso binario de software de cliente

• Crear una cuenta:
• Subtécnica: Cuenta en la Nube
• Subtécnica: Cuenta de Dominio
• Subtécnica: Cuenta Local
• Crear o modificar procesos del sistema:
• Subtécnica: Agente de lanzamiento
• Subtécnica: Servicio Systemd •
Subtécnica: Servicio Windows
• Subtécnica: Launch Daemon
• Ejecución desencadenada por eventos:
• Subtécnica: cambiar la asociación de archivos predeterminada
• Subtécnica: Salvapantallas
• Subtécnica: suscripción a eventos de instrumentación de administración de Windows
• Subtécnica: Modificación de la configuración de Unix Shell
• Subtécnica: Trampa
• Subtécnica: Adición LC_LOAD_DYLIB
• Subtécnica: Netsh Helper DLL
• Subtécnica: funciones de accesibilidad
• Subtécnica: DLL de AppCert
• Subtécnica: DLL AppInit
• Subtécnica: aplicación de cuñas
• Subtécnica: inyección de opciones de ejecución de archivos de
imagen • Subtécnica: perfil de PowerShell
• Subtécnica: Emond
• Subtécnica: secuestro del modelo de objetos componentes
• Subtécnica: Paquetes de instalación
• Servicios Remotos Externos

• Flujo de ejecución de secuestro:
• Subtécnica: Secuestro de orden de búsqueda de DLL
• Subtécnica: carga lateral de DLL
• Subtécnica: Secuestro Dylib
• Subtécnica: debilidad de los permisos del archivador del instalador ejecutable
• Subtécnica: Secuestro de enlazador dinámico
• Subtécnica: intercepción de ruta por variable de entorno PATH
• Subtécnica: intercepción de rutas mediante el secuestro de órdenes de búsqueda
• Subtécnica: Intercepción de ruta por ruta no entrecomillada
• Subtécnica: debilidad de los permisos del archivador de servicios
• Subtécnica: Debilidad de permisos de registro de servicios
• Subtécnica: COR_PROFILER
• Subtécnica: KernelCallback TableImplant Internal Image
• Modificar el proceso de autenticación:
• Subtécnica: autenticación del controlador de dominio
• Subtécnica: Filtro de contraseña DLL
• Subtécnica: Módulos de autenticación enchufables • Subtécnica:
Autenticación de dispositivos de red
• Subtécnica: Cifrado reversible
• Subtécnica: autenticación multifactor
• Subtécnica: Identidad Híbrida
• Inicio de la aplicación de Office:
• Subtécnica: Complementos
• Subtécnica: macros de plantillas de Office
• Subtécnica: Prueba de oficina
• Subtécnica: Formularios de Outlook
• Subtécnica: Página de inicio de Outlook
• Subtécnica: Reglas de Outlook

Capítulo 10 439
• Arranque previo al sistema operativo:
• Subtécnica: Firmware del sistema
• Subtécnica: Firmware de componentes
• Subtécnica: Bootkit
• Subtécnica: ROMMONkit
• Subtécnica: Arranque TFTP
• Subtécnica: En
• Componente de software de servidor:
• Subtécnica: Componentes IIS
• Subtécnica: Procedimientos almacenados de SQL
• Subtécnica: DLL de servicios de terminal
• Subtécnica: Agente de Transporte
• Subtécnica: Web Shell
• Señalización de Tráfico:
• Subtécnica: Golpeo de puertos
• Subtécnica: Filtros de socket
• Subtécnica: Cuentas predeterminadas
• Subtécnica: Cuentas de Dominio
• Subtécnica: Cuentas Locales
• Subtécnica: Cuentas en la Nube

ATT&CK ofrece 76 mitigaciones para técnicas y subtécnicas asociadas con la táctica de persistencia.
Algunas de estas mitigaciones se aplican a una sola técnica y otras se utilizan para mitigar múltiples
técnicas. Los detalles asociados con estas mitigaciones, junto con los detalles completos sobre la táctica de
persistencia de ATT&CK, están disponibles en: https://attack.mitre.org/tactics/TA0003/
La táctica Escalada de privilegios tiene 13 técnicas y 52 mitigaciones asociadas. Los detalles asociados con
sus técnicas, subtécnicas y mitigaciones están disponibles en https://attack. mitre.org/tactics/TA0004/. Las
técnicas y subtécnicas incluyen:
• Abusar de los mecanismos de control de elevación:
• Subtécnica: Setuid y Setgid
• Subtécnica: omitir el control de cuentas de usuario
• Subtécnica: Sudo y Sudo Caching • Subtécnica:
Ejecución elevada con aviso
• Manipulación de tokens de acceso:
• Subtécnica: suplantación/robo de tokens
• Subtécnica: Crear Proceso con Token
• Subtécnica: crear y suplantar token • Subtécnica:
falsificación de PID principal • Subtécnica:
inyección de historial de SID
• Ejecución de inicio automático de inicio o inicio de sesión:
• Subtécnica: claves de ejecución del registro/carpeta de inicio
• Subtécnica: paquete de autenticación
• Subtécnica: Proveedores de tiempo
• Subtécnica: Winlogon Helper DLL
• Subtécnica: Proveedor de soporte de seguridad
• Subtécnica: módulos y extensiones del kernel
• Subtécnica: Solicitudes Reabiertas
• Subtécnica: Controlador LSASS
• Subtécnica: Modificación de accesos directos
• Subtécnica: Monitores de puerto
• Subtécnica: Procesadores de impresión

Capítulo 10 441
• Subtécnica: entradas de inicio automático XDG
• Subtécnica: Configuración activa
• Subtécnica: elementos de inicio de sesión
• Scripts de inicialización de arranque o inicio de sesión:
• Subtécnica: Script de inicio de sesión (Windows)
• Subtécnica: gancho de inicio de sesión
• Subtécnica: secuencia de comandos de inicio de sesión en red
• Subtécnica: RC Scripts
• Subtécnica: elementos de inicio
• Crear o modificar procesos del sistema:
• Subtécnica: Agente de lanzamiento
• Subtécnica: Servicio Systemd
• Subtécnica: Servicio de Windows
• Subtécnica: Launch Daemon
• Modificación de política de dominio:
• Subtécnica: Modificación de directivas de grupo •
Subtécnica: Modificación de confianza de dominio
• Escape al anfitrión
• Ejecución desencadenada por eventos:
• Subtécnica: cambiar la asociación de archivos predeterminada
• Subtécnica: Salvapantallas
• Subtécnica: suscripción a eventos de instrumentación de administración de Windows
• Subtécnica: Modificación de la configuración de Unix Shell • Subtécnica:
Trap
• Subtécnica: Adición LC_LOAD_DYLIB
• Subtécnica: Netsh Helper DLL
• Subtécnica: funciones de accesibilidad
• Subtécnica: DLL de AppCert
• Subtécnica: DLL AppInit

• Subtécnica: aplicación de cuñas
• Subtécnica: Inyección de opciones de ejecución de archivo de imagen
• Subtécnica: perfil de PowerShell
• Subtécnica: Emond
• Subtécnica: secuestro del modelo de objetos componentes
• Subtécnica: Paquetes de instalación
• Explotación para escalada de privilegios
• Flujo de ejecución de secuestro:
• Subtécnica: Secuestro de orden de búsqueda de DLL
• Subtécnica: carga lateral de DLL
• Subtécnica: Secuestro Dylib
• Subtécnica: debilidad de los permisos del archivo del instalador ejecutable
• Subtécnica: Secuestro de enlazador dinámico
• Subtécnica: intercepción de ruta por variable de entorno PATH
• Subtécnica: intercepción de rutas mediante el secuestro de órdenes de búsqueda
• Subtécnica: Intercepción de ruta por ruta no entrecomillada
• Subtécnica: Debilidad de permisos de archivos de servicios
• Subtécnica: Debilidad de permisos de registro de servicios
• Subtécnica: COR_PROFILER
• Subtécnica: KernelCallbackTable
• Inyección de proceso:
• Subtécnica: inyección de biblioteca de enlace dinámico
• Subtécnica: Inyección ejecutable portátil
• Subtécnica: secuestro de ejecución de subprocesos
• Subtécnica: Llamada a procedimiento asíncrono
• Subtécnica: almacenamiento local de subprocesos
• Subtécnica: Llamadas al sistema Ptrace
• Subtécnica: Memoria Proc
• Subtécnica: inyección de memoria de ventana adicional
• Subtécnica: proceso de vaciado

Capítulo 10 443
• Subtécnica: Proceso Doppelgänging
• Subtécnica: secuestro de VDSO
• Subtécnica: ListPlanting
• Subtécnica: En
• Subtécnica: Cuentas predeterminadas
• Subtécnica: Cuentas de Dominio
• Subtécnica: Cuentas Locales
• Subtécnica: Cuentas en la Nube
Las mitigaciones a las que se hace referencia con más frecuencia entre las tácticas de persistencia y escalada
de privilegios incluyen (MITRE, 2021):
• ID de mitigación M1026: Administración de cuenta privilegiada (17/151 = 11 %)
• ID de mitigación M1018: Administración de cuentas de usuario (16/151 = 11 %)
• ID de mitigación M1022: Restringir permisos de archivos y directorios (13/151 = 9 %)
• Mitigación ID M1038: Prevención de ejecución (11/151 = 7 %)
• ID de mitigación M1040: Prevención de comportamiento en Endpoint (10/151 = 7 %)
Fase de Ataque – Comando y Control (C2)

Si los atacantes tienen éxito en la fase de instalación de su ataque, generalmente buscan establecer canales de
comunicación con los sistemas comprometidos. Estos canales de comunicación permiten a los atacantes enviar
comandos a los sistemas comprometidos, lo que les permite tomar una serie de acciones en las próximas fases
de sus ataques. Una botnet es un gran ejemplo ilustrativo. Una vez que los atacantes han comprometido los
sistemas e instalado su software C2 en ellos, pueden usar esos sistemas "zombie" para una gran cantidad de
propósitos ilícitos, incluido el robo de identidad, el robo de propiedad intelectual, los ataques DDoS, etc.
Existen numerosas técnicas que los atacantes pueden emplear para las comunicaciones C2. Algunos
son más innovadores e interesantes que otros. La comunicación a través de la red es el enfoque más
sencillo y los atacantes han desarrollado muchos métodos y protocolos diferentes para facilitar las
comunicaciones C2; estos van desde simplemente escuchar en un número de puerto TCP o UDP
predefinido para los comandos hasta el uso de protocolos más elaborados como RPC y DNS,
protocolos personalizados y el empleo de proxies para ofuscar aún más sus comunicaciones.
Todas estas técnicas pueden potencialmente ayudar a los atacantes a controlar de forma remota los entornos
comprometidos mientras evaden la detección. Quieren que su tráfico de red se mezcle con otro tráfico de
red legítimo. Algunos atacantes han desarrollado impresionantes algoritmos de generación de dominios que
les permiten cambiar dinámicamente las direcciones IP utilizadas para las comunicaciones C2. Conficker fue
el primer gran ataque de gusanos que utilizó este método, hace más de 15 años. Algunos atacantes han
desarrollado protocolos ofuscados y encriptados que dificultan que los defensores detecten y detengan el ataque.
comandos del atacante.
Al detectar, denegar, interrumpir, degradar, engañar y limitar las comunicaciones C2, los defensores pueden
minimizar los daños y los gastos de sus organizaciones y acelerar la recuperación, al mismo tiempo que aumentan
los gastos de los atacantes. Esta es un área en la que los proveedores que tienen amplia experiencia y
capacidades en redes, combinados con inteligencia de amenazas, realmente pueden agregar valor. Algunas de
las formas en que los defensores pueden hacer esto incluyen:
• IDS/IPS: Estos sistemas pueden detectar y bloquear comunicaciones C2 en varios lugares de las
redes. Muchas organizaciones ejecutan IDS/IPS en sus DMZ y dentro de sus redes corporativas.
Muchos proveedores ofrecen sistemas IDS/ IPS, incluidos:
• Cisco
• ojo de fuego
• HP
•IBM
• Enebro
• McAfee
• Otros
• Microsegmentación de red: esto puede proporcionar un control granular al permitir que las
organizaciones apliquen políticas a cargas de trabajo individuales. Esto puede dificultar que los
atacantes utilicen sistemas comprometidos para comunicaciones C2.
Capítulo 10 445
• Revisiones de registros: el análisis de registros, datos de NetFlow y consultas de DNS en un entorno puede ayudar
detectar comunicaciones C2. Dado que puede haber demasiados datos para que los humanos hagan esto, hombre
Por lo general, muchas organizaciones ahora emplean inteligencia artificial y/o aprendizaje automático para hacer
esto por ellas. Por supuesto, la nube hace que esto sea mucho más fácil que intentar hacerlo en las instalaciones.
Controles de ejemplo para C2

Los siguientes son ejemplos de controles que se pueden utilizar en la fase C2.
• IDS/IPS: Puede detectar y detener las comunicaciones de los atacantes.
• Cortafuegos y servidores proxy: La comunicación con redes remotas puede ser detectada y bloqueada por cortafuegos
y servidores proxy.
• Revisiones de registros: la revisión de varios registros del sistema, incluidas las consultas de DNS, puede revelar indicadores
de comunicaciones C2.
• Entornos de corta duración: los sistemas que se reemplazan cada pocas horas pueden hacer que C2 com
comunicaciones más difíciles de lograr e inconsistentes.
• Controles de IAM: Seguir estrictamente el principio de privilegio mínimo puede hacer que algunas comunicaciones C2
técnicas de comunicación mucho más difíciles.
• Microsegmentación de la red: Hacer cumplir las reglas que restringen las comunicaciones puede hacer
Comunicaciones C2 más difíciles.
• Tecnología engañosa: los atacantes que se comunican con entornos falsos desperdician su
tiempo y energía.
Tenga en cuenta que las mismas ideas de control en la lista anterior pueden aplicarse a Interrumpir, Degradar y Limitar en
la fase de ataque C2.
Figura 10.13: Resumen de ideas de control para la fase C2

Un aspecto crítico para detectar y prevenir las comunicaciones C2 es la inteligencia de amenazas. Tenga en cuenta
los consejos que proporcioné en el Capítulo 2, Lo que debe saber sobre la inteligencia de amenazas, sobre cómo
identificar la inteligencia de amenazas creíble, mientras evalúa a los proveedores para ayudar en esta fase del marco.
Proporcionar inteligencia antigua, inteligencia de productos básicos y falsos positivos rara vez es útil, pero
parece ser un desafío común que enfrentan muchos proveedores. También descubrí que, a menos que las
comunicaciones C2 u otro tráfico de red malicioso se puedan rastrear hasta un contexto de identidad específico
en el entorno comprometido, puede ser menos procesable. Posteriormente, los sistemas de detección y
prevención de C2 que están integrados con sistemas de identidad parecen tener una ventaja sobre aquellos
que no tienen tales integraciones. El valor de estos sistemas parece ser una función del tiempo y el esfuerzo
dedicados a ajustarlos, especialmente para minimizar los falsos positivos.
El marco ATT&CK proporciona una gran lista de técnicas que utilizan los atacantes para las comunicaciones
C2 (MITRE, 2019). Este es otro buen ejemplo de cómo el marco ATT&CK y el marco Intrusion Kill Chain se
complementan entre sí. La táctica de Comando y Control de ATT&CK es donde “el adversario intenta
comunicarse con los sistemas comprometidos para controlarlos” (MITRE, 2019). Esta táctica cuenta con 16
técnicas y 23 subtécnicas (MITRE, 2019):
• Protocolo de la capa de aplicación:
• Subtécnica: DNS
• Subtécnica: Protocolos de transferencia de archivos
• Subtécnica: Protocolos de correo
• Subtécnica: Protocolos Web
• Comunicación a través de medios extraíbles
• Codificación de datos:
• Subtécnica: codificación no estándar
• Subtécnica: codificación estándar
• Ofuscación de datos:
• Subtécnica: Datos basura
• Subtécnica: suplantación de protocolo
• Subtécnica: Esteganografía
Capítulo 10 447
• Resolución dinámica:
• Subtécnica: Cálculo de DNS

• Subtécnica: Algoritmos de Generación de Dominio
• Subtécnica: Fast Flux DNS
• Canal encriptado:
• Subtécnica: criptografía asimétrica

• Subtécnica: criptografía simétrica
• Canales alternativos
• Transferencia de herramientas de ingreso
• Canales de varias etapas

• Protocolo de capa de no aplicación
• Puerto no estándar
• Tunelización de protocolos
• Apoderado:
• Subtécnica: Dominio Fronting

• Subtécnica: Proxy Externo
• Subtécnica: Proxy Interno
• Subtécnica: Proxy multisalto
• Software de acceso remoto
• Señalización de Tráfico:
• Subtécnica: Golpeo de puertos

• Subtécnica: Filtros de socket
• Servicio web:
• Subtécnica: Comunicación Bidireccional

• Subtécnica: Dead Drop Resolver
• Subtécnica: comunicación unidireccional
ATT&CK proporciona 52 mitigaciones para estas técnicas y subtécnicas. Algunas de estas mitigaciones abordan una sola
técnica y otras se utilizan para mitigar múltiples técnicas. Las mitigaciones que aparecen con más frecuencia y, por lo
tanto, tienen potencialmente el mayor retorno de la inversión incluyen (MITRE, 2019):
1. ID de mitigación M1031: Prevención de intrusiones en la red (31/52 = 60 %)
2. ID de mitigación M1037: Filtrar tráfico de red (6/52 = 12 %)
3. Mitigación ID M1021: Restringir contenido basado en la web (6/52 = 12 %)
4. ID de mitigación M1020: Inspección de SSL/TLS (4/52 = 8 %)
5. ID de mitigación M1042: Administración de cuentas de usuario (6/82 = 7 %)
Los detalles asociados con estas identificaciones de mitigación, junto con los detalles completos sobre la táctica de
comando y control de ATT&CK, están disponibles en: https://attack.mitre.org/tactics/TA0011/
Fase de ataque Reconocimiento II

Una de las cosas que los atacantes a menudo ordenan que hagan los sistemas comprometidos que controlan es ayudarlos
a mapear la red de su víctima. Los atacantes a menudo quieren explorar las redes para buscar datos valiosos, propiedad
intelectual valiosa y activos de alto valor que pueden robar, dañar o exigir un rescate a cambio de su devolución. También
buscan información, cuentas, infraestructura y cualquier otra cosa que pueda ayudarlos a acceder a la lista de valores
antes mencionada. Nuevamente, están tratando de combinar sus actividades de reconocimiento con los procesos comunes
y legítimos de tráfico de red, autenticación y autorización que ocurren en las redes de sus víctimas. Esto les ayuda a evadir
la detección y permanecer persistentes en la red durante períodos más largos.
La detección de actividades de reconocimiento puede ayudar a los defensores a descubrir sistemas comprometidos en su
entorno. Además, hacer que este tipo de reconocimiento sea difícil o imposible de realizar para los atacantes podría ayudar
a limitar el daño y los gastos asociados con un compromiso. Esto puede ser más fácil decirlo que hacerlo, especialmente
en entornos heredados con muchas aplicaciones propias y aplicaciones antiguas cuyo comportamiento puede ser
sorprendente e impredecible en muchos casos. Muchos analistas de SOC han detectado un escaneo secuencial de
puertos en su red, solo para encontrar alguna aplicación local que utiliza la forma más ruidosa posible de comunicarse en
la red. Este comportamiento generalmente se remonta a un desarrollador que intenta resolver un problema mientras hace
su vida más fácil. El mundo está lleno de aplicaciones como esta, que hacen que la detección de anomalías verdaderas
sea más laboriosa.
Esta es otra fase en la que los atacantes rutinariamente “viven de la tierra”. Ya sea que estén ejecutando scripts para
realizar un reconocimiento o haciéndolo manualmente, cuando los defensores dejan la mayoría de las herramientas que
los atacantes necesitan instaladas de forma predeterminada en los sistemas, facilita el trabajo de los atacantes.
Capítulo 10 449
Eliminar o restringir el uso de estas herramientas comunes en todos los lugares donde sea posible incomoda
a los atacantes y hará que sea más fácil detectar cuándo estas herramientas, u otras similares, se usan en
el entorno. Sin embargo, es poco probable que los equipos de seguridad puedan eliminar todos los archivos
binarios y bibliotecas que los atacantes pueden usar de sus entornos.
Algunas de las otras capacidades incluidas en las listas de control anteriores incluyen:
• Tecnología de engaño: Ya sea que la parte que realiza el reconocimiento dentro de la red sea un
atacante o un infiltrado, la tecnología de engaño puede ser útil para detectar su presencia. Cuando
alguien comienza a hurgar en los activos que nadie en la organización tiene ningún negocio
legítimo que tocar, esto puede ser una señal de alerta. Además, si los atacantes muerden el
anzuelo que ofrecen las tecnologías de engaño, como robar credenciales, por ejemplo, y usan
esas credenciales en otro lugar del entorno, es una muy buena indicación.
de las actividades de reconocimiento.
• Análisis del comportamiento del usuario (UBA): UBA, o análisis del comportamiento de la entidad, puede ayudar a identificar
cuándo los usuarios y otras entidades acceden a los recursos fuera de lo normal. Esto puede indicar una información privilegiada
amenazas o credenciales robadas que utilizan los atacantes y descubrir actividades de reconocimiento.
Hay muchos proveedores que ofrecen productos que realizan este tipo de detección, entre ellos:
• examen
• Punto de fuerza
• LogRitmo
• Microsoft
• RSA
• Splunk
• Muchos otros
• SAW/PAW: Las estaciones de trabajo de administrador seguras (SAW) o las estaciones de trabajo de
acceso privilegiado (PAW) harán que sea mucho más difícil para los atacantes robar y usar credenciales
para cuentas de administrador y otras cuentas con privilegios elevados. Las SAW/PAW supervisadas
y auditadas ayudan a detectar el uso inusual de credenciales privilegiadas.
• Refuerzo de Active Directory: hace que sea más difícil para los atacantes acceder y robar credenciales.
• Cifrado en todas partes: Protección de datos mientras viajan por la red y cada
donde descansa puede ser un poderoso control para prevenir un reconocimiento efectivo.
Controles de ejemplo para Reconnaissance II

Los siguientes son ejemplos de controles que se pueden usar en la fase de Reconocimiento II:
• Tecnología de engaño: las tecnologías de engaño pueden ayudar a detectar las actividades de reconocimiento del
atacante y pueden engañar a los atacantes para que dediquen tiempo a realizar reconocimiento en
entornos falsos en lugar de reales.
• Revisiones de registros: la revisión de varios registros del sistema, incluidas las consultas de DNS, puede revelar indicadores
de compromiso
• UBA: Puede detectar comportamientos anómalos.
• SAW/PAW: las SAW/PAW monitoreadas y auditadas ayudan a detectar el uso inusual de credenciales privilegiadas.
Esto puede hacer que sea mucho más difícil para los atacantes robar y usar credenciales para
cuentas de administrador y otras cuentas con privilegios elevados.
• Microsegmentación de la red: Hacer cumplir las reglas que restringen el tráfico de la red puede hacer
reconocimiento más difícil.
• Controles de IAM: Seguir estrictamente el principio de privilegio mínimo puede dificultar la realización del
reconocimiento.
• Cifrado en todas partes: el cifrado de datos en tránsito y en reposo puede proteger los datos de
atacantes
• Fortalecimiento de Active Directory: Esto hace que sea más difícil para los atacantes acceder y robar cre.
denciales
Tenga en cuenta que las mismas ideas de control en la lista anterior pueden aplicarse a Denegar, Interrumpir, Degradar y
Limitar en la fase de ataque de Reconocimiento II.
Figura 10.14: Un resumen de ideas de control para la fase de Reconocimiento II
Hay muchas más formas de detectar y hacer que el reconocimiento sea más difícil para los atacantes, sin embargo, parece
que solo después de un compromiso exitoso, durante la respuesta, se detectan los signos reveladores del reconocimiento.
Las inversiones en esta fase del marco pueden tener grandes beneficios para los equipos de seguridad.
Capítulo 10 451
Este es otro buen ejemplo de un punto de integración entre el marco ATT&CK y el marco Intrusion Kill Chain. ATT&CK proporciona
al menos dos tácticas que los atacantes podrían utilizar en la etapa de Reconocimiento II de sus ataques. Estas tácticas son
Discovery y Credential Access (MITRE, nd). Sin embargo, también se pueden usar otras tácticas mientras los atacantes se mueven
alrededor de los entornos de sus víctimas, como Evasión de defensa, Movimiento lateral, Colección (MITRE, sin fecha). Esta es una
de las características que hace poderoso a ATT&CK; no asume que los ataques son pasos discretos secuenciales: los atacantes
pueden elegir hacer muchas cosas e iterar entre tácticas según sea necesario. Echemos un vistazo más de cerca a la táctica
Discovery.
Discovery cuenta con 30 técnicas y 13 subtécnicas (MITRE, 2019):
• Descubrimiento de cuenta:
• Subtécnica: Cuenta en la Nube
• Subtécnica: Cuenta de Dominio
• Subtécnica: Cuenta de correo electrónico
• Subtécnica: Cuenta Local
• Descubrimiento de la ventana de la aplicación
• Descubrimiento de marcadores del navegador
• Descubrimiento de infraestructura en la nube
• Tablero de servicios en la nube
• Descubrimiento de servicios en la nube
• Detección de objetos de almacenamiento en la nube
• Descubrimiento de contenedores y recursos
• Evasión del depurador
• Descubrimiento de confianza de dominio
• Descubrimiento de archivos y directorios
• Descubrimiento de directivas de grupo
• Descubrimiento de servicios de red
• Detección de recursos compartidos de red
• Rastreo de redes
• Descubrimiento de políticas de contraseñas

• Detección de dispositivos periféricos
• Descubrimiento de grupos de permisos:
• Subtécnica: Grupos de nubes
• Subtécnica: Grupos de Dominio
• Subtécnica: Grupos Locales
• Descubrimiento de procesos
• Registro de consultas
• Descubrimiento de sistemas remotos
• Descubrimiento de software:
• Subtécnica: descubrimiento de software de seguridad
• Descubrimiento de información del sistema
• Descubrimiento de la ubicación del sistema:
• Subtécnica: descubrimiento del idioma del sistema
• Descubrimiento de la configuración de la red del sistema:
• Subtécnica: Descubrimiento de conexión a Internet
• Descubrimiento de conexiones de red del sistema
• Descubrimiento del propietario/usuario del sistema
• Descubrimiento de servicios del sistema
• Descubrimiento de la hora del sistema
• Evasión de Virtualización/Sandbox:
• Subtécnica: Comprobaciones del sistema
• Subtécnica: verificaciones basadas en la actividad del usuario
• Subtécnica: Evasión basada en el tiempo
Para estas 43 técnicas y subtécnicas, ATT&CK ofrece 18 mitigaciones. Algunos son únicos y otros se usan varias veces en técnicas y
subtécnicas. Las mitigaciones citadas con más frecuencia incluyen las siguientes:
1. “Este tipo de técnica de ataque no se puede mitigar fácilmente con controles preventivos ya que se basa en el abuso de las
funcionalidades del sistema” (MITRE, 2019) (58% de las técnicas y subtécnicas mencionaron esta falta de mitigación)
Capítulo 10 453
2. ID de mitigación M1018: Administración de cuentas de usuario (5/18 = 28 %)
3. ID de mitigación M1028: Configuración del sistema operativo (4/18 = 22 %)
La información sobre todas las técnicas, subtécnicas y mitigaciones está disponible en https://attack.
mitre.org/tactics/TA0007/.
Fase de Ataque – Acciones sobre Objetivos

Recuerde que hay muchas motivaciones posibles para los ataques, incluyendo notoriedad, lucro, espionaje militar, espionaje
económico, venganza, anarquía y muchos otros. Una vez que los atacantes llegan a esta fase de su ataque, sus objetivos
están potencialmente a su alcance. En esta fase, pueden bloquear el acceso de los administradores a los sistemas, filtrar
datos, comprometer la integridad de los datos, cifrar datos, dañar la infraestructura, hacer que los sistemas no se puedan
iniciar o simplemente permanecer persistentes para observar a sus víctimas y recopilar datos. Lo que hacen los atacantes en
la etapa Acciones sobre objetivos de sus ataques depende de sus motivaciones.
En algunos casos, esta es la última oportunidad del defensor para detectar y detener a los atacantes antes de que la
recuperación se vuelva más costosa y potencialmente aspiracional. Sin embargo, el hecho de que los atacantes hayan
llegado a esta fase de su Kill Chain no significa automáticamente que tengan acceso a todos los recursos y control total del
entorno de TI; su objetivo podría tener un alcance mucho más estricto, o los controles de seguridad que se han implementado
para impedir su progreso podrían haber tenido el efecto deseado. Esto podría significar que muchos de los controles
utilizados para romper otras fases de Kill Chain aún pueden ser útiles en esta fase. Si los atacantes pudieron anular o eludir
los controles en fases anteriores de su ataque, esto no significa que puedan hacerlo en cualquier parte del entorno de TI, en
cualquier momento.
Lo ideal es detectar y rechazar a los atacantes, pero interrumpir, degradar, engañar y limitar sus ataques es mucho mejor
que recuperarse de ellos.
Algunos de los controles a considerar al mitigar esta fase de un ataque incluyen:
• Copias de seguridad de datos: si los atacantes eligen destruir los datos dañando los medios de almacenamiento o el
firmware, borrando los medios de almacenamiento, cifrando los datos o alterando la integridad de los datos, las
copias de seguridad pueden ser muy útiles. Las copias de seguridad sin conexión son muy recomendables, ya que
los atacantes cifrarán felizmente las copias de seguridad en línea si pueden con su ransomware o cryptoware.
• SAW/PAW: SAW o PAW pueden hacer que sea mucho más difícil para los atacantes usar cuentas privilegiadas para
bloquear el acceso de los administradores a los sistemas que administran.
• Cifrado en todas partes: recuerde que el cifrado no solo proporciona confidencialidad, sino que también puede
salvaguardar la integridad de los datos; el cifrado puede ayudar a detectar que los datos tienen
sido alterado.
• Controles de IAM: la identidad es fundamental para la seguridad. Si los atacantes ya poseen la instancia de Active Directory en el
entorno, será muy difícil o imposible expulsarlos.
Sin embargo, si solo tienen acceso a algunas cuentas, los controles de IAM aún pueden ayudar a limitar el alcance de su
ataque.
Controles de ejemplo para acciones en objetivos

Los siguientes son ejemplos de controles que se pueden utilizar en la fase Acciones sobre objetivos:
• Paquetes antimalware: el antimalware puede detectar y bloquear malware.
• FIM: puede detectar y prevenir cambios en los sistemas y archivos de aplicaciones.
• Revisiones de registros: la revisión de varios registros del sistema puede revelar indicadores de compromiso.
• Análisis del comportamiento del usuario: puede detectar comportamientos anómalos.
• Tecnología de engaño: las tecnologías de engaño pueden detectar las acciones del atacante en los activos
y engañarlos para que ataquen entornos falsos.
• SAW/PAW: las SAW/PAW supervisadas y auditadas ayudan a detectar el uso inusual de

cartas credenciales.
• Entornos de corta duración: los sistemas que se reemplazan cada pocas horas pueden hacer que sea más difícil
para que los atacantes persistan en entornos de TI comprometidos.
• Windows Device Guard: puede dificultar la ejecución de programas no autorizados.
• Control de acceso obligatorio, control de acceso basado en funciones (RBAC), control de acceso basado en atributos (ABAC):
puede dificultar la ejecución de programas no autorizados.
• Controles de IAM: seguir estrictamente el principio de privilegios mínimos puede hacer que sea más difícil para el
las acciones del atacante sobre los objetivos.
• Cifrado en todas partes: el cifrado de datos en tránsito y en reposo puede proteger los datos de
atacantes
• Copias de seguridad: restaure a partir de copias de seguridad según sea necesario.
• Imágenes y contenedores: reconstruir la infraestructura según sea necesario.
• Procesos y tecnologías de recuperación ante desastres: recupere los sistemas de TI de manera eficiente para minimizar
tiempo de inactividad y pérdida de datos.
Tenga en cuenta que las mismas ideas de control en la lista anterior pueden aplicarse a Denegar, Interrumpir, Degradar, y hay
controles muy similares para Limitar en la fase de ataque Acciones sobre objetivos.
Capítulo 10 455
Figura 10.15: Un resumen de ideas de control para la fase Acciones sobre objetivos
Acciones sobre objetivos es otra fase en la que existe un gran potencial de integración
entre el modelo Intrusion Kill Chain y el marco ATT&CK. Hay al menos dos tácticas ATT&CK
que pueden ser utilizados por los atacantes en la etapa de Acción sobre Objetivos de sus ataques,
Exfiltración e Impacto (MITRE, nd). Echemos un vistazo rápido a estas dos tácticas.
La táctica de exfiltración de ATT&CK “consiste en técnicas que los adversarios pueden usar para robar
datos de su red” (MITRE, 2019). Esta táctica cuenta con 9 técnicas y 8 subtécnicas (MITRE, 2019):
• Exfiltración automatizada:
• Subtécnica: Duplicación de Tráfico
• Límites de tamaño de transferencia de datos
• Exfiltración sobre protocolo alternativo:
• Subtécnica: Exfiltración a través del protocolo no C2 cifrado asimétrico
• Subtécnica: Exfiltración a través del protocolo no C2 cifrado simétrico
• Subtécnica: exfiltración a través del protocolo no C2 sin cifrar
• Exfiltración sobre el canal C2

• Exfiltración sobre otro medio de red:
• Subtécnica: Exfiltración por Bluetooth

• Exfiltración sobre medio físico:
• Subtécnica: Exfiltración por USB
• Exfiltración a través del servicio web:
• Subtécnica: Exfiltración a almacenamiento en la nube
• Subtécnica: Exfiltración al repositorio de código
• Transferencia programada
• Transferir datos a la cuenta en la nube
Para estas 17 técnicas y subtécnicas, ATT&CK ofrece 36 mitigaciones. Algunos son únicos y otros se usan
varias veces en técnicas y subtécnicas. Las mitigaciones citadas con más frecuencia incluyen las siguientes:
1. Mitigación ID M1057: Prevención de pérdida de datos (7/36 = 19 %)
2. ID de mitigación M1031: Prevención de intrusiones en la red (7/36 = 19 %)
La información sobre todas las técnicas, subtécnicas y mitigaciones para la táctica de Exfiltración está
disponible en https://attack.mitre.org/tactics/TA0010/.
La táctica ATT&CK Impact es donde "el adversario intenta manipular, interrumpir o destruir sus sistemas y
datos". (MITRE, 2019). Esta táctica tiene un total de 26 técnicas y subtécnicas.
Estos incluyen (MITRE, 2019):
• Eliminación del acceso a la cuenta
• Destrucción de datos
• Datos cifrados para impacto
• Manipulación de datos:
• Subtécnica: manipulación de datos en tiempo de ejecución
• Subtécnica: manipulación de datos almacenados
• Subtécnica: Manipulación de datos transmitidos
• Desfiguración:
• Subtécnica: desfiguración externa
• Subtécnica: desfiguración interna

Capítulo 10 457
• Limpieza de disco:
• Subtécnica: limpieza del contenido del disco
• Subtécnica: limpieza de la estructura del disco
• Denegación de servicio de punto final:
• Subtécnica: Inundación por agotamiento de la aplicación
• Subtécnica: Aplicación o Explotación del Sistema
• Subtécnica: inundación de agotamiento del sistema operativo
• Subtécnica: inundación de agotamiento del servicio
• Corrupción de firmware
• Inhibir la recuperación del sistema
• Denegación de servicio de red:
• Subtécnica: Direct Network Flood
• Subtécnica: Amplificación de reflexión
• Secuestro de recursos
• Parada de servicio
• Apagado/reinicio del sistema
Para estas 13 técnicas y 13 subtécnicas, ATT&CK ofrece 36 mitigaciones. Algunas de estas mitigaciones abordan una
sola técnica y otras se utilizan para mitigar múltiples técnicas. Las mitigaciones citadas con más frecuencia incluyen las
siguientes:
1. ID de mitigación M1053: Respaldo de datos (9/36 = 25 %)
3. ID de mitigación M1022: Restringir permisos de archivos y directorios (4/36 = 11 %)
4. ID de mitigación M1041: Cifrar información confidencial (3/36 = 8 %)
La información sobre todas las técnicas, subtécnicas y mitigaciones para la táctica Impact está disponible en https://
attack.mitre.org/tactics/TA0040/.
En este punto, hemos cubierto todas las fases de nuestra cadena de eliminación de intrusos modificada. Hemos discutido
numerosas ideas para controles efectivos para cada fase y complementamos estas ideas con conocimientos del marco
ATT&CK. Tenga en cuenta que no incluimos todas las tácticas que se incluyen en ATT&CK Matrix for Enterprise en nuestro
diseño Kill Chain; hay muchas más tácticas, técnicas y mitigaciones para informar el diseño del conjunto de control de
Intrusion Kill Chain.

Puede obtener una lista completa y actualizada de tácticas en https://attack.mitre.org/tactics/

empresa/.
La lista completa de técnicas y subtécnicas está disponible en https://attack.mitre.org/

técnicas/empresa/.
La lista completa de todas las mitigaciones está disponible en https://attack.mitre.org/mitigations/

empresa/.
Conclusión
Esa es una forma de implementar el marco Intrusion Kill Chain. Obviamente, existen otras posibles interpretaciones
y enfoques para implementar este modelo. He visto algunos enfoques muy bien pensados y sofisticados para este
marco en conferencias y documentados en Internet, pero la mejor manera es la que aborda los HVA y los riesgos
específicos que preocupan a su organización.
Recuerde que las mejores prácticas se basan en las amenazas y los activos que otra persona tiene en mente, no
necesariamente los suyos.
Esto puede parecer obvio, pero el marco Intrusion Kill Chain puede ayudar a los CISO y a los equipos de seguridad
a adoptar un enfoque estructurado para gestionar las intrusiones. Podría decirse que las intrusiones son las
amenazas más graves para la mayoría de las organizaciones debido a su impacto potencial, pero existen otras
amenazas que los CISO deben abordar. Los ataques DDoS, por ejemplo, normalmente no implican intentos de
intrusión ni requieren un marco Kill Chain para abordarlos.
Además, el enfoque de Intrusion Kill Chain se ha vuelto un poco anticuado en un mundo donde la nube ha
interrumpido y mejorado los enfoques tradicionales de TI y ciberseguridad. Aunque este enfoque aún tiene el
potencial de ser altamente efectivo en entornos locales e híbridos, un marco diseñado para romper las cadenas
de eliminación de intrusiones y detener a los llamados actores de amenazas persistentes avanzadas (APT) no es
tan relevante en la nube. Si se usan de manera efectiva, las canalizaciones de CI/CD, los entornos de corta
duración, el escalado automático y otras capacidades que ofrece la nube simplemente no dejan lugar para que
los actores de APT u otros atacantes se afiancen para moverse lateralmente y permanecer persistentes. En pocas
palabras, la nube brinda a los CISO la oportunidad de cambiar drásticamente el campo de juego. Discutiré los
beneficios de seguridad cibernética que ofrece la nube con más detalle en el Capítulo 12, Enfoques modernos
para la seguridad y el cumplimiento.
Dado que la industria continuará con la transición del antiguo mundo de TI en las instalaciones a la nube durante
la próxima década, el marco Intrusion Kill Chain todavía parece estar bien preparado para ayudar a las
organizaciones como una estrategia de ciberseguridad centrada en el ataque de transición.
Capítulo 10 459
Puede ayudar a las organizaciones en las instalaciones y en la nube a medida que modernizan su fuerza laboral
para aprovechar DevOps, así como los métodos Zero Trust, a medida que se materializan.
También puede ayudar a los CISO que desean aprovechar una única estrategia de ciberseguridad en todo su
patrimonio de TI, incluidos los entornos heredados en las instalaciones y en la nube. He proporcionado una
ventaja inicial en el desarrollo de un enfoque Kill Chain para entornos locales en este capítulo. Además, fui
coautor de un documento técnico cuando trabajé en AWS que brindará a los equipos de seguridad una gran
ventaja para implementar una cadena de eliminación de intrusos en AWS. Este documento se titula “Marcos de
análisis de intrusión clásicos para entornos de AWS” (Rains, et al. 2022), y en el momento de redactar este
documento todavía está disponible para su descarga pública en el sitio web de AWS. Este documento contiene
70 páginas de servicios y controles de seguridad de AWS asignados al marco Intrusion Kill Chain. Esto ahorrará
potencialmente a los equipos de seguridad semanas o meses de trabajo tratando de hacer este mapeo ellos mismos.
Finalmente, emplear esta estrategia es potencialmente muy superior a no tener una estrategia de seguridad
cibernética o usar muchas de las otras estrategias que examiné en el Capítulo 9, Estrategias de seguridad
cibernética. Si su organización no tiene una estrategia de seguridad cibernética o la tiene, pero nadie puede
articularla, es probable que le vaya mucho peor que adoptar la estrategia Intrusion Kill Chain. Para hacerlo, en
muchos casos, tendrá que ser mucho más detallado y específico que el ejemplo de alto nivel que he proporcionado
aquí. Sin embargo, creo que le he brindado una ventaja inicial sobre la estrategia de seguridad cibernética con
mejor puntuación. ¡Esto no es algo malo de tener!
Resumen
Los CISO y los equipos de seguridad tienen numerosas estrategias, modelos, marcos y estándares de
ciberseguridad para elegir al desarrollar su enfoque para proteger, detectar y responder a las amenazas
modernas. Una estrategia centrada en el ataque que examinamos en el Capítulo 9, Estrategias de seguridad
cibernética, la Intrusion Kill Chain, merece una consideración seria, ya que obtuvo la puntuación total estimada
más alta de CFSS. Obtuvo una puntuación casi perfecta con 95 puntos de 100 posibles.
Este capítulo buscó brindarle un ejemplo de una forma en que se puede implementar este modelo.
El modelo Intrusion Kill Chain fue iniciado por Lockheed Martin; las fases de Kill Chain
proporcionadas en el documento de Lockheed Martin sobre este tema incluyen Reconocimiento,
Armamento, Entrega, Explotación, Instalación, Comando y Control (C2) y Acciones sobre
objetivos (Hutchins, Cloppert, Amin, nd). Una consideración antes de implementar este marco
es si los defensores deben usar el marco original de Intrusion Kill Chain o actualizarlo.
Hay varias formas de modernizar este marco. Se puede modificar o reorganizar en torno a los sospechosos
habituales de ciberseguridad para garantizar que se mitiguen y facilitar la identificación de brechas en la postura
de seguridad de una organización.
Divida la fase de Reconocimiento en dos fases en lugar de una; uno que los atacantes pueden usar antes del
compromiso inicial y otro después del compromiso. La fase de Armamento puede descartarse ya que los CISO
normalmente no tienen controles muy efectivos para la protección y detección antes de la fase de Entrega. La fase
Destroy se puede reemplazar con fases más pragmáticas como Limit y Restore.
Agregar un índice de madurez, para capturar y comunicar cuánto o qué tan bien cada capacidad de seguridad
cibernética mitiga las amenazas, puede ayudar a identificar áreas de inversión insuficiente y brechas potenciales en
las defensas. También puede ser útil incluir una estimación de qué tan generalizado se ha implementado un control .
Agregar un punto de contacto para cada mitigación, para dejar en claro quién está consumiendo los datos generados
por las capacidades de seguridad cibernética, ayudará a garantizar que no haya mitigaciones no administradas en
el entorno. El seguimiento de las renovaciones de licencias de seguridad cibernética y los plazos de soporte
ayudarán a prevenir fallas en las capacidades.
El enfoque de Intrusion Kill Chain se puede complementar con el marco ATT&CK, publicado por MITRE.
ATT&CK tiene muchos usos. Por ejemplo, las tácticas, técnicas y subtécnicas proporcionadas por
ATT&CK se pueden aprovechar para informar el diseño y las pruebas del conjunto de control para Kill Chain.
Racionalizar las mitigaciones puede ayudar a identificar brechas y áreas de inversión insuficiente y excesiva . Dónde
comenzar con una implementación puede estar informado por muchos factores, incluidos el presupuesto, los
recursos, las brechas y las áreas de inversión insuficiente y excesiva. La implementación de controles que ayuden
a romper las Kill Chains de los atacantes en varios lugares podría ofrecer a los equipos de seguridad un ROI más alto.
Con esto concluye mi ejemplo de cómo se puede implementar una estrategia de ciberseguridad. Espero que los
consejos y trucos que he proporcionado te sean útiles. En el próximo capítulo, examinaré cómo los CISO y los
equipos de seguridad pueden medir si la implementación de su estrategia es efectiva. Este puede ser un objetivo
importante, aunque elusivo, para los equipos de seguridad.
Referencias
• Hutchins, EM, Cloppert, MJ, Amin, RM Ph.D. (Dakota del Norte). Defensa de redes informáticas basada en
inteligencia informada por análisis de campañas adversarias y cadenas de eliminación de intrusos.
Obtenido de Lockheed Martin: https://lockheedmartin.com/content/dam/lockheedmartin/
• Sanghvi, HP, Dahiya, MS (2013). Reconocimiento Cibernético: Una Alarma antes del Ataque Cibernético.
International Journal of Computer Applications (0975 – 8887), Volumen 63– No.6, páginas 23.
Obtenido de https://research.ijcaonline.org/volume63/number6/pxc3885202.pdf
• Matt Miller, M. (8 de diciembre de 2010). Sobre la efectividad de DEP y ASLR. Obtenido del Centro de
respuestas de seguridad de Microsoft: https://msrcblog.microsoft.com/2010/12/08/
sobrelaefectividaddedepyaslr/
Capítulo 10 461
• Corporación Microsoft. (13 de octubre de 2017). Controle el estado de los dispositivos

basados en Windows 10. Obtenido de Microsoft Docs : https://docs.microsoft.com/en
us/windows/security/threatprotection/protecthighvalueassetsbycontrollingthehealthof
dispositivos basados en Windows 10
• Corporación Microsoft. (Dakota del Norte). Escáner de puerto de línea de comando PortQry Versión
2.0. Obtenido del Centro de descarga de Microsoft: https://www.microsoft.com/enus/download/
detalles.aspx?id=17148
• INGLETE. (Dakota del Norte). MITRE ATT&CK®. Obtenido de MITRE ATT&CK®: https://attack.
mitre.org/
• INGLETE. (Dakota del Norte). Preguntas frecuentes sobre MITRE ATT&CK®. Obtenido de MITRE ATT&CK®: https://attack.
mitre.org/resources/faq/
• INGLETE. (18 de octubre de 2020). Reconocimiento. Obtenido de MITRE ATT&CK®: https://

attack.mitre.org/tactics/TA0043/
• INGLETE. (19 de julio de 2019). Acceso Inicial. Obtenido de MITRE ATT&CK®: https://attack.
mitre.org/tactics/TA0001/
• INGLETE. (19 de julio de 2019). Ejecución. Obtenido de MITRE ATT&CK®: https://attack.

• INGLETE. (19 de julio de 2019). Persistencia. Obtenido de MITRE ATT&CK®: https://attack.

• INGLETE. (6 de enero de 2021). Escalada de privilegios. Obtenido de MITRE ATT&CK®: https://

• INGLETE. (19 de julio de 2019). Comando y control. Obtenido de MITRE ATT&CK®: https://
• INGLETE. (19 de julio de 2019). Descubrimiento. Obtenido de MITRE ATT&CK®: https://attack.

• INGLETE. (19 de julio de 2019). Exfiltración. Obtenido de MITRE ATT&CK®: https://attack.

• INGLETE. (19 de julio de 2019). Impacto. Obtenido de MITRE ATT&CK®: https://attack.mitre.

org/tácticas/TA0040/
• Rains, Walker, Ryland, ScottCowley, Evans, Lyle, Samuel, Hodges, Alexander,

Gera y Vyas. (2022). Marcos clásicos de análisis de intrusiones para entornos
de AWS: aplicación y mejora. Obtenido de https://docs.aws.amazon.com/
whitepapers/ Latest/classicintrusionanalysisframeworksforawsenvironments/
classic intrusionanalysisframeworksforawsenvironments.html

11
Medición del rendimiento y
Eficacia
¿Cómo sabemos si la estrategia de ciberseguridad que hemos empleado está funcionando según lo planeado?
¿Cómo sabemos si el CISO y el equipo de seguridad están siendo efectivos? Este capítulo se centrará en
medir la eficacia de las estrategias de ciberseguridad.
A lo largo de este capítulo, cubriremos los siguientes temas:
• Uso de datos de gestión de vulnerabilidades
• Medir el desempeño y la eficacia de las estrategias de ciberseguridad
• Examen de una estrategia de ciberseguridad centrada en ataques como ejemplo
• Uso de los resultados de la reconstrucción de intrusiones
• Aprovechamiento de MITRE ATT&CK®
Comencemos este capítulo con una pregunta. ¿Por qué los CISO necesitan medir algo?
Introducción
Hay muchas razones por las que los equipos de ciberseguridad necesitan medir las cosas. El cumplimiento de los estándares
regulatorios, los estándares de la industria y sus propios estándares de seguridad interna suelen ser los principales.
464 Medición del rendimiento y la eficacia
Hay cientos de métricas relacionadas con la gobernanza, el riesgo y el cumplimiento con las que las
organizaciones pueden elegir medirse. Cualquiera que haya estudiado para obtener la certificación
de Profesional certificado en seguridad de sistemas de información (CISSP) sabe que existen numerosos
dominios, incluidos seguridad y gestión de riesgos, seguridad de activos, arquitectura de seguridad y
Ingeniería, Comunicación y Seguridad de Redes, Gestión de Identidad y Acceso (IAM), y algunos
otros (ISC2, 2021). El desempeño y la eficacia de las personas, los procesos y las tecnologías en
cada uno de estos dominios se pueden medir de muchas maneras. De hecho, la cantidad de
métricas y las formas en que se pueden medir es vertiginosa. Si está interesado en conocer la
variedad de métricas disponibles, le recomiendo leer el libro de 848 páginas de Debra S. Herrmann
sobre el tema, Guía completa de métricas de seguridad y privacidad: Medición del cumplimiento
normativo, la resiliencia operativa y el ROI (Herrmann, 2007).
Además de medir las cosas por razones de cumplimiento, los equipos de seguridad cibernética también intentan
encontrar métricas significativas para ayudar a demostrar que están agregando valor a las empresas que respaldan.
Esto puede ser desafiante y un poco injusto para los CISO. Indicadores clave de rendimiento (KPI) y objetivos y resultados clave
(OKR) normalmente miden el rendimiento frente a metas u objetivos. Para los equipos de seguridad, fallar
en lograr un objetivo tiende a causar daño. Puede ser difícil encontrar datos significativos que ayuden a
demostrar que las inversiones y los esfuerzos del CISO y el equipo de seguridad cibernética son las razones
por las que la infraestructura de TI de la organización no se ha visto comprometida ni ha sufrido una filtración
de datos. ¿Fue su trabajo lo que evitó que los atacantes tuvieran éxito? ¿O la organización simplemente
“pasó por debajo del radar” de los atacantes, como he oído sugerir a tantos ejecutivos no relacionados con
la seguridad? Aquí es donde la analogía del submarino que introduje en el prefacio puede ser útil. No pasa
desapercibido en Internet en lo que respecta a la ciberseguridad; solo hay una presión constante desde
todas las direcciones. Además, la esperanza no es una estrategia; es la abdicación de la responsabilidad.
No obstante, los CISO deben poder demostrarles a sus pares, a las empresas o ciudadanos a los que apoyan
y a los accionistas que los resultados que han producido no son un subproducto de la suerte o el cumplimiento
de la esperanza. Necesitan demostrar que sus resultados son el producto de ejecutar con éxito su estrategia
de ciberseguridad.
He visto a muchos CISO intentar hacer esto a través de opiniones y evidencia anecdótica. Pero sin datos
para respaldar opiniones y anécdotas, estos CISO tienden a tener más dificultades para defender el éxito de
su estrategia y programa de ciberseguridad. Es solo cuestión de tiempo antes de que un auditor o consultor
ofrezca una opinión diferente que cuestione la descripción del CISO del estado actual de las cosas.
Capítulo 11 465
Los datos son clave para medir el rendimiento y la eficacia de una estrategia de ciberseguridad. Los datos ayudan a los
CISO a gestionar sus programas e inversiones en ciberseguridad y les ayudan a demostrar que su programa de
ciberseguridad ha sido eficaz y mejora constantemente. En este capítulo, proporcionaré sugerencias a los CISO y los
equipos de seguridad sobre cómo pueden medir la eficacia de su estrategia de ciberseguridad. Para hacer esto, usaré
la mejor estrategia de puntaje que examiné en el Capítulo 9, Estrategias de seguridad cibernética, y el Capítulo 10,
Implementación de la estrategia, la estrategia centrada en el ataque, como ejemplo. También me basaré en conceptos
e ideas que proporcioné en los capítulos anteriores de este libro. No cubriré la medición de cosas para el cumplimiento
u otros propósitos aquí, ya que hay muchos libros, documentos y estándares que ya hacen esto. Empecemos analizando
el valor potencial de los datos de gestión de vulnerabilidades.
Uso de datos de gestión de vulnerabilidades

Para las organizaciones que recién están iniciando un programa de seguridad cibernética o para los CISO que han
asumido el liderazgo de un programa que ha estado luchando por obtener tracción en su organización, los datos de
gestión de vulnerabilidades pueden ser una herramienta poderosa. Incluso para los programas de seguridad cibernética
bien establecidos, los datos de gestión de vulnerabilidades pueden ayudar a ilustrar cómo el equipo de seguridad ha
estado gestionando eficazmente el riesgo para su organización y mejorando con el tiempo. A pesar de esto,
sorprendentemente, he conocido a algunos CISO de empresas grandes y bien establecidas que no agregan ni analizan
o, de lo contrario, usan datos de sus programas de gestión de vulnerabilidades. Esto me sorprende cuando lo encuentro,
porque estos datos representan una de las formas más sencillas disponibles para que los CISO comuniquen la efectividad
de sus programas de ciberseguridad.
Un desafío para los CISO y los ejecutivos de TI es desarrollar una descripción general del desempeño basada en datos
que se alinee con la forma en que los ejecutivos comerciales miden y comunican el desempeño. El impacto de dichos
datos también puede ser completamente diferente para los CISO.
Por ejemplo, cuando un sitio de producción de productos está atrasado, se activarán recursos y planes de acción
adicionales para ayudar a compensar. Pero para los CISO, los recursos adicionales rara vez son el resultado de estar
atrasados; en su mayor parte, se supone que los programas de seguridad son como una utilidad: allí cuando la necesita,
pero fuera de la vista hasta entonces.
Como discutí extensamente en capítulos anteriores, las vulnerabilidades sin parches y las configuraciones erróneas de
seguridad son dos de los cinco sospechosos habituales de ciberseguridad que se gestionan a través de un programa de
gestión de vulnerabilidades. Posteriormente, un programa de gestión de vulnerabilidades bien ejecutado no es opcional.
Como mencioné en el Capítulo 8, Ingredientes para una estrategia de seguridad cibernética exitosa, los inventarios de
activos que están completos y actualizados son fundamentales para el éxito de los programas de gestión de
vulnerabilidades y los programas de seguridad cibernética en general. Después de todo, es difícil para los equipos de
seguridad administrar activos que no saben que existen.

Los equipos de gestión de vulnerabilidades deben escanear todo en sus inventarios todos los días en busca de
vulnerabilidades y configuraciones incorrectas. Esto puede ayudar a minimizar la cantidad de tiempo que las
vulnerabilidades y configuraciones erróneas críticas y de alta gravedad no mitigadas están presentes y explotables
en sus entornos. Recuerde que las vulnerabilidades y las configuraciones incorrectas pueden introducirse en los
entornos de TI de varias maneras: vulnerabilidades recientemente reveladas (en promedio, 69 por día en 2022),
software y sistemas creados a partir de imágenes antiguas o restaurados a partir de copias de seguridad, software
y sistemas heredados que quedan fuera de soporte y activos huérfanos que no se administran con el tiempo, entre
otras formas .
Cada día que un equipo de administración de vulnerabilidades escanea todos sus activos, tendrán una nueva
instantánea del estado actual del entorno que pueden unir con todas las instantáneas de los días anteriores. Con el
tiempo, el equipo de ciberseguridad puede utilizar estos datos de múltiples formas. Permítanme darles algunos
ejemplos de cómo se pueden utilizar estos datos.
Activos bajo administración versus activos totales

La cantidad de activos escaneados por un equipo de gestión de vulnerabilidades frente a la cantidad total de activos
que posee y opera una organización puede ser un punto de datos interesante para algunas organizaciones . La
diferencia entre estos dos números representa potencialmente un riesgo, especialmente si hay activos que nadie
gestiona activamente en busca de vulnerabilidades y configuraciones incorrectas. He visto grandes diferencias entre
estos dos números en organizaciones en las que TI ha tenido una falta de personal crónica durante largos períodos
y no hay suficiente documentación o conocimiento tribal para informar inventarios de activos precisos. Posteriormente,
puede haber grandes franjas de activos de TI que no se inventarian y no se gestionan activamente como parte de
un programa de gestión de vulnerabilidades.
También he visto grandes diferencias en estos números cuando los CISO no tienen buenas relaciones con el
liderazgo de TI; en casos como este, los inventarios de TI inexactos parecen comunes y representan un riesgo real
para una organización. En algunos de los casos que he visto, TI sabe dónde están todos o la mayoría de los activos,
pero no trabajará de manera proactiva con el CISO para garantizar que todos estén inventariados y reparados.
Como escribí en el Capítulo 8, Ingredientes para una estrategia de seguridad cibernética exitosa, los CISO deben
trabajar para tener buenas relaciones con sus comunidades de partes interesadas, especialmente con sus organizaciones de TI.
Los CIO y CTO también deben darse cuenta de que sus roles tienen un destino compartido con el CISO; cuando
falla el programa de gestión de vulnerabilidades, todos fallan y deberían compartir la “gloria”. Los días en que el
CISO es el único chivo expiatorio de las fallas de seguridad de TI son en gran medida cosa del pasado: los
reguladores, las juntas y los accionistas saben mejor después de décadas de filtraciones de datos. Los CISO que
se encuentran en este escenario deben trabajar para mejorar su relación con sus socios de TI. En algunos casos,
es más fácil decirlo que hacerlo.
Capítulo 11 467
En el escenario de ejemplo ilustrado en la Figura 11.1, el programa de administración de vulnerabilidades

continúa administrando vulnerabilidades y configuraciones incorrectas para la misma cantidad de activos
de TI durante todo el año. Felizmente ignoran que hay subredes con activos de TI que no están
analizando en busca de vulnerabilidades y configuraciones incorrectas. Tampoco están analizando los
nuevos activos de TI que se han introducido en el entorno durante el año. El espacio entre las dos
líneas del gráfico representa el riesgo para la organización.
Figura 11.1: Un ejemplo de datos de tendencia que ilustra la diferencia entre la cantidad total de
activos de TI en el inventario y la cantidad de activos inscritos en la gestión de vulnerabilidades
programa
El número total de activos de TI y el número total de activos que se analizan en busca de vulnerabilidades
y las configuraciones incorrectas todos los días deben ser idénticas para minimizar el riesgo. Sin embargo, puede
haber buenas razones, en entornos grandes y complejos, para que haya excepciones a esta regla. Pero las
excepciones aún deben ser conocidas, comprendidas y rastreadas por los equipos responsables de gestionar las
vulnerabilidades; de lo contrario, el riesgo para la organización no se manifiesta en el nivel de gestión correcto de
la organización. Dicho de otra manera, si la organización va a tener sistemas sin parches, la decisión de hacer esto
y por cuánto tiempo debe ser aceptada por la capa de administración adecuada más alta y revisada periódicamente.
La capa de gestión adecuada para decisiones como esta podría no estar en TI en absoluto; depende de la
organización y el modelo de gobierno que haya adoptado. Recuerde, la decisión de permitir que un sistema sin
parches se ejecute en el entorno es una decisión de aceptar el riesgo en nombre de toda la organización, no solo
del propietario o administrador de ese activo.
He visto gerentes de proyecto demasiado entusiastas para aceptar todo tipo de riesgos en nombre de toda
su organización para cumplir con el cronograma, el presupuesto y los objetivos de calidad de sus proyectos.
Esto es a pesar del hecho de que el alcance de su función se limita a los proyectos en los que trabajan. Si un
riesgo nunca se eleva al nivel de gestión adecuado, podría permanecer desconocido y potencialmente sin
gestionar para siempre. Se deben emplear registros de riesgo para rastrear el riesgo y revisar periódicamente
las decisiones de transferencia y aceptación del riesgo.
En entornos donde el número total de activos de TI y el número total de activos que están
las vulnerabilidades administradas activamente son significativamente diferentes, esta es una oportunidad para
que los CISO y los gerentes de programas de vulnerabilidad muestren cómo están trabajando para cerrar esa
brecha y, por lo tanto, reducir el riesgo para la organización. Pueden usar estos datos para educar a los líderes
de TI y a su junta directiva sobre los riesgos que representan para sus organizaciones. Para ello, pueden utilizar
inventarios de activos parciales e inexactos y hablar de la presencia de activos no gestionados. Los CISO
pueden proporcionar a las partes interesadas actualizaciones periódicas sobre cómo la diferencia entre la
cantidad de activos bajo el mandato del equipo de gestión de vulnerabilidades y la cantidad total de activos que
la organización posee y opera las tendencias a lo largo del tiempo, a medida que TI y su equipo de
ciberseguridad trabajan juntos para reducirlo y minimizarlo. Este punto de datos representa un riesgo real para
una organización, y los datos de tendencias ilustran cómo el CISO y su equipo de gestión de vulnerabilidades
lo han gestionado a lo largo del tiempo. Si este número va en la dirección equivocada, es responsabilidad de la
alta dirección y del consejo de administración reconocerlo y ayudar a solucionarlo.
La Figura 11.2 ilustra que el CISO y el equipo de gestión de vulnerabilidades han estado trabajando con
sus socios de TI para reducir el riesgo que representan los sistemas que no se han inscrito en su
programa de gestión de vulnerabilidades.
Esta es una tendencia positiva que el CISO puede utilizar para comunicar el valor de la ciberseguridad.
programa.
Capítulo 11 469
Figura 11.2: Un ejemplo de datos de tendencias que ilustran una mejora en la diferencia entre la
cantidad total de activos de TI en el inventario y la cantidad de activos inscritos en la vulnerabilidad
programa de gestión
Vulnerabilidades conocidas sin parchear

Otro punto de datos clave de los programas de gestión de vulnerabilidades es la cantidad de vulnerabilidades
conocidas sin parchear que están presentes en un entorno. Recuerde que hay muchas razones por las que
algunas organizaciones tienen sistemas sin parches en sus inventarios de activos de TI. Para ser totalmente
franco, la razón citada con más frecuencia que he escuchado es la falta de inversión en programas de
gestión de vulnerabilidades; Los programas con personal y recursos insuficientes simplemente no pueden
administrar el volumen de nuevas vulnerabilidades en sus entornos. Probar las actualizaciones de seguridad
e implementarlas requiere personas capacitadas, procesos efectivos y tecnologías de soporte, además de tiempo.
Independientemente de las razones, sigue siendo importante comprender qué sistemas no tienen parches, la
gravedad de las vulnerabilidades sin parches y el plan de mitigación para ellas. Compartir regularmente cómo
se reduce la cantidad de vulnerabilidades sin parchear con el tiempo puede ayudar a comunicar cómo el CISO
y el equipo de seguridad cibernética están contribuyendo al éxito del negocio. Un matiz a tener en cuenta para
los entornos que cambian rápidamente es cómo se redujo la cantidad de vulnerabilidades, a pesar de los
cambios materiales en la infraestructura o los aumentos en la cantidad de activos de TI. Para comunicar esto
de manera efectiva, es posible que los CISO deban educar a parte de su comunidad de partes interesadas
sobre los conceptos básicos y los matices de las métricas de gestión de vulnerabilidades, así como su
importancia para el riesgo general de la organización. Por lo general, solo hay uno o dos miembros en una
junta directiva que tienen experiencia en seguridad cibernética, e incluso menos ejecutivos con esa experiencia
en el Csuite típico. En mi experiencia, educar a estas partes interesadas es un tiempo bien invertido y ayudará
a todos a comprender el valor que brinda el equipo de seguridad cibernética. En los casos en los que el equipo
de gestión de vulnerabilidades no cuenta con recursos suficientes, estos datos pueden ayudar a construir el
caso comercial para una mayor inversión de una manera fácil de entender.
La Figura 11.3 ilustra un escenario en el que un equipo de gestión de vulnerabilidades minimizaba con éxito
los aumentos de vulnerabilidades sin parches en su entorno, a pesar de los modestos aumentos en la cantidad
de activos de TI inscritos en su programa. Sin embargo, la adquisición de una empresa más pequeña que cerró
en octubre introdujo una gran cantidad de nuevos activos de TI que se esperaba que administrara el equipo de
administración de vulnerabilidades. Esto fue un tanto disruptivo para el programa durante un período corto y
condujo a un aumento dramático en la cantidad de vulnerabilidades sin parchear, que el equipo pudo reducir a
niveles más típicos al final del trimestre.
Figura 11.3: Un ejemplo de datos de tendencias que ilustran la cantidad de vulnerabilidades parcheadas y la
cantidad de vulnerabilidades sin parchear en activos inscritos en el programa de administración de
vulnerabilidades de una organización
Capítulo 11 471
Con datos como estos, el CISO y el equipo de ciberseguridad parecen héroes. Sin datos como este, sería mucho
más difícil describir el alcance del desafío que la adquisición trajo consigo para el equipo de administración de
vulnerabilidades, el posterior aumento de la carga de trabajo y los resultados positivos. Sin embargo, no todo son
noticias positivas, ya que esta organización tiene una cantidad significativa de vulnerabilidades sin parchear en su
entorno, y con una mayor cantidad de activos para administrar, se enfrentará al desafío de mantener bajos los
recuentos de vulnerabilidades sin parchear con el tiempo. El CISO debe ser capaz de articular el plan para reducir
la cantidad de vulnerabilidades sin parchear lo más cerca posible de cero, utilizando estos mismos datos para
solicitar más recursos para acelerar ese esfuerzo. Tenga en cuenta que las figuras que utilicé en este ejemplo son
completamente ficticias; los datos reales pueden variar enormemente, según la cantidad de activos, hardware,
software, aplicaciones, políticas de remediación, prácticas de gobierno, etc.
Pero reducir la cantidad de vulnerabilidades sin parchear puede ser más fácil de decir que de hacer para algunas
organizaciones. Algunas vulnerabilidades conocidas simplemente no se pueden reparar. Hay numerosas razones
para esto. Por ejemplo, muchos proveedores no ofrecerán actualizaciones de seguridad para el software que se
queda sin soporte. Algunos proveedores cierran y, posteriormente, nunca se ofrecerán actualizaciones de seguridad
para los productos que sus clientes han implementado. Otro ejemplo común son las aplicaciones heredadas que
tienen problemas de compatibilidad con actualizaciones de seguridad específicas para sistemas operativos o
navegadores web. En casos como este, a menudo existen soluciones alternativas que se pueden implementar para
hacer que la explotación de vulnerabilidades específicas sea poco probable o imposible, incluso sin instalar las
actualizaciones de seguridad que las solucionan. Por lo general, las soluciones alternativas están destinadas a ser
soluciones a corto plazo hasta que se pueda implementar la actualización de seguridad que corrige las
vulnerabilidades. Sin embargo, en muchos entornos, las soluciones alternativas se convierten en inquilinos
permanentes. Informar cómo se mitigan las vulnerabilidades conocidas sin parches mediante soluciones temporales,
en lugar de actualizaciones de seguridad, puede ayudar a comunicar el riesgo y cómo se gestiona. Proporcionar
categorías como soluciones alternativas en curso, soluciones alternativas implementadas y ninguna solución
disponible puede ayudar a los patrocinadores comerciales a ver dónde se deben tomar decisiones. La cantidad de
sistemas con soluciones alternativas implementadas, así como la gravedad de las vulnerabilidades subyacentes
que mitigan, brindan una visión matizada del riesgo en el entorno. Combina estos datos con el plan de mitigación a
largo plazo para las vulnerabilidades subyacentes y los CISO tienen una historia de gestión de riesgos que pueden compartir con las part
Vulnerabilidades sin parchear por gravedad

Otro punto de datos potencialmente poderoso es la cantidad de vulnerabilidades sin parchear en un entorno,
clasificadas por gravedad. Como discutí extensamente en el Capítulo 3, Uso de las tendencias de vulnerabilidad
para reducir el riesgo y los costos, las vulnerabilidades críticas y de alta gravedad que se sabe que se explotan
activamente en Internet representan el mayor riesgo debido a la probabilidad y el impacto de su explotación.
Comprender cuántas de estas vulnerabilidades están presentes en el entorno en cualquier momento, cuánto tiempo han
estado presentes y el tiempo de remediación son puntos de datos importantes para ayudar a articular el riesgo que
representan. A más largo plazo, estos datos pueden ayudar a los CISO a comprender qué tan rápido se mitigan estos
riesgos y descubrir los factores que conducen a una vida útil relativamente larga en sus entornos. Estos datos pueden
ayudar a los gerentes de programas de gestión de vulnerabilidades y a los CISO a construir el caso de negocios para
obtener más recursos y mejores procesos y tecnologías. Estos datos también pueden ser uno de los indicadores más
poderosos del valor de los equipos de seguridad cibernética y remediación y la eficacia con la que han estado
gestionando el riesgo para la organización, porque el riesgo que plantean estas vulnerabilidades se encuentra entre los
más graves y es fácil de articular a los ejecutivos y juntas.
No descarte el valor de las vulnerabilidades de gravedad media en los entornos de TI para los atacantes.
Debido al valor monetario de las vulnerabilidades críticas y de alta calificación, los atacantes han estado encontrando
formas de utilizar una combinación de vulnerabilidades de gravedad media para comprometer los sistemas.
Los CISO y los equipos de administración de vulnerabilidades deben administrar estas vulnerabilidades de manera
agresiva para minimizar el riesgo en sus entornos. Esta es otra oportunidad para mostrar valor a las empresas a las
que apoyan y comunicar el progreso parcheando estas vulnerabilidades constantemente.
Vulnerabilidades por tipo de producto

Otro conjunto de datos potencialmente útil son las vulnerabilidades clasificadas por tipo de producto. Seamos realistas:
la mayor parte de la acción ocurre en los escritorios de los usuarios porque traen amenazas a través de las defensas
perimetrales a los entornos de TI. Así como los ojos son las ventanas del alma de las personas, también lo son los
navegadores de los sistemas operativos. Los atacantes intentan constantemente encontrar y explotar vulnerabilidades
en los navegadores web y los sistemas operativos.
Los datos explorados en la Figura 11.4 también se abordan en el Capítulo 3, Uso de tendencias de vulnerabilidad para
Reduzca el riesgo y los costos:
Capítulo 11 473
Figura 11.4: Vulnerabilidades en los 25 productos con más CVE categorizados por tipo de producto
(1999–2022) (CVE Details, 2022)
Los equipos de gestión de vulnerabilidades pueden desarrollar vistas similares para sus entornos para ilustrar
el desafío que tienen y su competencia y progreso en la gestión. Datos como este, combinados con los
puntos de datos anteriores que discutí, pueden ayudar a ilustrar dónde está el riesgo para una organización
y ayudar a optimizar su tratamiento. La cantidad de vulnerabilidades sin parches, de gravedad crítica, alta y
media en los sistemas operativos, los navegadores web y las aplicaciones en un entorno, junto con la
cantidad de sistemas que no son administrados por un programa de administración de vulnerabilidades,
puede ayudar a los CISO y sus partes interesadas a comprender el riesgo en su entorno de TI. Por supuesto,
según el entorno, los datos relacionados con los activos basados en la nube, los dispositivos móviles, el
hardware, el firmware, los dispositivos, los equipos de conmutación y enrutamiento y otras tecnologías que
se utilizan en cada entorno de TI proporcionarán una visión más completa. La combinación de estas
tecnologías y sus vulnerabilidades subyacentes es única para cada organización.
Proporcionar a los equipos de gestión ejecutiva y a los miembros de la junta datos cuantitativos como este les ayuda
a comprender la realidad frente a la opinión. Sin este tipo de datos, puede ser mucho más difícil hacer casos
comerciales convincentes y comunicar el progreso con respecto a las metas de los programas de seguridad
cibernética. Estos datos también facilitarán las cosas cuando ejecutivos aleatorios y otras partes interesadas, como
proveedores demasiado agresivos, pregunten a las partes interesadas del programa de seguridad cibernética sobre
la "vulnerabilidad del día" que aparece en los titulares de las noticias. Si las partes interesadas sénior saben que su
CISO, el equipo de gestión de vulnerabilidades y los equipos de remediación están gestionando las vulnerabilidades
y las configuraciones incorrectas en su entorno de manera competente y diligente, se puede filtrar una gran cantidad
de ruido que de otro modo podría distraer a los CISO.
Este informe puede sonar complicado e intimidante para algunos. La buena noticia es que existen productos de
administración de activos y administración de vulnerabilidades disponibles que brindan capacidades analíticas y de
generación de informes enriquecidas. Los CISO no se limitan a las ideas que proporcioné en este capítulo, ya que los
proveedores de administración de activos y administración de vulnerabilidades tienen muchas maneras excelentes de
ayudar a medir y comunicar el progreso. La clave es utilizar mecanismos de análisis e informes para mostrar de
manera efectiva a las partes interesadas cómo su programa de gestión de vulnerabilidades está reduciendo el riesgo
para la organización y solicitar recursos cuando se necesitan.
Aunque los datos de los programas de gestión de vulnerabilidades pueden ser muy útiles para los CISO, solo les
ayudan a gestionar dos de los cinco sospechosos habituales de ciberseguridad. Hay potencialmente muchos más
datos que pueden ayudar a los CISO a comprender y administrar el rendimiento y la eficacia de sus estrategias de
seguridad cibernética. Exploremos esto a continuación usando el ejemplo que discutí extensamente en el Capítulo 10,
Implementación de la estrategia, una estrategia centrada en el ataque conocida como el marco Intrusion Kill Chain
(Hutchins, EM, Cloppert, MJ, Amin, RM, nd).
Medir el rendimiento y la eficacia de un

Estrategia centrada en el ataque
Como mencioné en el Capítulo 9, Estrategias de ciberseguridad, y el Capítulo 10, Implementación de la estrategia, el
marco Intrusion Kill Chain tiene muchos atributos que lo convierten en una estrategia de ciberseguridad atractiva . En
primer lugar, obtuvo la puntuación total estimada más alta del Sistema de puntuación de fundamentos de ciberseguridad
(CFSS) en el Capítulo 9, Estrategias de ciberseguridad.
Esto significa que tiene el mayor potencial para mitigar por completo los sospechosos habituales de ciberseguridad.
Además, este enfoque se puede utilizar en entornos locales y entornos híbridos y en la nube. Quizás lo que más me
gusta de este marco es que su rendimiento y eficacia se pueden medir de una manera relativamente sencilla.
Examinemos esto en detalle.

Capítulo 11 475
Realización de reconstrucciones de intrusión

Es probable que esto le parezca extraño cuando lo lea, pero cuando se trata de medir el rendimiento y la eficacia
de una estrategia de ciberseguridad, los intentos de intrusión son regalos de los atacantes a los defensores. Son
regalos porque ponen a prueba la implementación y el funcionamiento de las estrategias de ciberseguridad de
los defensores. Pero para obtener valor de los intentos de intrusión, cada intento de intrusión exitoso, parcialmente
exitoso y fallido debe descomponerse y estudiarse. Al hacer esto, hay dos preguntas clave que deben responderse.
Primero, ¿hasta dónde llegaron los atacantes con su Intrusion Kill Chain antes de ser detectados y finalmente
detenidos? En segundo lugar, ¿cómo derrotaron o eludieron los atacantes las capas de controles de mitigación
que el equipo de seguridad cibernética implementó para romper su Intrusion Kill Chain?
Dicho de otra manera, si los atacantes llegaron a la fase cuatro de su Intrusion Kill Chain, ¿cómo superaron todas
las mitigaciones en capas en las fases uno, dos y tres?
Estas son las preguntas centrales que las reconstrucciones de intrusión (Hutchins, EM, Cloppert, MJ, Amin, RM,
nd) deberían ayudar a responder. Al buscar las respuestas a estas dos preguntas, las reconstrucciones de
intrusión también deberían responder muchas otras preguntas que ayudarán a medir el rendimiento y la eficacia
de cada implementación de este enfoque. Como verá mientras describo este proceso, el tema subyacente de
estas preguntas es si las personas, los procesos y las tecnologías que están trabajando para romper las cadenas
de intrusión y eliminación de los atacantes son efectivos. Queremos descubrir si se requieren cambios en cada
fase de nuestra estrategia centrada en el ataque. Empecemos.
El concepto de reconstrucciones de intrusión se analiza en el artículo de Lockheed Martin sobre Intrusion Kill
Chains (Hutchins, EM, Cloppert, MJ, Amin, RM, nd). Una vez más, recomiendo leer este documento. El enfoque
que describiré en este capítulo es ligeramente diferente del enfoque descrito en el artículo de Lockheed Martin.
Hay al menos algunas formas en que se pueden hacer reconstrucciones de intrusión; Describiré una forma que
he usado con cierto éxito en el pasado.
Este enfoque supone que los defensores no podrán realizar la atribución con confianza, por lo que no se basa en
la atribución de la forma en que lo hacen otros enfoques. Considero que esto es una ventaja, ya que la atribución
fuerte es una aspiración y es menos probable a medida que los atacantes se vuelven más sofisticados. El objetivo
de este enfoque para las reconstrucciones de intrusiones es identificar áreas donde se puede mejorar la
implementación del marco Intrusion Kill Chain, no identificar a los atacantes y emprender acciones militares o
legales contra ellos.
Permítanme ofrecer algunos consejos sobre cuándo hacer reconstrucciones de intrusión. No realice
reconstrucciones mientras las actividades de respuesta a incidentes están en marcha. El uso de valiosos recursos
y experiencia que tienen un papel en el proceso de respuesta a incidentes de su organización, durante un
incidente activo, es una distracción innecesaria.
La reconstrucción puede esperar hasta que hayan pasado los períodos de crisis. Idealmente, las reconstrucciones
se pueden hacer mientras los detalles aún están frescos en la mente de los participantes en los días o semanas
posteriores al incidente . Sin embargo, si su organización siempre está en modo de crisis, ignore este consejo y
obtenga acceso a personas e información cuando pueda. Tal vez pueda ayudar a romper el ciclo de crisis identificando
qué deficiencias están contribuyendo a ello.
Para realizar una reconstrucción de intrusión, le sugiero encarecidamente que tenga al menos un representante de
todos los equipos responsables de la estrategia, la arquitectura, la protección, la detección, la respuesta y la
recuperación de ciberseguridad. En entornos realmente grandes, esto puede aplicarse a los equipos relevantes que
fueron responsables de las áreas involucradas en el intento de intrusión. Una vez que la organización se vuelve
buena para hacer reconstrucciones, es probable que la cantidad de participantes se reduzca aún más.
Pero necesita la experiencia y la visibilidad que cada equipo tiene para reconstruir lo que sucedió durante cada
intento de intrusión fallido, parcialmente exitoso y completamente exitoso. Recuerde que una de las modificaciones
que hicimos a la Matriz de cursos de acción (Hutchins, EM, Cloppert, MJ, Amin, RM, nd) en el Capítulo 10,
Implementación de la estrategia, fue agregar un "punto de contacto del consumidor de datos" para cada mitigación.
Esta información puede ser útil para identificar a las personas adecuadas de diferentes equipos para participar en
las reconstrucciones.
Se debe tomar una decisión con respecto a invitar a los proveedores a participar en estas reuniones.
Me ha resultado útil contar con representantes de confianza de algunos de los proveedores de ciberseguridad que
utilizamos para participar en las reconstrucciones de intrusiones.
Hay al menos un par de beneficios en este enfoque. En primer lugar, los proveedores deben poder aportar su
experiencia sobre sus productos y servicios y proporcionar información que, de lo contrario, se perdería.
En segundo lugar, es importante compartir los "regalos" que los atacantes le brindan con los proveedores que ha
seleccionado para ayudarlo a defenderse de ellos. Estos ejercicios pueden informar los esfuerzos de sus proveedores
para hacer mejores productos, de los cuales su organización y otros pueden beneficiarse. Pero también le brinda la
oportunidad de ver qué tan útiles están realmente dispuestos a ser sus proveedores y si están dispuestos a hacerse
responsables de sus deficiencias. Descubrí que algunos de los proveedores que utilicé, que pensé que me
respaldarían durante los incidentes de seguridad, se plegaron como una carpa de circo y se fueron de la ciudad
cuando realmente los necesitaba. Durante las reconstrucciones de intrusiones, estos mismos proveedores tuvieron
el coraje de participar, pero por lo general culparon a sus clientes por el hecho de que sus productos no funcionaran
como se esperaba. Si realiza suficientes ejercicios de reconstrucción con los proveedores, es probable que pueda
determinar si realmente tienen el deseo y la capacidad de ayudar a su organización de la manera que pensó que lo
harían. Este conocimiento resulta útil más adelante, cuando se acercan las fechas de renovación de la licencia del
producto. Discutiré esto más adelante en este capítulo.
Capítulo 11 477
Dicho todo esto, invitar a los proveedores a participar en las reconstrucciones también tiene un riesgo asociado.
En pocas palabras, algunos proveedores son realmente malos para mantener la confidencialidad de la información
confidencial. Mi consejo es discutir la inclusión de proveedores en estas reuniones, caso por caso, con las partes
interesadas que participan en los ejercicios de reconstrucción. Si un proveedor agrega suficiente valor y es confiable,
entonces hay un caso para incluirlo en estos ejercicios. Discutir esta idea con el liderazgo senior para su consejo también
es un paso prudente antes de finalizar una decisión para incluir

vendedores en estos ejercicios.
Si su organización tiene un equipo de análisis forense o utiliza un proveedor de análisis forense, estos expertos pueden
ser increíblemente útiles para los ejercicios de reconstrucción de intrusiones. Las herramientas y habilidades que tienen
pueden ayudar a determinar si los sistemas en la reconstrucción se han visto comprometidos, cuándo y probablemente
cómo. En mi experiencia, me he encontrado con dos tipos de equipos forenses.
El primero es el equipo forense tradicional, que cuenta con examinadores forenses certificados que siguen procedimientos
estrictos para mantener la integridad de las pruebas que recopilan. En mi experiencia con las organizaciones que tienen
este tipo de equipo forense, necesitan un equipo de expertos de tiempo completo que pueda preservar evidencia,
mantener la cadena de custodia y potencialmente testificar en la corte en los asuntos criminales que ayudan a investigar.
Más a menudo, las organizaciones subcontratan este tipo de trabajo.
El otro tipo de equipo forense, que veo mucho más a menudo, realiza una función diferente y, a veces, se lo conoce
simplemente como Respondedores de incidentes. Ellos también buscan determinar si los sistemas se han visto
comprometidos. Pero estos equipos generalmente no cuentan con profesionales forenses certificados, no mantienen la
integridad de la evidencia y no planean testificar en un tribunal de justicia. De hecho, muchas veces, sus esfuerzos por
determinar si un sistema ha sido comprometido resultan en la destrucción de lo que se consideraría evidencia en un
proceso penal. Aquí es donde he encontrado actitudes interesantes ya veces provinciales entre los expertos forenses
certificados, ya que muchos de ellos no llamarían forenses a estos esfuerzos en absoluto porque destruyen la evidencia
en lugar de preservarla adecuadamente. Pero estas personas deben tener en cuenta que muchos ingenieros que usan
anillos en el dedo meñique (Order of the Engineer, nd) se resienten de que los ingenieros de TI usen "ingeniero" en sus
títulos; a los arquitectos que diseñan edificios tampoco les gusta que los arquitectos de TI usen su título, y el título de
"investigador de seguridad" hace que muchos investigadores académicos se estremezcan. Pero yo divago. La realidad
es que no todas las organizaciones quieren dedicar tiempo y esfuerzo a rastrear a los atacantes y tratar de procesarlos
en un tribunal de justicia. Las organizaciones deben decidir qué tipo de profesionales forenses necesitan y pueden pagar.
Ambos tipos de expertos forenses pueden valer su peso en oro cuando ayudan a determinar si los sistemas se han visto
comprometidos y participan en ejercicios de reconstrucción de intrusiones.

¿Quién debe dirigir los ejercicios de reconstrucción? Recomiendo que la persona o grupo responsable de la
estrategia de ciberseguridad dirija estos ejercicios. Este individuo o grupo es, en última instancia, responsable del
desempeño y la eficacia de la estrategia general. También son probablemente responsables de hacer los ajustes
necesarios para garantizar el éxito de la estrategia. Una alternativa al grupo de estrategia es el equipo de Respuesta
a Incidentes (IR) . El equipo de IR debe tener la mayoría, si no todos, los detalles necesarios para liderar la
reconstrucción de una intrusión. Si no es así, acaba de identificar la primera área de mejora.
El equipo de IR gestiona los incidentes, por lo que deberían tener la mayor parte de la información relacionada con
los intentos de intrusión parcial o totalmente exitosos al alcance de la mano. Pero es posible que no estén
involucrados en intentos fallidos que no califican como incidentes. En estos casos, es probable que el personal del
SOC, el personal de operaciones y los arquitectos tengan información clave para la reconstrucción.
Tenga en cuenta que el objetivo no es clasificar todos los escaneos de puertos que ocurren en los firewalls
orientados a Internet de la organización. Sugiero llegar a un acuerdo entre los grupos que participarán en los
ejercicios de reconstrucción con mayor frecuencia sobre un principio que se utiliza para determinar los tipos de
intrusiones en las que se deben realizar las reconstrucciones. Es decir, definir las características de los intentos de
intrusión que determinan si se realiza una reconstrucción formal. Como se muestra en la Figura 11.5, usando nuestra
Matriz de Cursos de Acción actualizada del Capítulo 10, Implementación de la Estrategia, un principio efectivo
podría ser que cualquier intrusión que vaya más allá de la acción Denegar en la fase de Entrega debe ser
reconstruida. Un principio mucho menos agresivo podría ser que cualquier intento de intrusión que resulte en una
acción de Restaurar debe ser reconstruido. Hay muchas otras opciones entre estos dos ejemplos.
El objetivo de dicho principio es imponer una consistencia que ayude a equilibrar adecuadamente el riesgo y el
valioso tiempo de los participantes en la reconstrucción. Este principio no necesita ser cincelado en piedra, puede
cambiar con el tiempo. Cuando una organización comienza por primera vez a realizar reconstrucciones, puede tener
un principio relativamente agresivo que le permite aprender rápidamente. Luego, una vez que las lecciones de las
reconstrucciones se hayan “normalizado” un poco, se puede adoptar un principio menos agresivo. Pero lograr un
acuerdo entre las partes interesadas en estos ejercicios de reconstrucción sobre el principio utilizado para iniciarlos
es importante para su éxito a largo plazo y, por lo tanto, el éxito de la estrategia de seguridad cibernética. Muy
pocas reconstrucciones en relación con los intentos de intrusión podrían significar que la organización no está
prestando suficiente atención a los obsequios que le dan los atacantes y que potencialmente se está adaptando
demasiado lentamente a los ataques. Demasiadas reconstrucciones pueden ser perjudiciales y contraproducentes.
El principio acordado debe lograr el equilibrio adecuado para la comunidad de partes interesadas a lo largo del tiempo.
Capítulo 11 479
Figura 11.5: Un ejemplo de una matriz de cursos de acción actualizada (Hutchins, EM,
Cloppert, MJ, Amin, RM, nd)
Una vez que se hayan identificado los participantes apropiados, o sus delegados, y un líder de
reconstrucción de intrusión esté listo para facilitar, se puede programar una reunión de reconstrucción.
Proporcionar a los participantes suficiente tiempo de anticipación y orientación para recopilar los datos
apropiados para la reconstrucción ayudará a ahorrar tiempo y frustración. Según mi experiencia, algunos
ejercicios de reconstrucción son sencillos porque el intento de intrusión se detectó y detuvo en una fase temprana.
En estos casos, el número de participantes y la cantidad de datos que necesitan para reconstruir el intento de
intrusión pueden ser relativamente menores. Posteriormente, la cantidad de tiempo que normalmente se necesita
para este ejercicio es relativamente corta, como 45 minutos o una hora, por ejemplo. Si recién está comenzando a
hacer reconstrucciones en su organización, naturalmente necesitará un poco más de tiempo del que necesitará
después de acostumbrarse a ellas. Para intentos de intrusión más complicados, especialmente cuando los atacantes
llegan a las últimas etapas de su Kill Chain, es posible que se requieran más participantes con más datos, lo que
aumenta la cantidad de tiempo necesario para los ejercicios de reconstrucción.
Muchas de las organizaciones con las que he trabajado etiquetan los incidentes de seguridad con nombres en
clave. Todas las comunicaciones posteriores sobre un incidente utilizan su nombre en clave. De esta manera, si
alguien que no ha leído el incidente ve un correo electrónico u otras comunicaciones, su contexto y significado no
son obvios. Las comunicaciones e invitaciones a reconstrucciones de intrusiones deben usar nombres de código
de incidentes cuando las organizaciones etiquetan incidentes con ellos. Si decide utilizar nombres en clave de
incidentes, tenga cuidado con los nombres que utiliza y evite etiquetas que sean potencialmente ofensivas. Esto
incluye nombres en idiomas distintos al inglés.
Considere el impacto potencial en la reputación de una organización si el nombre en clave alguna vez se hiciera
público. Manténgase alejado de los temas que son inconsistentes con la marca de la organización o la marca que
aspira construir en la mente de sus clientes. Realmente no hay una razón comercial convincente para usar nada
más que nombres en clave benignos. Estos son aburridos pero efectivos en múltiples niveles.
Ahora tenemos un nombre en clave para nuestro ejercicio de reconstrucción, participantes que traerán datos
relevantes, potencialmente algunos proveedores confiables que participarán y un líder para facilitar
itar el ejercicio.
El objetivo del ejercicio es reconstruir los pasos que dieron los atacantes en cada fase de su Kill Chain. Puede
que no sea posible hacer esto con total certeza, y pueden ser necesarias algunas suposiciones sobre sus tácticas
y técnicas. Pero cuantos más detalles pueda incluir la reconstrucción, más fácil será identificar las áreas en las
que las personas, los procesos y las tecnologías se desempeñaron como se esperaba o no. Esté preparado para
tomar notas detalladas durante estos ejercicios. Un producto de los ejercicios de reconstrucción de intrusiones
debe ser un informe que contenga los detalles del intento de intrusión, así como el desempeño de las defensas
que el equipo de seguridad cibernética tenía en su lugar.
Estos artefactos tendrán un valor potencial durante muchos años, ya que proporcionarán una continuidad útil del
conocimiento sobre ataques pasados, incluso cuando el personal clave abandone la organización. Dicho de otra
manera, cuando se documentan las lecciones aprendidas de estos intentos de intrusión, están disponibles para
que el personal actual y futuro aprenda de ellas. Esta es otra razón por la que llamo “regalos” a los intentos de intrusión.
Nuestro marco Kill Chain actualizado tiene siete fases. ¿Dónde debe comenzar un ejercicio de
reconstrucción ? ¿En la primera fase, o quizás en la última fase? La respuesta a esta pregunta es, depende.
A veces, una intrusión es sencilla y se puede registrar de principio a fin en orden secuencial. Sin embargo, con
intrusiones complicadas o intrusiones que comenzaron meses o años antes, puede que no sea prudente o posible
abordar una reconstrucción de esa manera. Comience con la fase sobre la que tenga la mejor información y la
mayor certeza. Esto podría ser tarde en Kill Chain. Desde su punto de partida, construya una línea de tiempo en
ambas direcciones, utilizando los datos y las perspectivas que pueden ofrecer los participantes en la reconstrucción.
Puede que no sea posible construir la línea de tiempo completa debido a la falta de datos o a la incertidumbre.
Cuantos más detalles descubra la reconstrucción, mejor, ya que esto ayudará a identificar oportunidades de
mejora, brechas y fallas en las defensas. En mi ejemplo, simplemente comenzaré en la primera fase y avanzaré a
través de Kill Chain. Pero tenga en cuenta que esto podría no ser posible para cada intrusión. Comencemos con
la fase de Reconocimiento I.
Puede que no sea posible atribuir las actividades de ningún actor de amenazas en particular en la fase de
Reconocimiento I, antes de su ataque. Con tanto tráfico de red que bombardea constantemente todos los
dispositivos conectados a Internet, suele ser un desafío identificar sondeos específicos y actividades de
reconocimiento realizadas por atacantes específicos. Pero no es imposible. Esta es un área donde la combinación
de inteligencia artificial (IA), aprendizaje automático (ML), buena inteligencia de amenazas y registros granulares
es muy prometedora. El uso de sistemas AI/ML para procesar cantidades masivas de datos de registro, como
datos de flujo de red, registros de DNS, registros de autenticación y autorización, registros de actividad de API y
otros, casi en tiempo real para encontrar actividades específicas de atacantes ya no es ciencia ficción. Los
servicios en la nube pueden hacer esto hoy a escala. ¡La guinda del pastel es que Amazon Alexa puede leer los
hallazgos de seguridad a sus analistas de SOC (Worrell, 2018)!
Capítulo 11 481
Estos son los tipos de capacidades que, hasta hace poco, solo eran posibles en la ciencia ficción. Pero ahora, cualquier
persona con una tarjeta de crédito y un poco de tiempo puede lograrlo con las capacidades que brinda la computación
en la nube. ¡Verdaderamente asombroso! Hablaré más sobre la computación en la nube en el próximo capítulo.
La recopilación de datos y conocimientos de la fase de entrega de un ataque es obviamente muy importante.
La pregunta clave es, ¿cómo derrotaron o eludieron los atacantes las capas de mitigaciones que el equipo de seguridad
cibernética implementó para romper esta fase de su Kill Chain? ¿Cómo entregaron con éxito su arma y qué personas,
procesos y tecnologías participaron?
Para responder a estas preguntas, me ha resultado útil dibujar diagramas de flujo del sistema en una pizarra durante
el ejercicio de reconstrucción con la ayuda de los participantes. Comience dibujando la infraestructura involucrada con
el mayor detalle posible, incluidas las defensas perimetrales, los servidores, los clientes, las aplicaciones, los nombres
de los sistemas, las direcciones IP, etc. Dibuje un mapa de la infraestructura involucrada y grafique cómo se supone
que fluirán los datos en esta infraestructura, los protocolos utilizados, los límites de autenticación y autorización, las
identidades involucradas, el almacenamiento, etc. Luego, dibuje cómo los atacantes entregaron el arma durante su
intento de intrusión y qué sucedió durante la entrega.
Este es otro lugar donde el marco MITRE ATT&CK puede ser muy útil. Su táctica de acceso inicial contiene una
miríada de formas en que los atacantes pueden entregar sus armas. Utilice esta base de conocimientos para ayudar a
identificar las técnicas específicas que utilizaron los atacantes y acelerar las reconstrucciones de intrusión en el
proceso.
¿Qué permitió el éxito del atacante en esta fase? La respuesta a esta pregunta implica hacer y responder muchas
otras preguntas. Deja que te dé algunos ejemplos. Un punto de datos útil en la reconstrucción de una intrusión es
cuánto tiempo se tardó en detectar el ataque. Crear una línea de tiempo de ataque puede ser una herramienta útil
para ayudar a determinar cómo se ejecutó un ataque. En el contexto de la fase de Entrega, ¿se detectó la entrega del
arma y qué control la detectó? Si no se detectó la entrega, documente qué controles se suponía que la detectarían. Si
hay una brecha clara aquí en su implementación del marco Kill Chain, documéntelo. Esta información será muy útil
más adelante cuando subsane las deficiencias en la implementación de la estrategia.
¿Hubo algún control que debería haber detectado la entrega, pero no lo hizo? ¿Por qué estos controles no funcionaron
como se esperaba? ¿Fracasaron porque simplemente no hicieron lo que el proveedor dijo que harían? ¿Fracasaron
debido a integraciones o automatización entre controles, o sistemas que no funcionaron según lo previsto? Aquí es
donde los datos de registro y otras fuentes de datos de los sistemas en el diagrama de flujo de reconstrucción pueden
ser muy útiles. Trate de reconstruir cómo se entregó el arma, paso a paso, a través de datos en registros de varios
sistemas en el diagrama de flujo.

¿Parece que todos estos sistemas funcionaron como se esperaba? De no ser así, identifique las anomalías y los eslabones débiles.
En algunos casos, es posible que los datos de registro no estén disponibles porque no se activó el registro o porque
los controles agresivos de retención de datos eliminaron los datos de registro. ¿Existe una buena justificación para no
habilitar el inicio de sesión en estos sistemas y almacenar registros para ayudar en el futuro? Una vez más, ATT&CK
podría proporcionar una lista de mitigaciones que puede verificar en su reconstrucción para garantizar que sea integral.
¿Hubo suficientes datos para determinar cómo se entregó el arma? A veces, simplemente no es posible determinar
cómo se entregó el arma con los datos disponibles. Algunos equipos de IR se refieren al primer sistema que se
comprometió en una intrusión como "paciente cero". En algunas intrusiones, el punto de entrada del atacante es muy
obvio y se puede rastrear hasta un correo electrónico, una visita a un sitio web malicioso, una unidad USB, malware,
etc. En otros casos, si el compromiso inicial se logró semanas, meses o años antes, y los atacantes eran expertos en
cubrir sus huellas, encontrar al paciente cero es una aspiración y simplemente no sería posible. Piensa en lo que te
hubiera ayudado en este escenario. ¿Habría ayudado aumentar la verbosidad del registro? ¿Habría ayudado el
archivado de registros durante períodos más largos o el envío de registros fuera del sitio? ¿Hay alguna capacidad que
no tenga actualmente que hubiera ayudado a llenar este vacío?
¿Obtuvieron los consumidores de datos para las mitigaciones de la fase de Entrega los datos que necesitaban para
detectar y romper esta fase? Por ejemplo, ¿obtuvo el SOC los datos que necesitaba para detectar una intrusión? ¿Los
consumidores de datos identificados en la matriz de cursos de acción actualizada recibieron o tuvieron acceso a los
datos según lo previsto? Si no, ¿qué salió mal? ¿Falló el mecanismo de entrega de datos o se filtraron los datos
requeridos en el destino por algún motivo? Podría haber habido múltiples fallas en la recopilación, entrega y análisis de
los datos. Profundice en esto para identificar las cosas que no funcionaron según lo planeado y documéntelos.
¿Los controles, la automatización y las integraciones funcionaron como se esperaba, pero las personas o los procesos
fueron las fuentes de la falla? Este escenario ocurre más de lo que piensas. La arquitectura era sólida, los sistemas
funcionaban como se esperaba, las tecnologías funcionaban como se esperaba, se detectó el arma, pero nadie prestó
atención, o se notó la alerta pero se descartó.
Desafortunadamente, las fallas de personas y procesos son tan comunes, si no más, que las fallas de control técnico.
Las fallas en los procesos de SOC, la mala toma de decisiones, los proveedores que cometen errores y, a veces, solo
la pereza entre el personal clave pueden provocar fallas para detectar y romper ataques.
¿Los atacantes y/o los defensores tuvieron suerte en alguna parte de esta fase del ataque? Algunos profesionales
de la seguridad que he conocido me han dicho que no creen en la suerte. Pero atribuyo esta creencia a la
ingenuidad. He visto ataques exitosos debido a una comedia de errores que probablemente no podrían repetirse o duplicarse.
Capítulo 11 483
Las combinaciones de personas, procesos, tecnologías y circunstancias pueden conducir a escenarios de ataque tan
probables como ganar una lotería. No descarte el papel que puede desempeñar la suerte. Recuerde que no todos los
riesgos pueden identificarse realmente; pueden ocurrir eventos de “cisne negro” (Taleb, 2007).
Una vez que el equipo de reconstrucción comprende cómo se logró la fase de Entrega del ataque y esto se ha
documentado, podemos pasar a la siguiente fase del ataque, la fase de Explotación (Hutchins, EM, Cloppert, MJ, Amin,
RM, nd). Aquí, el equipo de reconstrucción repetirá el proceso, utilizando datos para tratar de determinar si se intentó,
detectó y detuvo la explotación.
Las mismas preguntas que hicimos para la fase de Entrega también se aplican en esta fase. ¿Qué controles no lograron
prevenir y detectar la explotación? Utilice las técnicas y subtécnicas de la táctica de ejecución de ATT&CK como fuente
de preguntas para hacer aquí. ¿Qué técnicas en la táctica de Ejecución usó el atacante? ¿Ha implementado mitigaciones
que deberían haber detenido o detectado esta técnica? ¿ Dónde contribuyeron las brechas en los controles de protección
y detección al éxito del atacante en esta fase de su ataque?
¿Funcionaron las mitigaciones de ciberseguridad de los proveedores como se anuncia? ¿Los consumidores de datos
obtuvieron los datos que necesitaban para detectar y romper esta fase? ¿Comenzó el proceso de IR y funcionó según
lo planeado? ¿Qué podemos aprender del éxito de los atacantes en esta fase para que dicho éxito sea más difícil o
imposible en el futuro? Documente sus hallazgos.
Continúe realizando esta investigación para todas las fases de Kill Chain. Puede haber fases en las que no ocurrió nada
porque los atacantes fueron detenidos antes de esas fases. Tenga en cuenta dónde y cuándo se detectó y interrumpió
con éxito el ataque. Si el ataque no se hubiera interrumpido en la fase en la que se encontraba, ¿las mitigaciones
estratificadas en fases posteriores habrían detectado y detenido con éxito el ataque? Continúe haciendo un uso completo
de ATT&CK como base de conocimiento de técnicas y mitigaciones específicas en su reconstrucción, como una fuente
de preguntas para hacer. ¿Qué técnicas de ATT&CK usó el atacante? ¿Su organización implementó alguna de las
mitigaciones sugeridas por ATT&CK para esas técnicas y funcionó como se esperaba? Esto puede ayudar a garantizar
que sus reconstrucciones de intrusión sean completas y acelerarlas. Sean tan sinceros con ustedes mismos como sea
posible en esta evaluación; los lugares comunes, el optimismo y los planes en un futuro indefinido pueden no ser
suficientes para romper la cadena de destrucción de intrusos del próximo atacante. Sin embargo, la determinación
sobria de hacerlo lo más difícil posible para los atacantes puede ser útil. Recuerde documentar estos pensamientos.
Ahora la reconstrucción está completa y ha hecho y respondido tantas preguntas como sea necesario para descubrir
qué sucedió, idealmente en cada paso del ataque. A continuación, permítanme brindar algunos ejemplos de las acciones
específicas que la reconstrucción debería haber identificado a raíz de ataques fallidos, parcialmente exitosos y totalmente
exitosos.
Uso de los resultados de la reconstrucción de intrusiones

Primero, recuerde la discusión sobre la identificación de brechas y áreas de inversión excesiva o insuficiente en el
Capítulo 10, Implementación de la estrategia. Una reconstrucción de la intrusión puede confirmar algunos de los análisis
sobre las brechas y las inversiones insuficientes que se realizaron al planificar la implementación de esta estrategia.
Por ejemplo, si se identificó una brecha en la detección en la fase de entrega durante la planificación y los datos
posteriores de reconstrucción de intrusiones también ilustran esta misma brecha, esta es una noticia extrañamente tranquilizadora.
Ahora, el CISO tiene más datos para ayudar a construir el caso comercial de inversión para mitigar esta brecha.
Una cosa es que un CISO diga que necesita invertir en capacidades de detección o pueden suceder cosas malas. Pero
tales solicitudes son mucho más poderosas cuando los CISO pueden mostrar a los altos ejecutivos y a la Junta Directiva
que los atacantes han estado utilizando activamente brechas conocidas.
Contrarresta cualquier noción de que el riesgo es teórico cuando los CISO pueden proporcionar evidencia de que el
riesgo es real. También ayuda a generar un sentido de urgencia donde antes no lo había. Si el intento de intrusión generó
gastos no planificados relacionados con las actividades de respuesta y recuperación, esto ayudará a ilustrar los costos
actuales y futuros potenciales relacionados con la brecha. Estos datos pueden informar tanto el lado de la probabilidad
como el del impacto de la ecuación del riesgo, lo que facilita la comparación con otros riesgos. Con datos como este, los
CISO pueden proporcionar a sus consejos de administración actualizaciones sobre brechas y áreas de inversión
insuficiente en cada reunión de revisión del programa de seguridad cibernética hasta que se mitiguen.
Cuando los ejercicios de reconstrucción descubren brechas previamente desconocidas o áreas de inversión insuficiente,
esto realmente es un regalo de los atacantes. Al hacerlo, los atacantes brindan a los CISO información valiosa sobre las
deficiencias en la implementación de sus estrategias, así como un claro llamado a la acción para implementar nuevas
mitigaciones o mejorar las existentes. Los datos de reconstrucción de intrusiones también pueden ayudar a informar las
hojas de ruta de inversión en seguridad cibernética. Recuerde que detener a los atacantes tan pronto como sea posible
en la Intrusion Kill Chain es preferible a detenerlos en fases posteriores. Los datos de reconstrucción pueden ayudar a
los equipos de seguridad cibernética a identificar y priorizar las mitigaciones que ayudarán a que a los atacantes les
resulte más difícil o imposible llegar a las fases posteriores de su ataque. Ayudar a los equipos de ciberseguridad a
comprender las deficiencias y las áreas de mejora en las fases de entrega y explotación es un resultado clave de los
ejercicios de reconstrucción de intrusiones. Estos datos se pueden usar para planificar la hoja de ruta de inversión que
traza las personas, los procesos y las tecnologías que una organización planea implementar y cuándo. Dado que la
mayoría de las organizaciones tienen limitaciones de recursos, los datos de reconstrucción y las hojas de ruta de inversión
que informan pueden convertirse en el centro de los procesos de planificación de un equipo de seguridad cibernética.
¿Recuerda esos imperativos de seguridad cibernética y sus proyectos de apoyo que discutí en el Capítulo 8, Ingredientes
para una estrategia de seguridad cibernética exitosa? Un imperativo es una meta grande, audaz y de varios años,
idealmente alineada con los objetivos comerciales de una organización.

Capítulo 11 485
Actualizar a un sistema de identidad moderno muy necesario o finalmente deshacerse de las VPN en favor de soluciones
modernas de acceso remoto para miles de trabajadores de la información son dos ejemplos. Los datos de reconstrucción
pueden ayudar a proporcionar datos de apoyo para los imperativos de seguridad cibernética y proporcionar un sentido
compartido de propósito para el personal que trabaja en ellos. Por el contrario, es posible que los datos de reconstrucción
no siempre respalden la noción de que los imperativos planificados son la dirección correcta para la organización.
No hay expectativa de que estos se alinearán necesariamente, especialmente en organizaciones grandes con entornos
complejos y múltiples imperativos. Pero cuando cae un rayo o una intrusión, los datos de reconstrucción sugieren que un
imperativo es crítico para la organización, puede sobrecargar a los equipos de proyecto que están trabajando en él. Este
tipo de impulso positivo puede ser beneficioso al ayudar a mantener los plazos de los proyectos y lograr que los proyectos
lleguen a su meta.
Identificación de controles cojos

Otra área de acción potencial derivada de la reconstrucción de una intrusión es la corrección de las mitigaciones que no
funcionaron como se esperaba. Estos son controles que se implementaron y se administran activamente, pero no
protegieron, detectaron ni ayudaron a responder al intento de intrusión como se diseñó. Para decir lo obvio, los CISO y
los equipos de seguridad no pueden confiar en controles que no funcionan como deberían. Existe una gama de posibles
causas raíz para los controles que fallan.
Una causa raíz común de falla es que el control en realidad no realiza la función que el equipo de seguridad pensó que
hacía. Lamentablemente , los desajustes entre las funciones de los controles de seguridad y las expectativas de los
equipos de seguridad son muy comunes. Algunos controles están diseñados para mitigar amenazas muy específicas en
circunstancias específicas. Pero tales matices pueden perderse en los materiales de marketing y los movimientos de
ventas de los proveedores. Esta es una función crítica que los arquitectos desempeñan en muchos equipos de
ciberseguridad: comprender realmente las amenazas que mitiga cada control y cómo se deben orquestar los controles
para proteger, detectar y responder a las amenazas a sus organizaciones. Deben realizar cuidadosamente los inventarios
de capacidades de seguridad cibernética que analicé en el Capítulo 10, Implementación de la estrategia, y realizar cambios
en esos inventarios para minimizar las brechas y las áreas de inversión insuficiente. Pero, como mencioné anteriormente,
la madurez de la implementación de los controles es un factor importante, al igual que el consumo de los datos generados
por los controles. Esto es algo en lo que los arquitectos pueden participar, es decir, el inventario y la planificación, pero
los consumidores de datos, el personal de operaciones y los ingenieros de SOC, entre otros, deben ayudar a completar
esta imagen. De lo contrario, los desajustes entre las funciones de control y las expectativas pueden quemar al equipo de
ciberseguridad.
Otra causa común por la que las mitigaciones no funcionan como se esperaba es que simplemente no funcionan de la
forma en que los proveedores dicen que funcionan. Sé que esta es una revelación impactante para algunas personas y
es un desafío demasiado común para los equipos de seguridad.

Si los proveedores cumplieran todas sus promesas, entonces no habría un desafío de seguridad cibernética global, ni
habría una industria de seguridad cibernética multimillonaria. Esta es una de las razones por las que es prudente tener
capas de defensas, de modo que cuando un control falle, otros controles puedan ayudar a mitigar la amenaza.
Esta es un área donde los CISO pueden compartir y aprender mucho de otros CISO. La experiencia profesional con
proveedores específicos y productos específicos suele ser la mejor referencia que se puede tener.
Otra razón común por la que las mitigaciones no logran proteger, detectar o responder es que la base informática
confiable en la que se basan se ha visto comprometida. Es decir, los atacantes han socavado las mitigaciones al
comprometer el hardware o el software del que dependen para ejecutarse. Por ejemplo, una de las primeras cosas
que hacen muchos atacantes una vez que usan uno o más de los sospechosos habituales de ciberseguridad para
comprometer un sistema es desactivar el software antimalware que se ejecuta en él. Una táctica menos visible es
agregar directorios a la lista de excepciones del motor antimalware para que las herramientas del atacante no sean
escaneadas o detectadas. Una vez que los atacantes o el malware comprometen inicialmente los sistemas, es común
que socaven los controles que se implementaron para proteger los sistemas y detectar a los atacantes. Por lo tanto,
ser excelente en los fundamentos de la ciberseguridad es un requisito previo para implementar capacidades avanzadas
de ciberseguridad. No se moleste en implementar ese costoso sistema de detección de atacantes que usa IA para
realizar análisis de comportamiento a menos que también esté dedicado a administrar los fundamentos de
ciberseguridad para ese sistema. Los atacantes socavarán esas capacidades avanzadas de ciberseguridad si las
vulnerabilidades no reparadas, las configuraciones de seguridad incorrectas y las credenciales débiles, filtradas o
robadas les permiten acceder a los sistemas en los que se ejecutan. Discutí esto extensamente en capítulos anteriores,
pero lo reiteraré aquí nuevamente. Ninguna estrategia de ciberseguridad, ni siquiera una estrategia de puntuación alta
como el marco Intrusion Kill Chain, será eficaz si los fundamentos de la ciberseguridad no se gestionan de manera
eficaz.
Además, es importante que los propios productos de ciberseguridad se gestionen de manera eficaz teniendo en cuenta
los fundamentos de la ciberseguridad. Los motores antimalware y otras mitigaciones comunes han sido fuentes de
vulnerabilidades explotables y errores de configuración de seguridad en el pasado. También deben administrarse de
manera efectiva para que no aumenten el área de superficie de ataque en lugar de disminuirla.
Otro elemento de acción, relacionado con los controles fallidos, que puede surgir de los ejercicios de reconstrucción
de intrusiones es abordar las integraciones de control que fallaron. Por ejemplo, un intento de intrusión no se detectó
hasta relativamente tarde en la Kill Chain de un atacante porque, aunque un control lo detectó con éxito en una fase
anterior, esos datos nunca llegaron al SIEM. Las integraciones rotas y degradadas como este ejemplo son comunes
en entornos de TI grandes y complejos y pueden ser difíciles de detectar.

Capítulo 11 487
Sería ideal si los equipos de seguridad cibernética pudieran confiar simplemente en los consumidores de datos para identificar
anomalías en los informes de datos de los controles de seguridad cibernética, pero en muchos casos, la ausencia de datos no es
una anomalía. La deuda técnica en muchas organizaciones puede dificultar la identificación y solución de integraciones deficientes.
Muchas veces, dichas integraciones las realizan proveedores u organizaciones de servicios profesionales que tienen un
conocimiento limitado de los entornos de TI de sus clientes. Aquí es donde los ingenieros de SOC pueden ser valiosos; pueden
ayudar a garantizar que las integraciones funcionen como se espera y mejorarlas con el tiempo.
Aprendiendo del fracaso

Además de identificar brechas y controles e integraciones subóptimos, las reconstrucciones de intrusiones pueden ayudar a los
CISO y los equipos de seguridad cibernética a confirmar que tienen las prioridades de inversión correctas . Los datos de las
reconstrucciones pueden ayudar a volver a priorizar las inversiones para que las áreas más críticas se aborden primero. Estos
datos no solo pueden ayudar a racionalizar las decisiones de inversión, sino que también pueden ayudar a los CISO a justificar
sus decisiones de inversión, especialmente frente a las críticas de los CIO y CTO que tienen opiniones diferentes y posiblemente
agendas diferentes. Invertir en áreas que desbaratan los esfuerzos de los atacantes en lugar de nuevas capacidades de las que
dependa TI podría no ser una opción popular entre los líderes de TI. Pero el uso de datos de reconstrucción de intrusiones para
defender tales decisiones hará que sea más difícil que otros no estén de acuerdo.
Además de identificar tecnologías que no funcionaron como se esperaba, las reconstrucciones de intrusiones pueden brindar una
oportunidad para mejorar las personas y los procesos que se desempeñaron por debajo de las expectativas. Por ejemplo, en los
casos en que las fallas en la gobernabilidad condujeron a resultados de seguridad deficientes, estos pueden ser buenos datos
para ayudar a impulsar cambios positivos en los procesos de gobernabilidad y la capacitación asociada. Si cumplir con un estándar
interno o un estándar de la industria no fue útil para proteger, detectar o responder a un ataque, la reconstrucción de intrusiones
podría ser un impulso para el cambio.
Es importante permitir que las personas de una organización aprendan del fracaso. Después de dedicar tiempo y esfuerzo para
comprender y recuperarse de las fallas, las organizaciones pueden aumentar el rendimiento de estas inversiones al difundir las
lecciones de las fallas a las personas de la organización que se beneficiarán más de ellas. Los datos de reconstrucción pueden
ayudar a construir un caso para la capacitación en ingeniería social para ejecutivos o para toda la organización, por ejemplo.
Identificación de proveedores útiles

Los proveedores son socios importantes para las organizaciones, ya que suelen proporcionar tecnologías, servicios, personas y
procesos en los que confían sus clientes. Los datos de reconstrucción de intrusiones pueden ayudar a identificar a los proveedores
que están funcionando a la altura de las expectativas o por encima de ellas. También puede ayudar a identificar a los proveedores
que no se desempeñan como se esperaba.

Esto incluye cómo los proveedores participan en los ejercicios de reconstrucción de intrusiones. Los ejercicios de
reconstrucción pueden ayudar a revelar a los proveedores que tienden a culpar a sus clientes por las fallas en el
desempeño de sus productos y servicios, lo que rara vez es útil. Esto, junto con los datos sobre el rendimiento de los
productos y servicios de los proveedores, puede ayudar a informar las negociaciones de renovación de licencias de
productos de proveedores. Una vez que los equipos de seguridad prueban cómo funcionan realmente los productos
de los proveedores y qué tan útiles están dispuestos a ser durante las intrusiones, es posible que estén dispuestos a
pagar mucho menos por ellos en el futuro, o que no estén dispuestos a usarlos en absoluto. Si su organización aún no
hace esto, sugiero mantener una renovación de licencia y una "lista de horizonte" de fin de vida útil que le muestre
cuándo se acercan las fechas clave relacionadas con las renovaciones y el fin de vida útil de los productos.
Asegúrese de que su organización se notifique a sí misma con suficiente anticipación para que pueda dedicar una
cantidad de tiempo razonable a reevaluar si existen mejores mitigaciones. Después de implementar y operar los
productos de los proveedores, es probable que la organización tenga muchos más datos de mejor calidad sobre el
desempeño de sus proveedores actuales para informar las evaluaciones de productos que cuando los adquirió originalmente.
Recompense a los proveedores que son útiles y considere reemplazar a los proveedores que no entienden que se
supone que su valor principal es el servicio al cliente. Mirando a todos los proveedores que mencioné en el Capítulo
10, Implementación de la estrategia, además de todos los proveedores que no mencioné, no faltan empresas que
compiten por el negocio de su organización. No se conforme con proveedores que culpen a su organización por sus
fallas. Incluso si es cierto, deberían ayudarlo a superar estos desafíos en lugar de jugar el juego de la culpa. Los
ejercicios de reconstrucción de intrusiones son su oportunidad para demostrar que están comprometidos con su éxito,
en lugar de ser un tercero desinteresado al margen, esperando la próxima fecha de renovación de la licencia. Si han
estado tratando de ayudar a su organización a obtener más valor de sus productos pero su organización no ha sido
receptiva, entonces esto debe reconciliarse antes de tomar decisiones precipitadas. Reemplazar a buenos proveedores
que han estado nadando constantemente contra la corriente para ayudar a su organización no lo ayuda y podría
retrasar su programa de seguridad cibernética meses o incluso años. Pero sus productos funcionan como se anuncia
y están dispuestos a ayudarlo a lograr ese estado en un período de tiempo razonable, o deben ser reemplazados. De
lo contrario, solo aumentan el área de superficie de ataque mientras usan recursos que podrían usarse en otros lugares
para proteger, detectar y responder mejor a las amenazas.
Los datos de reconstrucción de intrusiones son probablemente los mejores datos que tendrá para medir verdaderamente
el desempeño de sus proveedores de ciberseguridad. Úselo en las negociaciones de renovación de licencias para
contrarrestar los problemas de marketing y las promesas de los ejecutivos de ventas de que la última versión o la
siguiente resuelve todos sus desafíos, incluida su incapacidad para brindar niveles esenciales de servicio al cliente. A
veces, los proveedores desesperados , al sentir que van a perder negocios, deciden “terminar” con el equipo de CISO
y seguridad cibernética apelando directamente a otros ejecutivos o a la Junta Directiva. Esto puede resultar subóptimo
para los CISO que cargan con productos que no los ayudan.
Capítulo 11 489
Pero es más difícil para los ejecutivos y la junta otorgar más negocios a dichos proveedores cuando el
El CISO les ha estado informando sobre los resultados de la reconstrucción de intrusiones, además de mostrarles
cuán útiles o inútiles han sido algunos de sus proveedores. Si los ejecutivos aún deciden otorgar más negocios a
los proveedores que, según indican los datos, no se han desempeñado según las expectativas, han decidido aceptar
el riesgo en nombre de toda la organización. Los CISO se quedan atascados en la gestión de este tipo de riesgo
todo el tiempo. Pero a medida que los datos continúan aumentando, será más difícil para todos aceptar simplemente
el statu quo. Los datos, en lugar de solo la opinión, deberían ayudar a las organizaciones a tomar mejores decisiones
sobre las capacidades de ciberseguridad en las que invierten.
Informar evaluaciones internas

La última área de posible elemento de acción derivada de los resultados de las reconstrucciones de intrusión que
analizaré son las pruebas de penetración y los ejercicios del equipo rojo, azul y morado. Muchas organizaciones
invierten en pruebas de penetración y equipos rojos, azules y morados para poder simular ataques de una manera
más estructurada y controlada. Las lecciones de los ejercicios de reconstrucción de intrusiones pueden informar las
pruebas de penetración y los ejercicios del Equipo Rojo/Equipo Púrpura. Si los ejercicios de reconstrucción han
descubierto debilidades o costuras que los atacantes pueden usar en la implementación de una estrategia de
seguridad cibernética, deben probarse más hasta que se aborden adecuadamente. Cuando los probadores de
penetración profesionales y los equipos rojos reciben resultados de reconstrucción de intrusiones, pueden ayudarlos
a diseñar pruebas que garantizarán que estas debilidades se hayan mitigado adecuadamente. Idealmente, los
evaluadores de penetración y los equipos rojo, azul y morado encuentran las deficiencias de implementación antes
de que los atacantes tengan la oportunidad de hacerlo.
Emulaciones adversarias que aprovechan ATT&CK

Es importante aprovechar al máximo todos los "regalos" que los atacantes le dan a su equipo de seguridad probando
sus defensas . Sin embargo, el objetivo es romper sus Kill Chains lo antes posible. Para hacer esto, es prudente
que los equipos de seguridad prueben y evalúen la implementación de sus estrategias de ciberseguridad de manera
continua. Los entornos de TI de empresas grandes y complejas cambian constantemente, a veces de manera
inesperada. Al mismo tiempo, los atacantes están evolucionando sus ataques y potencialmente volviéndose más
efectivos. No espere a que los atacantes le muestren dónde están los controles y las brechas de bajo rendimiento:
encuéntrelos antes de que lo hagan para minimizar los posibles daños y costos.
Tal vez recuerde en el Capítulo 9, Estrategias de seguridad cibernética, que mencioné varias formas diferentes
en las que se puede usar el marco ATT&CK. ATT&CK se puede aprovechar para propósitos de Cyber Threat
Intelligence, detección de amenazas, evaluaciones y emulación de atacantes. Posteriormente, ATT&CK puede
ser una herramienta invaluable para probar y evaluar cómo funcionan las implementaciones de estrategias.
Afortunadamente, MITRE publicó una serie de publicaciones de blog que brindan orientación sobre cómo comenzar
a usar ATT&CK para cada uno de estos propósitos. Si planea usar ATT&CK para cualquiera de estos propósitos, se
recomienda leer estas publicaciones de blog. Proporcionan un modelo de madurez del equipo de seguridad (recién
principiante, nivel medio y avanzado) y orientación para los equipos en cada nivel del modelo:
• Introducción a ATT&CK: inteligencia sobre amenazas (https://medium.com/mitreattack/
empezarconelataquecti4eb205be4b2f)
• Introducción a ATT&CK: detección y análisis (https://medium.com/mitre attack/gettingstartedwithattack
detectiona8e49e4960d0)
• Primeros pasos con ATT&CK: Emulación adversaria y Red Teaming (https://medium.
com/mitreattack/empezandoconelataquerojo29f074ccf7e3)
• Primeros pasos con ATT&CK: evaluaciones e ingeniería (https://medium.com/
mitreattack/introducciónalaevaluacióndeataquecc0b01769cb4)
Por ejemplo, la publicación de blog sobre emulación adversaria y Red Teaming proporciona una definición útil como
punto de partida, seguida de una guía paso a paso sobre cómo aprovechar ATT&CK en este contexto, para cada uno
de los tres niveles de madurez del equipo de seguridad.
“Para aquellos que no están familiarizados con esto, la emulación adversaria es un tipo de
compromiso del equipo rojo que imita una amenaza conocida para una organización al combinar
inteligencia de amenazas para definir qué acciones y comportamientos usa el equipo rojo. Esto es
lo que diferencia a la emulación del adversario de las pruebas de penetración y otras formas de red teaming.
Los emuladores de adversario construyen un escenario para probar ciertos aspectos

de las tácticas, técnicas y procedimientos (TTP) de un adversario . Luego, el equipo
rojo sigue el escenario mientras opera en una red objetivo para probar cómo les iría
a las defensas contra el adversario emulado” (Blake Strom, Tim Schulz y Katie Nickels,
2019).
Estas publicaciones de blog hacen referencia a numerosos recursos de ATT&CK que debe tener en cuenta. En el
contexto de la emulación de atacantes, MITRE proporciona "planes de emulación de adversarios". El propósito de
estos planes es “permitir que los defensores prueben sus redes y defensas de manera más efectiva al permitir que
los equipos rojos modelen más activamente el comportamiento del adversario, como lo describe ATT&CK” (MITRE, sin fecha).
Puede encontrar estos planes de emulación adversarios aquí: https://attack.mitre.org/resources/

adversarioemulaciónplanes/.
Capítulo 11 491
Esto concluye nuestra discusión sobre la medición del desempeño y la efectividad de las estrategias de seguridad
cibernética.
Resumen
Los equipos de ciberseguridad necesitan medir muchas cosas diferentes para una variedad de propósitos, incluido el
cumplimiento de los estándares normativos, industriales e internos. Sin embargo, este capítulo se centró en cómo los CISO
y los equipos de ciberseguridad pueden medir el rendimiento y la eficacia de la implementación de su estrategia de
ciberseguridad, utilizando como ejemplo una estrategia centrada en el ataque.
Los datos ayudan a los CISO a administrar sus programas e inversiones en seguridad cibernética y les ayudan a demostrar
que su programa de seguridad cibernética ha sido efectivo y mejora constantemente; también puede ayudar a ilustrar la
efectividad de las acciones correctivas después de que se detectan los problemas. Un programa de gestión de
vulnerabilidades bien ejecutado no es opcional; aprovechar los datos representa una de las formas más fáciles para que
los CISO comuniquen la efectividad y el progreso. Los equipos de gestión de vulnerabilidades deben escanear todo en sus
inventarios todos los días en busca de vulnerabilidades y configuraciones incorrectas.
Esto puede ayudar a minimizar la cantidad de tiempo que las vulnerabilidades no mitigadas y las configuraciones incorrectas
están presentes y son explotables. Los datos de tendencias valiosos pueden surgir de los datos de escaneo de gestión de
vulnerabilidades a lo largo del tiempo. Algunos ejemplos de datos valiosos incluyen:
• El número de activos bajo el mandato del equipo de gestión de vulnerabilidades versus el número total de activos que
la organización posee y opera.
• El número de vulnerabilidades sin parchear en el entorno por gravedad de vulnerabilidad.
• Las vulnerabilidades por tipo de producto pueden ayudar a ilustrar dónde existe el mayor riesgo en un entorno ; la
cantidad de vulnerabilidades sin parches, de gravedad crítica, alta y media en los sistemas operativos,
navegadores web y aplicaciones en un entorno, junto con la cantidad de sistemas no administrados, puede
ayudar a los CISO y sus partes interesadas a comprender el

riesgo en su entorno de TI.
Las estrategias centradas en ataques, como Intrusion Kill Chain, hacen que sea relativamente fácil medir el rendimiento y
la eficacia; para ello se utilizan reconstrucciones de intrusión. Los resultados de la reconstrucción de intrusiones pueden
ayudar a los CISO de muchas maneras diferentes, sobre todo al identificar las mitigaciones que no funcionaron como se
esperaba. Para obtener valor de los intentos de intrusión, cada intento de intrusión exitoso, parcialmente exitoso y fallido
debe descomponerse y estudiarse para responder a dos preguntas clave:
1. ¿Hasta dónde llegaron los atacantes con su Intrusion Kill Chain antes de ser detectados y
finalmente detenido?
2. ¿Cómo derrotaron o eludieron los atacantes todas las capas de controles de mitigación que el equipo de
seguridad cibernética implementó para romper su Intrusion Kill Chain antes de que fueran detenidos?
Las organizaciones que tienen los recursos deben probar y evaluar la efectividad de la implementación de su
estrategia de manera continua. Esto puede ayudar a los equipos de seguridad a descubrir y abordar las deficiencias
antes de que los atacantes tengan la oportunidad de hacerlo.
En el próximo y último capítulo, exploraremos algunos enfoques modernos de la ciberseguridad y el cumplimiento.
Referencias
• Orden del Ingeniero (nd). Obtenido de Orden del Ingeniero: https://orderof
elingeniero.org/
• Detalles CVE (2022). Los 50 productos principales por número total de vulnerabilidades "distintas".
Obtenido de Detalles de CVE: https://www.cvedetails.com/top50products.php
• Hutchins, EM, Cloppert, MJ, Amin, RM Ph.D. (Dakota del Norte). Defensa de redes informáticas basada en
inteligencia informada por análisis de campañas adversarias y cadenas de eliminación de intrusos. Obtenido
de Lockheed Martin: https://lockheedmartin.com/content/dam/lockheedmartin/
• Herrmann, DS (2007). Guía completa de métricas de seguridad y privacidad: medición regulatoria

Cumplimiento, resiliencia operativa y ROI. Publicaciones de Auerbach.
• ISC2 (2021). Actualización de dominio CISSP. Obtenido de Certificaciones ISC2: https://www.isc2.

org//media/ISC2/Certifications/DomainRefresh/CISSPDomainRefresh.ashx
• Taleb, NN (2007). El cisne negro: el impacto de lo altamente improbable. Libros de pingüinos
• Worrell, C. (3 de abril de 2018). Cómo usar Amazon Alexa para obtener estadísticas y resultados de
Amazon GuardDuty. Obtenido del blog de seguridad de AWS: https://aws.amazon.com/blogs/security/
cómousaramazonalexaparaobtenerestadísticasyhallazgosdeamazonguardduty/
• Strom, B., Schulz, T., Nickels, K. (17 de julio de 2019). Primeros pasos con ATT&CK: Emulación adversaria y
Red Teaming. Obtenido de https://medium.com/mitreattack/getting

comenzóconataquerojo29f074ccf7e3
• INGLETE. (Dakota del Norte). Planes de emulación del adversario. Obtenido de MITRE ATT&CK® : https://
attack.mitre.org/resources/adversaryemulationplans/
Capítulo 11 493

12
Enfoques modernos de seguridad
y cumplimiento
En los capítulos anteriores de este libro, le presenté a los sospechosos habituales de ciberseguridad y discutimos la
inteligencia de amenazas de ciberseguridad (CTI), las divulgaciones de vulnerabilidades, las amenazas como el
malware y las amenazas basadas en Internet, los roles que los gobiernos pueden desempeñar en la ciberseguridad
y el acceso del gobierno a los datos. También discutimos los ingredientes que pueden ayudar a respaldar una
estrategia de seguridad cibernética exitosa, evaluamos algunas estrategias de seguridad cibernética, observamos
de cerca cómo se podría implementar la mejor estrategia de puntuación y discutimos cómo medir el desempeño de esa estrategia.
Ahora vamos a echar un vistazo más de cerca a cómo las tecnologías más nuevas y modernas, como la
computación en la nube, pueden ayudar a los equipos de seguridad y cumplimiento a modernizar sus
métodos. Este fue mi trabajo de tiempo completo entre 2012 y 2022. Durante este período, hablé de las
ventajas de seguridad y cumplimiento de la nube con miles de clientes empresariales del sector público y
privado en mis funciones en Microsoft y Amazon Web Services (AWS) , dos de los tres proveedores de
servicios en la nube (CSP) más destacados del mundo. En Microsoft, trabajé como Global Chief Security
Advisor, entre otras funciones, y en AWS, fui Global Security and Compliance Lead para el sector público.
A menudo, yo era la primera persona con la que los clientes hablaban sobre la nube una vez que decidían
evaluarla seriamente. Me siento muy afortunado de haber tenido la oportunidad de trabajar con tanta
gente brillante en estos CSP y de haber ayudado a tantos clientes empresariales de todo el mundo a
modernizar su TI y mejorar sus programas de seguridad y cumplimiento. Compartiré algunas de las cosas
que aprendí en el camino y algunas ideas clave en este capítulo. Tenga en cuenta que todos los puntos
de vista y opiniones escritos en este capítulo, así como en el resto de este libro, son mis opiniones
personales y no las de ninguno de mis empleadores pasados o presentes.
496 Enfoques modernos de seguridad y cumplimiento
Este capítulo presentará algunos conceptos que ayudarán a poner la nube en contexto para los CISO y los
profesionales de seguridad y cumplimiento que aún no la han adoptado por completo. También proporcionará a los
equipos de seguridad y cumplimiento que tienen experiencia en la nube algo de reflexión sobre enfoques efectivos
para la ciberseguridad y el cumplimiento en entornos de nube que podrían no estar aprovechando.
• El poder de las interfaces de programación de aplicaciones (API)
• Las ventajas de la automatización para ayudar a mitigar los sospechosos habituales de ciberseguridad
• Estrategias de ciberseguridad en la nube
• Cifrado y gestión de claves
Comencemos observando en qué se diferencia la nube de lo que los equipos de seguridad y TI han estado haciendo
en entornos de TI locales.
Introducción
El surgimiento de la computación en la nube comercial en 2006 provocó un gran debate entre algunas organizaciones
sobre si se podía confiar en la nube, así como si es tan segura como los entornos de TI locales . Sin embargo, para
muchas organizaciones, la nube representa mucho más que nueva tecnología. En pocas palabras, la nube
representa el cambio. Seamos realistas, el cambio es fácil para algunas organizaciones, como las empresas
emergentes, mientras que puede ser más difícil para las organizaciones grandes, bien establecidas y altamente
reguladas, como las instituciones de servicios financieros y algunas verticales en el sector público.
Muy a menudo, es el CISO en estas organizaciones el que es reacio al cambio, operando como si el resultado ideal
fuera un punto muerto con los atacantes, en entornos de TI donde los CISO tienen cierto control sobre el cambio.
Mientras nada cambie, pueden mantener este estado de relativo éxito y seguir mejorando. Sin embargo, por
supuesto, las cosas cambian constantemente; solo toma tiempo para que nosotros, los humanos ocupados, lo
notemos. Las empresas que no siguen el ritmo de los avances tecnológicos pueden quedarse atrás de sus
competidores y ser presa de las nuevas empresas que buscan interrumpir su industria: el lobo siempre está a la
puerta. No se puede culpar a los CISO por esperar mantener el statu quo cuando han tenido éxito. Sin embargo,
los CISO que no pasan parte de su tiempo fingiendo ser un CTO pueden perjudicar a sus organizaciones al
ralentizarlas demasiado y obstaculizar la innovación.
Esto no significa que los CISO puedan, o deban, abogar por la adopción de cada nueva tecnología que aparezca en
el horizonte. Sin embargo, después de más de una década de debate, el veredicto es claro: la nube cambia las
reglas del juego para los profesionales de la seguridad y el cumplimiento. La nube es un gran amplificador de talento
en ciberseguridad que puede ayudar a las organizaciones a ejecutar su estrategia actual de ciberseguridad o
adoptar un enfoque más moderno de la seguridad y el cumplimiento.
Capítulo 12 497
Comencemos esta discusión con una introducción rápida a la computación en la nube. Descubrí que establecer un
nivel para todos, incluso los profesionales de TI, seguridad y cumplimiento que han estado usando la nube, sobre lo
que es y lo que no es la nube, puede ayudar a proporcionar una comprensión compartida sobre la cual podemos
construir . De lo contrario, los conceptos erróneos comunes y la información inexacta tienden a dificultar las
conversaciones significativas sobre seguridad y cumplimiento en la nube.
¿En qué se diferencia la computación en la nube?

Los tres CSP más populares del mundo son AWS, Microsoft y Google. Estos CSP a menudo se denominan CSP de
hiperescala porque sus ofertas en la nube están disponibles en todo el mundo y en escalas nunca antes imaginadas.
Cuando las organizaciones contemplan por primera vez aprovechar los servicios ofrecidos por los CSP, los primeros
temas que la mayoría de ellos quieren explorar son la seguridad y el cumplimiento. Necesitan comprender cómo los
CSP pueden proporcionar las capacidades de TI que necesitan, mientras cumplen o superan los estándares de
seguridad de la industria, los estándares regulados y sus propios estándares de seguridad internos. He escuchado
muchos mitos sobre la computación en la nube y he visto que la nube ayuda a las organizaciones a lograr cosas que
posiblemente no podrían lograr en sus propios entornos de TI locales.
Aunque la informática en la nube está siendo adoptada por industrias de todo el mundo, esto ha sucedido de manera
desigual y más lenta en algunas regiones del mundo. A medida que la computación en la nube comenzó a ganar
terreno entre las empresas, las descripciones del modelo de servicio facilitaron la educación de las personas sobre
lo que es y lo que no es la nube. Tres modelos de servicios de computación en la nube se hicieron populares:
infraestructura como servicio (IaaS), plataforma como servicio (PaaS) y software como servicio (SaaS). Estas
descripciones de modelos de servicio facilitaron que todos entendieran los tipos de servicios en la nube disponibles
y dónde podrían encajar en la cartera de TI de cada organización. Por ejemplo, las organizaciones podrían ejecutar
sus propios servidores virtuales en la oferta de IaaS de un CSP, como Amazon Elastic Compute Cloud.
(Amazon EC2), Microsoft Azure Virtual Machines o Google Compute Engine.
Los CSP ofrecen servicios basados en infraestructuras de TI físicas masivas que han construido en todo el mundo.
Con el tiempo, el modelo de infraestructura física alrededor del cual los CSP se han fusionado se basa en el modelo
pionero de AWS: el concepto de regiones y zonas de disponibilidad. En el lenguaje de AWS, una zona de
disponibilidad es un grupo de centros de datos y una región es un grupo de zonas de disponibilidad. Existen
diferencias significativas en el tamaño y alcance de las infraestructuras de los CSP y cómo aprovechan los
componentes de este modelo. Puede obtener información sobre la infraestructura de cada CSP en sus respectivos
sitios web:
• AWS: https://aws.amazon.com/aboutaws/globalinfrastructure/
• Google: https://cloud.google.com/compute/docs/regionszones/
• Microsoft: https://azure.microsoft.com/explore/globalinfrastructure/
Aunque los términos IaaS, PaaS y SaaS todavía se usan ampliamente en la actualidad, se están volviendo
obsoletos lentamente. Cuando se acuñaron por primera vez, los CSP solo tenían un puñado de servicios y estos
modelos de servicio ayudaron a describir cómo se implementaba cada servicio. Sin embargo, esto ha ido cambiando
rápidamente. En el momento de escribir este artículo, los tres CSP de hiperescala mencionados anteriormente
ofrecían cientos de servicios en la nube. Posteriormente, han surgido acrónimos más nuevos como Contenedores
como servicio (CaaS), Identidad como servicio (IDaaS) y Función como servicio (FaaS) . Esta proliferación de
servicios se ha acelerado porque los desarrolladores de nuevos servicios pueden usar los servicios existentes
como bloques de construcción. Por ejemplo, si un CSP está desarrollando un nuevo servicio en la nube y necesita
almacenamiento para él, en lugar de construir una nueva infraestructura de almacenamiento desde cero,
simplemente puede usar uno de los servicios de almacenamiento en la nube existentes que cumpla con sus
requisitos. Este enfoque no solo ayuda a acelerar el desarrollo de nuevos servicios en la nube, sino que también
significa que los servicios podrían tener componentes IaaS, PaaS y/o SaaS, borrando las líneas entre estas antiguas descripciones de m
En otras palabras, las soluciones a problemas específicos se están volviendo más importantes que mantener las
definiciones del modelo de servicio. A medida que continúa esta proliferación de servicios en la nube, las empresas
podrán obtener soluciones para los problemas específicos que desean resolver, y los modelos de servicio antiguos
serán cada vez menos importantes.
Una distinción importante cuando se trata de modelos de servicio es la diferencia entre los servicios que
brindan los CSP de hiperescala y los de los proveedores de servicios administrados (MSP) tradicionales.
Muchas organizaciones de todo el mundo han aprovechado los MSP durante décadas. Los gobiernos,
por ejemplo, tienden a firmar acuerdos a muy largo plazo con los MSP para administrar sus centros de
datos y brindarles servicios de TI. Los MSP han jugado un papel importante para tales organizaciones,
al menos por un par de razones. En primer lugar, los MSP han logrado mantener una masa crítica de
talento de TI que, de otro modo, sería un desafío para las empresas atraer y retener. En segundo lugar,
los MSP se familiarizaron íntimamente con los entornos de TI de sus clientes porque los administraban;
este conocimiento tribal brindó la continuidad que las empresas necesitaban para minimizar posibles
interrupciones cuando el personal clave cambiaba. Por supuesto, los MSP ofrecen otros beneficios a sus clientes
también.
Cada vez más organizaciones quieren pasar de un modelo de gastos de capital (CAPEX) a un modelo de gastos
operativos (OPEX) . CAPEX generalmente requiere que las organizaciones realicen grandes inversiones en TI por
adelantado y registren estos costos en los registros contables durante un período de años en función de los
programas de depreciación o amortización.
Capítulo 12 499
Debido a que pagan por adelantado bajo este modelo CAPEX, tienen que estimar sus necesidades de capacidad
y utilización y esperar que estas estimaciones sean correctas, de lo contrario, terminan pagando por adelantado
por la capacidad que quizás nunca usen. Los estudios sobre la utilización real del servidor de TI en los centros de
datos empresariales sugieren que la utilización real del servidor es casi siempre una fracción de lo que se estimó
y adquirió. Un modelo OPEX es atractivo para algunas organizaciones que no pueden pagar por adelantado el
equipo de TI. La nube les permite pagar sobre la marcha, pagando solo por los recursos específicos que utilizan.
Los MSP y CSP pueden ayudar a sus clientes con este cambio. Sin embargo, los MSP tienden a tener un modelo
de negocio basado en la subcontratación, mientras que los CSP ofrecen un modelo de autoservicio para la
transformación en lugar de la replicación de los procesos existentes.
Proveedores de servicios en la nube frente a proveedores de servicios gestionados

Un error que es fácil de cometer para las empresas que contemplan usar la nube por primera vez es la suposición
de que los CSP son solo otro tipo de MSP. no lo son Los CSP de hiperescala ofrecen un modelo de TI de
autoservicio extremadamente escalable y ágil en el que sus clientes solo pagan por lo que usan, medido en
segundos de cómputo y la cantidad de datos que almacenan o transfieren a través de las redes. Cualquier persona
con una tarjeta de crédito puede abrir una cuenta y obtener acceso a cientos de servicios que serían
prohibitivamente costosos de construir en entornos de TI locales o de MSP. Cuando los clientes terminan de usar
los servicios de su CSP, por lo general pueden alejarse de ellos sin ninguna obligación.
Por el contrario, los MSP administran los centros de datos y los sistemas en nombre de sus clientes. Debido a las
inversiones iniciales necesarias para construir físicamente los centros de datos y los sistemas que se ejecutan en
ellos, el modelo de MSP generalmente requiere contratos a largo plazo que aseguren que los MSP puedan obtener
los rendimientos adecuados de sus inversiones. Este modelo pone en desventaja a los MSP y a sus clientes. Los
CSP distribuyen sus gastos entre millones de clientes en todo el mundo, donde los MSP tienden a tener un
conjunto mucho más pequeño de clientes a los que atender, que deben pagar todo ellos mismos. Algunos MSP
han creado sus propias nubes privadas para sus clientes, que buscan imitar la elasticidad y otras características
de la computación en la nube. Sin embargo, en mi experiencia, el término nube privada es un eufemismo para
escala limitada, servicios limitados y cambios lentos. En algunos casos, una nube privada es simplemente un
centro de datos subcontratado. Compararlos con la gama de servicios que ofrecen los CSP de hiperescala no es
realmente una comparación de manzanas con manzanas. Posteriormente, muchos MSP han desarrollado sus
productos y servicios para ejecutarse sobre los servicios de CSP. Esto tiene mucho sentido, ya que ellos también
pueden beneficiarse de las economías de escala que brindan los CSP de hiperescala.
Lo hacen reduciendo drásticamente los gastos de capital, obteniendo una escala prácticamente ilimitada para
sus productos y permitiéndoles adoptar un ritmo increíble de innovación que probablemente no podrían lograr
por sí mismos. Existe una gran oportunidad para que los MSP diseñen, construyan y administren sistemas
para sus clientes. Sin embargo, en lugar de centrarse en la administración de la infraestructura de TI, pueden
centrarse más en la innovación. También pueden lograr una mejor seguridad para sus clientes. Discutiré
algunas de las formas en que la nube puede proporcionar una mejor seguridad y cumplimiento en este capítulo.
La falta de comprensión de la diferencia entre los CSP y los MSP puede ralentizar a las organizaciones cuando
evalúan la seguridad y el cumplimiento de la nube. Muchas organizaciones dedican una cantidad considerable
de tiempo a tratar de comprender cómo mantienen el statu quo si eligen aprovechar la nube. Sin embargo,
como mencioné anteriormente, la nube representa el cambio; reconciliar estas dos cosas es una de las primeras
cosas a las que se enfrentan las organizaciones cuando contemplan por primera vez el uso de la nube. Esta
reconciliación puede manifestarse de varias maneras diferentes. Dejame darte un par de ejemplos.
Migrando a la nube
Como mencioné anteriormente, como grupo, los CSP de hiperescala ofrecen cientos de servicios a sus clientes.
A pesar de esto, muchas empresas aún eligen levantar y trasladar aplicaciones a la nube. Esto generalmente
significa que toman una aplicación que han estado ejecutando en servidores en su entorno de TI local y la
ejecutan en servidores alojados en la nube. Este tipo de transición a la nube les permite mantener las personas,
los procesos y las tecnologías que han estado utilizando durante años, mientras pasan de CAPEX a OPEX.
Para muchas organizaciones, esto es completamente natural, ya que tienen una gran experiencia en la creación
y administración de estos sistemas en su entorno de TI local, y pueden seguir aprovechando esta experiencia
cuando trasladan esos mismos sistemas a la nube. En la nube, pueden aprovechar el mismo hardware y
software, o uno similar, que han estado usando localmente. Posteriormente, este tipo de transición puede ser
relativamente fácil y rápida.
El desafío de levantar y cambiar aplicaciones es que la complejidad, las ineficiencias y la deuda técnica también
se trasladan a la nube con las aplicaciones. Aún así, para algunas organizaciones, este tipo de transición
puede ser un punto de partida para cosas más grandes y mejores. Por lo general, una vez que las
organizaciones comienzan a usar la nube, desarrollan cierta experiencia con ella y exploran su conjunto más
amplio de capacidades, hacen un uso más amplio de ella en el futuro. En lugar de levantar y cambiar más
aplicaciones, cambian la plataforma de las aplicaciones, recompran aplicaciones o refactorizan aplicaciones
usando capacidades nativas de la nube. Con el tiempo, dejan de administrar la nube como lo hacían con la TI
local y la verdadera innovación comienza a florecer. Sin embargo, para algunas organizaciones, esta transición
y evolución puede llevar tiempo.
Capítulo 12 501
Para acelerar las cosas, algunas organizaciones deciden hacer movimientos grandes y audaces. En lugar de
levantar y cambiar las aplicaciones heredadas a la nube, deciden migrar una aplicación de misión crítica a la
nube. Su lógica es que, dado que la aplicación es crítica para el negocio, se hará bien la primera vez y las cosas
que aprenden en el proceso se pueden aplicar a todas las demás aplicaciones menos críticas que la siguen a la
nube; este enfoque acelerará sus transformaciones digitales y los ayudará a superar potencialmente a sus
competidores.
Cuestionarios de evaluación de la ciberseguridad

Algunos CISO lidian con el cambio que representa la nube y buscan mantener el statu quo. Esto se debe a que
han gestionado con éxito su programa de ciberseguridad en el entorno de TI actual de sus organizaciones. El
cambio puede representar un riesgo para algunas organizaciones. El lugar donde he visto esto ilustrado con
mayor frecuencia es con las evaluaciones de seguridad que los equipos de seguridad empresarial utilizan para
determinar si las nuevas soluciones cumplen con sus estándares y requisitos de seguridad. Dichas evaluaciones
buscan determinar si existe un conjunto mínimo de controles para proteger los datos de la organización mientras
se procesan, almacenan y transmiten mediante nuevas soluciones. Por ejemplo, una pregunta de evaluación
podría determinar si la nueva solución protege los datos en tránsito con la versión más reciente del protocolo
Transport Layer Security (TLS) . Otra pregunta de evaluación podría determinar si los datos en reposo en la
solución se cifran mediante un algoritmo específico. Otra pregunta de evaluación podría ser si el proveedor tiene
una atestación o certificación de seguridad específica de terceros, como ISO 27001, por ejemplo.
En algunas organizaciones, cuando las nuevas soluciones basadas en la nube llegan al equipo de seguridad
para una evaluación de seguridad, aplican el mismo proceso de evaluación que han estado usando para evaluar
nuevas soluciones en su entorno de TI local. Esto parece razonable; después de todo, la evaluación verifica si
las soluciones cumplen con los estándares de seguridad de la organización.
Algunos de los cuestionarios de evaluación de seguridad que he visto a lo largo de los años han sido elaborados
e incluyen cientos de preguntas. Muchos de estos cuestionarios se desarrollaron durante un período de muchos
años y se han personalizado para reflejar los entornos de TI específicos y los requisitos de cumplimiento de las
organizaciones que los emplean.
Sin embargo, muchas de las preguntas de dichos cuestionarios de evaluación se basan en algunas suposiciones
subyacentes clave; por ejemplo, la suposición de que los evaluadores tendrán acceso físico al hardware para
responder a sus preguntas. Otro ejemplo similar es que los evaluadores evaluarán los sistemas que la
organización administra por sí mismos. Otra suposición popular que he visto es que la tecnología utilizada por
una solución nunca se desviará de las tecnologías actuales disponibles comercialmente.
Por ejemplo, el hipervisor en el que se ejecutan las cargas de trabajo virtualizadas de una solución se ejecuta
exactamente de la misma manera que los hipervisores que han estado ejecutando en sus entornos de TI locales.
Un último ejemplo es la suposición de que el proveedor que proporciona la solución solo tiene una solución y no
un gran conjunto o pila de tecnologías que se pueden combinar de diferentes maneras para resolver problemas.
Cuando cualquiera de estos supuestos u otros no sean ciertos, las valoraciones que se basen en ellos no podrán completarse en su
totalidad. Cuando esto sucede, algunos equipos de seguridad simplemente rechazan una solución porque no pudieron determinar si
cumplía con sus estándares utilizando su cuestionario de evaluación de seguridad probado y verdadero. Sin embargo, la falla evidente
en su proceso de evaluación es que no verificó si la solución cumplía con los estándares de seguridad de la organización; verificó si las
preguntas de su cuestionario podían responderse tal como estaban escritas. Esta es una diferencia sutil pero importante.
Permítanme usar una analogía exagerada para ilustrar lo que quiero decir. Durante las últimas décadas, los propietarios de automóviles
han podido llevar sus automóviles a talleres administrados profesionalmente para que se completen las inspecciones de múltiples puntos.
En algunos casos, estas inspecciones son obligatorias por ley, como las inspecciones de emisiones, por ejemplo. Sin embargo, ¿qué le
sucedió al propietario del primer automóvil completamente eléctrico cuando llevó su automóvil a la inspección de emisiones obligatoria
por ley? ¿El taller pudo procesar la evaluación que exige la ley? ¿El automóvil tenía un tubo de escape o un convertidor catalítico para
probar en el taller? Después de todo, todos los automóviles deben tener estas tecnologías, ¿verdad?
Dado que el garaje no pudo probar este automóvil de la misma manera que lo habían hecho durante décadas, ¿deberían fallar en
certificar el automóvil, aunque exceda los estándares de emisiones de automóviles de una manera que los motores de combustión
interna heredados nunca podrían lograr ? Algunos equipos de seguridad rechazan las soluciones basadas en la nube porque no pueden
evaluarlas de la misma forma en que siempre han evaluado las soluciones.
Pocos equipos de seguridad cuestionan espontáneamente las suposiciones en las que se basan sus procesos de evaluación de años .
Sus requisitos de seguridad no necesariamente tienen que cambiar. Sin embargo, necesitan evolucionar y modernizar sus procesos de
evaluación para determinar si las nuevas tecnologías pueden cumplir o superar esos requisitos. El objetivo de las evaluaciones de
seguridad es garantizar que las nuevas soluciones cumplan con los requisitos de seguridad de las organizaciones, no garantizar que sus
preguntas de evaluación de seguridad nunca tengan que cambiar. Las empresas necesitan cuestionar sus suposiciones de vez en
cuando para verificar si siguen siendo precisas y relevantes.
¡Vamos a saltar directamente a eso! A continuación, compartiré por qué creo que la nube cambia las reglas del juego para los
profesionales de la seguridad y el cumplimiento.
Cambiadores de juego de seguridad y cumplimiento

Hay numerosas formas en que la nube puede inclinar el campo de juego a favor de los defensores. En esta sección, cubriré dos cambios
de juego de seguridad y cumplimiento.

Capítulo 12 503
El poder de las API

Las interfaces de programación de aplicaciones (API) proporcionan un mecanismo poderoso para que los
sistemas interactúen con humanos y otros sistemas. Existen diferentes tipos de API, pero en general, las
API definen las entradas específicas que un sistema está dispuesto a aceptar y las salidas que proporcionará.
Los detalles de cómo el sistema procesa las entradas y proporciona las salidas se pueden abstraer de la
vista, simplificando así el sistema para los humanos y otros sistemas que quieran usarlo. En otras palabras,
no necesito saber cómo funciona el sistema internamente para usarlo. Solo necesito saber acerca de sus
API. Puedo llamar a una API y pasarle la información que requiere y luego esperar el resultado, mientras
sucede la magia del software.
Magia aquí es un eufemismo para todo el trabajo de los ingenieros y desarrolladores inteligentes en el hardware, el firmware, los sistemas
operativos y el software que componen la pila de tecnologías en las que se basan la API y su sistema.
Las API pueden ser específicas del lenguaje de programación y, por lo tanto, incluirse como parte de los kits de desarrollo de software (SDK).
Esto facilita que los desarrolladores que conocen C++, Java u otros lenguajes de programación más nuevos y populares aprovechen las API.
Si bien los desarrolladores alguna vez usaron las API principalmente para ayudarlos a desarrollar aplicaciones, los roles de operaciones ahora
también usan API para implementar y operar la infraestructura de TI, lo que ayuda a anunciar la era DevOps.
En el contexto de la informática en la nube, las API se pueden llamar desde una aplicación, desde una línea de comandos o desde la consola
web proporcionada por el CSP. Deja que te dé algunos ejemplos.
Supongamos que queremos aprovisionar y lanzar cinco máquinas virtuales en Amazon EC2, en una de las tres zonas de disponibilidad
actualmente disponibles en la región de Londres. Podríamos usar la API RunInstances (AWS, 2020):
https://ec2.amazonaws.com/?Action=RunInstances
&ImageId= ami0c5300e833c2b32f3
&TipoDeInstancia=t2.micro
&MaxCount=5
&Número mínimo=1
&KeyName=mipardeclaves
&Colocación.AvailabilityZone=euwest2a
&AUTHPARAMS
Si usáramos la consola de AWS para hacer lo mismo, el asistente de instancia de lanzamiento recopilaría toda la información de configuración
de las máquinas virtuales y realizaría el mismo tipo de llamada a la API en
nuestro nombre.
También podríamos usar la interfaz de línea de comandos (CLI) de AWS para lanzar estas máquinas virtuales,
especificando los mismos parámetros, y la CLI haría el mismo tipo de llamada a la API por nosotros:
aws ec2 instancias de ejecución imageid ami0c5300e833c2b32f3 cuenta 5

tipoinstancia t2.micro nombreclave miparclave
Bajo las cubiertas del sistema desde el que se ejecuta este comando AWS CLI, enviará este tipo de solicitud
a Amazon EC2 utilizando el protocolo HTTPS en el puerto TCP 443 (AWS, 2020).
Una cosa importante a tener en cuenta es que las llamadas API requieren mecanismos de autenticación,
autorización, integridad y confidencialidad. No entraré en todos estos detalles aquí, pero los CSP ofrecen
documentación que lo ayudará a comprender los mecanismos que implementaron o no implementaron para
proporcionar estas cosas para sus API. Por ejemplo, puede leer sobre la seguridad de AWS CLI en esta
URL: https://docs.aws.amazon.com/cli/latest/userguide/security.html.
Por supuesto, al igual que AWS, Google Cloud y Microsoft Azure tienen API similares y admiten una
variedad de lenguajes de programación y secuencias de comandos, así como CLI. Este es un ejemplo del
CLI SDK de Google, primero creando una máquina virtual y luego iniciándola (Google, nd)
Las instancias informáticas de gcloud crean una instancia de ejemplo imagefamily=rhel8

imageproject=rhelcloud zone=uscentral1a
Las instancias de computación de gcloud comienzan instanciaejemplo zone=uscentral1a
Un ejemplo similar se puede ver aquí con respecto a la creación de una máquina virtual en Microsoft Azure
utilizando las API de transferencia de estado representacional (REST) (Microsoft Corporation, 2020).
Una vez creada la máquina virtual, se iniciará otra llamada a la API. Esto también se puede hacer
mediante la CLI de Azure, Azure PowerShell y Azure Portal:
PUT https://management.azure.com/subscriptions/{subscription id}/resourceGroups/

myResourceGroup/providers/Microsoft.Compute/
máquinas virtuales/{vmname}?apiversion=20220801
{
"ubicación": "oeste",
"propiedades": {
"perfil de hardware": {
"vmSize": "Estándar_D1_v2"
},
"perfil de almacenamiento": {
"osDisk": {
"nombre": "mi disco VMos",
"imagen": {
Capítulo 12 505
"uri": "http://{nombredelacuentadealmacenamientoexistente}.blob.core. windows.

net/{nombre del contenedor existente}/{nombre del blob de la imagen del sistema operativo generalizado existente}.
vhd"
},
"osType": "Windows",
"createOption": "DeImagen",
"almacenamiento en caché": "LecturaEscritura",
"vhd": {
"uri": "http://{nombredelacuentadealmacenamientoexistente}.blob.core. windows.
net/{nombredecontenedorexistente}/myDisk.vhd"
}
}
},
"perfilOS": {
"adminUsername": "{tuusuario}",
"nombreDeEquipo": "miVM",
"adminPassword": "{tucontraseña}"
},
"perfil de red": {
"interfaces de red": [
{
"id": "/suscripciones/{idsuscripción}/resourceGroups/
myResourceGroup/providers/Microsoft.Network/networkInterfaces/ {nombre de NIC existente}",
"propiedades": {
"primario": cierto
}
}
]
}
}
}
Como ha visto, el uso de API permite a los usuarios de estos servicios implementar infraestructura, como
servidores, firewalls, balanceadores de carga de red y dispositivos de terceros. Sin embargo, también nos
permite configurar esa infraestructura exactamente como queremos que esté configurada. Por ejemplo, al
implementar servidores, podemos especificar los sistemas operativos, las direcciones IP, las configuraciones
de seguridad de la red, las tablas de enrutamiento, etc.
Esto es extremadamente poderoso. Con un solo comando, podemos iniciar una máquina virtual o cien mil
máquinas virtuales, todas configuradas exactamente como las queremos configurar. Como sabemos
exactamente cómo deben configurarse nuestros sistemas, podemos comparar las configuraciones actuales
de los sistemas que se ejecutan en producción con nuestra configuración estándar y determinar si hay alguna
diferencia. Podemos hacer esto constantemente para detectar cambios que podrían ser indicadores de
compromiso.
En entornos de TI locales, esto normalmente implicaría implementar agentes o software de administración en

los servidores que monitorearán los cambios de configuración.
Un desafío que enfrentan muchas organizaciones es implementar y administrar múltiples agentes y suites de
administración de diferentes proveedores. Cada agente requiere cierto nivel de administración y actualizaciones
de seguridad para garantizar que no aumente el área expuesta a ataques. Por lo general, los CISO y los CIO
buscan formas de reducir la cantidad de agentes que se ejecutan en los sistemas y se resisten a la idea de
implementar más de ellos en sus entornos. Mientras tanto, las fuentes de cambios en la configuración del
sistema pueden incluir todo tipo de cosas: administradores, software de gestión, usuarios, malware,
restauración desde copias de seguridad, etc. Esto puede dificultar la detección de cambios y determinar si
los cambios en los sistemas son indicadores de compromiso.
En la nube, dado que todo sucede a través de las API, las API brindan el cuello de botella perfecto para la
visibilidad y el control. Si las organizaciones pueden monitorear sus llamadas API y tomar medidas en función
de lo que sucede, tendrán una gran visibilidad y control. En este entorno, la implementación de agentes y
software de administración en cientos o miles de sistemas es opcional porque las API se integran en la nube.
Si una organización tiene requisitos de cumplimiento normativo que dictan configuraciones de control
específicas, pueden monitorear esos controles para asegurarse de que siempre cumplan.
En la práctica, las llamadas a la API se registran en los servicios de registro de la API para este fin. Por
ejemplo, AWS CloudTrail es un servicio de registro de API que registra las llamadas a la API en cuentas de
AWS (AWS, 2020). Anteriormente, cuando ejecutamos el comando que inició cinco máquinas virtuales en
AWS EC2, si AWS CloudTrail estaba habilitado, habría registrado un evento que capturó los detalles de esa
llamada a la API. Este evento contiene una increíble cantidad de detalles, incluida la cuenta que se utilizó, el
principal que realizó la llamada, algunos detalles de autenticación y autorización, la hora, la región, la dirección
IP de origen de la llamada, detalles sobre la máquina virtual y algunos detalles sobre su configuración . Estos
registros se pueden combinar con otros datos de registro, agregados y analizados por humanos y sistemas
de análisis de datos, importados a SIEM en la nube y/o descargados a sistemas en entornos de TI locales.
Estos registros también son esenciales para las investigaciones de respuesta a incidentes.
Capítulo 12 507
Google ofrece Cloud Audit Logs (Google, 2020), mientras que Microsoft ofrece Azure Monitor (Microsoft
Corporation, 7 de octubre de 2019), además de otros mecanismos de registro, para fines similares.
Este es un ejemplo truncado de un evento registrado por AWS CloudTrail:
{
"eventVersion": "1.05",
"userIdentity": { "type":
"AssumedRole",
"principalId": "Ejemplo:usuario123", "arn":
"arn:aws:sts::Ejemplo:funciónasumida/Administrador/usuario123",
"accountId": "EjemploID",
"accessKeyId": "Ejemploaccesoclave",
"sessionContext": {
"Emisor de sesión": {
"type": "Role",
"principalId": "Ejemploprincipio", "arn":
"arn:aws:iam::Ejemplo:role/Admin", "accountId":
"EjemploID",
"nombre de usuario": "Administrador"
},
"webIdFederationData": {},
"atributos": {
"mfaAuthenticated": "falso",
"fechadecreación": "20200401T05:09:15Z"
}
}
},
"eventTime": "20200401T05:09:26Z", "origen
del evento": "ec2.amazonaws.com",
"eventName": "RunInstances",
"awsRegion": "euwest2",
"dirección IP de origen": "169.254.35.31",
"agente de usuario": "awscli/1.3.23 Python/2.7.6 Linux/2.6.18164.el5 ",
"parámetros de solicitud": {
"conjunto de instancias": {
"elementos": [
{
"imageId": "i030322d35173f3725",
"cuenta min": 1,
"contador máximo": 5,
"keyName": "mipardeclaves"
}
]
},
"tipo de instancia": "t2.micro"
En resumen, cada interacción con la nube ocurre a través de una llamada a la API. Este modelo tiene numerosos
beneficios, incluidos los beneficios de seguridad y cumplimiento. Debido a esto, la visibilidad y el control que ofrece la
nube son superiores a los de la mayoría de los entornos de TI locales, sin mencionar la simplicidad y los beneficios de
costo de este enfoque. Además, permite nuevos enfoques para las operaciones de TI y seguridad. Por ejemplo,
sabemos que cada sistema que implementamos está configurado para cumplir con nuestros estándares de seguridad y
cumplimiento, porque así se ha definido en el código que usamos para implementarlos. Dado que el almacenamiento y
las redes están desacoplados de los servicios informáticos, nada nos impide simplemente apagar los sistemas e
implementar nuevos sistemas para reemplazarlos cada pocas horas. Solo se necesitan unas pocas líneas de código en
un script o aplicación para hacer esto, como vimos anteriormente.
Si los sistemas son de corta duración, es más difícil para los administradores y el software de gestión introducir
configuraciones erróneas de seguridad con el tiempo que los atacantes pueden usar para afianzarse en el sistema.
ambiente.
Las API son poderosas, pero también deben implementarse correctamente para que no creen una superficie de ataque
porosa. Por supuesto, los CSP lo saben y emplean experiencia, procesos y tecnología en el desarrollo de sus API para
minimizar el riesgo. Capa en mecanismos de autenticación y autorización, protección, monitoreo, detección, respuesta
y capacidades de auditoría, ¡y las API son geniales!
He discutido un escenario aquí, que usa API para configurar e iniciar máquinas virtuales.
Ahora, imagine si pudiera usar las API para controlar cientos de servicios en la nube que realizan todo tipo de funciones,
como computación, almacenamiento, redes, bases de datos, contenedores, computación sin servidor, inteligencia
artificial, aprendizaje automático, IoT y seguridad, por nombrar solo algunos. Imagínese tener control programático
sobre todo eso, prácticamente a cualquier escala, en cualquier parte del mundo, realmente asombroso.
¡Este es el poder de las API! Realmente son un cambio de juego para los profesionales de seguridad y cumplimiento.
El poder de las API no solo está disponible para grandes organizaciones con grandes presupuestos de TI; cualquier
persona con una tarjeta de crédito puede abrir una cuenta con un CSP y obtener el poder de estas API. A continuación,
veamos otro cambio de juego, la automatización.

Capítulo 12 509
Las ventajas de la automatización.

Como hemos visto, el poder de las API nos permite configurar y controlar la mayoría de las cosas en la nube usando
código, incluso infraestructura. Para aprovechar al máximo el poder de las API, la nube ofrece altos niveles de
automatización. Además de ejecutar comandos CLI, puede automatizar flujos de trabajo complejos mediante scripts,
plantillas, aplicaciones y servicios en la nube.
Los CSP ofrecen ricas capacidades de automatización. Estas capacidades se distribuyen entre diferentes servicios
en la nube, al igual que las API que aprovechan. Algunos ejemplos de servicios que ayudan a automatizar funciones
incluyen Microsoft Azure Automation (Microsoft Corporation, 18 de octubre de 2018), Google Cloud Composer (Google,
2020) y AWS CloudFormation (AWS, 2020). También hay soluciones de automatización disponibles de terceros, como
Chef (Chef, 2020), Puppet (Puppet, 2020), Ansible (Ansible, 2020), Terraform (Hashicorp, 2020) y muchos otros.
Para los profesionales de la seguridad y el cumplimiento, todas estas capacidades y herramientas de automatización
pueden ayudar a aprovisionar, configurar, administrar, monitorear, reconfigurar y desaprovisionar la infraestructura y
otros servicios en la nube. Además, estas ricas capacidades de automatización pueden ayudar a proteger, detectar,
responder y recuperar, mientras mantienen el cumplimiento de los estándares regulados, los estándares de la industria
y los estándares de seguridad internos. En muchos casos, todo esto puede suceder casi en tiempo real porque la
automatización, no los humanos, está realizando estas operaciones.
De hecho, reducir la participación humana en estas operaciones tiene muchas ventajas. Recuerde los sospechosos
habituales de ciberseguridad que analicé en detalle en el Capítulo 1, Introducción; Veamos algunos ejemplos de cómo
la automatización puede ayudarnos a mitigar algunos de estos. Comencemos analizando las amenazas internas y la
ingeniería social.
Mitigación de amenazas internas e ingeniería social

Recuerde los dos tipos de amenazas internas que definí anteriormente: personas internas maliciosas que abusan de
su acceso privilegiado a los recursos y personas internas no maliciosas que cometen errores que conducen a
resultados de seguridad deficientes. La automatización puede ayudar a mitigar ambos tipos de amenazas. Por
ejemplo, cuanta más automatización desarrollemos, probemos e implementemos, menos posibilidades tendrán los
administradores de cometer errores que tengan consecuencias para la seguridad.
El uso de la automatización para completar procesos repetibles puede conducir a resultados más consistentes y
rápidos que son menos propensos a errores humanos.
La automatización de los procesos administrativos también dará como resultado menos oportunidades para que
actúen los malintencionados . Aquí es donde los conceptos de administración justo a tiempo y administración
justa pueden ser útiles.
Con altos niveles de automatización, los administradores necesitarán menos acceso a los sistemas, lo que reducirá las
oportunidades que tienen de robar datos o dañar la infraestructura. Los entornos altamente automatizados también facilitan
la detección cuando los administradores acceden a los sistemas porque tales ocasiones serán excepciones a las reglas.
Cuando los malintencionados saben que tienen mayor visibilidad y escrutinio cuando acceden directamente a los datos y
sistemas, se reduce la frecuencia con la que intentarán acceder a los recursos sin motivos legítimos.
La automatización puede ayudar a minimizar la cantidad de acceso que tienen los administradores. Por ejemplo, en lugar
de permitir que los administradores tengan acceso completo a los sistemas a los que se conectan, solo permitirles ejecutar
scripts probados y aprobados y la automatización en esos sistemas reducirá las oportunidades que tienen de ejecutar
comandos arbitrarios. Con suficiente automatización, la única vez que los administradores tienen una causa legítima para
ejecutar comandos arbitrarios es en escenarios de "rotura de cristales" donde la automatización existente no puede
solucionar un problema. Estos casos se pueden monitorear y auditar para reducir las posibilidades de que actúe un
infiltrado malicioso. Durante tales escenarios, el empleo de procedimientos de administración basados en quórum con dos
o más participantes también puede ayudar a mitigar las amenazas internas. Agregar más automatización con el tiempo
para cubrir más escenarios de soporte puede reducir drásticamente las oportunidades que tienen los administradores de
ejecutar comandos arbitrarios.
También hay beneficios de privacidad al usar la automatización. Si los humanos no tienen acceso a datos
confidenciales, entonces no pueden estar expuestos a información de identificación personal (PII) o información
de salud protegida (PHI), o información financiera confidencial. El uso de la automatización para interactuar con
datos, en lugar de humanos, ayuda a las organizaciones a cumplir las promesas de privacidad que hacen a sus clientes.
o ciudadanos.
Suena genial, ¿verdad? ¿Quizás demasiado bueno para ser verdad? ¿No podemos hacer esto ya en entornos de TI
locales mediante el uso de hosts bastión y sesiones de Secure Shell (SSH) ? Grandes preguntas. Veamos un ejemplo del
mundo real.
Los requisitos del equipo de seguridad en este ejemplo especifican que los administradores no pueden acceder
directamente a los sistemas que están administrando. Esto significa que usar SSH para acceder a los sistemas
directamente no cumplirá con los requisitos. Si usaron SSH para acceder a estos sistemas, entonces podrían ejecutar
comandos arbitrarios en estos sistemas, algo que el equipo de seguridad quiere evitar.
El equipo de seguridad en este escenario también desea limitar el uso de hosts bastión en su entorno . Se han quemado
utilizando hosts de bastión en el pasado. Los hosts bastión generalmente abarcan una zona de mayor seguridad y una
zona de menor seguridad, lo que permite a los administradores obtener acceso a los sistemas en la zona de mayor
seguridad desde la zona de menor seguridad; posteriormente, los hosts bastión deben administrarse como si fueran parte
de la zona de mayor seguridad.

Capítulo 12 511
Resulta que esto puede ser más difícil de lo que parece y las fallas en los procesos de esta organización
ficticia llevaron a un compromiso del sistema en su entorno. Habiendo sido quemados una vez, quieren
para minimizar la cantidad de hosts bastión en su entorno.
Una forma de cumplir estos requisitos con AWS, por ejemplo, es usar el servicio AWS Systems Manager para
ejecutar comandos en máquinas virtuales que se ejecutan en el servicio Amazon EC2. Para ello, se instalará
el Agente de Systems Manager en dichas máquinas virtuales. Esto es fácil de hacer usando la automatización.
Dado que cada máquina virtual se aprovisiona en EC2 mediante código, el agente de Systems Manager
también se instalará en ellas. Una vez que ese agente está configurado correctamente, los administradores
pueden ejecutar scripts probados y aprobados desde la consola de AWS Systems Manager que se ejecutarán
en esas máquinas virtuales a través de Systems Manager Agent (AWS, 2020).
Hay algunas ventajas geniales en este enfoque. Primero, los administradores no necesitan tener credenciales
de administrador para las máquinas virtuales que administran. Dado que ejecutan scripts desde el servicio
AWS Systems Manager en la nube, no necesitan credenciales locales para acceder a sistemas individuales.
Si los administradores no conocen los nombres de usuario y las contraseñas de esos sistemas, no pueden
iniciar sesión directamente en ellos. Se limitan a ejecutar los scripts probados y aprobados desde la nube.
Esto ayuda a mitigar el riesgo de amenazas internas para esos sistemas.
Este enfoque también mitiga parte del riesgo asociado con la ingeniería social en estos sistemas. No se puede
engañar a los administradores para que revelen las credenciales de esos sistemas porque no los conocen.
Dado que la única forma en que los administradores interactúan con estos sistemas es mediante la ejecución
remota de secuencias de comandos preaprobadas, no se les puede engañar para que ejecuten comandos
arbitrarios o instalen software nuevo, lo que puede socavar la seguridad de estos sistemas y generar malos
resultados de seguridad. Por supuesto, dado lo insidiosa que es la ingeniería social, este enfoque debe
combinarse con algunas otras mitigaciones para mitigarlo por completo; por ejemplo, MultiFactor Authentication
(MFA) para las propias cuentas de AWS. Sin embargo, espero que pueda ver las posibles ventajas de este
enfoque cuando se trata de mitigar los típicos ataques de ingeniería social contra los administradores.
Cuando los administradores solo tienen acceso cuando lo necesitan y ese acceso tiene un alcance y un control
estrictos, hay menos oportunidades de que las tácticas típicas de ingeniería social tengan éxito.
Recuerda que una de las grandes ventajas de utilizar la nube es la escalabilidad. Si instalamos el Agente de
Systems Manager en cada máquina virtual que implementamos, utilizando la automatización, por supuesto,
tendremos la capacidad de usar este método de administración en tantos sistemas como sea necesario; la
escala es prácticamente ilimitada. Usando la automatización, podemos administrar tres sistemas o tres mil
sistemas con la misma técnica y cantidad de esfuerzo.
A medida que aumenta o disminuye la cantidad de sistemas que administramos, los administradores no
requieren trabajo adicional porque ejecutan los mismos scripts independientemente de la cantidad de sistemas
que administren; administrar más sistemas no significa que los administradores tengan más acceso.
Si estamos registrando las llamadas a la API generadas por las interacciones de los administradores con el
servicio de AWS Systems Manager en AWS CloudTrail, sus actividades se pueden monitorear y auditar casi en
tiempo real (AWS, 2020). También podemos monitorear y auditar cualquier interacción que los administradores
tengan con las propias máquinas virtuales para garantizar que los administradores solo accedan a estos
sistemas en eventos de emergencia.
Por supuesto, otros CSP también tienen ricas capacidades de automatización. Por ejemplo, Microsoft ofrece
una variedad de servicios y capacidades para ayudar, incluidos Azure Automation, Azure PowerShell, Azure
Monitor y otros. Google también ofrece varios servicios, incluidos Cloud Monitoring, Cloud Functions y Cloud
Asset Inventory, entre otros.
La automatización nos permite diseñar sistemas que no requieren interacción humana directa muy a menudo.
Esto hace que sea más fácil detectar cuándo ocurren esos incidentes y mitigar mejor las amenazas internas y la
ingeniería social. A continuación, veamos cómo se puede mitigar otro de los sospechosos habituales de
ciberseguridad, las vulnerabilidades sin parches, en este escenario.
Mitigación de vulnerabilidades sin parches Veamos cómo
podemos usar la automatización para ayudar a administrar las vulnerabilidades en las máquinas virtuales que usamos .
Como vimos en el Capítulo 3, Uso de las tendencias de vulnerabilidad para reducir el riesgo y los costos, hasta la fecha,
los equipos de gestión de vulnerabilidades se han enfrentado con hasta 69 divulgaciones de vulnerabilidades nuevas
por día en toda la industria que pueden afectar sus sistemas. La automatización en la nube puede ayudar a reducir la
cantidad de trabajo relacionado con los sistemas de inventario, los sistemas de escaneo y los sistemas de aplicación de parches.
Por ejemplo, recuerde que escribí en el Capítulo 3 que los inventarios precisos son fundamentales para los
equipos de gestión de vulnerabilidades. En la nube, porque nada se aprovisiona o desaprovisiona sin usar las
API, las API y la automatización ayudan a proporcionar inventarios precisos rápidamente. Inventariar entornos
como este no lleva horas ni días; puede ser casi instantáneo.
Hay muchos métodos disponibles para escanear y parchear máquinas virtuales en la nube. En nuestro ejemplo
de AWS, AWS Systems Manager se puede utilizar para aplicar parches a los sistemas. Además, es probable
que los proveedores que utiliza su organización para el software de administración de vulnerabilidades en su
entorno de TI local también tengan capacidades similares creadas para la nube. Esto le permite a su
organización aprovechar la experiencia que ha desarrollado a partir de la gestión de vulnerabilidades en su
entorno de TI local y continuar aprovechándola en la nube.
Capítulo 12 513
Quizás se pregunte cómo se ven potencialmente afectados los procesos de administración de vulnerabilidades para las
máquinas virtuales que se ejecutan en la nube cuando la cantidad de sistemas se puede escalar hacia arriba y hacia
abajo de forma completamente dinámica para cumplir con los objetivos de disponibilidad de aplicaciones y carga. En
este escenario, se puede usar Amazon EC2 Auto Scaling para lograr esto (AWS, 2016). También puede ayudar a
mantener los sistemas actualizados. En lugar de escanear y parchear cada sistema en una gran flota de sistemas, Auto
Scaling se puede usar para reducir drásticamente este esfuerzo. Para hacer esto, la imagen de la máquina de Amazon
utilizada para construir las máquinas virtuales se analiza en busca de vulnerabilidades y las actualizaciones de seguridad
se instalan según sea necesario después de la prueba. Esto garantiza que la imagen esté actualizada y que se hayan
probado las actualizaciones de seguridad. Después de actualizar la imagen de máquina de Amazon, apague una
máquina virtual que se esté ejecutando en producción y que esté basada en la versión anterior de esa imagen. Según
las reglas de carga y disponibilidad que establezca para Auto Scaling, cuando Auto Scaling decide que es hora de
lanzar una nueva máquina virtual, lo hace utilizando la imagen que acaba de parchear y probar. Cuando se inicia la
nueva máquina virtual, está completamente parcheada. Puede usar la automatización para apagar cuidadosamente las
máquinas virtuales que se ejecutan en producción que se basan en la imagen anterior, y Auto Scaling reiniciará las
máquinas virtuales nuevas con parches completos para reemplazarlas. Sin escanear ni parchear cientos o miles de sistemas.
Y el dolor de los reinicios se mitiga en gran medida. Esta es una forma mucho más fácil de hacer algo que durante
mucho tiempo ha sido un punto débil para las grandes empresas.
Google y Microsoft también brindan herramientas para encontrar y mitigar vulnerabilidades de manera eficiente.
Por ejemplo, Google ofrece gestión de inventario del sistema operativo, gestión de parches del sistema operativo y Web
Security Scanner, mientras que Microsoft ofrece Azure Automation y Microsoft Defender for Cloud, entre otras
herramientas. Existen numerosos proveedores externos que brindan soluciones de gestión de vulnerabilidades para
entornos de nube, incluidos Qualys, Tenable y muchos otros.
Por supuesto, este es solo un método para aplicar parches; hay otros. También existe la posibilidad de eliminar por
completo la aplicación de parches mediante el uso de servicios que los CSP administran por usted. Como mencioné
anteriormente en este capítulo, IaaS es solo un tipo de modelo de servicio en la nube; hay cientos de servicios de CSP
que no requieren que usted aprovisione, administre ni aplique parches a los servidores en absoluto. Si no necesita
administrar los servidores usted mismo, ¿por qué molestarse?
Deje que los CSP administren la infraestructura por usted, y podrá dedicar el tiempo normalmente relegado a tales
tareas a reducir la deuda técnica en otras áreas, proyectos de trabajo que parece que nunca se hacen o innovar,
imagínese eso. Imagínese dedicar tiempo a descubrir cómo usar la computación sin servidor, la IA, el ML y el IoT para
proteger, detectar y responder mejor a las amenazas, en lugar de probar parches y reiniciar los servidores. El uso de
servicios administrados no aumenta la superficie de ataque que su equipo de seguridad necesita rastrear y administrar:
los CSP lo hacen por usted.

El resultado neto es potencialmente un aumento drástico de las capacidades de TI sin aumentar la superficie de ataque de TI y la
cantidad de sistemas para parchear y administrar. Por ejemplo, usar un servicio administrado para aumentar las capacidades de
detección para su estado de TI en la nube, sin aprovisionar ninguna infraestructura adicional que necesite administrar. Potencialmente,
esto le dará más visibilidad sin aumentar la complejidad y la deuda técnica.
La nube definitivamente puede ayudar a mitigar las vulnerabilidades sin parches y hacer que esto sea mucho
más fácil de lo que es en la mayoría de los entornos locales, algo que ha afectado a las empresas durante décadas.
Ahora, veamos cómo la automatización en la nube puede ayudar a mitigar otro de los sospechosos habituales de la ciberseguridad,
las malas configuraciones de seguridad.
Mitigación de configuraciones erróneas de seguridad

Como escribí en el Capítulo 1, Introducción, las configuraciones incorrectas de seguridad pueden ser configuraciones predeterminadas
deficientes en hardware, sistemas operativos y aplicaciones, o pueden ocurrir con el tiempo a medida que los sistemas se “desvían”
de los estándares de su organización en función de los ajustes que introducen los administradores o las actualizaciones de software.
Además, en grandes entornos de TI, la tecnología abandonada puede convertirse rápidamente en un riesgo olvidado que no se
gestiona activamente. Debido a la lucha constante que han tenido las grandes empresas para mantener las cosas configuradas de la
forma en que las necesitan, la gestión de cambios surgió como una disciplina de TI en toda regla , respaldada por toda una industria
de proveedores. Esto es importante, no solo por motivos de seguridad, sino también por motivos de cumplimiento. Garantizar que los
sistemas cumplan con los estándares regulados, los estándares de la industria y los estándares internos de TI es importante y, en
muchos casos, obligatorio.
En nuestro escenario de ejemplo, las organizaciones pueden optar por instalar software de gestión en los servidores que implementan
en la nube. Pueden continuar midiendo y remediando los cambios de configuración de la misma manera que lo han hecho en su
entorno de TI local.
También pueden aprovechar el poder de las API y la automatización integrada en la nube. Por ejemplo, AWS Config es un servicio en
la nube que supervisa los recursos en busca de cambios de configuración y le permite realizar una variedad de acciones en función
de esos cambios.
En nuestro escenario de ejemplo, el equipo de seguridad podría decidir que un tipo de cambio debe corregirse automáticamente;
cuando se detecta el cambio, la automatización cambiará la configuración a su configuración estándar. Alternativamente, solo para
estar seguro, la automatización se puede usar para apagar el sistema mal configurado y, si está habilitado, Auto Scaling iniciará un
nuevo sistema que cumpla con todos los estándares de la organización para reemplazarlo.
Capítulo 12 515
El equipo de seguridad podría considerar otro tipo de cambio como un indicador de compromiso que debe ser
investigado por su equipo de respuesta a incidentes. En este caso, la automatización puede tomar una instantánea
de la máquina virtual, crear una nueva nube privada virtual (VPC) , llamémosla IR Clean Room, copiar la instantánea
en la IR Clean Room aislada, conectar el software forense del equipo de IR a la imagen, enviar un mensaje al equipo
de IR para investigarlo y apagar la máquina virtual original. Si está configurado, Auto Scaling iniciará una nueva
máquina virtual prístina que cumple con todos los estándares aprobados para ocupar su lugar. Hace todo esto casi
en tiempo real. Tenga en cuenta que, en estos ejemplos , no había ningún software de administración ni agente en
la máquina virtual ni analistas de SOC que realizaran consultas manuales en busca de indicadores de riesgo. Dado
que la infraestructura es código, podemos automatizar cualquier cantidad de acciones para satisfacer las necesidades
de la organización.
En un contexto de cumplimiento, esta funcionalidad es poderosa ya que puede ayudar a mantener las cosas
configuradas de manera que cumplan con los estándares. Cuando usamos la automatización para detectar cambios
y tomar las medidas apropiadas, también podemos usar esa automatización para generar artefactos de cumplimiento
que ayudarán a la organización a demostrar el cumplimiento continuo de los estándares específicos que se aplican
a ellos. Esto ayuda a reducir las auditorías manuales y la reparación manual de sistemas mal configurados.
Microsoft Azure Automation y Google Cloud Asset Inventory brindan capacidades similares para sus respectivos
servicios. También hay terceros que brindan soluciones de automatización como Ansible, Chef, Terraform y muchos
otros.
A continuación, veamos cómo la automatización en la nube ayuda a mitigar los últimos sospechosos habituales de la
ciberseguridad: credenciales débiles, filtradas y robadas.
Mitigación de credenciales débiles, filtradas y robadas

Los CSP y numerosos proveedores externos ofrecen soluciones de administración de acceso e identidad para la
nube y los entornos híbridos. Por ejemplo, Microsoft ofrece Azure Active Directory y servicios de soporte como
capacidades de acceso privilegiado justo a tiempo a través de Azure Active Directory Privileged Identity Management
(PIM) (Microsoft Corporation, 2022). Terceros como Centrify, CyberArk y muchos otros también brindan servicios que
pueden ayudar en varios escenarios diferentes. Google Cloud ofrece Cloud Identity and Access Management,
mientras que AWS ofrece AWS Identity and Access Management.
Los CSP ofrecen MFA, que es un control altamente efectivo que mitiga en gran medida las credenciales débiles,
filtradas y robadas. Aprovechar MFA y limitar la cantidad de tiempo que los usuarios tienen acceso a los recursos
entre las solicitudes de autenticación puede hacer que sea mucho más difícil para los atacantes usar con éxito las
credenciales robadas y filtradas.

El uso de un administrador de secretos para administrar las claves de acceso, los certificados y las credenciales que
los cambia automáticamente y los rota periódicamente también puede ser efectivo. Para ello, Google ofrece Google
Cloud Secret Manager (Google, 2020), Microsoft ofrece Azure Key Vault (Microsoft Corporation, 2020) y AWS
proporciona AWS Secrets Manager (AWS, 2020). Nuevamente, hay muchos proveedores externos que también
ofrecen soluciones, incluidos Docker Secrets, SecretHub y otros.
De hecho, hay tantas capacidades y funcionalidades en los servicios y soluciones de gestión de acceso e identidad
que se han dedicado libros enteros a esta área temática. La identidad es la clave de la seguridad. Recomiendo
enfáticamente dedicar algún tiempo a conocer las poderosas capacidades de gestión de acceso e identidad que
ofrecen los CSP y otros proveedores.
Cambios en el juego de seguridad y cumplimiento: resumen

Las API y la automatización en la nube son dos elementos revolucionarios para los profesionales de la seguridad y
el cumplimiento . Eso no quiere decir que las API y la automatización no estén disponibles en entornos de TI locales.
Sin embargo, la inversión y el esfuerzo para equiparar estas capacidades con las integradas en la nube serían
prohibitivamente costosos y difíciles de implementar; Teniendo en cuenta que cualquier persona con una tarjeta de
crédito y unos minutos para abrir una cuenta con un CSP obtiene estas capacidades de forma predeterminada, sería
difícil justificar la implementación de versiones locales.
Ahora hemos visto que la nube puede ofrecer algunas formas efectivas e innovadoras para abordar todos los
sospechosos habituales de ciberseguridad. Dicho de otra manera, la nube hace que abordar los fundamentos de
ciberseguridad sea más fácil que mitigarlos en entornos de TI locales. Realmente solo hemos arañado la superficie
aquí porque el escenario de ejemplo que usé a lo largo de esta sección fue un ejemplo de IaaS. Como mencioné, los
CSP ofrecen cientos de servicios que abarcan y combinan IaaS, PaaS, SaaS, FaaS, IDaaS y otros. Sin mencionar
que no me sumergí en ninguno de los servicios de seguridad que ofrecen estos CSP. Se han dedicado libros enteros
al tema de la seguridad en la nube.
Ahora veamos cómo la nube puede respaldar las estrategias de seguridad cibernética que examinamos en el Capítulo
9, Estrategias de seguridad cibernética.
Uso de estrategias de ciberseguridad en la nube

En el Capítulo 9, Estrategias de ciberseguridad, examinamos varias estrategias de ciberseguridad que he visto
empleadas en la industria durante las últimas dos décadas. Evaluamos estas estrategias utilizando el Sistema
de puntuación de fundamentos de seguridad cibernética (CFSS). La estimación del puntaje CFSS para cada
estrategia nos ayuda a comprender qué tan bien abordan los fundamentos de ciberseguridad. Para refrescar su
memoria, en la Figura 12.1 se proporciona un resumen de las puntuaciones CFSS para cada estrategia .
Capítulo 12 517
Figura 12.1: Resumen de la estimación de la puntuación CFSS
Casi cualquiera de estas estrategias se puede utilizar en la nube. Veamos algunas de estas estrategias en el
contexto de la nube.
Uso de la estrategia de protección y recuperación en la nube

Los CSP ofrecen firewall granular y controles de red que pueden ayudar a las organizaciones a adoptar y operar
la estrategia de protección y recuperación. El poder de las API y la automatización en la nube permite a los
equipos de red y de seguridad aprovisionar y operar firewalls de aplicaciones web, así como firewalls de red en el
borde de sus propiedades en la nube, y construir y operar DMZ. También proporcionan VPC o redes virtuales que
agregan otra capa de control sobre el tráfico de red, además de ACL de red, tablas de enrutamiento, reglas de
subred, firewalls basados en host, etc. Los CSP suelen ofrecer una variedad vertiginosa de controles de red.
Dado que todos estos controles se pueden aprovisionar y monitorear mediante código y automatización, es mucho
más fácil ejecutar esta estrategia en la nube que en las instalaciones. En la nube, no hay que pedir ni recibir
hardware, no hay almacenamiento ni apilamiento en el centro de datos, y nada que requiera más espacio de rack,
alimentación o refrigeración. Simplemente ejecuta el código y los CSP hacen todo lo demás. Si necesita escalar
su infraestructura hacia arriba o hacia abajo, solo necesita más código y automatización. Solo paga por lo que usa
y puede apagarlo en cualquier momento que su organización lo decida. La estrategia Proteger y recuperar es una
estrategia de puntuación deficiente, como discutimos en el Capítulo 9, Estrategias de seguridad cibernética. Se
puede usar en combinación con otras estrategias para abordar de manera más completa los fundamentos de la
ciberseguridad. Es más fácil extender esta estrategia también en la nube, porque todo es código. Veamos una
mejor estrategia de puntuación ahora.
El cumplimiento como estrategia de ciberseguridad en la nube

Veamos otra estrategia del Capítulo 9, Estrategias de ciberseguridad, Cumplimiento como estrategia de
ciberseguridad. Anteriormente en este capítulo, analizamos cómo las API y la automatización en la nube ayudan
a mitigar las configuraciones incorrectas de seguridad. Esas mismas capacidades pueden ayudar a las
organizaciones a cumplir continuamente con los estándares de seguridad, ya sean estándares regulados, de la
industria o internos. Ya he discutido cómo las API y la automatización pueden garantizar que los sistemas estén
configurados correctamente y monitoreados continuamente para cambios de configuración. Sin embargo, hay un
matiz importante a tener en cuenta para ejecutar esta estrategia.
Muchos equipos de seguridad y equipos de cumplimiento que contemplan usar la nube por primera vez se
preguntan cómo pueden demostrar que cumplen con los estándares, es decir, cuando no son propietarios de los
centros de datos en los que se ejecutan sus infraestructuras y, posteriormente, no pueden obtener acceso de sus
auditores a estas instalaciones . Independientemente de quién sea el propietario de los centros de datos, muchas
organizaciones aún deben demostrar a sus auditores y reguladores que cumplen con los estándares requeridos.
En la mayoría de los casos, esta es otra ventaja de aprovechar los CSP de hiperescala. AWS, Google y Microsoft
tienen numerosas certificaciones y certificaciones en sus servicios en la nube. Por ejemplo, ISO 27001 es una
apuesta en la mesa para cualquier CSP hoy en día: todos deben tener esta certificación para satisfacer los
requisitos de sus clientes empresariales. Hay dos certificaciones que son más valiosas para muchos CISO.
El primero es el Instituto Americano de Controles de Sistemas y Organizaciones (SOC) del Instituto Americano de
CPA , en particular la certificación SOC2 Tipo II (AICPA, nd). Hay al menos un par de cosas que hacen que esta
certificación sea valiosa para los CISO, los equipos de seguridad y los equipos de cumplimiento. En primer lugar, el
alcance de los controles que se auditan en un SOC2 Tipo II suele responder a la mayoría de las preguntas que las
empresas tienen sobre la seguridad. En segundo lugar, no se trata de una instantánea de "punto en el tiempo" de la
configuración de control o el diseño arquitectónico; las organizaciones que persiguen el SOC2 Tipo II necesitan 6
meses de auditoría continua para lograrlo . Los pasos que toman las organizaciones para prepararse para este tipo
de auditoría pueden mejorar drásticamente su postura de seguridad. Entonces, lograr esta certificación y mantenerla
en el tiempo y demostrar continuamente que los servicios se están operando de la forma en que se describen puede ser un gran desafío.
Muchas empresas ni siquiera intentarían obtener esta certificación porque es difícil de lograr y puede ser costosa.
Sin embargo, los CSP de hiperescala logran y mantienen esta certificación en muchos de sus servicios para
mantener sus estándares de seguridad entre los más altos de la industria.
Los CSP normalmente compartirán sus informes de auditoría SOC2 Tipo II con sus clientes. Para los equipos de
Seguridad y Cumplimiento, vale la pena descargar estos informes y revisarlos para asegurarse de que las
soluciones que están evaluando cumplen o superan sus estándares. Las preguntas no respondidas por el informe
de auditoría SOC2 Tipo II se pueden dirigir a los propios CSP, quienes normalmente estarán encantados de
responderlas.
Capítulo 12 519
Otro testimonio que muchos CISO y equipos de seguridad consideran valioso es el Catálogo de controles de
cumplimiento de computación en la nube (C5), diseñado por la Oficina Federal para la Seguridad de la Información.
(BSI), una oficina del gobierno federal en Alemania (The BSI, 2018). El C5 es un certificado de garantía de seguridad
en profundidad . Tiene criterios para muchos dominios, incluidas las políticas, el personal, la seguridad física, la
gestión de acceso e identidad, el cifrado y otros. Nuevamente, el alcance y la complejidad de esta certificación
pueden hacer que sea un desafío lograrlo y mantenerlo. Al igual que el SOC2 Tipo II, para los CISO, esta certificación
contiene respuestas a muchas de las preguntas que tienen sobre los conjuntos de control de seguridad de los CSP.
SOC2 Tipo II y C5 son como tesoros de información de seguridad para CISO, equipos de seguridad, equipos de
cumplimiento y auditores. Los CSP suelen combinarlos con muchas otras certificaciones y certificaciones para ayudar
a sus clientes a demostrar que cumplen con los requisitos de cumplimiento.
Sin embargo, los clientes de los CSP también tienen un papel que desempeñar en esto. Recuerde que los CSP son
diferentes de los proveedores de servicios administrados (MSP). Los CSP ofrecen nubes de autoservicio. Sus clientes
y proveedores de software independientes (ISV) pueden construir sobre esas nubes para crear soluciones.
Sin embargo, los alcances de las certificaciones y atestiguaciones de los CSP no cubren la parte de las soluciones
diseñadas y operadas por sus clientes; a diferencia de los MSP, los CSP generalmente no tienen la visibilidad o el
acceso necesarios para hacer esto.
Este acuerdo significa que los CSP y sus clientes son responsables de sus respectivas partes de las soluciones que
diseñan y operan. Google, Microsoft y AWS se refieren a este acuerdo como una responsabilidad compartida. Tanto
los CSP como sus clientes proporcionan las certificaciones y certificaciones adecuadas para demostrar que sus
respectivas partes de sus soluciones cumplen los requisitos de las normas a las que están obligados. Este acuerdo
generalmente ahorra tiempo y dinero a los clientes de los CSP. Esto se debe a que la parte de sus soluciones que
deben atestiguar puede reducirse drásticamente en casi todos los casos. Por ejemplo, dado que los clientes de los
CSP no son propietarios de los centros de datos en los que se ejecutan sus infraestructuras, esencialmente han
delegado la responsabilidad de auditar y certificar esos centros de datos a sus CSP. Dicho de otra manera, ya no
tienen que lidiar con la complejidad y el costo de los centros de datos físicos, ya que los CSP lo hacen por ellos. Es
una victoria para los clientes de los CSP porque pueden cumplir o superar los estándares de seguridad de los que
son responsables mientras reducen la cantidad de esfuerzo y costo para ellos.
La información sobre los programas de cumplimiento en los que operan los CSP se puede encontrar en sus
respectivos sitios web, pero los propios informes de los auditores generalmente están reservados para los clientes
de los CSP; aquí están las ubicaciones que contienen información del programa de cumplimiento para AWS, Google y Microsoft:
• AWS: https://aws.amazon.com/compliance/programs/
• Gafas: https://cloud.google.com/security/compliance/
• Microsoft: https://www.microsoft.com/enus/trustcenter/compliance/compliance
descripción general
La combinación de API, automatización y las certificaciones y atestaciones proporcionadas por los CSP pueden
ayudar a las organizaciones que desean buscar el cumplimiento como una estrategia de ciberseguridad. Para
las organizaciones que desean ampliar esta estrategia para abordar por completo los Fundamentos de la
ciberseguridad, la nube suele hacer que esto sea más fácil que en los entornos de TI locales. Esto se debe a
las API y las capacidades de automatización que hemos discutido. Todo es código. Veamos una estrategia
más que examinamos en el Capítulo 9, Estrategias de ciberseguridad, y veamos cómo se puede implementar en la nube.
Uso de la estrategia centrada en el ataque en la nube La mejor puntuación de

todas las estrategias que examinamos fue la estrategia centrada en el ataque. En el Capítulo 10,
Implementación de la estrategia, profundizamos en esta estrategia e ilustramos una forma en que podría
implementarse. En el Capítulo 11, Medición del desempeño y la eficacia, examinamos una forma en que
se puede medir la eficacia de esta estrategia. Sin embargo, ¿se puede implementar esta estrategia en la nube?
La respuesta corta a esta pregunta es sí, se puede implementar en la nube. De hecho, soy coautor de un
documento técnico que ayudará a los equipos de seguridad a implementar un modelo de Intrusion Kill Chain
en AWS. Puede leer más sobre este enfoque y obtener acceso al documento en esta URL: https://aws.amazon.
com/blogs/security/whitepaperdisponibleclásicointrusiónanálisismarcospara
awsentornos/.
En el Capítulo 10, Implementación de la estrategia, discutimos cómo el marco MITRE ATT&CK® puede
complementar el modelo Intrusion Kill Chain, que examinamos en profundidad. Ambos marcos se pueden
utilizar en la nube. Para hacer esto, probablemente querrá concentrar sus esfuerzos en el desarrollo de una
matriz de cursos de acción (Hutchins, EM, Cloppert, MJ, Amin, RM, nd) como hicimos en el Capítulo 10, para
la solución que está implementando en la nube . Dicho de otra manera, dado que este puede ser un ejercicio
que requiere mucho tiempo, como vio, no necesita crear una matriz de cursos de acción para cada servicio
en la nube que ofrece un CSP, solo para los que planea usar. Si planea aprovechar AWS, esto ya está hecho
para usted en el documento técnico mencionado anteriormente del que soy coautor. Ya se ha creado para
usted una matriz completa de cursos de acción que incluye todos los servicios y funciones de seguridad de
AWS (que estaban disponibles cuando escribimos el documento). El apéndice de ese documento proporciona
70 páginas de asignaciones de funciones y servicios a las fases de un marco modificado de Intrusion Kill
Chain. Desarrollar este apéndice fue meses de trabajo para un equipo de nosotros en AWS y proporciona a
los equipos de seguridad una gran ventaja. Si planea usar Google Cloud o los servicios en la nube de
Microsoft, es posible que tengan contenido similar disponible, o tendrá que desarrollar su propia matriz de cursos de acción.
Capítulo 12 521
La creación de una matriz de cursos de acción para soluciones desarrolladas para entornos IaaS es, en algunos
aspectos, similar a realizar este mapeo para entornos de TI locales. Esto se debe a que gran parte del hardware y el
software pueden ser iguales o similares. Por ejemplo, las mitigaciones del sistema operativo identificadas para una
solución que se ejecuta en Linux o Windows serán muy similares, independientemente de si ese sistema operativo se
ejecuta en la nube o en las instalaciones. Sin embargo, como comentamos anteriormente, los controles nativos de la
nube y las soluciones de terceros también se pueden superponer en el entorno, además de estas mitigaciones del
sistema operativo, para implementar un conjunto de controles que dificultarán mucho el éxito de los atacantes. Por
ejemplo, los mismos servicios que nos ayudan a detectar cambios de configuración nos ayudarán a detectar indicadores
de compromiso en la nube, casi en tiempo real.
Las mismas capacidades de administración de acceso e identidad que discutimos harán que sea mucho más difícil para
los atacantes usar credenciales robadas para moverse lateralmente. Las técnicas de las que hablamos para ayudar a
mantener los sistemas actualizados dificultarán que los atacantes encuentren y exploten las vulnerabilidades sin parchear.
Tenga en cuenta que, aunque el enfoque Intrusion Kill Chain se presta bien a las soluciones que se crean en entornos
de IaaS, este enfoque es menos útil para las soluciones que se crean utilizando servicios en la nube más arriba en la
pila, como los servicios administrados. En estos casos, los CSP son responsables de proteger el entorno de TI
subyacente, por lo general, dejando menos acceso directo y menos control directo de la infraestructura de TI subyacente
a los equipos de seguridad de sus clientes. Esto no significa que los equipos de seguridad no tengan la visibilidad y el
control que necesitan; es todo lo contrario, como hemos comentado. Sin embargo, los tipos de controles de mitigación
probablemente serán diferentes a las soluciones tradicionales desarrolladas para entornos locales o IaaS.
Los controles deberían ser diferentes porque algunas de las amenazas y riesgos ciertamente son diferentes.
Posteriormente, Intrusion Kill Chain podría no ser el mejor enfoque de puntuación para las organizaciones en la nube,
según los tipos de servicios que utilicen. A medida que las empresas consumen más y más servicios que desdibujan los
límites entre IaaS, PaaS, SaaS, FaaS, IDaaS y otros modelos, menos relevante se vuelve el enfoque de Intrusion Kill
Chain.
Esto no es algo malo, es solo más cambio para abrazar. Recuerde, el papel de los CISO y los equipos de seguridad no
es garantizar el statu quo, es proteger los datos de sus organizaciones, incluso cuando estas organizaciones deciden
que es hora de evolucionar las tecnologías y los procesos que utilizan para seguir siendo competitivos y/o relevantes.
La nube ofrece la oportunidad de modernizar no solo las tecnologías y los procesos, sino también las estrategias de
ciberseguridad que se pueden emplear. Exploremos este concepto un poco más y veamos un enfoque más moderno
de la ciberseguridad que mencioné en el Capítulo 9, Estrategias de ciberseguridad, llamado DevOps.

DevOps: un enfoque moderno de la seguridad en la nube

A falta de un nombre mejor, simplemente llamemos a este enfoque DevOps. También escuché que algunos profesionales
de la seguridad se refieren a ella como "infraestructura inmutable de corta duración" o simplemente como "repavimentación".
Esta estrategia representa un enfoque más moderno en comparación con las otras estrategias de ciberseguridad que
hemos examinado. Reconoce que las disciplinas de desarrollo y operaciones de TI han estado uniendo fuerzas, en parte
porque, juntas, estas funciones están bien posicionadas para aprovechar el poder de las API y la automatización. Debido a
que todo es código en la nube, incluida la infraestructura, los equipos que entienden las operaciones de desarrollo e
infraestructura de TI pueden aprovechar al máximo todo lo que la nube tiene para ofrecer. Veamos algunas de las formas
en que una estrategia de seguridad impulsada por DevOps puede ayudar a los equipos de seguridad a proteger, detectar
y responder a las amenazas modernas en entornos basados en la nube.
Recuerde el Capítulo 4, La evolución del malware, donde describí por qué el ecosistema de Windows
tiene mucho más malware que el ecosistema de Apple iOS. La clave, al parecer, es cómo se ha
distribuido tradicionalmente el software en estos ecosistemas. Microsoft permitió que el software
desarrollado por cualquier persona fuera instalado libremente por sus clientes en sus sistemas basados en Windows.
Apple, por otro lado, proporciona una fuente única para todas las aplicaciones destinadas a dispositivos basados en iOS,
su App Store. Mientras que los clientes de Windows debían tomar sus propias decisiones sobre la confiabilidad del software
que querían ejecutar, Apple impuso un estándar de seguridad que todos los ISV debían cumplir antes de que sus
aplicaciones pudieran distribuirse a dispositivos basados en iOS. Esta diferencia en los métodos de distribución de software,
al menos parcialmente, explica por qué el ecosistema Apple iOS ha mantenido una prevalencia tan baja de malware.
Tomemos esta lección y apliquémosla a nuestro enfoque de la seguridad en la nube. Aprovechar las pruebas
continuas, la integración continua (CI) y la entrega continua o la implementación continua (CD) puede ayudar
a minimizar la cantidad de software cuestionable que llega a los entornos basados en la nube que crean y
operan los clientes de los CSP. En sus canalizaciones de CI/CD, pueden imponer comprobaciones de
seguridad y cumplimiento automatizadas (y manuales). Estos aseguran que cualquier software o infraestructura
que se implemente en entornos de producción a través de estas canalizaciones cumpla con los requisitos de
seguridad y cumplimiento de sus organizaciones.
Para hacer esto, cada paso de la canalización de CI/CD tendrá las verificaciones de seguridad y cumplimiento adecuadas
automatizadas. Por ejemplo, un equipo de DevOps podría desarrollar o adquirir una automatización que busque problemas
contenidos en OWASP Top 10 (OWASP, 2022). Otro ejemplo común es el requisito de realizar análisis de código estático
y/o un conjunto específico de pruebas de seguridad funcional.
La infraestructura tendrá que cumplir con los requisitos de configuración de control definidos por el equipo de cumplimiento
de cada organización, y esto se verificará a medida que los elementos pasen por la canalización.
Capítulo 12 523
La implementación de tales pruebas generalmente se realiza en código y automatización, por lo que la cantidad y los
tipos de controles que se pueden realizar son casi ilimitados. Por supuesto, debido a que esto puede ser efectivo y
divertido, una vez que algunos equipos de DevOps comiencen a desarrollar estas comprobaciones, dedicarán más
tiempo al desarrollo de sus canalizaciones de CI/CD que a las aplicaciones y la infraestructura.
Si un elemento de la aplicación o la infraestructura no pasa una de estas comprobaciones, la canalización se
detendrá, se puede alertar al personal correspondiente, la aplicación o la infraestructura no avanzarán por el resto
de la canalización y no se introducirán en el entorno de producción según lo planeado.
La deficiencia en la aplicación o el elemento de infraestructura deberá abordarse para pasar la verificación que falló
y luego pasar por toda la canalización nuevamente.
De esta forma, solo los elementos que superen todas las comprobaciones de seguridad y cumplimiento del proceso
pasarán a producción. Esto significa que los equipos de Seguridad y Cumplimiento pueden tener mucha confianza
en que todo lo que se introduce en su entorno de producción cumple con todos sus requisitos de seguridad y
cumplimiento y que no introducirán más riesgos en ese entorno. Para lograr esto, todo debe pasar por una
canalización de CI/CD. Dicho de otra manera, la única forma de poner en producción una aplicación o elemento de
infraestructura es a través de una canalización de CI/CD. Para tener la mejor oportunidad de éxito, las organizaciones
deben tener la disciplina, así como los mecanismos de gobierno, para hacer cumplir este requisito. La gestión de
múltiples canalizaciones de CI/CD es un resultado común y predecible, especialmente para organizaciones grandes
y distribuidas. El riesgo para algunas organizaciones es que la cantidad de canalizaciones de CI/CD prolifere a
niveles que comiencen a comprometer los altos estándares de seguridad y cumplimiento que impusieron las
canalizaciones iniciales; demasiadas canalizaciones pueden convertirse en un problema de gobernanza.
Además, tenga en cuenta que los atacantes se han dado cuenta del hecho de que cada vez más organizaciones
utilizan canalizaciones DevOps y CI/CD. Esto convierte a las propias canalizaciones de CI/CD en un objetivo
potencial para los atacantes. Es importante comprender la pila de tecnologías y automatizaciones que utiliza su
organización para sus canalizaciones y tomar medidas para protegerlas. Para algunas organizaciones, las
canalizaciones de CI/CD pueden convertirse en activos de alto valor y merecen una atención especial, como se
explicó en el Capítulo 8, Ingredientes para una estrategia de seguridad cibernética exitosa.
Ahora que los equipos de seguridad y cumplimiento tienen confianza en sus implementaciones, ¿cómo mantienen
esos entornos en ese estado impecable a lo largo del tiempo? Pueden usar los servicios y la automatización que
discutimos anteriormente en este capítulo para monitorear los cambios de configuración. Cuando las configuraciones
cambian, pueden usar la automatización para volver a cumplirlas o imponer investigaciones más profundas sobre
cómo y por qué cambiaron.
Como comentamos anteriormente, existe una gama de opciones para la gestión de vulnerabilidades en la nube.
Continuar utilizando las tecnologías y los procesos que su organización ha utilizado durante años en su entorno local
es probablemente una opción posible.
Sin embargo, el uso de la automatización, como el ejemplo de Auto Scaling que proporcioné anteriormente, tiene el
potencial de simplificar y acelerar la gestión de vulnerabilidades. Otra opción es que las organizaciones evolucionen
desde la administración de servidores y aplicaciones por sí mismas, hasta el uso de servicios en la nube en un nivel
más alto de la pila y dejen los parches de infraestructura a los CSP. Por supuesto, también es permisible una
combinación de todos estos enfoques. Sin embargo, si va a modernizar los procesos, las tecnologías y su estrategia,
le recomiendo encarecidamente que salga del juego de gestión de vulnerabilidades tanto como pueda. Después de
todo, la única forma de ganar ese juego es no jugarlo. Aplique parches a una cantidad relativamente pequeña de
imágenes, no a cientos o miles de máquinas virtuales en ejecución, y use servicios administrados cuando sea posible
para delegar la administración de vulnerabilidades a los CSP.
Una de las razones por las que las estrategias centradas en ataques ganaron tanta popularidad en la industria es que
pueden dificultar el éxito de los actores de amenazas "avanzadas": la llamada amenaza persistente avanzada (APT).
Sin embargo, aquí es donde el poder de las API y los altos niveles de automatización también pueden ser útiles. Por
ejemplo, cuando las organizaciones cierran cuidadosamente subconjuntos de servidores que se ejecutan en la nube
cada pocas horas y los reemplazan por otros nuevos que cumplen con todos los requisitos, puede dificultar que los
atacantes obtengan y mantengan un punto de apoyo en ese entorno. Los sistemas relativamente inmutables y de
corta duración pueden dejar muy poco oxígeno para que lo utilicen los atacantes, a diferencia de los sistemas que
permanecen en funcionamiento durante meses o años.
Las capacidades de detección en la nube son superiores a las que se encuentran en la mayoría de los
entornos locales . Recuerde que el poder de las API y la automatización en la nube brinda visibilidad y control
que pocos entornos locales pueden lograr. La nube puede facilitar el registro de llamadas API, tráfico de red,
operaciones de autenticación y autorización, operaciones de clave de cifrado y descifrado, etc. Sin embargo,
un desafío que comparten la mayoría de los equipos de seguridad, ya sea que usen la nube o no, es que la
gran cantidad de datos en todos estos registros hace que sea casi imposible que los humanos los revisen y
usen de manera oportuna. Aquí es donde la nube también puede ayudar. Los servicios de inteligencia artificial
(IA) y aprendizaje automático (ML) se pueden usar para revisar todos estos registros y la actividad de la API,
en lugar de los miembros del equipo de seguridad, e identificar las cosas que realmente requieren atención
humana. Esto es posible porque los servicios de AI/ML pueden escalar tanto como sea necesario para
procesar enormes conjuntos de datos de registro mucho, mucho más rápido que los humanos. Mientras hacen
esto, estos servicios, con la ayuda de la automatización, pueden detectar y responder a todo tipo de ataques,
incluidos DDoS, malware, explotación de vulnerabilidades, amenazas internas y muchos más.
Capítulo 12 525
Permítanme resumir las características de esta estrategia que llamé DevOps, a veces denominada "infraestructura
inmutable de corta duración" y, a veces, simplemente "repavimentación":
• La automatización se utiliza para aprovisionar y configurar sistemas y otra infraestructura. Todo lo que se
lanza a las cuentas/entornos de la nube de producción debe pasar por una canalización de CI/CD.
• La canalización de CI/CD puede emplear comprobaciones y pruebas de seguridad y cumplimiento manuales

y automáticas para garantizar que todo lo que llega a la producción cumpla con los estándares de
seguridad y cumplimiento. Si algo no cumple con los estándares, la tubería se detiene y las deficiencias
son remediados.
• Los sistemas están diseñados para ser inmutables, es decir, diseñados para no cambiar mientras se ejecutan
en producción. Los cambios en los sistemas inmutables que se ejecutan en producción suelen ser un
indicador de compromiso. Esto hace que la detección de amenazas sea más fácil y rápida.
• Todos los cambios se realizan en las imágenes en las que se basan las instancias en ejecución. Esto
incluye buscar e instalar actualizaciones de seguridad. Las imágenes son escaneadas y parcheadas, no
las instancias en ejecución. Esto reduce drásticamente la complejidad y el tiempo que lleva administrar
las vulnerabilidades en una gran cantidad de sistemas.
• Para minimizar las oportunidades de amenazas internas, los administradores no tienen un enfoque directo
para el acceso de seguridad cibernética a los sistemas que se ejecutan en producción. Se prohíbe la
ejecución de SSH, RDP y otro software de acceso remoto en los sistemas de producción. Los
administradores están limitados a ejecutar scripts probados y preaprobados en sistemas que se ejecutan
en producción, excepto durante escenarios de ruptura de vidrio que son monitoreados y auditados. MFA
se utiliza para autenticar a los administradores en la nube, donde pueden iniciar la ejecución de estos scripts.
• La automatización se utiliza para cerrar cuidadosamente los sistemas de producción cada pocas horas de
manera que no afecte la disponibilidad de las aplicaciones. Auto Scaling u otra automatización reiniciará
los sistemas en función de las imágenes totalmente parcheadas a medida que se necesiten. Esto reduce
y limita la cantidad de tiempo que los atacantes pueden utilizar los sistemas comprometidos en el entorno
de producción.
• Los servicios administrados se utilizan para mejorar las capacidades de detección y respuesta en lugar de
implementar más sistemas para albergar funciones de seguridad. Esto proporciona capacidades superiores
de detección y respuesta y no aumenta la superficie de ataque ni la cantidad de sistemas.
administrar.
• Hacer uso de capacidades de cifrado omnipresentes para proteger los datos en la nube y proteger las claves.
Discutiré esto más adelante en este capítulo.
• Tenga en cuenta que aunque me he centrado en el uso de máquinas virtuales en esta descripción de la estrategia,
un número cada vez mayor de organizaciones aprovechan los contenedores y el software de orquestación de
contenedores de formas muy similares para lograr una mejor seguridad.
Finalmente, si todas estas capacidades fallaron en proteger, detectar y responder a los atacantes, DevOps y la nube
pueden hacer que la recuperación de los entornos de producción sea mucho más fácil que en los entornos locales
típicos. Dado que todo es código, la reconstrucción de entornos en la nube puede ser relativamente fácil si se ha
realizado una planificación y una preparación cuidadosa. Echemos un vistazo rápido a algunas capacidades de
recuperación ante desastres (DR) en la nube.
Recuperación ante desastres en la nube

Como discutimos en el Capítulo 4, La evolución del malware, los ataques dirigidos que involucran extorsión (también
llamados ataques de ransomware) son comunes hoy en día. El ransomware es un desastre provocado por el hombre.
Posteriormente, la mayoría de los CISO y los equipos de seguridad con los que he hablado en los últimos años están
mucho más interesados que nunca en DR. Además del espectro del ransomware, el temor a una mayor frecuencia de
fenómenos meteorológicos extremos, debido al cambio climático, también está generando interés en DR.
DR es "el proceso de proporcionar una recuperación rápida y confiable de los sistemas de TI para minimizar el tiempo
de inactividad y la pérdida de datos" (Rains, 2022). El enfoque tradicional de DR ha llevado a muchas organizaciones a
construir centros de datos físicos con distancias específicas entre ellos. Si un centro de datos se ve afectado por un
evento meteorológico, una interrupción del suministro eléctrico o un desastre provocado por el hombre, la organización
planea reanudar las operaciones de TI en otro centro de datos. La distancia entre los centros de datos es arbitraria
porque no existe un estándar de la industria: cada organización realiza sus propios cálculos en función de los tipos de
riesgos que intenta mitigar. Pero, en general, cuanto mayor sea la distancia entre los centros de datos, es menos
probable que los afecte un solo evento meteorológico, un terremoto, un incendio o una interrupción del suministro eléctrico.
En la nube, como mencioné anteriormente, las regiones y las zonas de disponibilidad se utilizan para diseñar
infraestructuras en la nube resistentes y de alta disponibilidad. La distancia entre los centros de datos en una zona de
disponibilidad puede ser lo suficientemente grande como para mitigar cortes de energía localizados y eventos climáticos a gran escala.
Para las organizaciones que desean aún más seguridad, pueden usar varias regiones y obtener las ventajas de usar
incluso más zonas de disponibilidad que tienen mayores distancias entre ellas. Por ejemplo, una organización podría
usar una región en la nube ubicada en la costa oeste de los EE. UU. y planear usar una región en la costa este para DR.
Las posibilidades de que un solo evento interrumpa las operaciones en ambos lados del país al mismo tiempo son muy
bajas. Muchas grandes empresas multinacionales utilizan Regiones en la nube en diferentes países para diversos fines,
incluso para fines de recuperación ante desastres.

Capítulo 12 527
Por ejemplo, aprovechan una región en la nube en la costa este de los EE. UU. y otra región en Irlanda para
propósitos de recuperación ante desastres. Dado que hay tantas regiones y zonas disponibles disponibles, hay
muchas opciones diferentes para fines de recuperación ante desastres. Sin embargo, recuerda que la velocidad
de la luz es una constante. Cuanto mayor sea la distancia entre los centros de datos, más latencia de red se
convertirá en un factor limitante.
Cuando trabajé en AWS, escribí una publicación de blog sobre cómo piensan sobre las distancias entre sus
centros de datos y las zonas de disponibilidad para fines de recuperación ante desastres. Si está interesado en
leerlo, esa publicación de blog se titula "La zona Goldilocks para la recuperación ante desastres, la planificación
de la continuidad del negocio y la preparación ante desastres". Está disponible en esta URL: https://aws.amazon.com/blogs/
publicsector/goldilockszonedisasterrecoverybusinesscontinuityplanning
preparación para desastres/.
La nube ofrece a las organizaciones la capacidad de aprovechar todas las arquitecturas DR clásicas, incluidas las
de copia de seguridad y restauración, Pilot Light, Warm Standby y MultiSite Active/Active. Por ejemplo,
implementar un diseño de Pilot Light es relativamente fácil porque todo es código. Duplicar su entorno de nube de
producción, cuando sea necesario, es tan simple como usar código y automatización desarrollados y probados
previamente para reaprovisionar y configurar toda la infraestructura de nube existente en una zona o región de
disponibilidad diferente. Gran parte puede estar en una cuenta en la nube aprovisionada, pero no en un estado de
ejecución. Por lo general, los clientes no pagarán por esta infraestructura hasta que esté en funcionamiento . Una
vez que la infraestructura está en funcionamiento como se esperaba, tal vez en unos pocos minutos (según la
complejidad), se cambian los registros DNS apropiados para que apunten a la nueva infraestructura. Esto es un
poco simplificado, pero es mucho menos complicado y costoso que adquirir bienes raíces para centros de datos,
realizar proyectos de construcción para construir centros de datos, adquirir las infraestructuras de energía y
energía de respaldo adecuadas, adquirir, implementar y operar toda la infraestructura de TI, pagar impuestos
inmobiliarios cada año, etc.
Tenga la seguridad de que si desea implementar DR como parte de una estrategia de protección y
recuperación, una estrategia centrada en ataques, una estrategia DevOps u otras estrategias en la nube,
tiene mucha flexibilidad y opciones a su disposición gracias al poder de las API y la automatización en la
nube. La clave para elegir qué arquitecturas DR usar debe basarse en los objetivos de punto de recuperación
(RPO) y los objetivos de tiempo de recuperación (RTO) para cada aplicación dentro del alcance de sus
planes DR. Defínalos y luego diseñe arquitecturas DR que puedan lograrlos por usted.
AWS publicó una buena serie de publicaciones de blog que puede proporcionar más información llamada "Recuperación ante desastres
(DR) Arquitectura en AWS”:
• Parte 1: https://aws.amazon.com/blogs/architecture/disasterrecoverydr
arquitecturaenawsparteiestrategiasparalarecuperaciónenlanube/
arquitecturaenawsparteiirespaldoyrestauraciónconrecuperaciónrápida/
arquitecturaenawsparteiiipilotlightandwarmstandby/
arquitecturaenawsparteivmultisitioactivoactivo/
Con esto concluye este apartado sobre estrategias de ciberseguridad en la nube. Sin embargo, antes de que
lleguemos al final de este capítulo y de este libro, quiero resaltar otro conjunto importante de capacidades que
ofrece la nube: el cifrado y la gestión de claves.
Cifrado y gestión de claves

En mi experiencia, la mayoría de las conversaciones sobre seguridad en la nube concluyen discutiendo el
cifrado y la gestión de claves. Independientemente de los temas con los que comience una conversación,
como vulnerabilidades, exploits, malware, amenazas basadas en Internet o acceso gubernamental a los datos,
concluyen discutiendo el cifrado y la gestión de claves. Esto se debe a que se reconoce y se ha demostrado
que el cifrado es un poderoso control de protección de datos que ayuda a proporcionar confidencialidad e
integridad para los datos, ya sea en la nube, en entornos híbridos o en las instalaciones.
No importa qué estrategia de seguridad cibernética o combinación de estrategias sigan las organizaciones,
cuando el caucho sale a la carretera, el objetivo es proteger los datos. Eso es lo que puede distraer tanto de
las estrategias de seguridad cibernética que examinamos que son sustitutos de la protección de datos. Los
equipos de seguridad se concentran tanto en proteger los puntos finales o las aplicaciones que pueden perder
de vista que el objetivo subyacente es proteger los datos. Los proxies que mencioné son importantes y deben
administrarse de manera efectiva, ¡pero no se olvide de los datos!
Todos los CSP saben esto y ofrecen a sus clientes conjuntos completos de capacidades de encriptación y
administración de claves. Su objetivo es proteger los datos cuando están en tránsito y en reposo. TLS
(actualmente versión 1.3) es el estándar de Internet de facto para proteger los datos en tránsito. Posteriormente,
los CSP admiten TLS, además de proporcionar otros mecanismos para proteger los datos en tránsito, como
conexiones VPN o conectar directamente sus infraestructuras en la nube a las redes de sus clientes, por ejemplo.
Capítulo 12 529
Como mencioné en el Capítulo 7, Acceso gubernamental a los datos, los CSP ofrecen una variedad de opciones
de cifrado para proteger los datos en reposo, lo que permite a sus clientes cifrar los datos antes de colocarlos en la
nube (en algunos escenarios) y/o después de colocarlos en la nube. Recuerde la diferencia entre el cifrado del lado
del cliente y el cifrado del lado del servidor. El estándar de cifrado actual que ofrecen los CSP para cifrar datos en
reposo es el Estándar de cifrado avanzado (AES), que normalmente utiliza longitudes de clave de 128 o 256 bits.
Si un atacante tuviera acceso a los datos (el acceso generalmente se autentica y autoriza) protegidos por AES256,
romper este tipo de cifrado utilizando técnicas de fuerza bruta y mucha potencia informática convencional
probablemente tomaría mucho más tiempo que el valor de vida útil de los datos.
Un matiz importante que deben comprender los equipos de seguridad es exactamente qué se está cifrando y qué
riesgos mitiga ese tipo de cifrado. Por ejemplo, si el medio de almacenamiento subyacente está encriptado, pero
los datos que se escriben en el medio no están encriptados antes de escribirse, entonces los riesgos que se mitigan
son la pérdida o el robo del medio de almacenamiento. Los medios de almacenamiento cifrados ayudan a mitigar
los ataques en los que los atacantes tienen acceso físico a los medios de almacenamiento. Si alguien obtiene
acceso físico a los medios de almacenamiento cifrados pero no posee las claves para montarlos y descifrarlos, los
datos escritos en ellos están protegidos contra el acceso no autorizado. Sin embargo, si los atacantes buscan
acceder a los datos de forma lógica en lugar de físicamente, a través de una red, por ejemplo, es probable que el
cifrado a nivel de almacenamiento no mitigue este riesgo porque los datos se descifran a medida que se accede a ellos desde la red.
Es importante comprender el riesgo específico que debe mitigarse y las mitigaciones específicas para ese riesgo
en particular, a fin de tener la confianza de que el riesgo realmente se ha mitigado.
Si el deseo es evitar el acceso no autorizado a los datos en reposo, a través de una red, cifrar los datos en sí, en
lugar de solo los medios de almacenamiento, será una mitigación más efectiva. Esto puede sonar obvio, pero es un
error común que cometen los equipos de seguridad durante la seguridad de las aplicaciones.
evaluaciones
Además de ofrecer opciones de cifrado de datos, los CSP realmente proporcionan cifrado de datos autenticado y
autorizado. Es decir, cada llamada API de operación de cifrado se autentica y debe ser autorizada; las operaciones
de cifrado y descifrado no se realizarán sin haber sido autenticadas y autorizadas primero. El uso de los servicios
de Identidad y Acceso de esta manera brinda a los equipos de seguridad mucha flexibilidad. Por ejemplo, una
persona o grupo de personas puede estar autorizado para cifrar datos, pero no para descifrarlos. A otro grupo se le
pueden otorgar permisos para descifrar datos, pero no para realizar operaciones de cifrado y descifrado. El cifrado
autenticado y autorizado permite una separación de funciones que puede ser útil en muchos escenarios.
Para muchas organizaciones, una de las partes más desafiantes del cifrado puede ser la administración de claves.
Hay mucho en juego porque si las claves de una organización se dañan, se pierden o se las roban, podría tener
un impacto catastrófico en ellas. En términos generales, los CSP desean que la administración de claves sea fácil
y segura para sus clientes. Google ofrece Cloud Key Management Service (Google, 2020), Microsoft ofrece Azure
Key Vault (Microsoft Corporation, 2020) y AWS proporciona AWS Key Management Service (AWS, 2020). Por
supuesto, existen proveedores externos que también ofrecen servicios de administración de claves y encriptación,
como Thales, Equinix y otros.
Los servicios de gestión de claves de los CSP pueden ofrecer una ventaja interesante, ya que pueden integrarse
en sus otros servicios en la nube. Esto significa que algunos servicios en la nube pueden realizar el cifrado y
descifrado en nombre de los usuarios. La ventaja de la protección de datos aquí es que los datos pueden
protegerse mediante el cifrado AES hasta que estén en la memoria física de los servidores que ejecutan el servicio
que los procesará. Una vez que se completa el procesamiento, el servicio puede volver a cifrar los datos antes de
moverlos al almacenamiento u otros servicios para un mayor procesamiento. Las claves utilizadas para el cifrado
y descifrado pueden protegerse en tránsito entre los servicios de gestión de claves y los servicios que las utilizan.
Esto significa que los datos sin cifrar solo ven la luz del día en entornos altamente controlados que están
autorizados por el propietario de los datos. Esto puede ayudar a maximizar la cantidad de lugares y el tiempo que
los datos están protegidos con cifrado. Los servicios de administración de claves de los CSP tienden a estar
diseñados para baja latencia y alta disponibilidad a fin de procesar miles de millones de solicitudes.
Algunas organizaciones desean una separación de funciones entre el proveedor que utilizan para la computación y
el almacenamiento y los proveedores que brindan servicios de administración clave. Los proveedores externos que
ofrecen servicios de gestión de claves pueden desempeñar esta función, o los propios clientes de los CSP pueden
operar y mantener sus propias infraestructuras de gestión de claves. Las organizaciones que eligen esta opción
deben sentirse cómodas administrando su propia infraestructura de administración de claves o permitiendo que un
tercero lo haga por ellas. Sin embargo, administrar módulos de seguridad de hardware (HSM) e infraestructuras de
clave pública (PKI) es notoriamente difícil. Esto hace que el uso de los servicios de administración de claves de los
CSP sea una opción popular.
Para las organizaciones que necesitan mantener sus claves en las instalaciones pero que aún desean obtener los
beneficios de la nube, el cifrado del lado del cliente es una solución potencial. El uso del cifrado del lado del cliente
significa que el propietario de los datos cifra los datos antes de colocarlos en un servicio en la nube. Por ejemplo,
el propietario de los datos tiene su propia infraestructura de administración de claves local. Antes de colocar los
datos en un servicio de almacenamiento en la nube, generan una clave en las instalaciones y luego usan una
aplicación que también se ejecuta en las instalaciones para cifrar los datos con esta clave. Luego, autentican y
transfieren de forma segura los datos cifrados al servicio de almacenamiento en la nube. En este escenario, su
CSP nunca tuvo acceso a sus datos no cifrados ni a la clave de cifrado, ya que ninguno abandonó el entorno de TI local.
Capítulo 12 531
Para descifrar estos datos, el propietario de los datos se autentica en el servicio de almacenamiento en la
nube, descarga de forma segura los datos cifrados y usa su aplicación local y su clave local para descifrar
los datos. Una vez más, ni los datos no cifrados ni la clave de cifrado se compartieron nunca con el CSP.
El cifrado del lado del cliente no se limita a escenarios de almacenamiento; se puede utilizar con otros servicios,
como bases de datos, por ejemplo. En este escenario, el cifrado del lado del cliente se usa para cifrar registros
o campos individuales a medida que se escriben en un servicio de base de datos que se ejecuta en la nube.
Para ello, se recupera una clave de cifrado del sistema de gestión de claves local y la aplicación que realiza el
cifrado la utiliza temporalmente para operaciones de cifrado. Una vez que el registro se cifra tal como se escribe
en la base de datos, la clave de cifrado se puede eliminar de la memoria de la aplicación que realizó la
operación de cifrado, lo que reduce el tiempo que la clave reside en un sistema fuera del sistema de
administración de claves local. La aplicación que realiza operaciones de cifrado y descifrado en los registros de
la base de datos puede ejecutarse localmente o en la nube. Dado que el cliente del CSP tiene el control total
de las claves, el CSP no puede obtener acceso a las claves a menos que el cliente le conceda acceso. Los
índices y las claves de la base de datos se dejan sin cifrar para que aún se pueda realizar la indexación y la
búsqueda en la base de datos. Por este motivo, es importante no introducir datos confidenciales en estos
campos. Para descifrar los datos, los registros apropiados se recuperan y descifran después de proporcionar la
clave desde el sistema de administración de claves local. Después de la operación de descifrado, la clave se
puede volver a eliminar de la memoria de la aplicación que realiza la operación de descifrado.
Hay muchas formas diferentes de realizar el cifrado del lado del cliente y la administración de claves. Sin
embargo, este método puede ser más complicado y costoso de implementar que simplemente usar los servicios
integrados de encriptación y administración de claves que ofrecen los CSP. Algunas organizaciones que
comienzan usando el cifrado del lado del cliente con claves guardadas en las instalaciones, con el tiempo
concluyen que el uso de los servicios de administración de claves de los CSP mitiga los riesgos que más les
preocupan y ayuda a simplificar sus aplicaciones. Después de todo, las operaciones de cifrado y descifrado en
la nube se realizan mediante llamadas API que se autentican, autorizan, supervisan y controlan potencialmente
mediante la automatización, como comentamos anteriormente.
Los CSP desean brindar a sus clientes la confidencialidad e integridad que brinda el cifrado del lado del cliente,
sin la complejidad y los costos adicionales. Después de todo, mover material clave entre entornos de TI locales
y entornos de nube también tiene riesgos asociados y no mejora el rendimiento de la aplicación, especialmente
a escala. Los CSP ofrecen alternativas sofisticadas al cifrado del lado del cliente que también pueden ayudar a
mitigar las amenazas internas en muchos escenarios.
La siguiente lista contiene algunos ejemplos:
• El sistema AWS Nitro: https://aws.amazon.com/ec2/nitro/
• Enclaves AWS Nitro: https://aws.amazon.com/ec2/nitro/nitroenclaves/
• Los procesadores AWS Graviton2 cuentan con cifrado DRAM de 256 bits siempre activo: https://docs.
aws.amazon.com/AWSEC2/latest/UserGuide/dataprotection.html
• Descripción general del cifrado de Azure: https://learn.microsoft.com/enus/azure/security/
fundamentos/descripción general del cifrado
• Informática confidencial de Azure: https://azure.microsoft.com/enus/solutions/
cómputo confidencial/#resumen
• Cifrado de datos en la nube de Google: https://cloud.google.com/security/encryption
• Informática confidencial de Google: https://cloud.google.com/blog/products/

identidadseguridad/introduccióngooglecloudconfidentialcomputingwith
confidencialvms
La combinación de un cifrado implementado correctamente y una administración de claves eficaz, junto con el poder
de las API y la automatización en la nube, ayuda a proteger los datos de formas que serían más complejas de
duplicar en entornos de TI locales. El cifrado y la administración de claves ayudan a proteger los datos de muchas
de las amenazas que analizamos a lo largo de este libro; son poderosos controles de protección de datos que
deben ser parte de cualquier estrategia de ciberseguridad que persiga su organización.
Conclusión
Para las organizaciones que aún no han adoptado la nube, o que no lo harán a favor de sus entornos de TI locales,
me viene a la mente una cita:
El futuro ya está aquí, solo que no está distribuido uniformemente”.
— (Gibson, 2003)
La oportunidad de aprovechar el poder de las API y la automatización de la nube a una escala nunca antes
imaginada está esperando a todas las organizaciones. Estos cambios de juego no solo facilitan mucho el
aprovisionamiento, la configuración, el funcionamiento y el desaprovisionamiento de aplicaciones e infraestructura
de TI, sino que también brindan a los profesionales de seguridad y cumplimiento la visibilidad y el control que
probablemente no hayan tenido en el pasado. Animo a los CISO y a los equipos de seguridad a adoptar la nube
como una forma de hacer más con menos y compensar la escasez perpetua de talento en ciberseguridad de la industria.
Capítulo 12 533
Resumen
Este capítulo presentó algunos de los beneficios de seguridad y cumplimiento de la computación en la
nube. Centré mi discusión en las capacidades básicas de los CSP más populares del mundo, es decir,
de Amazon Web Services, Google y Microsoft.
El modelo de infraestructura física alrededor del cual los CSP de hiperescala se han fusionado se basa en el concepto
de regiones y zonas de disponibilidad. Este concepto es que una zona de disponibilidad es un clúster de centros de
datos y una región es un clúster de zonas de disponibilidad. Existen diferencias significativas en el tamaño y el
alcance de las infraestructuras de los CSP y cómo aprovechan los componentes de este modelo. Aunque los
términos IaaS, PaaS y SaaS todavía se usan ampliamente en la actualidad, se están volviendo obsoletos lentamente.
Los servicios más nuevos que resuelven problemas específicos pueden desdibujar las líneas entre los modelos de
servicio IaaS, PaaS y SaaS, haciéndolos menos importantes.
Los CSP son diferentes de los proveedores de servicios gestionados (MSP) tradicionales en algunos aspectos clave.
Es importante que los ejecutivos reconozcan esto cuando contemplan por primera vez el uso de la nube para evitar
confusiones que los retrasen. Los MSP que se basan en las ofertas de los CSP continúan desempeñando un papel
importante para sus clientes y la industria.
En este capítulo, analicé dos cambios de juego de seguridad y cumplimiento que ofrece la nube:
• El poder de las interfaces de programación de aplicaciones (API)
• Las ventajas de la automatización
Cada interacción con la nube a través de consolas de administración, CLI y aplicaciones se realiza mediante API.
Las API proporcionan el cuello de botella perfecto para la visibilidad y el control. Si las organizaciones pueden
monitorear sus llamadas API y tomar medidas en función de lo que sucede, tendrán mayor visibilidad y control. Para
aprovechar al máximo el poder de las API, la nube ofrece altos niveles de automatización. Además de ejecutar
comandos CLI, puede automatizar flujos de trabajo complejos mediante scripts, plantillas, aplicaciones y servicios en
la nube. La automatización en la nube puede ayudar a abordar los fundamentos de la ciberseguridad de maneras
que son potencialmente más eficientes que en los entornos de TI tradicionales.
La nube es lo suficientemente flexible como para soportar casi cualquiera de las estrategias de seguridad cibernética
que analizamos en el Capítulo 9, Estrategias de seguridad cibernética. DevOps ofrece un enfoque más moderno en
comparación con las otras estrategias de ciberseguridad que examinamos. Debido a que todo es código en la nube,
incluida la infraestructura, los equipos que entienden tanto el desarrollo como las operaciones de infraestructura de
TI pueden aprovechar al máximo todo lo que la nube tiene para ofrecer.

Las canalizaciones de integración continua (CI), entrega continua e implementación continua (CD) pueden
tener las comprobaciones de seguridad y cumplimiento adecuadas automatizadas en ellas; por ejemplo,
el OWASP Top 10 (OWASP, 2020).
Espero que haya encontrado útil esta segunda edición de mi libro. En este libro, traté de cubrir los temas que
los CISO y los equipos de seguridad querían discutir conmigo con mayor frecuencia, en mi rol como asesor
de seguridad cibernética en dos de las empresas de tecnología líderes en el mundo. Traté de empaquetar
este libro con datos, marcos útiles y conocimientos que potencialmente ayudarán a los CISO, aspirantes a
CISO y otros profesionales de la ciberseguridad a comprender mejor algunos aspectos clave de la
ciberseguridad y ayudarlos a tomar mejores decisiones. Por supuesto, el panorama de las amenazas seguirá
evolucionando y espero que algo de lo que he escrito aquí ayude a las organizaciones a navegar por él.
¡Buen viaje!
Referencias
• AICPA. (Dakota del Norte). SOC 2® SOC para Organizaciones de Servicios: Criterios de Servicios
de Confianza. Obtenido de AICPA: https://www.aicpa.org/interestareas/frc/assuranceadvisoryservices/
aicpasoc2report.html
• Servicios web de Amazon. (marzo de 2020). Computación en la nube con AWS. Obtenido de AWS:
https://aws.amazon.com/queesaws
• Ansible. (abril de 2020). Red Hat Ansible. Obtenido de Red Hat Ansible: https://www.
ansible.com/
• AWS. (20 de octubre de 2016). Gestión de flotas simplificada con Auto Scaling. Obtenido de AWS
Compute Blog: https://aws.amazon.com/blogs/compute/fleetmanagement
hechofácilconescalaautomática/
• AWS. (abril de 2020). Referencia de la API de Amazon Elastic Compute Cloud. Obtenido de
AWS: https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_RunInstances.html
• AWS. (abril de 2020). Formación en la nube de AWS. Obtenido de AWS: https://aws.amazon.com/
formación de nubes/
• AWS. (abril de 2020). AWS Cloud Trail. Obtenido de AWS: https://aws.amazon.com/

rastro de nubes/
• AWS. (abril de 2020). Servicio de administración de claves de AWS (KMS). Obtenido de AWS: https://
aws.amazon.com/kms/
• AWS. (abril de 2020). Administrador de secretos de AWS. Obtenido de AWS: https://aws.amazon.com/

administrador de secretos/
Capítulo 12 535
• AWS. (abril de 2020). Registro de llamadas a la API de AWS Systems Manager con AWS
CloudTrail. Obtenido de AWS: https://docs.aws.amazon.com/systemsmanager/latest/userguide/
monitorizacióncloudtraillogs.html
• AWS. (abril de 2020). Ejecute comandos de forma remota en una instancia EC2. Obtenido de AWS: https://
aws.amazon.com/gettingstarted/handson/remotelyruncommandsec2
administradordesistemasdeinstancias/
• AWS. (abril de 2020). Uso de la CLI de AWS. Obtenido de AWS: https://docs.aws.amazon.

com/cli/latest/userguide/clichapusing.html
• Cocinero. (abril de 2020). Cocinero. Obtenido de Chef: https://www.chef.io/products/chef
infra/
• Hutchins, EM, Cloppert, MJ, Amin, RM (nd). Defensa de redes informáticas impulsada por
inteligencia informada por análisis de campañas adversarias y cadenas de destrucción de
intrusos. Obtenido de Lockheed Martin: https://lockheedmartin.com/content/dam/lockheedmartin/
• Gibson, W. (4 de diciembre de 2003). Libros del año. El economista. •
Google. (abril de 2020). Registros de auditoría en la nube. Obtenido de Google Cloud: https://cloud.
google.com/logging/docs/auditoría
• Google. (abril de 2020). Servicio de gestión de claves en la nube. Obtenido de Google Cloud:
https://cloud.google.com/kms/
• Google. (abril de 2020). Compositor en la nube. Obtenido de Google Cloud: https://cloud.
google.com/compositor
• Google. (22 de enero de 2020). Presentamos el administrador secreto de Google Cloud.
Obtenido del blog de Google Cloud: https://cloud.google.com/blog/products/identitysecurity/
introduccióngooglecloudssecretmanager
• Google. (Dakota del Norte). creación de instancias informáticas de gcloud. Obtenido de Google: https://nube.
google.com/sdk/gcloud/reference/compute/instances/create
• Hashicorp. (abril de 2020). Terraformar. Obtenido de Terraform por Hashicorp: https://
www.terraform.io/
• Corporación Microsoft. (18 de octubre de 2018). Una introducción a la automatización de Azure. Obtenido
de Microsoft Azure: https://docs.microsoft.com/enus/azure/automation/
Introducción a la automatización
• Corporación Microsoft. (7 de octubre de 2019). Introducción a Azure Monitor. Obtenido de Microsoft

Azure: https://docs.microsoft.com/enus/azure/azuremonitor/overview
• Corporación Microsoft. (marzo de 2020). Productos Azure. Obtenido de Microsoft Azure:

https://azure.microsoft.com/enus/services/
• Corporación Microsoft. (abril de 2020). Bóveda de llaves. Obtenido de Microsoft Azure: https://
azure.microsoft.com/enus/services/keyvault/
• Corporación Microsoft. (abril de 2020). Administre secretos en sus aplicaciones de servidor con Azure Key Vault.
Obtenido de Microsoft Learn: https://docs.microsoft.com/enus/learn/modules/

administrarsecretosconazurekeyvault/
• Corporación Microsoft. (abril de 2020). Máquinas virtuales Inicio. Obtenido de

Microsoft Corporation : https://docs.microsoft.com/enus/rest/api/compute/virtualmachines/
comenzar
• Corporación Microsoft. (4 de noviembre de 2022). ¿ Qué es la administración de identidades con

privilegios de Azure AD? Obtenido de Microsoft Azure: https://docs.microsoft.com/enus/azure/
directorio activo/privilegedidentitymanagement/pimconfigure
• INGLETE. (9 de octubre de 2019). Matriz de nubes. Obtenido de MITRE ATT&CK®: https://

attack.mitre.org/matrices/enterprise/cloud/
• OWASP. (2022). Los 10 principales riesgos de seguridad de las aplicaciones web. Obtenido de OWASP: https://
owasp.org/wwwprojecttopten/
• Marioneta. (abril de 2020). Empresa de marionetas. Obtenido de Puppet: https://puppet.com/

productos/empresatítere/
• El BSI. (25 de enero de 2018). Catálogo de controles de cumplimiento de computación en la nube.
Obtenido de la Oficina Federal de Seguridad de la Información: https://www.bsi.bund.de/SharedDocs/
Descargas/ES/BSI/Publicaciones/CloudComputing/ComplianceControlsCatalogo
Computación_en_la_nubeC5.html
• Lluvias, T. (31 de enero de 2022). La zona Goldilocks para la recuperación ante desastres, la planificación de la
continuidad del negocio y la preparación ante desastres. Obtenido del blog del sector público de AWS: https://aws.
amazon.com/blogs/publicsector/goldilockszonedisasterrecoverybusinesscontinuityplanning
disasterpreparedness/ _
Capítulo 12 537

packt.com
Suscríbase a nuestra biblioteca digital en línea para obtener acceso completo a más de 7000 libros y videos, así como
herramientas líderes en la industria para ayudarlo a planificar su desarrollo personal y avanzar en su carrera. Para obtener
más información, por favor visite nuestro sitio web.
¿Por qué suscribirse?

• Pase menos tiempo aprendiendo y más tiempo codificando con prácticos libros electrónicos y videos de
más de 4.000 profesionales de la industria
• Mejore su aprendizaje con planes de habilidades creados especialmente para usted
• Obtenga un libro electrónico o un video gratis todos los meses
• Completamente investigable para un fácil acceso a información vital
• Copiar y pegar, imprimir y marcar contenido
En www.packt.com, también puede leer una colección de artículos técnicos gratuitos, suscribirse a una variedad de boletines
gratuitos y recibir descuentos y ofertas exclusivos en libros y libros electrónicos de Packt.

Otros libros que puede disfrutar
Si disfrutó de este libro, es posible que le interesen estos otros libros de Packt:
El manual de seguridad cibernética para empresas modernas
Jeremy Wittkop
ISBN: 9781803248639
• Comprender las macroimplicaciones de los ataques cibernéticos

• Identifique usuarios maliciosos y evite daños a su organización • Descubra
cómo se producen los ataques de ransomware • Trabaje
con técnicas emergentes para mejorar los perfiles de seguridad • Explore la
gestión de identidades y accesos y la seguridad de terminales • Familiarícese
con la creación de modelos de automatización avanzados • Cree
programas de capacitación efectivos para protegerse contra las técnicas de piratería •
Descubra las mejores prácticas para ayudarlo a usted y a su familia a mantenerse seguros en línea
542 Otros libros que puede disfrutar
Manual de derecho de ciberseguridad y privacidad
walter rocchi
ISBN: 9781803242415
• Fortalecer la postura de ciberseguridad en toda su organización
• Use tanto ISO27001 como NIST para crear un mejor marco de seguridad
• Comprender las leyes de privacidad como GDPR, PCI CSS, HIPAA y FTC
• Descubra cómo implementar la formación para aumentar la concienciación sobre ciberseguridad
• Descubra cómo cumplir con las normas de privacidad en la nube
• Examinar las complejas leyes de privacidad en los EE. UU.

Otro libro que puede disfrutar 543
Ciberseguridad: estrategias de ataque y defensa, tercera edición
Yuri Diógenes
Dr. Erdal Ozkaya
ISBN: 9781803248776
• Aprenda a mitigar, recuperarse y prevenir futuros eventos de ciberseguridad
• Comprender la higiene de la seguridad y el valor de priorizar la protección de sus cargas de trabajo •
Explorar la segmentación de redes físicas y virtuales, la visibilidad de la red en la nube y Zero

Consideraciones de confianza
• Adoptar nuevos métodos para recopilar inteligencia cibernética, identificar riesgos y demostrar el impacto
con estrategias del Equipo Rojo/Azul
• Explora herramientas legendarias como Nmap y Metasploit para mejorar tu Red Team
• Descubra la seguridad de la identidad y cómo realizar la aplicación de políticas
• Integre sistemas de detección de amenazas en sus soluciones SIEM
• Descubra MITRE ATT&CK Framework y herramientas de código abierto para recopilar inteligencia
544 Otros libros que puede disfrutar
Packt está buscando autores como tú

Si está interesado en convertirse en autor de Packt, visite authors.packtpub.com y presente su solicitud hoy.
Hemos trabajado con miles de desarrolladores y profesionales de la tecnología, como usted, para ayudarlos
a compartir sus conocimientos con la comunidad tecnológica mundial. Puede hacer una solicitud general ,
postularse para un tema candente específico para el cual estamos reclutando un autor o enviar su propia idea.
Comparte tus pensamientos

Ahora que ha terminado Amenazas de ciberseguridad, tendencias y estrategias de malware, segunda
edición, ¡ nos encantaría escuchar sus opiniones! Si compró el libro en Amazon, haga clic aquí para ir
directamente a la página de reseñas de Amazon de este libro y compartir sus comentarios o dejar una
reseña en el sitio donde lo compró.
Su revisión es importante para nosotros y para la comunidad tecnológica y nos ayudará a asegurarnos de que
ofrecemos contenido de excelente calidad.
Índice
Estimación de puntaje CFSS 361

A
desventajas 362
Acciones sobre objetivos Programación de aplicaciones
ATT&CK, conocimientos 455457 Interfaces (API) 503
controles, ejemplos 454 ejemplo 503508
Protocolo de resolución de direcciones (ARP) 135 Tienda de aplicaciones 123
Disposición del espacio de direcciones Informe de tendencias de actividad de phishing del APWG 199
Aleatorización (ASLR) 415
Inteligencia Artificial (IA) 32, 209, 480, 524
capacidades avanzadas de ciberseguridad 313
Seguridad Patrimonial
Estándar de cifrado avanzado (AES) 529
464 activos bajo gestión
Amenaza persistente avanzada (APT) 10, 524 Enlace de versus activos totales 466468
referencia de planes de emulación Estrategia centrada en el ataque 374376

de adversario 490
ventajas 378
soluciones antimalware Estimación de puntaje CFSS 377
habilidad, debate 183, 184 desventajas 378
Grupo de trabajo contra el phishing (APWG) 198 rendimiento y eficacia, midiendo 474 usando, en la nube
520, 521
Apple iOS 123
motivaciones de los atacantes
frente a Google Android 93
frente a las tácticas de los atacantes 1720
Tendencias de vulnerabilidad de Apple iOS 91, 92
fase de ataque
Apple macOS
frente a Microsoft Windows 10 97 Acciones sobre Objetivos 453, 454
Comando y Control (C2) 443, 444
Tendencias de vulnerabilidad de Apple macOS 9597
Entrega 422424
Tendencias de vulnerabilidad de Apple Safari 103, 104
Explotación 427, 428
Tendencias de vulnerabilidad de Apple 8385 Instalación 432434
estrategia centrada en la aplicación 359, 360 Reconocimiento I 417420
ventajas 361 Reconocimiento II 448, 449

546 Índice
Marco ATT&CK 421 Seguridad de Sistemas de Información Certificados

referencias 490 Certificación profesional (CISSP) 464
técnicas 421, 426, 427, 430, 431, 436443, 446, 447, 451, Jefe de Seguridad de la Información
452, 455457 Oficiales (CISO) 165
usando, para emulaciones adversarias 489, 490 tipos 36
frente al marco Intrusion Kill Chain 399, 404, 405 Aclaración del uso lícito de datos en el extranjero
(NUBE) Ley 262267
Táctica ATT & CK
cifrado del lado del cliente
referencias 421
ejemplos 531, 532
automatización 419, 509 computación en la nube 496, 497

capacidades 509 CSP, versus MSP 499, 500
amenazas internas e ingeniería social, mitigación cuestionarios de evaluación de
509511 ciberseguridad 501, 502
errores de configuración de seguridad, estrategias de ciberseguridad 516
mitigar 514, 515 caracteristicas 497
credenciales robadas, mitigando 515, 516
migración, a la nube 500
vulnerabilidades sin parchear,
Controles de cumplimiento de computación en la nube
mitigando 512, 513
Catálogo (C5) 519
Administración de derechos de Azure (Azure RMS) 370
modelos de servicio de computación en la nube
Infraestructura como servicio (IaaS) 497

B
Plataforma como servicio (PaaS) 497
troyano de puerta trasera 131 Software como servicio (SaaS) 497
botnets 212215 Proveedores de servicios en la nube (CSP) 262, 497
Políticas Traiga su propio dispositivo (BYOD) 9 versus Servicio Administrado

Proveedores (MSP) 499
modificadores de navegador 139
comando combatiente (CCMD) 241
Compromiso de correo electrónico comercial (BEC) 423
Comando y Control (C2) fase 398
alineación de objetivos de negocio 314, 315
ATT&CK, perspectivas 446448
C controles, ejemplos 445
Vulnerabilidades comunes y
Inteligencia de seguridad canadiense Exposiciones (CVE) 47
Servicio (CSIS) 240
Puntuación de vulnerabilidad común
Tendencias de vulnerabilidad de Canonical Ubuntu Sistema (CVSS) 50
Linux 98, 99
Seguridad de las comunicaciones y las redes 464
Gastos de capital (CAPEX) modelo 498
Seguridad de las comunicaciones
Centro para la Seguridad en Internet (CIS) 10 Establecimiento (CSE) 240
Índice 547
Cumplimiento, como Ciberseguridad Programa de validación de módulos criptográficos

Estrategia 355357 (CMVP) 229
ventajas 358 Protocolos de intercambio de CTI

Estimación de puntaje CFSS 357, 358 33 medidas de seguridad 37
desventajas 358 uso, en medidas de seguridad, mejores prácticas 37
la nube 518, 519 programa de Expresión estructurada de información sobre amenazas
cumplimiento 320322 computadoras (STIX) 35
Protocolo de semáforo (TLP) 33, 34

limpiadas por mil (CCM) 139
Intercambio de Indicador Automatizado Confiable
Información de la División de Seguridad Informática
Información (TAXII) 35
Laboratorio de Tecnología (ITL) 58
capacidades actuales de ciberseguridad
Contenedores como servicio (CaaS) 498
madurez 406, 407
Implementación continua (CD) 522
omnipresencia 407
Integración Continua (CI) 522 Lista CVE
Integración Continua (CI)/Continuo enlace de referencia 48
Canalizaciones de implementación (CD) 124,
Autoridades de numeración CVE (CNA) 61 enlace
389, 522
de referencia 62
alineación del marco de control 320322
Equipos de Respuesta a Incidentes Cibernéticos (CIRT) 31
conjuntos de control
ciberseguridad
diseño 416, 417 dominios
gobiernos, rol 223226 renovaciones
de nivel superior de código de país (ccTLD) 202,
207 de licencias 409, 410
Cursos de Acción Matriz 405 Agencia de Seguridad Cibernética (CSA) 238
brechas, identificando 412 Ciberseguridad y Seguridad de Infraestructura

Agencia (CISA) 35, 238
áreas de inversión excesiva, identificando 413, 414
racionalizando 412 relación ciberseguridad y
áreas de inversión insuficiente, identificando 413 TI , significado 322324
Tribunal de Justicia de la Unión Europea Marco de ciberseguridad (CSF) 229 fundamentos
(TJUE) 285 de ciberseguridad 313 centrado en 16
fuentes de datos de inteligencia de amenazas
cibernéticas creíbles 38, Sistema de puntuación de fundamentos de ciberseguridad

39 predicción futura 41 (CFSS) 395, 474, 516
exageración, reconocimiento 40, Equipo de Respuesta a Incidentes de Ciberseguridad

41 identificación (CIRT) 27, 363
38 períodos de tiempo 39, estrategias de ciberseguridad 309, 313,

40 motivos de los proveedores 327329, 335
41, 42 joyas de la corona 310 apoyo a la junta directiva 316318

548 Índice
alineación de objetivos de negocio 314, 315 Inteligencia de amenazas cibernéticas (CTI) 24, 55, 56, 61,
Estimación de puntaje CFSS 387, 388 124, 178, 238, 375
recopilación de datos 2426
programa de cumplimiento 320322
alineación del marco de control 320322 eficacia,
medición 330335 ejemplo 313 D

datos 465
Activos de alto valor (HVA) 310
estrategia centrada en datos 366371
imperativos 315, 316
ventajas 373
ingredientes 314
Estimación de puntuación CFSS 371,
entradas 310
372 desventajas 373
misión 315, 316 visión
mapeo de consumo de
realista, de capacidades de ciberseguridad 319, 320
visión datos 408, 409
realista, de talento técnico 319, 320 apetito de riesgo Prevención de ejecución de datos (DEP) 415
318, 319 riesgos 311 Prevención de pérdida de datos (DLP) 367
controles de protección de datos

cultura de seguridad 324, 325 cifrado del lado del cliente 295, 296
apoyo a altos ejecutivos 316318 requisitos
planificación 295
específicos 311 resumen 386388
fuentes de datos 125
amenazas 311, 312
Eliminación de software malicioso
visión 315, 316
Herramienta (MSRT) 125, 126
Fuentes de datos que no son de seguridad
estrategias de ciberseguridad, para entornos de TI 128 Herramientas antimalware en tiempo real 126128
empresariales 6
Tendencias de vulnerabilidad de Debian 82, 83
amenazas internas 15, 16
tecnología engañosa 419
configuraciones incorrectas de seguridad 10,
Fase de entrega
11 ingeniería social 14, 15
ATT&CK, conocimientos 426, 427
vulnerabilidades sin parches 69
controles, ejemplos 425, 426
credenciales débiles, filtradas o robadas 1114
Zonas Desmilitarizadas (DMZ) 10, 336
estrategias de ciberseguridad, en la nube 516
Estrategia centrada en el ataque 520, 521 Departamento de Defensa (DoD) 241
Cumplimiento como Ciberseguridad Departamento de Transporte (DOT) 233

Estrategia 518, 519
DevOps 388390, 522
DevOps 522526
características 525, 526 usando,
Recuperación de desastres (DR) 526528
en la nube 522524
Estrategia de Protección y Recuperación 517
DevSecOps 389
Ciberseguridad Sospechosos Habituales 313
Índice 549
Recuperación ante desastres (DR) 526

F
usando, en la nube 526, 527
Ataque de denegación de servicio distribuido Oficina Federal de Investigaciones (FBI) 35, 236
(DDoS) 24, 131, 212215 Comisión Federal Reguladora de Energía

(FERC) 233
Ataques de descarga oculta 205208
mitigar 208, 209 Modernización de la seguridad de la información federal

Ley (FISMA) 232
Seguridad de aplicaciones dinámicas
Pruebas (DAST) 47 Comisión Federal de Comercio (FTC) 236
cortafuegos 419
mi
Vigilancia de inteligencia extranjera
Ley (FISA) 271
cifrado y gestión de claves 528532
Tribunal de Vigilancia de Inteligencia Extranjera
Detección de puntos finales y
(FISC) 271
Respuesta (EDR) 212, 342
Tribunal de Vigilancia de Inteligencia Extranjera de
estrategia de protección de punto final 341344
Revisión (FISCR) 271
ventajas 346
Foro de Respuesta a Incidentes y Seguridad
Estimación de puntuación CFFS 344, 345
Equipos (PRIMERO) 50
desventajas 346
Función como servicio (FaaS) 498
Acuerdo de licencia de usuario final (EULA) 132
Administración de seguridad mejorada GRAMO
Medio Ambiente (ESAE) 364

Protección de datos generales
equipos de seguridad empresarial 165, 166
Reglamento (RGPD) 232, 254, 328
Agencia de Protección Ambiental (EPA) 233
genérico (gTLD) 202
Junta Europea de Protección de Datos (EDPB) 328
evolución global del malware 166172
Espacio Económico Europeo (EEE) 232
conclusiones 172
Unión Europea (UE) 231
Infección global de malware de Windows
Fase de explotación 398 análisis 141144
ATT&CK, perspectivas 430432
googleandroid
controles, ejemplos 429, 430
contra Apple iOS 93
Catálogo de Vulnerabilidades Explotadas (KEV) 67
Tendencias de vulnerabilidad de Google Android 8991
kits de explotación 133
Tendencias de vulnerabilidad de Google Chrome 104, 105
hazañas 133
Google Play 124
Detección extendida y
Tendencias de vulnerabilidad de Google 7981
Respuesta (XDR) 31, 212, 342
Gobernanza, Riesgo y
Cumplimiento (GRC) 328
550 Índice
acceso del gobierno a los datos 252 Computación de alto rendimiento
escenario de acceso legal del Clústeres (HPC) 11

gobierno a los datos 254
Activos de alto valor (HVA) 310, 311, 332, 402
mitigar 293
riesgo, gestión 268272 I

escenario de inteligencia de señales 252, 253
Identidad y Acceso
escenario de acceso ilegal del gobierno a los
datos 253 Gestión (IAM) 413, 464
Identidad como servicio (IDaaS) 498

acceso del gobierno a los datos, gestión
de riesgos estrategia centrada en la identidad 362, 363
FISA Sección 702 284287 ventajas 366
RGPD 284287 Estimación de puntuación CFSS 365
Schrems II 285, 286 desventajas 366
Datos de acceso de inteligencia de EE. Equipo de respuesta a incidentes (IR) 478

UU., probabilidad 287292
software independiente
Aplicación de la ley de EE. UU. Accediendo a Proveedores (ISV) 342, 519
datos, probabilidad 275283
Indicadores de compromiso (IOC) 28
volumen de solicitudes de aplicación
ejemplo 29
de la ley 272275
Sistemas de control industrial (ICS) 10
Sede de Comunicaciones del Gobierno
(GCHQ) 240 Intercambio de información y
Centro de Análisis (ISAC) 32
gobiernos
rol, en ciberseguridad 223226 marco en línea (IFrame) 206
gobiernos, como participantes del mercado de Fase de instalación 398

ciberseguridad 226, 227 ATT&CK, perspectivas 435, 440, 443
gobiernos, como defensores 237 controles, ejemplos 434, 435
militar 241244 Servicio de Impuestos Internos (IRS) 236

seguridad nacional 239241 Organización Internacional para
seguridad pública 238 Normalización (ISO) 230
gobiernos, como ejecutores 232 amenazas basadas en Internet 193, 194

cumplimiento de la ley 235237
Grupo de Trabajo de Ingeniería de Internet (IETF) 231
reguladores 232234
Dispositivos de Internet de las cosas (IoT) 10, 63
gobiernos, como organismos de normalización 228232 Cadena de destrucción de intrusión 396400
Matriz de Cursos de Actuación, actualización 402, 403

H Sospechosos habituales de ciberseguridad, mapeo 401
Seguridad de hardware modernizando 400

Módulos (HSM) 296299, 530 fases 397
Índice 551
Intrusión Kill Chain marco malware 129, 130
frente al marco ATT&CK 399, 404, 405 modificadores de navegador 139
resultados de reconstrucción de intrusión exploit kit 133
proveedores útiles, identificando 487489 exploits 133
evaluaciones internas, informando 489 controles software potencialmente no deseado 131, 132
poco convincentes, identificando 485487 ransomware 137, 138
aprendiendo del fracaso 487 Troyanos 131

virus 138
usando 484, 485
gusanos 134137
reconstrucciones de intrusión
interpretando 475483 Malware como servicio (MaaS) 134
distribución de malware
j mitigar 211, 212
Tasa de encuentro de malware (ER) 140

Entorno de tiempo de ejecución de Java (JRE) 360
sitios de alojamiento de malware 209, 210
comando conjunto 241
medición de la prevalencia
Administración JustaSuficiente (JEA) 365
de malware 139, 140
Justo a tiempo (JIT) 365
Proveedores de servicios gestionados (MSP) 498, 519 frente
a proveedores de servicios en la nube (CSP) 499

k
registro de arranque maestro (MBR) 138
modo kernel rootkit 122
Directorio activo de Microsoft (AD) 12
Indicadores clave de rendimiento (KPI) 464
Unidad de Delitos Digitales de Microsoft (DCU) 23, 212
vulnerabilidades conocidas sin parches 469471
Protección contra malware de Microsoft
Centro (MMPC) 47, 125

L
Desarrollo de seguridad de Microsoft
acceso legal del gobierno a los datos 254262 Ciclo de vida (SDL) 47
NUBE Ley 262, 263 Respuesta de seguridad de Microsoft

Ley PATRIOTA 263266 Centro (MSRC) 23, 47
a la izquierda de la pluma 414 Inteligencia de amenazas de Microsoft

Centro (MSTIC) 23
Tendencias de vulnerabilidad del kernel de Linux 99, 100
Tendencias de vulnerabilidad de Microsoft 7478
METRO
microsoft windows 10
contra Apple macOS 97

Aprendizaje automático (ML) 209, 480, 524
Tendencias de vulnerabilidad de Microsoft
Eliminación de software malicioso
Windows 10 93, 94
Herramienta (MSRT) 125, 126
Inteligencia Militar, Sección 5 (MI5) 240
sitios web maliciosos 197
Inteligencia Militar, Sección 6 (MI6) 240
552 Índice
INGLETE ATT&CK® 375

PAG
usando 110
Ejército Popular de Liberación (EPL) 243
Enlace de referencia de conocimientos
de MITRE ATT&CK 28 estrategia de seguridad perimetral 336
MITRE ATT&CK modelo 396 Identificable personalmente

Información (PII) 33, 510 ataques
Gestión de aplicaciones móviles (MAM) 111
de phishing 196203 mitigación
multifactor
Autenticación (MFA) 11, 363, 511 203205 control físico y
autorización de seguridad estrategia 347352 ventajas

Asistencia Legal Mutua
Tratados (MLAT) 256 354
norte Estimación de la puntuación CFSS
352, 353 desventajas

Respuesta Nacional a Emergencias Informáticas
355 malas decisiones de confianza 194
Equipos (CERT) 238
software potencialmente no deseado 131, 132
Centro Nacional de Seguridad Cibernética (NCSC) 238
Estaciones de trabajo de acceso privilegiado (PAW) 364
Centro Nacional de Seguridad Cibernética
de Irlanda (NCSC) 238 Gestión de identidad privilegiada (PIM) 515
Instituto Nacional de Normas y Estrategia Proteger y Recuperar 336339 ventajas

Tecnología (NIST) 48, 228 341
Cartas de seguridad nacional (NSL) 271 Estimación de puntaje CFSS 339, 340
Base de datos de vulnerabilidad nacional (NVD) 48 desventajas 341 usando,
enlace de referencia 48 en la nube 517
Control de acceso a la red (NAC) 9, 380 Información de salud protegida (PHI) 510
Protección de acceso a la red (NAP) 9, 380 Proporcionar las herramientas apropiadas necesarias para
Interceptar y obstruir el terrorismo
Centro de operaciones de red (NOC) 408 Fuentes
(PATRIOTA) Ley 263266
de datos que no son de seguridad 128
Infraestructuras de clave pública (PKI) 370, 530
O R
Objetivos y resultados clave (OKR) 464

ransomware 137, 138, 233 modelo
Regulaciones de la Oficina de Control de Activos de negocio 181183
Extranjeros (OFAC) 234
mecanismos de entrega 177, 178
Open Source Threat Intelligence (OSINT) 24 tendencias de demandas y comunicaciones 180, 181
vulnerabilidad del sistema operativo 88, 89 evolución 173177
Modelo de gastos operativos (OPEX) 498
Tendencias de vulnerabilidad de Oracle 78, 79

Índice 553
mecanismos de ejecución 178, 179 cultura de seguridad 324, 325

métodos de pago 179, 180 Desarrollo de seguridad
herramientas antimalware en tiempo real 126128 Ciclo de vida (SDL) 23, 74, 359
Fase de reconocimiento I Información de seguridad y gestión de eventos

(SIEM) 31, 227
ATT&CK, conocimientos
421 controles, ejemplos 420, 421 Operaciones de seguridad
Centro (SOC) 27, 375, 408
Fase de reconocimiento II
Orquestación de seguridad, automatización y
ATT&CK, conocimientos 451453
Respuesta (SOAR) 31, 345
controles, ejemplos 450
Equipos de liderazgo sénior (SLT) 404 sistema
objetivos de punto de recuperación (RPO) 527
operativo de servidor que
Gasolina Reformulada (RFG) 233
compara 102
Análisis regional de infección de malware de
Acuerdos de nivel de servicio (SLA) 67, 428
Windows 144148
conclusiones 163, 164 escenario de inteligencia de señales 252
Transferencia de estado representacional (REST) inteligencia de señales (SIGINT) 240

API 504
Inicio de sesión único (SSO) 379
apetito de riesgo 318, 319 Kits de desarrollo de software (SDK) 503
Real Policía Montada de Canadá (RCMP) 240 Ciclos de vida de desarrollo de software (SDLC) 74
Ejecutivo Especial de Contrainteligencia,

S Terrorismo, venganza y extorsión
(ESPECTRO) 19
Navegación segura 197
Grupo de Interés Especial (SIG) 50
Alcance
enlace de referencia 50
objetivos realistas, establecimiento 294, 295
estándar 228
establecimiento 293, 294
Cláusulas contractuales estándar (SCC) 285 estatales,
Shell seguro (SSH) 510
locales, tribales y territoriales (SLTT) 236
Valores y Bolsa
Comisión (SEC) 236 Pruebas de seguridad de aplicaciones estáticas (SAST) 47
cambiadores de juego de seguridad y estrategia 309

cumplimiento 502, 516 implementación 410412
Programación de aplicaciones
estrategia implementación
Interfaces (API) 503508
planificación 414416
automatización 509
Expresión estructurada de información sobre amenazas
Seguridad y Gestión de Riesgos 464
(STIX) 35, 36
Arquitectura e Ingeniería de Seguridad 464 beneficio clave 36
554 Índice
T tu
Tácticas, Técnicas y Procedimientos (TTP) 6, 27, 330, 490 Comando cibernético de los Estados Unidos
(USCYBERCOM) 241
La Agencia Nacional de Ciberseguridad de Francia acceso ilegal del gobierno a los datos
(ANSSI) 238 escenario 253, 254
servicios de inteligencia de amenazas 418 vulnerabilidades sin parchear por

gravedad 471, 472
inteligencia de amenazas (TI) 24
URLhaus 210
CTI compartir protocolos 33
enlace de referencia 210
ejemplos 31
compartir 32 rootkits en modo usuario 121, 122
usando 2731 Servicio de Inmigración y Control de Aduanas de EE. UU. (ICE)
panorama de amenazas, Américas 160 236
Boleta de calificaciones regional de 10 años 161163 Agencia de Seguridad Nacional de EE. UU. (NSA) 239
panorama de amenazas, Asia y Oceanía 156 Informe
regional de 10 años 158160 panorama de

V
amenazas, Europa del Este 151, 152 Informe regional de 10 mejora del proveedor y del producto
años 155, 156 panorama de amenazas, Unión Tendencias de vulnerabilidad de Apple 8385
Europea 151 Informe regional de 10 años 152154 Tendencias de vulnerabilidad de Debian 82, 83
Tendencias de vulnerabilidad de Google 7981
panorama de amenazas, Medio Oriente y Norte Tendencias de vulnerabilidad de Microsoft 7478

África 148 Tendencias de vulnerabilidad de Oracle 78, 79
Boleta de calificaciones regional de 10 años 148151 resumen de tendencias de vulnerabilidad

los activos totales del proveedor 8588
versus activos bajo administración 466468 Nube privada virtual (VPC) 515
Protocolo de semáforo (TLP) 33, 34 virus 138
Cifrado del lado del cliente de Transport vulnerabilidades
Layer Security (TLS) 296 gestionar 54, 55
Troyano descargador y cuentagotas 131 vulnerabilidades por tipo de producto 472474
troyanos 131 datos de divulgación de vulnerabilidades
Intercambio de Indicador Automatizado Confiable fuentes 57, 58

Información (TAXII) 35, 36 beneficio
tendencias de divulgación de vulnerabilidades
clave 36
examinando 5867
patrón de ataque típico 194, 195 sistemas operativos 88, 89
proveedor y mejora del producto, midiendo 7174

Índice 555
Tendencias de vulnerabilidad de proveedores y productos

6871
navegadores web 103
resumen del marco de mejora de la vulnerabilidad
106, 107
gestión de vulnerabilidades 46, 47
guía 108112 cartilla

4757 gestión de
vulnerabilidad datos usando 465, 466
W
Armamento 397
Firewalls de aplicaciones web (WAF) 418
Tendencias de vulnerabilidad de los navegadores web 103
Apple Safari 103, 104
comparando 105, 106
Google cromo 104, 105
Tendencias de vulnerabilidad de Windows

Server 2016 101, 102
gusanos 134137, 170
Z
vulnerabilidad de día cero 51, 54
confianza cero 379383
Estimación de puntaje CFSS 384386
Zlobs 131
Descargue una copia gratuita en PDF de este libro

¡Gracias por comprar este libro!
¿Le gusta leer sobre la marcha pero no puede llevar sus libros impresos a todas partes?
¿La compra de su libro electrónico no es compatible con el dispositivo de su elección?
No se preocupe, ahora con cada libro de Packt obtiene una versión en PDF sin DRM de ese libro sin costo alguno.
Lea en cualquier lugar, en cualquier lugar, en cualquier dispositivo. Busque, copie y pegue el código de sus libros técnicos
favoritos directamente en su aplicación.
Las ventajas no terminan ahí, puede obtener acceso exclusivo a descuentos, boletines y excelente contenido gratuito en su
bandeja de entrada todos los días.
Siga estos sencillos pasos para obtener los beneficios:
1. Escanea el código QR o visita el siguiente enlace
https://packt.link/freeebook/9781804613672
2. Envía tu comprobante de compra
3. ¡Eso es todo! Le enviaremos su PDF gratuito y otros beneficios a su correo electrónico directamente

Cybersecurity Threats Pages ESP

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Cybersecurity Threats Pages ESP

Cargado por

Copyright:

Formatos disponibles

Machine Translated by Google

Machine Translated by Google

Descubra estrategias de mitigación de riesgos para amenazas modernas

Amenazas de ciberseguridad, tendencias de malware y estrategias

Copyright © 2023 Packt Publishing

Gerente sénior de productos editoriales: Aaron Tanna

Editor de Adquisiciones – Peer Reviews: Gaurav Gavas

Editor del proyecto: Meenakshi Vijay

Editor de desarrollo de contenido: Liam Thomas Draper

Editor de textos: Safis Editing

Corrector: Safis Editing

Indexador: Sejal Dsilva

Diseñador de la presentación: Rajesh Shirsath

Ejecutivo de marketing de relaciones con desarrolladores: Meghal Patel

Primera publicación: mayo de 2020

Segunda edición: enero de 2023

Referencia de producción: 1170123

Publicado por Packt Publishing Ltd.

Timothy Youngblood, CISSP

Gracias a mi esposo, John, por todo.

Únete a nuestra comunidad en Discord

Diferentes tipos de CISO: “The CISO Spectrum” 3

Cómo las organizaciones se ven comprometidas inicialmente y los fundamentos de ciberseguridad 6

Vulnerabilidades sin parchear • 6

Configuraciones erróneas de seguridad • 10

Credenciales débiles, filtradas y robadas • 11

Centrarse en los fundamentos de la ciberseguridad dieciséis

Comprender la diferencia entre las motivaciones y las tácticas de los atacantes 17

Capítulo 2: Qué saber sobre la inteligencia de amenazas 23

¿Qué es la inteligencia de amenazas?

¿De dónde provienen los datos de CTI? 24

Uso de inteligencia de amenazas 27

La clave para utilizar la inteligencia de amenazas • 31

Intercambio de inteligencia sobre amenazas 32

Protocolos para compartir CTI • 33

Razones para no compartir CTI • 37

Cómo identificar inteligencia creíble sobre ciberamenazas 38

Predicciones sobre el futuro • 41

Motivos de los vendedores • 41

Capítulo 3: Uso de tendencias de vulnerabilidad para reducir riesgos y costos 45

Introducción a la gestión de vulnerabilidades 47

Fuentes de datos de divulgación de vulnerabilidades 57

Tendencias de divulgación de vulnerabilidades de la industria 58

Tendencias de vulnerabilidad de proveedores y productos • 68

Reducción de riesgos y costos: medición de la mejora de proveedores y productos • 71

Tendencias de vulnerabilidades de Microsoft • 74

Tendencias de vulnerabilidades de Oracle • 78

Tendencias de vulnerabilidades de Google • 79

Tendencias de vulnerabilidades de Debian • 82

Tendencias de vulnerabilidad de Apple • 83

Resumen de tendencias de vulnerabilidad de proveedores • 85

Tendencias de vulnerabilidad del sistema operativo • 88

Tendencias de vulnerabilidades de Google Android • 89

Tendencias de vulnerabilidad de Apple iOS • 91

Resumen del sistema operativo móvil • 93

Tendencias de vulnerabilidades de Microsoft Windows 10 • 93

Tendencias de vulnerabilidad de Apple macOS • 95

Tabla de contenido iii

Resumen del sistema operativo de escritorio • 97

Tendencias de vulnerabilidades de Ubuntu Linux • 98

Tendencias de vulnerabilidades del kernel de Linux • 99

Tendencias de vulnerabilidad de Microsoft Windows Server 2016 • 101

Resumen del sistema operativo del servidor • 102

Tendencias de las vulnerabilidades de los navegadores web • 103