El pentest dice que corrijamos en 30 días: ¿son realistas los tiempos habituales de cierre de vulnerabilidades?

Seguro que al menos la mitad de los hallazgos medios son falta de cabeceras HTTP, algoritmos de cifrado débiles o exposición de la versión del software. Esos los cierras todos juntos en medio día desde los archivos de configuración del servidor o del proxy en la nube, sin tocar una sola línea de código.

Llama a la empresa de pentest ya mismo. Diles: "Por capacidad de desarrollo vamos a corregir las críticas y altas primero y queremos validar esas, para las medias pedimos más tiempo". No suelen poner pegas para ampliar el plazo del contrato a 60 días.

Los plazos de resolución aceptados en el sector suelen ser: 1) Críticas en un máximo de 7 a 14 días, 2) Riesgo alto en un máximo de 30 días, 3) Riesgo medio en 60 a 90 días, 4) Riesgo bajo en 180 días o en una ventana de mantenimiento adecuada.

edit: he corregido unas erratas.

Las empresas de auditoría meten presión con el "hay que arreglarlo todo en 30 días" para no retrasar su propia agenda y cerrar el expediente rápido. Ningún cliente B2B te va a cancelar un contrato por una vulnerabilidad media si le das una justificación lógica, no escribas código a lo loco por el pánico.

si le metes 28 fallos a un solo dev vas a retrasar las entregas del producto principal y los parches hechos con prisas van a crear nuevos agujeros. dile q se centre solo en las 3 criticas.

Hace dos años recibimos un informe parecido y sepultamos a nuestro único dev en tareas del pentest durante tres semanas. Al final se retrasaron un mes las funciones de clientes que tenían que salir a producción y se nos fastidió el flujo de caja. Luego nos dimos cuenta de que 15 fallos medios del informe se podían mitigar simplemente con restricciones de red interna. Tu prioridad siempre debe ser equilibrar el negocio que da dinero real con el riesgo de ataque efectivo.

Prepara un Plan de Remediación de Seguridad para presentárselo a tu cliente. Para los procesos de compliance corporativo suele ser suficiente con detallar punto por punto las fechas objetivo para las vulnerabilidades críticas y altas, y las medidas temporales adoptadas para las de nivel medio.

Arreglad las tres críticas ya y mandadle al cliente un calendario a tres meses para el resto.

La respuesta de arriba ha dado en el clavo. Si no lo pones por escrito desde el principio, luego surgen discusiones.

muchas gracias, lo proaré hoy.

Yo también tengo curiosidad.

Muchas gracias, lo probaré hoy. Todos los que se apresuran con tiempos de cierre de vulnerabilidades se atascan en el mismo punto.

Si el camino de la notificación es largo, la notificación no llega; una notificación que no llega significa un incidente detectado tarde. Corrijanme si me equivoco.

Si vas por ahí resuelve esto desde el principio. El error cometido por tiempos de cierre de vulnerabilidades suele ser reversible, pero caro.

Esto también tiene su parte de medición. Empezad con una pequeña prueba, no lo integréis todo de golpe.

Yo seguiría por ese camino.

A mí me pasó justo al revés, por eso escribo. La mayoría de los incidentes no empiezan por una vulnerabilidad, sino por una contraseña filtrada.

Tomar notas durante dos semanas da mejores resultados que estimar seis meses. Corrijanme si me equivoco.

Guardado.

Hace mucho que oímos eso, pero a nosotros nunca nos pasó así. Las soluciones que funcionan a pequeña escala se rompen al crecer, aprendí esto tarde.

Tomar medidas sin hacer inventario es dejar abierta una puerta que no ves.

Lo escribo para que no cometan el mismo error. Que la copia de seguridad sea accesible en la misma red y con la misma identidad la convierte en parte del objetivo.

Eso es todo, disculpa si me he extendido demasiado.