La gestión de vulnerabilidades se vuelve difícil cuando el informe crece más rápido que la capacidad de corregir. Una empresa puede recibir cientos de hallazgos, ordenarlos por severidad y seguir sin responder la pregunta que importa: cuál puede afectar primero un servicio relevante y quién debe resolverlo. Escanear con mayor frecuencia no corrige esa brecha. La prioridad necesita combinar evidencia técnica, contexto operativo y una decisión con responsable.

El objetivo tampoco es instalar todos los parches apenas aparecen. Algunos cambios requieren pruebas o coordinación con proveedores. Lo exigible es explicar por qué una vulnerabilidad quedó primero, qué acción se acordó y cómo se comprobará la reducción del riesgo.

La gestión de vulnerabilidades no puede depender solo de CVSS

CVSS permite comunicar características y severidad técnica con un método común. La especificación CVSS 4.0 de FIRST distingue métricas base, de amenaza y ambientales. El puntaje base representa cualidades intrínsecas; no conoce el servicio que sostiene el activo, su exposición ni el impacto particular para la empresa. Como única regla, puede postergar hallazgos con una ruta de explotación más directa.

La severidad sigue siendo útil, pero debe convivir con otras señales. El catálogo KEV de CISA identifica vulnerabilidades con evidencia de explotación conocida. EPSS, mantenido por FIRST, estima la probabilidad de que una CVE sea explotada en los próximos 30 días. KEV aporta evidencia observada; EPSS, probabilidad; CVSS, severidad. Ninguna fuente sabe si el activo está presente, alcanzable o vinculado con un proceso crítico de la organización.

Qué factores permiten decidir qué corregir primero

Una prioridad defendible comienza por validar producto, versión, configuración y alcance antes de movilizar una ventana urgente. Después conviene relacionar explotación conocida o probable, exposición, privilegios que habilitaría un abuso e impacto sobre el servicio, los datos y la continuidad.

Ese contexto cambia la lectura del reporte. Una vulnerabilidad media en una interfaz administrativa expuesta puede requerir más urgencia que una vulnerabilidad crítica presente en un componente deshabilitado. Del mismo modo, una falla en un servidor interno puede adquirir prioridad cuando forma parte de una cadena que conduce a identidades privilegiadas, respaldos o sistemas de producción. La superficie de ataque externa ayuda a reconocer activos públicos; la gestión de vulnerabilidades debe continuar el análisis y conectarlos con propietarios y consecuencias.

Convertir hallazgos en una cola que pueda gestionarse

El reporte técnico debe transformarse en trabajo asignado. Cada hallazgo necesita un activo confirmado, responsable, acción, plazo y evidencia de cierre. Las clases de atención pueden considerar criticidad y restricciones de cambio, pero no deberían convertirse en plazos universales. Las fechas obligatorias de CISA aplican a organismos federales civiles de Estados Unidos; para una empresa chilena, KEV funciona como señal dentro de su propio criterio de riesgo.

También debe existir una ruta cuando el parche no es viable. Segmentar, restringir acceso o deshabilitar una función puede reducir exposición mientras se prepara una solución definitiva. La excepción requiere dueño, justificación, control compensatorio y vencimiento. Si el activo está sin soporte, la decisión se acerca más a renovar, aislar o retirar que a prolongar el mismo ticket.

NIST trata el parcheo empresarial como mantenimiento preventivo. La SP 800-40 Rev. 4 incluye identificar, priorizar, instalar y verificar actualizaciones, bajo una estrategia acordada entre negocio y tecnología. Así se evita que seguridad entregue listas mientras operaciones asume sola el riesgo del cambio.

Cómo verificar que una vulnerabilidad realmente quedó cerrada

Cerrar no significa marcar el ticket como resuelto. La evidencia puede incluir versión instalada, configuración aplicada, nueva validación y comprobación del servicio. Una medida compensatoria debe verificarse desde la ruta que pretendía limitar. El reescaneo aporta evidencia, pero no demuestra por sí solo que todas las instancias recibieron la corrección.

Si el mismo hallazgo reaparece, el problema puede estar en el inventario, el despliegue, las imágenes base o la gestión de proveedores. Medir solo cuántas vulnerabilidades se cerraron premia el volumen. Resulta más útil observar exposición vencida, tiempo hasta validar, excepciones fuera de plazo, cobertura y reincidencia en servicios críticos.

Cuándo conviene una evaluación independiente

Una empresa puede necesitar apoyo externo cuando desconoce la cobertura de sus herramientas, acumula falsos positivos o no logra vincular hallazgos con activos. Antes de encargar pruebas, conviene distinguir el propósito mediante la comparación entre auditoría de seguridad y análisis de vulnerabilidades.

El servicio de Evaluación de Amenazas de AllDefense puede aportar una revisión focalizada de exposición y vulnerabilidades para convertir evidencia técnica en prioridades comprensibles. Si el problema está en el proceso, la trazabilidad o el cumplimiento de controles, una auditoría de seguridad permite evaluar por qué los hallazgos no se corrigen o vuelven a aparecer. La decisión útil no es producir otro listado: es establecer qué riesgo reducir, quién actuará y qué evidencia demostrará el resultado.

Fuentes consultadas

• NIST SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning.
• CISA: Known Exploited Vulnerabilities Catalog.
• FIRST: Exploit Prediction Scoring System.
• FIRST: CVSS v4.0 Specification.

Rodrigo Zamora

Cuando aparece una transferencia desconocida o una cuenta accede fuera de horario, la empresa necesita reconstruir lo ocurrido. Los logs de seguridad pueden aportar esa evidencia, pero acumular archivos no garantiza obtener una respuesta. Si falta el usuario, la acción ejecutada o la hora confiable, una plataforma costosa puede terminar mostrando actividad sin explicar su alcance.

La decisión para gerencia y TI no consiste solamente en cuánto almacenamiento comprar. Consiste en definir qué preguntas deberá responder la organización, qué sistemas generan los antecedentes y quién podrá analizarlos cuando exista una sospecha. Esa capacidad se construye antes del incidente; los eventos que nunca se registraron no aparecen al contratar una investigación.

Qué deberían responder los logs de seguridad

Un registro útil permite relacionar una identidad con una acción sobre un recurso, su resultado y un momento determinado. Por ejemplo, saber que alguien inició sesión no equivale a saber si modificó una cuenta bancaria, descargó documentos o cambió permisos. Cada pregunta puede requerir evidencia de una aplicación distinta.

La guía de logging de OWASP destaca el contexto que entregan las aplicaciones y que no necesariamente está disponible en los equipos de red. Esa diferencia importa al evaluar un servicio: conservar las conexiones de un servidor no reemplaza la trazabilidad de sus operaciones de negocio.

Pensemos en un cambio de datos de pago. Una revisión necesita distinguir la solicitud, la aprobación y la modificación efectiva. Si todo aparece bajo una cuenta compartida, el registro identifica una credencial, no necesariamente una persona. Correlacionar horarios ayuda, pero no convierte una inferencia en una atribución demostrada.

Centralizar no corrige lo que nunca se registró

Una plataforma central facilita consultar fuentes diferentes y puede apoyar la detección. Sin embargo, no corrige automáticamente campos incompletos, relojes inconsistentes ni aplicaciones que dejaron de enviar eventos. Antes de ampliar licencias conviene saber dónde existen esas brechas.

El Control 8 de CIS plantea recopilar, alertar, revisar y conservar registros para detectar, comprender o recuperarse de un ataque. La secuencia exige algo más que recepción: debe existir una responsabilidad sobre su uso. Un tablero sin errores de conexión puede convivir con un proceso crítico que nadie puede reconstruir.

Retener según la necesidad de investigar

La retención debe considerar cuánto puede tardar la empresa en detectar un problema y qué antecedentes necesitará después. Como ejemplo hipotético, guardar treinta días resultaría insuficiente si una irregularidad se descubre al conciliar operaciones de dos meses atrás. Aumentar el plazo para todas las fuentes, sin distinguir su utilidad, también puede encarecer una solución que sigue dejando vacíos.

La guía NIST SP 800-92 aborda la gestión de logs como una combinación de infraestructura y procesos organizacionales. Desde esa perspectiva, conviene separar la consulta rápida de información reciente del archivo histórico recuperable. La segunda opción puede ser más lenta y exigir un procedimiento de recuperación; ese tiempo debe conocerse antes de necesitarlo.

El plazo elegido también debe contrastarse con los contratos y requisitos aplicables a la actividad. No corresponde presentar una recomendación técnica como un período legal obligatorio para todas las empresas chilenas. La decisión requiere una justificación y un responsable, no solo aceptar el valor predeterminado de la herramienta.

Proteger los registros sin recopilar de más

Los propios logs pueden contener información sensible. OWASP recomienda evitar secretos como contraseñas o tokens de acceso y proteger los registros frente a lectura, modificación y eliminación indebidas. Registrar el cuerpo completo de una solicitud puede crear una exposición innecesaria cuando basta con identificar la operación y su resultado.

Además, concentrar administración del sistema y capacidad de borrar toda su evidencia merece una revisión de privilegios. El objetivo no es desconfiar de cada administrador, sino reducir la posibilidad de perder el rastro precisamente cuando una cuenta privilegiada es comprometida.

Qué pedir antes de contratar o renovar

En una plataforma tercerizada conviene precisar qué eventos se entregan, con qué detalle, durante cuánto tiempo y en qué formato pueden recuperarse. También importa conocer si su exportación depende de otra licencia o de una solicitud al proveedor. Tener acceso al portal no demuestra que la empresa pueda conservar evidencia fuera de él.

Una auditoría de seguridad puede contrastar esas condiciones con evidencia disponible. Como criterio de evaluación, proponer la reconstrucción de una operación autorizada permite observar vacíos concretos sin simular una intrusión. La asesoría estratégica ayuda a traducirlos en prioridades: ampliar cobertura, mejorar identidad, ajustar retención o acordar responsabilidades antes de comprar más capacidad.

Rodrigo Zamora

La presencia digital de una empresa rara vez termina en su sitio web oficial. Subdominios antiguos, portales de proveedores, accesos remotos, servicios en la nube y ambientes de prueba también pueden quedar visibles desde Internet. La superficie de ataque externa reúne esos puntos observables y muestra una realidad incómoda: un activo puede estar expuesto aunque el área de seguridad no sepa que existe o no tenga claro quién lo administra.

Qué integra la superficie de ataque externa

El concepto abarca los recursos tecnológicos a los que un tercero puede llegar desde Internet. Incluye aplicaciones web, direcciones IP públicas, concentradores VPN, interfaces de administración, servicios de correo, almacenamiento en la nube y dominios relacionados con la organización. También comprende la información técnica que permite vincular esos recursos, como certificados, registros DNS y tecnologías detectables de forma pública.

No todo activo visible representa una vulnerabilidad. Un portal publicado puede ser necesario y estar correctamente protegido. El riesgo aparece cuando la exposición es innecesaria, utiliza tecnología sin soporte, conserva una configuración débil o carece de un responsable capaz de decidir qué hacer con ella. Por eso, contar direcciones y puertos no basta: cada hallazgo necesita contexto empresarial.

El inventario interno no siempre refleja lo que ve Internet

Los inventarios suelen construirse desde compras, herramientas de gestión o registros de infraestructura. Esa información es valiosa, pero puede dejar fuera activos creados por un proyecto, una filial o un proveedor. Una migración también puede terminar sin retirar el servicio anterior. Meses después, el nuevo sistema está documentado y el antiguo continúa respondiendo en una dirección pública.

Las sucursales y servicios contratados agregan otra dificultad. Un equipo de acceso remoto instalado para resolver una contingencia puede permanecer conectado; una aplicación administrada por un tercero puede cambiar de dirección sin actualizar el inventario corporativo. La revisión externa sirve para contrastar lo registrado con lo que realmente puede descubrir cualquier persona fuera de la organización.

Visibilidad antes de evaluar vulnerabilidades

Un análisis de vulnerabilidades solo puede evaluar el alcance que recibe. Si una empresa entrega una lista incompleta de activos, los equipos desconocidos quedarán fuera aunque sean los más expuestos. La gestión de superficie de ataque invierte esa lógica: primero descubre y atribuye, luego valida qué pertenece a la organización y recién entonces incorpora los activos confirmados al proceso de evaluación.

Esto no reemplaza una auditoría ni un escaneo técnico. Responde una pregunta anterior: ¿qué existe afuera y quién debe hacerse cargo? El artículo sobre auditoría de seguridad y análisis de vulnerabilidades explica las diferencias entre esos enfoques. La visibilidad externa ayuda a que ambos trabajen sobre un perímetro más completo y verificable.

Priorizar por consecuencia, no por cantidad

Una fotografía de la exposición puede producir muchos datos, pero no todos merecen la misma urgencia. Conviene distinguir un sistema crítico de una página informativa, confirmar si procesa información sensible, revisar la fortaleza del acceso y determinar si la tecnología mantiene soporte. Una vulnerabilidad incluida en el catálogo de vulnerabilidades explotadas de CISA adquiere un peso diferente cuando está presente en un servicio alcanzable desde Internet.

La atribución también evita decisiones apresuradas. Un dominio con el nombre de la empresa podría pertenecer a una campaña fraudulenta y no a su infraestructura; un servicio desconocido podría ser legítimo y estar bajo contrato. Antes de bloquear, retirar o escalar un hallazgo, hay que reunir evidencia suficiente sobre propiedad, propósito y dependencia operativa.

Señales de una exposición difícil de gobernar

La falta de un propietario claro es una señal relevante. También lo son los certificados próximos a vencer en servicios que nadie reconoce, los subdominios que apuntan a plataformas abandonadas, las interfaces administrativas públicas y los activos que aparecen fuera del ciclo habitual de parches. Cuando distintas áreas contratan tecnología sin un mecanismo común de alta y baja, la superficie tiende a crecer con más rapidez que el inventario.

Descubrir un activo no resuelve el riesgo. Debe existir una ruta para validarlo, asignarle responsable, evaluar su necesidad y registrar la decisión. Si sigue expuesto, tendrá que incorporarse a monitoreo, gestión de vulnerabilidades y controles de acceso. Si ya no cumple una función, su retiro debe considerar dependencias y realizarse de forma controlada.

La superficie de ataque externa cambia con la empresa

Una revisión puntual entrega una línea base, pero comienza a envejecer cuando se publica una aplicación, cambia un proveedor o se abre una nueva sede. NIST CSF 2.0 y CIS Control 1 sitúan la identificación y gestión de activos como fundamentos del manejo del riesgo. En la práctica, esto exige combinar descubrimiento periódico con procesos internos que informen altas, cambios y retiros.

AllDefense puede apoyar esta revisión mediante su servicio de Evaluación de Amenazas, conectando la observación externa con el contexto del negocio. Cuando aparecen brechas de arquitectura, la segmentación de red empresarial puede limitar el alcance de un acceso inicial. El resultado útil no es un listado más extenso, sino una vista verificable que permita decidir qué corregir primero y qué exposición dejar de aceptar.

Para contrastar la exposición identificada con políticas, controles y evidencias de su empresa, revise el alcance del servicio de auditoría de seguridad de AllDefense.

Fuentes consultadas

CISA: Internet Exposure Reduction Guidance; NIST Cybersecurity Framework 2.0; CIS Control 1: Inventory and Control of Enterprise Assets; CISA: Known Exploited Vulnerabilities Catalog.

Rodrigo Zamora

Cuando una empresa solicita una ‘revisión de seguridad’, esa frase suele esconder preguntas muy distintas. La gerencia puede querer saber si los controles prometidos realmente existen, mientras el equipo técnico necesita identificar servidores expuestos, configuraciones débiles o software sin corregir. Ambas preocupaciones son legítimas, pero no conducen al mismo trabajo. Elegir una auditoría de seguridad cuando se espera un inventario técnico detallado —o pedir un análisis de vulnerabilidades para demostrar madurez de gestión— termina produciendo un informe correcto que no responde la pregunta importante.

La diferencia tampoco se reduce a que una evaluación sea más profunda que la otra. Cambia el objeto que se observa, la evidencia que se reúne y la decisión que el resultado permite tomar. Entender esa separación ayuda a definir un alcance útil, evitar expectativas irreales y destinar el presupuesto a la incertidumbre que hoy representa un mayor riesgo para la organización.

La auditoría examina controles; el análisis busca debilidades técnicas

Una auditoría de seguridad compara la realidad de la organización con criterios previamente definidos. Esos criterios pueden provenir de una política interna, un contrato, una norma, una exigencia regulatoria o un marco de control. El auditor no se limita a preguntar si existe un procedimiento: busca evidencia suficiente para establecer si fue aprobado, comunicado, aplicado y revisado con la frecuencia comprometida.

Por eso, una auditoría puede revisar responsabilidades, gestión de accesos, continuidad, proveedores, respaldo, respuesta ante incidentes, capacitación y seguimiento de hallazgos, además de componentes tecnológicos. La versión 2026 de ISO 19011 mantiene esa lógica al organizar la auditoría en torno a principios, gestión del programa, ejecución y competencia de quienes participan. El valor está en obtener una conclusión sustentada sobre el funcionamiento del sistema de gestión, no en acumular capturas de pantalla.

El análisis de vulnerabilidades parte desde otra pregunta: ¿qué debilidades técnicas pueden afectar los activos incluidos en el alcance? Para responderla se combinan herramientas automatizadas, validación profesional y contexto sobre redes, sistemas, aplicaciones o servicios expuestos. La guía técnica NIST SP 800-115 sitúa este tipo de pruebas dentro de las evaluaciones técnicas de seguridad y destaca que cada técnica tiene beneficios y limitaciones. Esa advertencia importa: detectar una condición no equivale todavía a comprender su impacto real en el negocio.

Un escaneo no reemplaza una auditoría, y una auditoría no reemplaza las pruebas técnicas

El resultado de un escáner puede revelar versiones vulnerables, servicios innecesarios o configuraciones que amplían la superficie de ataque. Sin embargo, no suele demostrar por sí solo quién aceptó ese riesgo, si existe una excepción vigente, si el activo tiene un responsable, si la corrección fue priorizada o si la organización verifica que los problemas no reaparezcan. Esas preguntas pertenecen al terreno del gobierno y de la eficacia de los controles.

A la inversa, una auditoría puede confirmar que existe un proceso formal de gestión de vulnerabilidades, con responsables, plazos y reportes. Aun así, esa evidencia no garantiza que la cobertura técnica sea completa ni que las herramientas estén identificando correctamente los activos relevantes. Un procedimiento impecable en el papel puede convivir con equipos fuera del inventario, credenciales con privilegios excesivos o servicios publicados sin autorización.

Esta es la razón por la que ambos trabajos se complementan, pero no deben confundirse. El análisis de vulnerabilidades aporta evidencia sobre condiciones técnicas. La auditoría determina, con un alcance y criterios definidos, si la organización gobierna esas condiciones de manera consistente. Uno observa principalmente la exposición; el otro evalúa cómo se decide, controla y demuestra la seguridad.

Qué información entrega cada evaluación a la gerencia

Un buen informe de vulnerabilidades no debería ser una exportación extensa de alertas ordenadas únicamente por severidad. Debería explicar qué activos fueron evaluados, qué limitaciones tuvo la revisión, cuáles hallazgos fueron validados y qué factores cambian su prioridad. Una vulnerabilidad técnicamente crítica puede tener una exposición limitada; otra, clasificada como media, puede afectar un servicio esencial o facilitar una cadena de ataque. La prioridad surge de combinar la evidencia técnica con el contexto operativo.

El informe de auditoría se estructura de otro modo. Relaciona criterios, evidencia y hallazgos para mostrar dónde existe cumplimiento, dónde hay desviaciones y qué controles no pueden demostrar eficacia. Su aporte para la gerencia es convertir observaciones dispersas en una visión sobre responsabilidades, consistencia y riesgo residual. También permite distinguir una falla puntual de un problema sistémico, como la ausencia de seguimiento o la falta de trazabilidad en decisiones sensibles.

En ambos casos, el informe debería hacer visible la incertidumbre. Ninguna evaluación razonable puede prometer que ‘no existen vulnerabilidades’ o que una organización está protegida frente a cualquier incidente. Un alcance excluye activos, una prueba representa un momento y una auditoría se basa en muestras. Explicar esas fronteras no debilita el resultado; permite usarlo sin convertirlo en una garantía que nunca pudo ofrecer.

Cuándo conviene priorizar un análisis de vulnerabilidades

El análisis técnico suele ser la mejor primera decisión cuando la principal duda está en la exposición de sistemas concretos. Puede ocurrir después de incorporar infraestructura, publicar un servicio, cambiar una arquitectura, integrar redes o descubrir que el inventario disponible no refleja el entorno real. También resulta pertinente cuando existen señales de deuda técnica y la organización necesita separar sospechas generales de hallazgos verificables.

En ese escenario, la evaluación de amenazas y vulnerabilidades ayuda a reconocer condiciones que podrían ser aprovechadas y a relacionarlas con activos y consecuencias. El alcance debe responder a la decisión posterior. Si el objetivo es priorizar correcciones en servicios expuestos a internet, incluir equipos sin relación con esos servicios puede consumir esfuerzo sin mejorar la respuesta. Si la preocupación es el movimiento lateral, limitarse al perímetro dejaría fuera una parte decisiva del problema.

También importa diferenciar análisis de vulnerabilidades y prueba de penetración. El primero busca cobertura y caracterización de debilidades dentro de un alcance; la segunda intenta validar, bajo reglas acordadas, si ciertas condiciones pueden encadenarse para alcanzar un objetivo. No todas las organizaciones necesitan comenzar por una explotación controlada. A veces el mayor valor proviene de conocer bien la superficie, corregir fallas evidentes y recién entonces validar escenarios de ataque relevantes.

Cuándo una auditoría de seguridad aporta más valor

La auditoría debe ocupar el primer plano cuando la pregunta es si los controles comprometidos funcionan y pueden demostrarse. Esto ocurre ante exigencias de clientes, directorios, contratos, normas o regulaciones, pero también cuando la organización ha invertido durante años en herramientas y no logra saber si el conjunto produce una reducción de riesgo coherente. La necesidad no es encontrar una falla aislada, sino evaluar el sistema que debería prevenirla, detectarla o corregirla.

Una señal frecuente es la distancia entre documentos y operación. Las políticas pueden asignar responsabilidades que nadie reconoce, los registros pueden existir sin revisión o los comités pueden reunirse sin decisiones trazables. Una auditoría bien diseñada no premia la cantidad de documentos. Contrasta lo declarado con entrevistas, registros, configuraciones y muestras de ejecución para determinar si el control tiene respaldo real.

El Cybersecurity Framework 2.0 de NIST refuerza esta mirada al presentar resultados de ciberseguridad que permiten comprender y mejorar la gestión del riesgo. Su utilidad para una auditoría o una revisión de madurez no consiste en imponer una herramienta específica, sino en ofrecer un lenguaje común entre gobierno, operación y negocio. La organización puede evaluar su situación actual, definir resultados esperados y explicar por qué ciertas brechas merecen prioridad.

Por qué muchas empresas terminan necesitando ambos enfoques

En organizaciones con cierta complejidad, la decisión rara vez es permanente. Una auditoría puede revelar que el proceso de gestión de vulnerabilidades carece de cobertura o que los plazos de corrección no se sustentan en riesgo. Ese hallazgo justifica una evaluación técnica focalizada. Del mismo modo, un análisis puede encontrar exposiciones repetidas en distintas áreas; cuando el patrón se repite, la causa probablemente supera la configuración de un equipo y exige revisar gobierno, responsabilidades o control de cambios.

El orden depende de la incertidumbre inicial. Si se desconoce qué activos están expuestos y qué tan urgente es corregirlos, la evaluación técnica puede aportar primero una base factual. Si existen múltiples reportes técnicos, pero nadie sabe por qué los problemas se mantienen abiertos o vuelven a aparecer, la auditoría puede explicar la falla de gestión. Encargar ambos trabajos sin una pregunta clara también es un error: aumenta el volumen de hallazgos sin asegurar una decisión mejor.

Una asesoría estratégica de ciberseguridad puede ayudar a ordenar esa secuencia cuando intervienen objetivos regulatorios, tecnológicos y comerciales. Lo importante es que cada evaluación tenga un propósito verificable: reducir una incertidumbre, respaldar una decisión y producir evidencia que pueda ser entendida por quienes asumirán el riesgo o financiarán la corrección.

La pregunta correcta no es cuál evaluación es ‘mejor’

Antes de contratar, conviene formular la decisión que el informe deberá sostener. ‘Necesitamos saber si los controles exigidos por nuestros clientes se aplican y dejan evidencia’ apunta a una auditoría. ‘Necesitamos conocer las debilidades de los servicios que acabamos de exponer’ apunta a un análisis de vulnerabilidades. ‘Tenemos hallazgos repetidos y no entendemos por qué no se cierran’ puede requerir ambos enfoques, probablemente en una secuencia definida.

Esa precisión también mejora la calidad de las propuestas. Permite acordar criterios, activos, procesos, exclusiones, profundidad de las pruebas, tipo de evidencia y destinatarios del informe. Sin ese marco, dos proveedores pueden cotizar actividades muy diferentes bajo el mismo nombre, y la comparación económica pierde sentido. El alcance más barato no necesariamente reduce la incertidumbre que motivó la evaluación.

Auditar y analizar vulnerabilidades son capacidades distintas dentro de una misma gestión de seguridad. La primera muestra si los controles se sostienen con evidencia y operan como fueron definidos. La segunda descubre y contextualiza debilidades técnicas dentro de un alcance. Elegir bien comienza por reconocer qué respuesta necesita hoy la empresa. Cuando esa pregunta está clara, el resultado deja de ser un documento para archivo y se convierte en una base útil para priorizar riesgo, inversión y responsabilidad.

Rodrigo Zamora

Durante mucho tiempo se habló de seguridad de acceso como si todo dependiera de que las personas eligieran una buena contraseña. Que fuera larga, difícil de adivinar, distinta para cada servicio y, ojalá, nunca compartida. Todo eso sigue siendo importante, pero hoy ya no basta.

La realidad es más incómoda: una contraseña siempre puede verse comprometida. Puede filtrarse, reutilizarse, ser capturada en una campaña de phishing, quedar guardada en un equipo inseguro o ser robada por malware. Por eso, cualquier sistema relevante que siga dependiendo solo de usuario y contraseña está funcionando con una debilidad conocida.

En ese contexto, la incorporación del segundo factor de autenticación en ClaveÚnica es una buena noticia, pero también deja una sensación inevitable: llegó tarde. ClaveÚnica no es una cuenta cualquiera. Es una identidad digital que permite acceder a múltiples servicios del Estado, realizar trámites y consultar información sensible. Por lo mismo, su protección debió evolucionar antes hacia mecanismos más robustos.

El punto no es criticar el avance en sí. Implementar 2FA es correcto y necesario. El problema es que este tipo de controles ya no debería verse como una mejora futura, sino como una base mínima de seguridad. Cuando una credencial abre muchas puertas, protegerla solo con una contraseña deja de ser razonable.

La misma reflexión aplica directamente a los portales corporativos. Muchas empresas todavía mantienen accesos a sistemas internos, portales de clientes, proveedores, recursos humanos, plataformas SaaS, VPN, correos corporativos o sistemas administrativos protegidos únicamente por contraseña. En la práctica, eso significa confiar demasiado en un dato que podría estar en manos de un tercero sin que nadie lo sepa.

El 2FA, y mejor aún el MFA, ya no debería ser opcional en sistemas importantes. No se trata de dificultar el trabajo de los usuarios ni de llenar los procesos de fricción innecesaria. Se trata de aceptar que la contraseña por sí sola no prueba lo suficiente. Si el atacante ya la conoce, el sistema debe tener una barrera adicional antes de permitir el acceso.

También es importante no conformarse con cualquier segundo factor. Un código enviado por correo puede ser mejor que no tener nada, pero no debe considerarse el punto final. El correo también puede ser comprometido. Para sistemas críticos, el camino debería avanzar hacia métodos más seguros, como aplicaciones autenticadoras, llaves de seguridad, passkeys o mecanismos resistentes a phishing.

Para las empresas, la lección es simple: no esperar a sufrir un incidente para reforzar los accesos. Todo portal que permita consultar, modificar, descargar o aprobar información sensible debería contar con MFA. Esto aplica especialmente a cuentas administrativas, correo corporativo, VPN, sistemas financieros, plataformas de recursos humanos, portales de clientes, proveedores, gestores documentales y aplicaciones donde se manejen datos personales o información crítica.

La seguridad no debe medirse solo por la ausencia de incidentes conocidos. También debe medirse por la capacidad de anticiparse a riesgos que son razonablemente probables. Y hoy, el robo o uso indebido de credenciales no es una amenaza excepcional. Es una de las formas más comunes de acceso inicial.

ClaveÚnica deja una lección útil para el sector público y privado: cuando una identidad digital concentra demasiado valor, su protección no puede depender de una sola contraseña. En los portales corporativos ocurre exactamente lo mismo. Si una cuenta permite acceder a información sensible o ejecutar acciones relevantes, el MFA no debería ser una opción avanzada, sino una condición básica de seguridad.

La contraseña puede fallar. El diseño de seguridad debe asumirlo desde el inicio.

Rodrigo Zamora Nelson

Rodrigo Zamora Nelson desarrolla su trabajo en torno a la ciberseguridad, la seguridad de la información y la gestión de riesgos tecnológicos. Su enfoque combina análisis técnico, visión de gobierno y comprensión del impacto que los incidentes de seguridad pueden generar en la operación, continuidad y reputación de una empresa.

Sus principales áreas de interés incluyen la respuesta estratégica a incidentes, la evaluación de controles de seguridad, el análisis de amenazas, la auditoría de seguridad, la continuidad operacional y la definición de lineamientos para fortalecer capacidades defensivas en entornos corporativos.

También participa en programas de formación profesional vinculados a ciberseguridad, ciberdefensa y respuesta a incidentes, aportando a la transferencia de conocimiento técnico y estratégico hacia profesionales del área.

alldefense.cl