Un servicio de producción crítico para el negocio parece vulnerable a un exploit de corrupción de memoria que podría hacerlo caer. ¿Qué haces?
Respuesta breve
Las reglas de enfrentamiento suelen excluir la denegación de servicio en producción, y una caída no planificada causa un daño real al negocio y puede anular el compromiso. Verifica primero el alcance; si una prueba de concepto destructiva no está autorizada, demuestra la vulnerabilidad por medios más seguros y documenta claramente el impacto probable. Lanzar el exploit por una captura de pantalla es temerario. Ejecutarlo repetidamente por «métricas de fiabilidad» multiplica la caída. Omitirlo en silencio oculta al cliente un riesgo serio y explotable.
Provocar una caída en un sistema crítico para el negocio es una de las formas más rápidas de que una prueba de penetración cause un daño real y pierda la confianza del cliente. Los exploits de corrupción de memoria son intrínsecamente frágiles —un casi acierto a menudo tumba el servicio en lugar de otorgar control limpio—, por lo que exigen una cautela adicional frente a la producción en vivo.
Por qué confirmar el alcance y probar de forma segura es lo correcto
Empieza por las reglas de enfrentamiento: muchas excluyen explícitamente la denegación de servicio y las pruebas destructivas contra producción. Si las pruebas propensas a caídas no están autorizadas, no lanzas el exploit. En su lugar, demuestra la vulnerabilidad mediante señales más seguras —huella de versión, disparadores sin caída, una prueba controlada contra un entorno de pruebas o una copia aislada, o evidencia de que la ruta de código vulnerable es alcanzable— y documenta claramente el impacto probable y la explotabilidad. Si una verdadera prueba de concepto es imprescindible, propón una ventana de mantenimiento o una réplica fuera de producción para que el cliente pueda consentir el riesgo.
Por qué las demás opciones están mal
- Lanzar el exploit por una captura de pantalla. Una caída no es una prueba limpia: es una interrupción. Provocar una indisponibilidad no planificada en un servicio crítico puede causar pérdidas financieras, incumplimientos de SLA y la terminación del compromiso.
- Ejecutarlo repetidamente por métricas de fiabilidad. Esto multiplica el daño. Las caídas repetidas en producción convierten una sola mala decisión en una interrupción sostenida, justo lo que el cliente te paga por evitar.
- Omitirlo en silencio. Un fallo de corrupción de memoria alcanzable en un servicio crítico es un hallazgo de gravedad alta. Ocultarlo porque probarlo es arriesgado deja al cliente ciego ante una amenaza seria. La vía profesional es reportarlo con las salvedades adecuadas.
Qué evalúa un entrevistador
Quiere criterio en la tensión entre exhaustividad y seguridad. La respuesta fuerte ni tumba imprudentemente la producción ni omite cobardemente el problema: delimita el alcance, prueba de forma segura, propone una manera controlada de confirmar y documenta con honestidad.
Posibles preguntas de seguimiento
- ¿Cómo evidencias un fallo de corrupción de memoria sin provocar una caída?
- ¿Qué propondrías para confirmar la explotabilidad de forma segura, por ejemplo una ventana de mantenimiento o un entorno de pruebas?
- ¿Cómo comunicas la incertidumbre residual cuando no puedes probar plenamente la explotación?