Encontrar vulnerabilidades nunca fue la parte difícil

Sigo escuchando la misma frustración cuando hablo con los líderes de seguridad. El verdadero problema en su escritorio no es encontrar vulnerabilidades. Se trata de decidir cuáles realmente importan.

La industria ha gastado miles de millones en una mejor visibilidad. Nos hemos convencido a nosotros mismos de que si pudiéramos descubrir más vulnerabilidades, recopilar más datos e ingerir más inteligencia sobre amenazas, estaríamos más seguros. Pero mira a tu alrededor. Las organizaciones todavía no son más seguras. Simplemente están abrumados.

Entonces llegó la IA y cambió el juego por completo. En cuestión de meses, el descubrimiento de vulnerabilidades se aceleró drásticamente. Los sistemas de inteligencia artificial revisan el código más rápido que los investigadores humanos. Identifican debilidades a una escala sin precedentes. Escanean continuamente sin limitaciones de tiempo, personal o atención. Los titulares han estado por todas partes. Los líderes gubernamentales están reevaluando las leyes de IA. Los directores ejecutivos dan vueltas y vueltas por la noche.

Pero nos estamos centrando en el tema equivocado. En realidad, nada de esto resuelve lo que más importa.

Durante años, los equipos de seguridad se han ahogado en hallazgos. Cada nueva fuente de amenazas prometía una mayor visibilidad. En cambio, lo que llegó fue ruido: más datos, más alertas, más paneles, más vulnerabilidades. Rara vez claridad. Ahora la IA está echando gasolina a ese fuego.

Las conversaciones sobre la IA en la ciberseguridad a menudo quedan estancadas en el lugar equivocado. La gente debate si ayudará a los defensores a moverse más rápido o permitirá a los atacantes más fácilmente. Ambos importan, pero no son el tema central.

La verdadera consecuencia de la IA es que está exponiendo algo que las organizaciones han evitado enfrentar. Una vulnerabilidad no es un riesgo, es sólo una pista. El riesgo surge cuando la información se conecta con el contexto: qué tan crítico es el activo afectado, qué controles lo rodean, qué tan probable es su explotación, los procesos de negocios que respalda y qué sucede operativamente si falla.

Sin ese contexto, la priorización se vuelve imposible. Los recursos se gastan en problemas de bajo riesgo mientras que las vulnerabilidades de misión crítica permanecen sin solucionarse.

Ahora la IA está haciendo que el problema del volumen de datos sea casi imposible de comprender. Una empresa que trabaja con cientos de proveedores de software, proveedores de nube, contratistas y socios tecnológicos debe investigar cada relación. Es como una muñeca de ciberseguridad donde la IA identifica continuamente vulnerabilidades en todo el ecosistema, cada minuto de cada día.

El verdadero desafío hoy no es descubrir las debilidades. Se trata de determinar cuáles de las decenas de miles de debilidades recientemente descubiertas podrían en realidad alterar las operaciones, afectar a los clientes, detener los ingresos o crear exposición regulatoria. La mayoría de las organizaciones no pueden responder esa pregunta rápidamente.

Algunos todavía clasifican el riesgo utilizando puntuaciones de gravedad creadas para equipos técnicos en lugar de para líderes empresariales. Otros dependen de la clasificación manual, que ya tenía problemas antes de la IA. Muchos todavía miden la madurez de la seguridad por la cantidad de hallazgos que identifican en lugar de por la velocidad y precisión de sus decisiones.

Estos enfoques ya no funcionan. Probablemente tampoco funcionaron ayer.

Lo que resulta incómodo de reconocer es que la IA no está creando una crisis de ciberseguridad. Es revelador uno que ha existido durante años. Las organizaciones que tengan éxito en este mundo de IA transformarán el descubrimiento en juicio más rápido que sus competidores. Cuando la IA puede encontrar casi todas las debilidades, la seguridad pertenece a quienes saben sobre qué actuar. Pertenece a quienes pueden conectar los datos con la realidad empresarial.

Esa es la verdadera ventaja. Eso es lo que separa a las organizaciones seguras de aquellas que simplemente recopilan más hallazgos.

Alex Santos

Escrito por Álex Santos

Alex Santos es el director ejecutivo de Fortress Information Security.

El incidente de Nightmare Eclipse muestra que es posible que las peleas entre investigadores y proveedores nunca desaparezcan por completo

Microsoft reabrió algunas heridas y ha reavivado el debate durante las últimas dos semanas sobre la divulgación de vulnerabilidades y la dinámica a veces conflictiva que crea entre investigadores y proveedores de seguridad.

La última controversia se produjo cuando Microsoft amenazó con emprender acciones legales penales contra un investigador de seguridad que reveló públicamente una serie de vulnerabilidades de día cero con exploits de prueba de concepto. microsoft insistió en que no recibió detalles sobre las vulnerabilidades antes del lanzamiento, y agregó que los defectos no fueron divulgados de manera responsable y pusieron a sus clientes en riesgos innecesarios.

La disputa pública entre Microsoft y el investigador conocido como “Eclipse de pesadilla«, que no pudo ser identificado ni contactado para hacer comentarios, provocó consternación entre algunos profesionales de la seguridad. La contundente respuesta de Microsoft y la reacción resultante revivieron un punto de fricción entre proveedores e investigadores que encuentran e informan fallas en el software que venden.

«La pelea se argumenta como una divulgación coordinada, pero la queja subyacente es personal y específica de una manera que la divulgación no debería serlo, especialmente con un proveedor que ha estado en esto durante tanto tiempo», dijo a CyberScoop Katie Moussouris, fundadora y directora ejecutiva de Luta Security.

«Microsoft pareció emocionarse y no debería haber dicho nada públicamente, pero de alguna manera se sintió justificado al llamar a un investigador e involucrar a las autoridades al mismo tiempo», dijo. «Eso los devuelve a las primeras etapas del duelo por la revelación de la vulnerabilidad: la negación y la ira».

El antiguo empleado de Microsoft que trabajó en contacto con la comunidad de seguridad, creó el primer programa de recompensas de la empresa y ha otorgado charlas en conferencias sobre el tema Ya en 2013, dijo que la compañía redobló su falta de responsabilidad en toda la saga.

Microsoft se negó a responder preguntas a raíz de las consecuencias.

Nightmare Eclipse insinuó una falla y una batalla inminente con el proveedor en una serie de publicaciones de blog previas a la misiva de Microsoft sobre las vulnerabilidades. rojosol, Desdefender, Martillo azul, llave amarillaGreenPlasma y MiniPlasma.

Los atacantes explotaron tres de las seis vulnerabilidades que Nightmare Eclipse lanzó antes de que Microsoft las parcheara.

El investigador afirmó que Microsoft se negó a comunicarse, no les pagó ni les dio crédito por descubrir e informar algunas de las vulnerabilidades, eliminó la cuenta del Centro de Respuesta de Seguridad de Microsoft que usaron para revelar las vulnerabilidades y marcó su cuenta de GitHub para su eliminación.

«Están demostrando a todos que están intensificando activamente este conflicto», escribieron, antes de amenazar a Microsoft con un comunicado a mediados de julio que «asegurará que sus huesos queden destrozados ese día».

La divulgación de vulnerabilidades es una vía de doble sentido

Las características de los procesos adecuados de divulgación de vulnerabilidades tienen matices y, a menudo, se enmarcan en los ojos del espectador.

Cualquier baile exitoso entre cazadores de insectos y vendedores se reduce a encontrarse a mitad de camino, dijo Andrew Morris, fundador y arquitecto jefe de GreyNoise.

Si bien los proveedores deben corregir los defectos del software y priorizar la seguridad, Morris señaló que la divulgación irresponsable de vulnerabilidades perjudica tanto a los respondedores de incidentes como a las víctimas potenciales.

«Personalmente, siento que este investigador está siendo extremadamente mezquino. Parece que tienen un interés especial», dijo.

«No puedes darle algo a alguien y decir que es por la bondad de tu corazón, y luego enojarte cuando no te pagan por ello».

Pero Morris también dejó claro que los proveedores tienen la responsabilidad de generar confianza entre los investigadores.

«Si realmente le importa ser el primero en enterarse de los errores en su software, no enterarse una vez que se ha producido un daño o una vez que alguien ha sido descubierto, entonces desea cultivar esa confianza con la comunidad de seguridad», dijo Morris.

Microsoft dijo que reconoce que la relación entre los investigadores de seguridad y los proveedores es crítica y, en ocasiones, frágil.

«Valoramos profundamente a la comunidad de seguridad y continuaremos tomando en serio sus comentarios», dijo la compañía en su publicación. en X.

Sin embargo, la compañía se mantiene firme en oponerse a las circunstancias de las revelaciones de Nightmare Eclipse, describiendo sus acciones como ilegales, injustificables e irresponsables.

«Cuando un individuo infringe la ley y participa en actividades maliciosas que causan un daño real a nuestros clientes, trabajaremos con las autoridades según corresponda», dijo Microsoft sin nombrar al investigador por su apodo. «Seguimos creyendo firmemente en la divulgación coordinada de vulnerabilidades como base para proteger a los clientes y mejorar nuestros productos. Sabemos que, dada la naturaleza de este trabajo, en ocasiones habrá malentendidos. Seguimos comprometidos a participar de buena fe y a brindar una experiencia respetuosa y profesional para todos los investigadores, independientemente de interacciones pasadas».

El costo del retroceso

Los investigadores de seguridad buscan defectos por varias razones: pagos de recompensas, reconocimiento, credibilidad de la industria o simplemente la emoción de la búsqueda que conlleva encontrar vulnerabilidades y solucionarlas.

En el mejor de los casos, este proceso ocurre entre bastidores, con parches publicados y advertidos a los clientes antes de que ocurra la explotación.

Este enfoque colaborativo ha arraigado y mejorado considerablemente, pero todavía hay casos en los que los investigadores se sienten despreciados.

“El público no tiene idea de lo que sucedió detrás de escena para juzgar por qué un investigador que previamente coordinaba finalmente se cansó y decidió abandonar un día cero. [vulnerability]», dijo Moussouris. Como tal, está menos inclinada a criticar las acciones de Nightmare Eclipse, y agrega que «parecen ser alguien que necesita ayuda».

Sin embargo, la confianza entre los investigadores y los proveedores de vulnerabilidades se rompe a menudo. A principios de esta semana, el investigador de seguridad Ammar Askar afirmó que su última interacción con el equipo de seguridad de Microsoft fue tan pobre que decidió revelar públicamente cualquier error que encuentre en VS Code en el futuro. Cumplió esa amenaza al dejando caer una vulnerabilidad y explotar el código para un defecto que permite a los atacantes robar tokens de GitHub.

Si bien acciones como esta pueden sabotear la confianza y abrir una brecha entre los proveedores y los investigadores de vulnerabilidades, el recurso es en gran medida limitado. Moussouris dijo que la mayoría de las veces los límites legales y éticos son claros para los involucrados. Los investigadores pueden informar errores, retenerlos, venderlos o publicarlos. «La única línea roja es el crimen: usar un defecto para extorsionar o atacar a la gente», dijo Moussouris.

«Amenazar con publicar en una fecha determinada es una amenaza con divulgar, y la divulgación es legal. El tono puede resultar feo. [Nightmare Eclipse] todavía no violó ninguna regla ni violó ningún deber”.

El momento no podría ser peor

Ambas partes son en parte responsables de lo sucedido, pero Microsoft empeoró las cosas, afirmó Morris. Amenazar con acciones legales y adoptar un enfoque agresivo nunca ha funcionado. Construir una buena relación entre investigadores y proveedores requiere comunicación abierta y confianza.

«Pensé que ya habíamos superado esto. Resulta que no», dijo.

El incidente de Nightmare Eclipse llega en un momento tenso en este espacio. Los proveedores y sus clientes se enfrentan a una avalancha de más vulnerabilidades, y el aumento de modelos de inteligencia artificial que las descubren está exacerbando este desafío, dejando a los expertos en seguridad alarmados por lo que se avecina.

Las perspectivas sobre dónde se descubrirán y explotarán las vulnerabilidades a continuación, y con qué impacto, son desconocidas y tremendamente inquietantes.

Estas señales implican que el sistema clásico basado en CVE con procesos divulgados responsablemente probablemente esté roto, dijo Morris. «Hay tantos CVE. Es como si esto ¿ya funciona?».

Por ahora, y a pesar de todos sus defectos, los programas coordinados de divulgación de vulnerabilidades se consideran ampliamente como el enfoque más sensato y escalable para este dilema.

«La divulgación coordinada es lo que sucede cuando un proveedor tiene suerte. Alguien a quien no contrató le entrega un error real en lugar de usarlo o venderlo. Eso pone toda la carga de mantener viva la coordinación en el proveedor», dijo Moussouris. «La aplicación de parches silenciosos sin CVE y la llamada a los investigadores que no siguen su cronograma de divulgación desperdician la suerte del proveedor».

Hizo hincapié en lo que está en juego: «Espero que Microsoft y todos los proveedores aprendan que la divulgación coordinada de vulnerabilidades es un regalo y una gracia de la comunidad de investigadores de seguridad para ellos, y la divulgación pública sigue siendo mejor que la no divulgación o el delito».

Las alternativas a una relación en deterioro podrían causar estragos y dejar a todos los proveedores y clientes más susceptibles a los ataques.

«Si los proveedores desaprenden cómo recibir propiedad intelectual y mano de obra gratuita de la comunidad de seguridad en forma de informes de vulnerabilidad con gratitud, nos dirigimos a un mundo donde nadie se molesta en avisar a los proveedores, o se mueven hacia un modelo de divulgación cronometrada que no da ninguna gracia», dijo Moussouris.

Concluyó con un mensaje directo: «Los proveedores de productos escribieron el código vulnerable, son dueños del riesgo y deben hacer todo lo que esté a su alcance para con sus usuarios para reducir ese riesgo». Eso incluye “guardar sus quejas para sí mismos y aprender de la introspección sobre la divulgación coordinada de vulnerabilidades que salieron mal”.

Matt Kapko

Escrito por Matt Kapko

Matt Kapko es reportero de CyberScoop. Su ámbito incluye delitos cibernéticos, ransomware, defectos de software y (mala) gestión de vulnerabilidades. El californiano de toda la vida comenzó su carrera periodística en 2001 con paradas anteriores en Cybersecurity Dive, CIO, SDxCentral y RCR Wireless News. Matt tiene una licenciatura en periodismo e historia de la Universidad Estatal de Humboldt.

Funcionario cibernético de la Casa Blanca: la seguridad de la identidad es más importante que nunca en la era de la IA

A medida que la IA se integre más en la TI federal (y en los conjuntos de herramientas de los atacantes), las agencias gubernamentales necesitarán centrar sus recursos en regular y monitorear las identidades que acceden a su red, dijo el jueves un alto funcionario de ciberseguridad de la Casa Blanca.

Nick Polk, director de la rama de ciberseguridad federal de la Oficina Ejecutiva del Presidente, dijo que si bien los modelos de IA presentarán amenazas únicas a las redes federales, en general seguirán requiriendo primero un acceso confiable, algo que los defensores pueden utilizar en su beneficio.

“Creo que lo importante es que en muchos casos para utilizar y explotar las vulnerabilidades que [AI] «Si pudieras encontrarlos o usarlos de una manera… que podría ser maliciosa o conflictiva, lo primero que tienes que hacer es ingresar a la red», dijo Polk en la Cumbre del Sector Público de Rubrik presentada por FedScoop. «Hay algunos casos en los que tu software está frente a Internet, hay una solución un poco más fácil allí, pero la mayoría de las veces tienes que ingresar a la red».

Esto a menudo significa explotar el acceso que un empleado, contratista o proveedor externo tiene a sus sistemas y datos. Incluso en un futuro impulsado por la IA, los límites de seguridad de la red siguen siendo importantes, ya que brindan a las organizaciones un control significativo sobre quién obtiene acceso a sus sistemas y datos y cómo.

«Ahí es donde una identidad fuerte sigue siendo realmente crítica para poder [first] repeler un intento de explotación antes de que pueda ocurrir o, [second,] «Identificar muy rápidamente que esta persona o esta máquina realmente no debería estar en la red» o se está comportando de manera anómala», dijo Polk.

Sin embargo, incluso antes de que surgieran los grandes modelos lingüísticos, los ciberdelincuentes y los adversarios extranjeros comprometían cada vez más a las organizaciones no con malware o exploits sofisticados, sino obteniendo acceso a la red a través de cuentas, credenciales y otros activos confiables robados.

La seguridad de la identidad federal, que ya es una preocupación, ahora se volverá más crítica en la era de la IA.

Justin Ubert, director de protección cibernética del Departamento de Transporte, dijo que más allá de la velocidad y la escala, las herramientas de inteligencia artificial han brindado a los piratas informáticos maliciosos otras ventajas, como obviar la necesidad de actuar con sigilo.

“Ahora, puedes destruir y apoderarte de tu red más rápido de lo que puedes responder porque… no hay necesidad de estar callado: simplemente entra, toma y listo. [home]», dijo Ubert. «Para cuando sus vallas estén funcionando como se supone que deben hacerlo, como las diseñamos, ya habrán desaparecido».

Las herramientas de inteligencia artificial también pueden convertirse fácilmente en amenazas internas. Incluso cuando los usuarios restringen su capacidad para realizar acciones sensibles como descargar o filtrar datos sin intervención humana, los modelos han superado esas barreras explotando oscuras lagunas técnicas.

Una investigación publicada el mes pasado por la Universidad de California-Riverside encontró que los agentes automatizados de IA «pueden obsesionarse peligrosamente con completar tareas sin reconocer cuándo sus acciones son dañinas, contradictorias o simplemente irracionales».

El estudio, que examinó Claude Sonnet y Opus 4 de Anthropic, así como ChatGPT-5 de OpenAI, encontró que los agentes modelo luchaban con el razonamiento contextual, tenían sesgos a la hora de tomar medidas (es decir, descubrir cómo hacer algo en lugar de si hacerlo) y con frecuencia se equivocaban con objetivos contradictorios o inviables.

Anna Likhen, CISO interina de la Oficina de Análisis Económico del Departamento de Comercio, dijo que la IA se ha vuelto “mucho más inteligente a la hora de ocultar cómo logró penetrar y atacar y presentarse como una fuente confiable”.

Cuando se le preguntó cómo estaba trabajando el gobierno federal para abordar las brechas actuales en la seguridad de la identidad que los sistemas de inteligencia artificial explotan cada vez más, Libkhen dijo que los líderes federales se están «orinando en los pantalones» antes de agregar «al menos lo estoy haciendo».

«Da miedo, sí, somos muy vulnerables», dijo Libkhen.

Comparó el uso de agentes de inteligencia artificial con enseñar a un niño a patinar sobre hielo: lo primero que se les enseña es cómo manejar una caída y recuperarse. Del mismo modo, las organizaciones deberán planificar para cuando sus agentes fallen y recuperar rápidamente los activos perdidos.

«Nuestros agentes se equivocarán, harán cosas que no esperamos que hagan. ¿Cómo nos levantamos?». dijo Libkhen. «¿Tenemos ese tercer conjunto de datos porque ese agente borró la base de datos y la copia de seguridad? ¿Está seguro en otro lugar? ¿Qué tipo de agujeros puede anticipar y qué será necesario para que nos recuperemos de esos agujeros?»

Derek B. Johnson

Escrito por Derek B. Johnson

Derek B. Johnson es reportero de CyberScoop, donde su área incluye la ciberseguridad, las elecciones y el gobierno federal. Antes de eso, ha brindado una cobertura galardonada de noticias sobre ciberseguridad en los sectores público y privado para varias publicaciones desde 2017. Derek tiene una licenciatura en periodismo impreso de la Universidad de Hofstra en Nueva York y una maestría en políticas públicas de la Universidad George Mason en Virginia.

La mayoría de los programas de reparación nunca confirman que la solución realmente funcionó – CYBERDEFENSA.MX

Los equipos de seguridad nunca han tenido mejor visibilidad de sus entornos y nunca han sido peores a la hora de confirmar que lo que reparan permanece fijo.

El informe M-Trends 2026 de Mandiant sitúa el tiempo medio de explotación en un estimado negativo de siete días. El DBIR 2025 de Verizon sitúa el tiempo medio para remediar las vulnerabilidades de los dispositivos perimetrales en 32 días. Es comprensible que estas cifras hayan impulsado a la industria hacia una respuesta clara: priorizar mejor, parchear más rápido. Ese consejo es necesario. También está incompleto. Porque la pregunta que todavía no recibe suficiente atención es la siguiente: cuando aplicas el parche, ¿cómo sabes que funcionó?

Los mitos no cambiaron el problema. Cambió la velocidad y facilidad de explotación.

Las discusiones sobre el impacto de la IA se han centrado en la velocidad: el desarrollo de exploits es cada vez más barato, más rápido y menos dependiente de las habilidades humanas de élite.

Para la remediación, esto cambia lo que está en juego. Muchas correcciones se marcan como «remediadas» cuando lo que realmente sucedió fue un parche del proveedor que resultó ser evitable, o una solución alternativa que dependía de que los atacantes se comportaran de cierta manera. Esas solían ser apuestas bastante seguras. Ya no lo son. La cuestión ya no es la velocidad de la remediación. La pregunta es si su solución realmente eliminó la exposición o simplemente movió el ticket a «Listo».

Parche perfecto, pero aún vulnerable

No todas las exposiciones se pueden parchear. Una regla de firewall débil deja la puerta abierta, por ejemplo. Se descubrió que la regla de política fue reescrita y supuestamente aplicada. ¿Pero lo fue? Cuando se aplica un parche, obtienes confirmación. Cuando se establece un privilegio, o se configura una política EDR o una configuración SIEM, es necesario realizar una prueba para verificar que haya surtido efecto.

La costura organizacional donde las semanas desaparecen

Incluso con hallazgos validados y de alta señal, el retraso entre la identificación y la remediación es principalmente organizacional. Encuentras el riesgo. No eres dueño de la solución. Los equipos que lo poseen operan en diferentes cronogramas con diferentes prioridades. Los hallazgos no se consolidan en acciones que la ingeniería pueda ejecutar, por lo que la señal se pierde nuevamente.

En entornos híbridos y nativos de la nube, la propiedad se vuelve más confusa: una vulnerabilidad puede ubicarse en la capa de aplicación, la capa de infraestructura o en una dependencia de terceros. Y una vez que llega a algún lugar, la remediación pasa por cualquier proceso que el equipo ya utilice, cambia las ventanas para TI y DevOps, y acelera los compromisos para ingeniería. Los resultados de seguridad terminan compitiendo con lo que ya estaba en el cronograma y, por lo general, pierden. Los atacantes acelerados por IA no están esperando la siguiente ventana de cambio o el próximo sprint.

La consolidación y la automatización son necesarias. No son suficientes.

El arrastre operativo tiene soluciones reales. Consolide los hallazgos relacionados para que varios problemas validados que se remontan al mismo balanceador de carga mal configurado se conviertan en un ticket con un solo propietario. Automatice el enrutamiento, la asignación, el cumplimiento de SLA y las rutas de escalamiento. Aprovecha el flujo de trabajo de las hojas de cálculo y los mensajes de Slack.

Pero el rendimiento y la velocidad indican qué tan rápido se mueve el sistema, no si está funcionando. Puede enviar un ticket consolidado a un propietario confirmado en minutos, hacer cumplir el SLA, escalarlo según lo programado y aun así cerrar un ticket que no eliminó la exposición. Tal vez la solución alternativa no sobreviva a un cambio de configuración, la solución se implementó en tres de los cuatro sistemas afectados o el parche se aplicó exitosamente pero dejó intacta una mala configuración circundante.

El ticket dice «resuelto». La vía de ataque sigue abierta. Cuando la IA puede derivar y volver a derivar de forma autónoma cadenas de exploits como lo demostró Mythos, la falsa confianza es lo más costoso en su programa de seguridad.

La reválida es la disciplina que falta

La revalidación debería significar que el riesgo ya no existe. Una nueva prueba sólo valida que el ataque original no existe. Debe validar que el riesgo en sí no existe.

Cuando cada solución se vuelve a probar y los resultados son visibles tanto para los líderes de seguridad como de ingeniería, las soluciones parciales y las soluciones alternativas se marcan inmediatamente en lugar de permanecer en un panel. Crea un circuito de retroalimentación que hace que todo el sistema se autocorrija.

El flujo de trabajo de remediación que se mantiene en las condiciones actuales: hallazgos validados consolidados en acciones de reparación, enviados a propietarios confirmados, rastreados hasta el cierre y luego revalidados para confirmar que el riesgo subyacente ha desaparecido, no solo la ruta de ataque original. Plataforma de Pentera está diseñado para ese modelo operativo, conectando el flujo de trabajo de remediación con la validación posterior a la corrección para que los equipos puedan medir si el riesgo realmente se eliminó.

Tres preguntas que separan un sistema de una esperanza

  • ¿Cuál es su tiempo promedio para remediar un hallazgo validado y explotable? Si no puede responder esto, está midiendo la actividad, no los resultados.
  • Cuando se aplica una solución, ¿cómo se confirma que funcionó? Si la respuesta es «el ingeniero cerró el ticket», pregúntese cuántos de esos hallazgos solucionados sobrevivirían a una nueva prueba.
  • ¿Está midiendo tickets cerrados o riesgo cerrado? El rendimiento de los tickets le indica que el equipo está ocupado. No te dice que la exposición ha desaparecido. Los programas mejoran cuando consolidan los hallazgos sobre el riesgo subyacente y rastrean si ese riesgo realmente desaparece.

Las organizaciones que entiendan esto serán las que dejen de tratar la remediación como algo que sucede después de que se haya realizado el trabajo de seguridad y comiencen a tratarla como el lugar donde realmente se mide el trabajo de seguridad.

Nota: Este artículo ha sido escrito y contribuido de manera experta por Nimrod Zantkern Lavi, Director de Producto, Pentera.

¿Encontró interesante este artículo? Este artículo es una contribución de uno de nuestros valiosos socios. Síguenos en noticias de google, Gorjeo y LinkedIn para leer más contenido exclusivo que publicamos.