El proceso de descubrimiento y tratamiento de una vulnerabilidad recorre generalmente caminos similares. Un individuo, por lo general externo a la empresa, descubre algún tipo de falla en un software o sistema determinado. Este puede ser, por ejemplo, en una aplicación web (el portal web de la empresa) o también en algún producto de la misma empresa (por ejemplo alguna aplicación desarrollada por la misma), entre otros.
El proceso continúa mediante un informe por parte del individuo hacia la empresa detallando el tipo de vulnerabilidad y cómo esta puede ser explotada.
De aquí la empresa en cuestión opta por una de las varias alternativas para responder:
- Responde con un mensaje automatizado, como por ejemplo un e-mail, indicando que se va a ocupar de resolverlo.
- Responde de manera fluida y amable, poniéndose a disposición y mostrando interés verdadero en resolver el problema.
- No existe ningún tipo de respuesta. Este es el caso de grandes empresas que fueron alertadas sobre fallos en sus sistemas y éstas hicieron caso omiso a las mismas dando lugar a ataques posteriores con fugas importantes de información y hasta interrupción de sus servicios.
Otro aspecto que también hay que destacar es la conducta de aquella persona que descubre la vulnerabilidad. Muchas veces estos individuos buscan nuevas fallas con el fin de obtener beneficios personales y no de informar a los desarrolladores sobre lo descubierto. En estos casos la vulnerabilidad queda expuesta cuando ya ha obtenido repercusión por el alcance que esta tuvo sobre la red. A modo de ejemplo podemos citar el caso de Mysql.com, el cual tuvo mucha repercusión debido a que el ataque fue mediante inyección SQL.
En cuanto al rol de la empresa, muchas veces las alertas de vulnerabilidades no son rsepondidas de forma eficiente, como por ejemplo cuando no se repara el problema en cuestión. Esto suele deberse a que la organización probablemente no cuenta con un sistema de gestión para actualizar y reparar aplicaciones. Otras veces, simplemente por falta de conocimiento, las personas que reciben el reporte no analizan el alcance de la vulnerabilidad y por lo tanto le dan una jerarquía muy baja dentro de sus prioridades.
Es en estos casos, como ya se mencionó, una mala respuesta puede causar la exposición indebida y reiteradas veces esto ha finalizado en incidentes de seguridad para la organización en cuestión. En ese contexto, aquí algunos consejos que pueden ser de utilidad para las empresas al momento de gestionar el reporte de una vulnerabilidad:
- Responda al correo de aviso amablemente, agradezca por el reporte y manifieste su compromiso en reparar el incidente. Aún si está enojado, una vez consumado el reporte lo más importante debe ser estar al tanto del mismo y priorizar la reparación. La falta de respuesta o un mensaje agresivo puede ser contraproducente para la organización.
- Remita con urgencia el mensaje a quienes puedan reparar la vulnerabilidad. Si no conoce quién podría hacerlo, escale la información lo suficiente hasta averiguarlo. Una vez que una vulnerabilidad es conocida, debe ser prioritario la reparación de la misma.
- Al haber sido el receptor del mensaje, solicite ser informado cuando la vulnerabilidad sea reparada.
- En caso de no obtener respuesta, realice un seguimiento interno y escale de ser necesario para que la vulnerabilidad sea corregida.
- Una vez corregida la vulnerabilidad, envíe un mensaje a quien reportó la misma indicando que esta ha sido reparada.
- Finalmente, realice un resumen de lo ocurrido y reporte a la persona responsable de la Seguridad de la Información (CIO, CSO, CISO, COO o incluso CEO; según la organización).
Finalmente, vale destacar que más allá de quién recibe el reporte, este tipo de incidentes deben ser utilizados para optimizar el proceso (¡o crearlo!) de gestión de riesgos, de forma tal de minimizar la probabilidad de que puedan ocurrir, o mejorar la respuesta en caso de ocurrencia. Para esto, es recomendable realizar periódicamente análisis de la seguridad, como los brindados por ESET Security Services, de forma tal de poder conocer cuáles son las vulnerabilidades o aspectos de mejora en la organización.
Fernando Catoira
Analista de Seguridad
