Los controles funcionan o no funcionan \u2014 pero determinar cu\u00e1l es el caso requiere algo m\u00e1s que una verificaci\u00f3n puntual. Las m\u00e9tricas proporcionan la evidencia longitudinal que los auditores necesitan para evaluar si los controles de seguridad est\u00e1n operando eficazmente con el tiempo<\/strong>, no solo el d\u00eda de la auditor\u00eda.<\/p>\n Una organizaci\u00f3n que puede producir m\u00e9tricas de seguridad de aplicaciones consistentes y generadas por el sistema demuestra madurez operativa. Una organizaci\u00f3n que no puede producir m\u00e9tricas \u2014 o solo produce n\u00fameros compilados manualmente \u2014 revela una brecha fundamental en su entorno de control.<\/p>\n Para los oficiales de cumplimiento, las m\u00e9tricas sirven un doble prop\u00f3sito: satisfacen los requisitos de informes regulatorios (DORA, NIS2 y los mandatos sectoriales espec\u00edficos requieren cada vez m\u00e1s informes de seguridad cuantitativos) y proporcionan advertencia temprana cuando los controles se est\u00e1n degradando. Un tiempo medio de remediaci\u00f3n creciente o un porcentaje de cobertura de pruebas en declive se\u00f1alan problemas antes de que se conviertan en hallazgos de auditor\u00eda.<\/p>\n Esta gu\u00eda define las m\u00e9tricas que importan, explica c\u00f3mo los auditores pueden evaluar su fiabilidad e identifica las formas m\u00e1s comunes en que las m\u00e9tricas pueden manipularse.<\/p>\n Las m\u00e9tricas de seguridad de aplicaciones se dividen en cuatro categor\u00edas, cada una con un prop\u00f3sito de garant\u00eda diferente:<\/p>\n La siguiente tabla proporciona una referencia completa para las m\u00e9tricas de seguridad de aplicaciones m\u00e1s importantes. Para cada m\u00e9trica, los auditores deben entender qu\u00e9 mide, c\u00f3mo se ve un objetivo razonable, de d\u00f3nde deben provenir los datos y c\u00f3mo puede manipularse.<\/p>\n Las m\u00e9tricas de cobertura responden a la pregunta: \u00bfest\u00e1 la organizaci\u00f3n probando lo que deber\u00eda estar probando?<\/strong><\/p>\n La m\u00e9trica de cobertura m\u00e1s fundamental es el porcentaje de aplicaciones con pruebas de seguridad activas en relaci\u00f3n con el inventario total de aplicaciones. Esto debe segmentarse por nivel de aplicaci\u00f3n, porque una tasa de cobertura general del 90% podr\u00eda ocultar el hecho de que varias aplicaciones cr\u00edticas de Nivel 1 no est\u00e1n siendo probadas.<\/p>\n Los auditores deben solicitar datos de cobertura desglosados de la siguiente manera:<\/p>\n Una m\u00e9trica de cobertura solo es significativa si el denominador es preciso. Si el inventario de aplicaciones est\u00e1 incompleto, los porcentajes de cobertura son enga\u00f1osos. Los auditores deben cruzar el inventario de aplicaciones utilizado para los c\u00e1lculos de cobertura con otras fuentes (CMDB, plataformas de despliegue, inventarios de cuentas en la nube) para verificar la completitud.<\/p>\n Las m\u00e9tricas de eficiencia responden a la pregunta: cuando la organizaci\u00f3n encuentra vulnerabilidades, \u00bflas corrige eficazmente?<\/strong><\/p>\n El Tiempo Medio de Remediaci\u00f3n (MTTR)<\/strong> es la m\u00e9trica de eficiencia m\u00e1s importante. Debe rastrearse por nivel de severidad y por nivel de aplicaci\u00f3n, porque un MTTR promedio de 30 d\u00edas es aceptable para hallazgos de alta severidad pero no para hallazgos cr\u00edticos en aplicaciones de Nivel 1.<\/p>\n El MTTR debe medirse desde la fecha de identificaci\u00f3n (cuando la herramienta de an\u00e1lisis o el tester report\u00f3 por primera vez el hallazgo) hasta la fecha de remediaci\u00f3n verificada (cuando un nuevo an\u00e1lisis o retest confirma que la correcci\u00f3n es efectiva). Las organizaciones que miden hasta la fecha en que el desarrollador cierra el ticket \u2014 sin verificaci\u00f3n \u2014 est\u00e1n reportando una m\u00e9trica incompleta.<\/p>\n La tasa de reapertura de vulnerabilidades<\/strong> indica la calidad de las correcciones. Una tasa superior al 5% sugiere que las remediaciones son superficiales o que no se est\u00e1n abordando las causas ra\u00edz.<\/p>\n La tasa de falsos positivos<\/strong> indica la efectividad de la herramienta y la calidad del triaje. Una tasa de falsos positivos inusualmente alta puede indicar que los hallazgos se est\u00e1n descartando como falsos positivos en lugar de investigarse \u2014 los auditores deben muestrear las clasificaciones de falsos positivos para verificar que son leg\u00edtimas.<\/p>\n El tiempo de ciclo de an\u00e1lisis a correcci\u00f3n<\/strong> mide el tiempo transcurrido de extremo a extremo desde que se completa un an\u00e1lisis hasta que se resuelven todos los hallazgos de ese an\u00e1lisis. Esto captura los retrasos en el triaje y la asignaci\u00f3n que el MTTR por s\u00ed solo puede no revelar.<\/p>\n Las m\u00e9tricas de riesgo responden a la pregunta: \u00bfcu\u00e1l es la exposici\u00f3n actual a vulnerabilidades y se est\u00e1 gestionando?<\/strong><\/p>\n El recuento de vulnerabilidades cr\u00edticas y de alta severidad abiertas<\/strong> es una m\u00e9trica de riesgo de referencia. Debe rastrearse como tendencia a lo largo del tiempo \u2014 un recuento estable o en declive indica un programa eficaz; un recuento creciente indica que los hallazgos se est\u00e1n generando m\u00e1s r\u00e1pido de lo que se est\u00e1n remediando.<\/p>\n El envejecimiento de vulnerabilidades<\/strong> mide cu\u00e1nto tiempo permanecen abiertas las vulnerabilidades. La antig\u00fcedad en el percentil 90 es m\u00e1s \u00fatil que la media porque las medias pueden sesgarse por un gran n\u00famero de hallazgos de baja severidad resueltos r\u00e1pidamente. Si la antig\u00fcedad P90 supera el SLA, la organizaci\u00f3n no est\u00e1 cumpliendo sus propios compromisos de remediaci\u00f3n para una porci\u00f3n significativa de los hallazgos.<\/p>\n Los recuentos de excepciones y supresiones<\/strong> revelan c\u00f3mo la organizaci\u00f3n gestiona los hallazgos que elige no corregir. Cada excepci\u00f3n debe tener una aprobaci\u00f3n documentada, un control compensatorio y una fecha de revisi\u00f3n. Un recuento de excepciones creciente sin la justificaci\u00f3n correspondiente indica que el proceso de excepciones se est\u00e1 utilizando para evitar la remediaci\u00f3n en lugar de gestionar el riesgo genuino.<\/p>\n La cartera de aceptaci\u00f3n de riesgos<\/strong> rastrea los riesgos formalmente aceptados. Los auditores deben verificar que cada riesgo aceptado tenga un propietario, una justificaci\u00f3n documentada, un control compensatorio y una fecha de revisi\u00f3n \u2014 y que las revisiones vencidas se escalen.<\/p>\n Las m\u00e9tricas de cumplimiento responden a la pregunta: \u00bfest\u00e1 la organizaci\u00f3n siguiendo sus propias pol\u00edticas y cumpliendo los requisitos regulatorios?<\/strong><\/p>\n La tasa de aprobaci\u00f3n de puertas de pol\u00edtica<\/strong> mide con qu\u00e9 frecuencia las versiones pasan las puertas de seguridad en el primer intento. Una tasa de aprobaci\u00f3n muy baja puede indicar que los requisitos de seguridad no est\u00e1n claros o que los equipos de desarrollo no est\u00e1n recibiendo retroalimentaci\u00f3n adecuada con suficiente antelaci\u00f3n. Una tasa de aprobaci\u00f3n sospechosamente alta (cercana al 100%) puede indicar que las puertas son demasiado permisivas.<\/p>\n La tasa de omisi\u00f3n de aprobaciones<\/strong> es una m\u00e9trica de control cr\u00edtica. En entornos regulados, cada omisi\u00f3n debe documentarse con una aprobaci\u00f3n de excepci\u00f3n. Una tasa de omisi\u00f3n superior al 2% \u2014 o cualquier omisi\u00f3n sin aprobaci\u00f3n documentada \u2014 es un hallazgo significativo.<\/p>\n La tasa de cumplimiento de SLA<\/strong> mide si las vulnerabilidades se remedian dentro de los plazos definidos en la pol\u00edtica de gesti\u00f3n de vulnerabilidades. Esto debe rastrearse por severidad y nivel. Las organizaciones que consistentemente no cumplen los SLAs para hallazgos cr\u00edticos en aplicaciones de Nivel 1 tienen una debilidad de control material.<\/p>\n La puntuaci\u00f3n de completitud de evidencia<\/strong> mide la preparaci\u00f3n de la organizaci\u00f3n para la auditor\u00eda rastreando qu\u00e9 porcentaje de los artefactos de evidencia requeridos est\u00e1n disponibles, actualizados y correctamente almacenados. Esta es una meta-m\u00e9trica que indica la madurez de la gobernanza.<\/p>\n No todas las m\u00e9tricas son igualmente fiables. Los auditores deben evaluar la fiabilidad de las m\u00e9tricas reportadas contra los siguientes criterios:<\/p>\n Las m\u00e9tricas solo son \u00fatiles si reflejan la realidad. A continuaci\u00f3n se presentan las t\u00e9cnicas de manipulaci\u00f3n m\u00e1s comunes y los procedimientos de auditor\u00eda para detectarlas:<\/p>\n Las vulnerabilidades se degradan de cr\u00edtica a alta, o de alta a media, para evitar activar los requisitos de SLA o los umbrales de informes ejecutivos.<\/p>\n Detecci\u00f3n:<\/strong> Compare las distribuciones de severidad a lo largo del tiempo. Una disminuci\u00f3n repentina en los hallazgos cr\u00edticos con un aumento correspondiente en los hallazgos altos es sospechosa. Muestree los hallazgos degradados y eval\u00fae si el cambio de severidad estaba justificado y fue aprobado.<\/p>\n Un gran n\u00famero de vulnerabilidades se cierran inmediatamente antes de un per\u00edodo de auditor\u00eda, ya sea mediante aceptaci\u00f3n masiva del riesgo o marcando los hallazgos como resueltos sin verificaci\u00f3n.<\/p>\n Detecci\u00f3n:<\/strong> Grafique las fechas de cierre de vulnerabilidades en una l\u00ednea de tiempo. La agrupaci\u00f3n de cierres antes de los per\u00edodos de auditor\u00eda es un indicador claro. Solicite evidencia de retest para una muestra de hallazgos cerrados recientemente.<\/p>\n Las aplicaciones se eliminan del inventario o se excluyen de los an\u00e1lisis para mejorar los porcentajes de cobertura y reducir el recuento total de vulnerabilidades.<\/p>\n Detecci\u00f3n:<\/strong> Compare el inventario de aplicaciones utilizado para las m\u00e9tricas con otras fuentes autorizadas (inventarios de cuentas en la nube, registros de plataformas de despliegue, an\u00e1lisis de red). Cualquier discrepancia requiere explicaci\u00f3n.<\/p>\n Las vulnerabilidades se cierran y reabren (o se crean nuevos tickets para el mismo hallazgo) para restablecer el reloj de las m\u00e9tricas de envejecimiento.<\/p>\n Detecci\u00f3n:<\/strong> Busque hallazgos con descripciones id\u00e9nticas y diferentes fechas de creaci\u00f3n. Compruebe si la plataforma de gesti\u00f3n de vulnerabilidades rastrea la fecha de descubrimiento original por separado de la fecha de creaci\u00f3n del ticket.<\/p>\n Los umbrales de las puertas de pol\u00edtica se relajan (por ejemplo, cambiar el umbral de bloqueo de \u00absin alto o cr\u00edtico\u00bb a \u00absin cr\u00edtico \u00fanicamente\u00bb) para mejorar las tasas de aprobaci\u00f3n sin mejorar la seguridad real.<\/p>\n Detecci\u00f3n:<\/strong> Solicite el historial de cambios de las configuraciones de puertas de pol\u00edtica. Cualquier cambio en los umbrales debe ser aprobado mediante el proceso de gobernanza y documentado con justificaci\u00f3n.<\/p>\n Las diferentes partes interesadas requieren diferentes niveles de detalle con diferentes frecuencias. La siguiente cadencia equilibra las necesidades operativas con los requisitos de gobernanza:<\/p>\n Para las organizaciones reguladas sujetas a DORA, los informes trimestrales al \u00f3rgano de direcci\u00f3n sobre el riesgo ICT \u2014 incluida la seguridad de aplicaciones \u2014 son una expectativa regulatoria, no una recomendaci\u00f3n de buenas pr\u00e1cticas.<\/p>\n Para orientaci\u00f3n relacionada sobre controles de seguridad de aplicaciones y evaluaci\u00f3n de auditor\u00eda, consulte:<\/p>\nCategor\u00edas de M\u00e9tricas AppSec<\/h2>\n
\n
Referencia de M\u00e9tricas Clave<\/h2>\n
\n\n
\n \nNombre de la M\u00e9trica<\/th>\n Qu\u00e9 Mide<\/th>\n Objetivo \/ Umbral<\/th>\n Fuente de Datos<\/th>\n Riesgo de Manipulaci\u00f3n<\/th>\n<\/tr>\n<\/thead>\n \n Tasa de Cobertura SAST<\/td>\n % de aplicaciones con an\u00e1lisis SAST activo<\/td>\n 100% para Niveles 1-3; basado en riesgos para Nivel 4<\/td>\n Plataforma SAST, registros del pipeline CI\/CD<\/td>\n Excluir aplicaciones del alcance para inflar el porcentaje<\/td>\n<\/tr>\n \n Tasa de Cobertura DAST<\/td>\n % de aplicaciones con an\u00e1lisis DAST a la frecuencia requerida<\/td>\n 100% para Niveles 1-2; 100% anualmente para Nivel 3<\/td>\n Plataforma DAST, registros de programaci\u00f3n de an\u00e1lisis<\/td>\n Ejecutar an\u00e1lisis con alcance limitado o rutas autenticadas<\/td>\n<\/tr>\n \n Tasa de Cobertura SCA<\/td>\n % de aplicaciones con an\u00e1lisis de dependencias activo<\/td>\n 100% para Niveles 1-3<\/td>\n Plataforma SCA, registros del pipeline de compilaci\u00f3n<\/td>\n Excluir repositorios o configuraciones de compilaci\u00f3n<\/td>\n<\/tr>\n \n Cobertura de Modelado de Amenazas<\/td>\n % de aplicaciones de Niveles 1-2 con modelos de amenazas actuales<\/td>\n 100% para Nivel 1; 100% para Nivel 2<\/td>\n Herramienta de modelado de amenazas o repositorio de documentos<\/td>\n Crear modelos superficiales que no reflejen la arquitectura real<\/td>\n<\/tr>\n \n Tiempo Medio de Remediaci\u00f3n (Cr\u00edtico)<\/td>\n D\u00edas promedio desde la identificaci\u00f3n de la vulnerabilidad hasta la correcci\u00f3n verificada para severidad cr\u00edtica<\/td>\n ≤15 d\u00edas<\/td>\n Plataforma de gesti\u00f3n de vulnerabilidades<\/td>\n Degradar la severidad para evitar el SLA; cerrar sin verificaci\u00f3n<\/td>\n<\/tr>\n \n Tiempo Medio de Remediaci\u00f3n (Alto)<\/td>\n D\u00edas promedio desde la identificaci\u00f3n hasta la correcci\u00f3n verificada para severidad alta<\/td>\n ≤30 d\u00edas<\/td>\n Plataforma de gesti\u00f3n de vulnerabilidades<\/td>\n Igual que el anterior<\/td>\n<\/tr>\n \n Tasa de Reapertura de Vulnerabilidades<\/td>\n % de vulnerabilidades que se cierran y luego reaparecen<\/td>\n <5%<\/td>\n Plataforma de gesti\u00f3n de vulnerabilidades<\/td>\n Redefinir los criterios de reapertura; crear nuevos tickets en lugar de reabrir<\/td>\n<\/tr>\n \n Tasa de Falsos Positivos<\/td>\n % de hallazgos marcados como falso positivo despu\u00e9s del triaje<\/td>\n <20% (var\u00eda seg\u00fan la herramienta)<\/td>\n Herramientas de pruebas de seguridad, registros de triaje<\/td>\n Clasificar los verdaderos positivos como falsos para reducir la carga de trabajo<\/td>\n<\/tr>\n \n Vulnerabilidades Cr\u00edticas\/Altas Abiertas<\/td>\n Recuento de vulnerabilidades de severidad cr\u00edtica y alta sin resolver<\/td>\n Tendencia a la baja; cero cr\u00edticas en aplicaciones de Nivel 1<\/td>\n Plataforma de gesti\u00f3n de vulnerabilidades<\/td>\n Degradar la severidad; mover a aceptaci\u00f3n del riesgo sin aprobaci\u00f3n adecuada<\/td>\n<\/tr>\n \n Antig\u00fcedad de Vulnerabilidades (P90)<\/td>\n Percentil 90 de la antig\u00fcedad de las vulnerabilidades abiertas<\/td>\n Dentro del SLA para cada nivel de severidad<\/td>\n Plataforma de gesti\u00f3n de vulnerabilidades<\/td>\n Restablecer la fecha de descubrimiento; cerrar y reabrir<\/td>\n<\/tr>\n \n Recuento de Excepciones\/Supresiones<\/td>\n N\u00famero de excepciones o supresiones de vulnerabilidades activas<\/td>\n Tendencia estable o a la baja; cada una con aprobaci\u00f3n documentada<\/td>\n Registro de excepciones, plataforma de vulnerabilidades<\/td>\n Supresi\u00f3n informal fuera de los sistemas rastreados<\/td>\n<\/tr>\n \n Cartera de Aceptaci\u00f3n de Riesgos<\/td>\n Recuento de riesgos formalmente aceptados con fechas de revisi\u00f3n abiertas<\/td>\n Todos dentro del per\u00edodo de revisi\u00f3n; ninguno vencido<\/td>\n Registro de riesgos<\/td>\n Establecer fechas de revisi\u00f3n en el futuro lejano para evitar la reevaluaci\u00f3n<\/td>\n<\/tr>\n \n Tasa de Aprobaci\u00f3n de Puertas de Pol\u00edtica<\/td>\n % de versiones que pasan todas las puertas de pol\u00edtica de seguridad en el primer intento<\/td>\n >80% (mejorando con el tiempo)<\/td>\n Pipeline CI\/CD, registros del motor de pol\u00edticas<\/td>\n Debilitar los criterios de puerta para aumentar la tasa de aprobaci\u00f3n<\/td>\n<\/tr>\n \n Tasa de Omisi\u00f3n de Aprobaciones<\/td>\n % de versiones que omitieron las aprobaciones de seguridad requeridas<\/td>\n <2%; todas con excepci\u00f3n documentada<\/td>\n Sistema de gesti\u00f3n de cambios, registros del pipeline<\/td>\n Usar procedimientos de emergencia de forma rutinaria<\/td>\n<\/tr>\n \n Tasa de Cumplimiento de SLA<\/td>\n % de vulnerabilidades remediadas dentro del SLA definido<\/td>\n >90%<\/td>\n Plataforma de gesti\u00f3n de vulnerabilidades<\/td>\n Ajustar las definiciones de SLA; pausar los temporizadores de SLA<\/td>\n<\/tr>\n \n Puntuaci\u00f3n de Completitud de Evidencia<\/td>\n % de artefactos de evidencia de auditor\u00eda requeridos que est\u00e1n disponibles y actualizados<\/td>\n >95%<\/td>\n Repositorio de evidencia, plataforma GRC<\/td>\n Generar evidencia retrospectivamente antes de la auditor\u00eda<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n M\u00e9tricas de Cobertura en Detalle<\/h2>\n
\n
M\u00e9tricas de Eficiencia en Detalle<\/h2>\n
M\u00e9tricas de Riesgo en Detalle<\/h2>\n
M\u00e9tricas de Cumplimiento en Detalle<\/h2>\n
Qu\u00e9 Hace que una M\u00e9trica sea Fiable para los Auditores<\/h2>\n
\n
M\u00e9tricas que Pueden Manipularse \u2014 y C\u00f3mo los Auditores Pueden Detectarlo<\/h2>\n
Reducci\u00f3n de Severidad<\/h3>\n
Cierres Masivos Antes de la Auditor\u00eda<\/h3>\n
Exclusi\u00f3n de Aplicaciones del Alcance<\/h3>\n
Restablecimiento de Fechas de Descubrimiento<\/h3>\n
Debilitamiento de los Criterios de las Puertas<\/h3>\n
Cadencia de Informes Recomendada<\/h2>\n
\n\n
\n \nNivel de Informes<\/th>\n Frecuencia<\/th>\n Audiencia<\/th>\n Contenido<\/th>\n<\/tr>\n<\/thead>\n \n Operativo<\/strong><\/td>\n Semanal<\/td>\n Equipo AppSec, Security Champions, Jefes de Equipo de Desarrollo<\/td>\n Nuevos hallazgos, progreso de remediaci\u00f3n, elementos vencidos, fallos de an\u00e1lisis, acciones inmediatas<\/td>\n<\/tr>\n \n Gesti\u00f3n<\/strong><\/td>\n Mensual<\/td>\n CISO, Responsable AppSec, Directores de Desarrollo, Oficial de Cumplimiento<\/td>\n An\u00e1lisis de tendencias, MTTR por severidad\/nivel, cambios de cobertura, cumplimiento de SLA, resumen de excepciones, riesgos emergentes<\/td>\n<\/tr>\n \n Ejecutivo \/ Auditor\u00eda<\/strong><\/td>\n Trimestral<\/td>\n Consejo \/ Comit\u00e9 de Riesgos, Auditores Externos, Reguladores<\/td>\n Resumen de postura de riesgo, evaluaci\u00f3n de madurez del programa, tendencias de m\u00e9tricas clave (vista de 12 meses), hallazgos materiales, estado de cumplimiento regulatorio, adecuaci\u00f3n de recursos<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Lectura Adicional<\/h2>\n
\n
Relacionado para Auditores<\/h3>\n