Está a punto de salir el nuevo “megaproyecto” web de la compañía y como desgraciadamente sucede en algunas ocasiones, los aspectos de seguridad no han sido revisados previamente a la puesta en producción. Para solventar esto, a última hora recae sobre el equipo de explotación la responsabilidad de auditar el sistema, detectar las posibles vulnerabilidades y decidir si se pueden arreglar, o si por el contrario son de tal magnitud que impiden la salida a producción del proyecto. La presión por parte de la organización en estos momentos es alta frente al equipo de explotación, por lo que las recomendaciones y decisiones que se tomen deben ser firmes y estar fuertemente razonadas.
El equipo técnico auditor mediante la utilización de ciertas herramientas automáticas y otras manuales entrega el informe, en el que aparecen tres vulnerabilidades de criticidad “grave”, cinco de criticidad “media” y tres de vulnerabilidad “baja”. ¿Qué hacemos ahora?
En primer lugar, cualquier responsable en esta situación lo primero que pide es que se solucionen todas las vulnerabilidades, y normalmente un alto numero de ellas son de resolución mas o menos sencilla: cambios en parámetros de la configuración, actualizaciones de versión en productos que no tienen interrelaciones, eliminado de ejemplos de configuración o funcionalidades innecesarias. Bien, con eso eliminamos una parte, pero en nuestro caso hipotético nos encontramos con que seguimos teniendo dos graves, tres medias y una baja. ¿Qué hacer en estos casos?
El siguiente paso es analizar la clasificación habitual de grave, media o baja, ya que es claramente insuficiente y dependerá mucho del proyecto y de la vulnerabilidad especifica. Por ejemplo, una vulnerabilidad grave que produzca una denegación de servicio, es realmente grave si se trata de un servicio en el que la disponibilidad sea un elemento indispensable, pero puede ser una vulnerabilidad aceptable en casos en los que una pérdida de servicio temporal es tolerable. Una vulnerabilidad de XSS puede ser perfectamente aceptable si afecta a una web estática, en la cual no se puedan robar ningún tipo de credenciales ni interactuar con la pagina, si bien hay que tener en cuenta que aquellos XSS que permiten modificar el resultado en el navegador haciendo parecer contenido licito puede llevar a malentendidos como los recientes de la pagina española de la Unión Europea (aunque no se pueda llegar a ella de manera directa sino a través de un enlace como si fuera phising).
En general hay que analizar con detalle como afecta cada una de las vulnerabilidades a las funcionalidades del servicio que se ofrece, y una vez hemos determinado cuantas vulnerabilidades tenemos y cuáles son sus implicaciones, si existe alguna especialmente grave, el siguiente paso no debería tener mucho misterio, aunque decisiones de ese tipo no siempre son fáciles de tomar ni dependen del personal técnico: o se arregla el problema, o no se sale a producción. Por suerte o por desgracia, en ocasiones existen criterios económicos y compromisos de otro tipo que deja poco margen de libertad, por lo que no queda otra que reducir al máximo la vulnerabilidad, trabajar para eliminarla lo antes posible, y rezar si es uno creyente.
Estas clasificaciones sobre las que he descrito de manera informal se encuentran estandarizadas y normalizadas por el FIRST; los detalles están en http://www.first.org/cvss/cvss-guide.html. Para acabar, me he permitido la libertad traducir las clasificaciones generales de vulnerabilidades:
Métrica Base
- Vector de acceso (Access Vector (AV))
- Local: vulnerabilidades sólo explotables desde el equipo local.
- Red adyacente: Solo explotables desde la misma red (ataques de N2 por ejemplo).
- Remoto: Accesibles desde cualquier acceso remoto de red.
- Complejidad de acceso (Access Complexity (AC))
- Alta: Complejidad en el ataque, combinación de ataques y de circustancias.
- Media: Complejidad media para un grupo de usuario.
- Baja: Configuracion y usuarios por defecto.
- Autenticación: Describe si…
- Múltiple: Si se requieren varias autenticaciones para poder explotar la vulnerabilidad.
- Simple: Si sólo se requiere una autenticación para poder explotar la vulnerabilidad.
- Ninguna: Si no se requiere autenticación para poder explotar la vulnerabilidad.
- Impacto en la confidencialidad: Si se ve afectada la confidencialidad.
- Impacto en la integridad: Si se ve afectada la integridad.
- Impacto en la disponibilidad: Si se ve afectada la disponibilidad.
Métricas temporales
- Explotabilidad: Si existen o no exploits disponibles.
- Facilidad de corrección:Si es fácil de solucionar.
- Fiabilidad del informe de vulnerabilidad: En ocasiones se anuncia la existencia de la vulnerabilidad pero no se confirman las fuentes.
Métricas de entorno
- Daños colaterales: Posibilidades que se produzcan daños económicos o humanos por esta vulnerabilidad.
- Distribución de equipos vulnerables: Si el número de equipos que tienen la vulnerabilidad es elevado o no.
- Requisitos de seguridad: Si cumple con los requisitos de seguridad comprometidos por política.
Con esta clasificación el estándar define una serie de ponderaciones para obtener una puntuación exacta que resulta útil para comparar productos, organizaciones, auditorias, etc. Volviendo al origen de este artículo, una valoración global no creo que sea útil para evaluar y decidir si una vulnerabilidad te impide o no que un proyecto pase a producción, por lo que separar dicho valor agrupado mediante esta clasificación es una buena aproximación para analizar el detalle, y en base a éstos tomar las decisiones adecuadas.
En todo caso, lo que hay que tener claro es que antes de asumir el riesgo de tener una vulnerabilidad, por muy leve que sea, hay que conocer todos los detalles y tomar la decisión adecuada. Cosa que, como todos sabemos, no siempre es fácil.
