Una evaluación de vulnerabilidades ayuda a identificar y analizar las debilidades en un conjunto de sistemas acordado. Una prueba de penetración verifica si estas debilidades pueden utilizarse para lograr un objetivo específico, como el acceso a datos protegidos. Ambos enfoques son útiles, pero responden a diferentes preguntas. Para elegir una prueba, primero defina la decisión que sus resultados deben respaldar.
Si necesita una lista de problemas para la remediación regular, comience con una evaluación de vulnerabilidades. Si necesita verificar una ruta de ataque específica o la resiliencia de una aplicación importante en un escenario definido, considere una prueba de penetración. Ningún informe garantiza la protección contra todos los ataques. Cada prueba tiene límites en el tiempo, el alcance, el acceso y las acciones permitidas.
Comprenda qué verifica cada enfoque
Evaluación de vulnerabilidades: desde el descubrimiento hasta los hallazgos verificados
Una evaluación puede incluir el escaneo automatizado, las comprobaciones de configuración y el análisis manual de los resultados. Un escáner compara los componentes y su estado descubiertos con las señales conocidas de problemas. Un especialista confirma si los hallazgos son aplicables, elimina duplicados y falsos positivos, evalúa las consecuencias y propone acciones. Por lo tanto, la exportación de un escáner no es equivalente a una evaluación completa.
Una prueba externa muestra la parte de un sistema accesible externamente. Una prueba interna examina las condiciones dentro de una red o entorno acordado. La prueba con credenciales puede revelar más sobre versiones y configuraciones que la observación externa, pero su cobertura depende de los permisos otorgados y el inicio de sesión exitoso. El fallo en la autenticación del escáner no prueba la ausencia de vulnerabilidades. Elija estas opciones para la tarea, en lugar de asumir que un método es el mejor.
Prueba de penetración: verificar un escenario acordado
Los probadores investigan el objetivo autorizado y tratan de confirmar una ruta hacia un resultado significativo. Pueden combinar varias debilidades que parecen menos graves individualmente. El trabajo combina herramientas y análisis manual. La explotación, el aumento de privilegios, el acceso a los datos y la prueba de la respuesta de los controles de protección solo están permitidos dentro de los límites acordados.
Una prueba no tiene que cubrir todos los dispositivos y todos los posibles ataques. A veces, la evidencia segura de un posible acceso, sin copiar datos reales, es suficiente para confirmar un riesgo. Las reglas del juego definen la profundidad. El fallo en la reproducción de un ataque dentro del tiempo asignado no significa que la ruta sea imposible.
Compare los métodos según las condiciones de trabajo
|
Criterio |
Evaluación de vulnerabilidades |
Pruebas de penetración |
|---|---|---|
|
Pregunta principal |
¿Qué debilidades se encontraron, qué afectan y qué necesita ser corregido? |
¿Pueden debilidades específicas o su combinación lograr el objetivo acordado? |
|
Alcance |
Un conjunto acordado de activos, servicios y métodos de acceso. A menudo se necesita una cobertura amplia y repetible. |
Aplicaciones, entornos o escenarios acordados. El alcance puede ser estrecho o amplio según la tarea. |
|
Método |
Escaneo, revisión de la configuración y análisis para determinar si los hallazgos son aplicables. |
Investigación de escenarios, pruebas manuales y confirmación autorizada de la viabilidad de un ataque. |
|
Autorización |
Se requiere la aprobación del propietario, así como la definición de límites, métodos y condiciones de inicio. |
Se necesitan reglas escritas que especifiquen claramente las acciones permitidas y prohibidas. |
|
Riesgo operativo |
Las pruebas activas también pueden generar carga o interrumpir un servicio sensible. |
Los intentos de explotación aumentan el riesgo de impacto; se necesitan condiciones de parada y recuperación. |
|
Resultado |
Una lista verificada de hallazgos, evidencia, aplicabilidad, recomendaciones y limitaciones de alcance. |
Rutas confirmadas, resultados obtenidos, limitaciones, evidencia y recomendaciones. |
|
Frecuencia |
Repetir según el nivel de riesgo, los cambios y los requisitos aplicables. La automatización ayuda, pero no reemplaza el análisis. |
Realizar cuando se necesita probar un escenario, después de cambios significativos y de acuerdo con los requisitos aplicables. |
|
Limitación principal |
No todos los hallazgos de escaneo son reales; errores desconocidos y lógica compleja pueden permanecer sin detectar. |
El tiempo, el conocimiento del equipo y las acciones permitidas limitan la profundidad. No se garantiza obtener resultados exhaustivos. |
El tamaño de la empresa por sí solo no determina el método. Un pequeño desarrollador puede necesitar una prueba exhaustiva de una aplicación de cliente, mientras que una gran organización necesita evaluaciones periódicas en muchos dispositivos. Compare las propuestas con el mismo alcance y resultado esperado. El costo depende de la complejidad, el acceso, el esfuerzo manual, la elaboración de informes y la reevaluación. Un precio o duración universal no sería útil.
Elija la prueba adecuada para la tarea
|
Situación |
Elección práctica |
Condición para obtener un resultado útil |
|---|---|---|
|
No existe una lista fiable de debilidades para los sistemas gestionados |
Una evaluación de vulnerabilidades con cobertura y aplicabilidad verificadas. |
Los propietarios de activos y las personas capacitadas para analizar y solucionar los hallazgos están disponibles. |
|
El acceso a los datos de otros usuarios debe ser probado antes de lanzar una aplicación importante |
Pruebas de penetración dirigidas con escenarios y cuentas autorizadas para diferentes roles. |
El entorno, los datos seguros y las reglas de prueba están preparados; los desarrolladores están listos para solucionar problemas. |
|
Existen herramientas de protección, pero su capacidad para bloquear una ruta de ataque específica no está clara. |
Probar el escenario acordado. Si es necesario, probar la detección y la respuesta por separado. |
La evaluación de la respuesta está incluida en la tarea, con roles y métodos de notificación acordados. |
|
Existe una larga lista de problemas conocidos sin acciones asignadas. |
Primero, analizar, priorizar y solucionar los hallazgos verificados. |
Realizar una nueva prueba para resolver una incertidumbre específica, en lugar de reemplazar el trabajo en problemas conocidos. |
|
La infraestructura ha cambiado o se ha solucionado un problema importante. |
Reevaluar el alcance afectado o realizar una prueba dirigida de la ruta de ataque anterior. |
El cambio que se está verificando y cualquier dependencia relacionada que el trabajo pueda haber afectado son claros. |
Después de un incidente, primero realizar la respuesta acordada, preservar la evidencia y limitar el impacto. Una prueba de penetración programada no reemplaza una investigación. Acordar pruebas y rutas de ataque restantes después de la estabilización para que no interfieran con la recuperación y el análisis.
Una evaluación de cumplimiento, un programa para que investigadores externos encuentren errores y un ejercicio de un equipo de seguridad tienen sus propios objetivos y reglas. No son sinónimos automáticos de las pruebas de penetración. Si el cliente espera pruebas de detección o respuesta de empleados, inclúyelas por separado en la tarea en lugar de tratarlas como una parte obligatoria de cada prueba.
Preparar el alcance y las condiciones de trabajo seguras.
Obtener la autorización del propietario del sistema autorizado. Para servicios externos e infraestructura en la nube, revise los términos del proveedor. Un contrato de una empresa con un probador no autoriza a probar los recursos de otra persona. Registrar las direcciones, aplicaciones, cuentas y entornos permitidos. Especificar las exclusiones, los impactos prohibidos y el proceso para aprobar los cambios en el alcance por separado.
- Indicar el objetivo, las fechas, el período de trabajo, el punto de partida y la información que el equipo recibe con antelación.
- Definir si están permitidos los controles activos, los intentos de explotación, las pruebas del personal y el acceso a los datos. La ausencia de una prohibición no sustituye a la autorización.
- Asignar contactos de operación y emergencia, condiciones de parada inmediata y un proceso de reanudación.
- Acordar los límites de carga, las medidas de recuperación y la preparación de copias de seguridad, en caso de que las pruebas puedan afectar a las operaciones. Discutir primero un método de prueba seguro para sistemas sensibles.
- Describir la protección de los resultados, la retención de pruebas, la entrega de informes y la eliminación del acceso y los artefactos temporales. Las contraseñas y los datos confidenciales no deben aparecer en informes accesibles al público.
La cantidad de información inicial también afecta al resultado. Las pruebas sin modelos de información de diseño internos limitan el conocimiento, pero el descubrimiento consume tiempo. Proporcionar la arquitectura y el acceso permite una prueba más profunda de las condiciones seleccionadas. Esto no es una escala de calidad. El enfoque debe adaptarse a la pregunta del cliente. Registrar la información proporcionada y las restricciones activas para que los resultados puedan compararse.
Acordar el informe y seguir los hallazgos a través de la verificación de la remediación.
¿Qué deben contener los resultados?
- Conclusión breve para el responsable del proceso: qué se probó, qué se encontró, y qué decisión es necesaria.
- Alcance actual, fechas, métodos, acceso, exclusiones y comprobaciones fallidas. Los activos no probados deben seguir visibles en el informe.
- Para cada hallazgo: activo afectado, condiciones desencadenantes, evidencia, nivel de confianza y posibles consecuencias.
- Recomendaciones con un efecto esperado claro. Las pruebas de penetración también necesitan una descripción de la ruta confirmada y el resultado obtenido dentro de los límites permitidos.
- El proceso para notificar los hallazgos críticos durante las pruebas, los criterios de re-prueba y las reglas para entregar el informe técnico detallado.
La severidad técnica ayuda a comparar los hallazgos, pero no reemplaza la evaluación de su importancia para un sistema específico. La prioridad de la remediación también considera la accesibilidad de la ruta de ataque, la explotación confirmada, el papel del activo y las restricciones existentes. Mantenga la matriz de prioridad detallada por separado. La asignación de la prueba debe proporcionar suficiente evidencia para completarla.
Quién es responsable después de la entrega del informe
Asigne un responsable a cada problema confirmado y un implementador para su solución. Acuerden sobre el plazo, las dependencias y una ventana de cambios segura. Si un hallazgo es objeto de discusión, solicite una comprobación de aplicabilidad y conserve la justificación. Elimine los falsos positivos mediante evidencia, no porque la remediación sea inconveniente. Documente cualquier imposibilidad de realizar el cambio de inmediato como una decisión temporal con un responsable y fecha de revisión.
Después del cambio, pruebe el componente relevante y las condiciones que anteriormente desencadenaron el problema. Para una cadena de ataque confirmada, verifique que la ruta al objetivo ha sido eliminada, en lugar de simplemente un hallazgo visible. Pruebe la operación de la aplicación por separado. Una re-prueba puede confirmar una solución específica, pero no hace que todo el entorno sea permanentemente seguro. Devuelva los resultados al proceso regular de gestión de vulnerabilidades.
Confirme la frecuencia de las pruebas y los formatos requeridos en comparación con los contratos, los requisitos y su alcance aplicables. No infiera la misma obligación para cada empresa simplemente por el nombre de una industria o estándar. Solicite el requisito y el criterio de aceptación exactos antes de elegir un proveedor. La evaluación de vulnerabilidades y las pruebas de penetración pueden complementarse, pero una no satisface automáticamente un requisito para la otra.
Si necesita primero una imagen verificada de las debilidades técnicas, discuta la tarea con los responsables de la seguridad a través de la página Evaluación de seguridad. Acuerden sobre el alcance, la información inicial y los resultados de la evaluación esperados.
