Proceso de gestión de vulnerabilidades

La gestión de vulnerabilidades debe ser un punto prioritario en el programa de seguridad de cualquier organización. Aunque tener todos los sistemas y aplicaciones parcheados y sin vulnerabilidades conocidas no es garantía de no poder sufrir un incidente, sí que reduce en gran medida la probabilidad de que ocurra.

Sin embargo, no siempre es sencillo implementar un proceso que sea adecuado y eficiente. A continuación os propongo un posible proceso a seguir para la gestión del ciclo de vida completo de las vulnerabilidades y un ejemplo del mismo esperando que os pueda ser de utilidad.

Procedimiento

1. Identificar vulnerabilidades. Las vulnerabilidades pueden ser detectadas a partir de fuentes diversas, las más comunes son las siguientes:
a. Escaneos (de infraestructura y de aplicación).
b. Pentesting.
c. Auditorías o revisiones de seguridad (tanto técnicas como no técnicas).
d. Notificaciones de terceros.

2. Aceptar la vulnerabilidad: El primer paso a realizar una vez identificada una vulnerabilidad es analizarla y realizar las pruebas que sean necesarias para verificar que la vulnerabilidad realmente existe, es decir, que no se trata de un falso positivo y tener claro en qué consiste dicha vulnerabilidad:
a. Identificar su valor CVSS
b. Saber a qué activos de la compañía está afectando
c. Saber si se tiene constancia de que la vulnerabilidad está siendo activamente explotada en la propia compañía o en otras compañías.

3. Clasificar las vulnerabilidades en función del riesgo: Las vulnerabilidades deben ser clasificadas y priorizadas en función del riesgo que supongan para la organización. A continuación propongo un posible método que he desarrollado para realizar esta clasificación y priorización, pero podría utilizarse cualquier otro método alternativo que se considerara conveniente:
a. Puntuación
i. CVSS  > 3 +1 punto.
ii. CVSS  > 6 +2 puntos.
iii. CVSS  > 8 +3 puntos.
iv. CVSS  > 9 +4 puntos.
v. La vulnerabilidad puede ser explotada remotamente -> +4 puntos
vi. La vulnerabilidad afecta a algún servidor o servicio crítico -> +3 puntos
vii. La vulnerabilidad afecta a un gran número de activos (+10 activos) -> +1 punto
viii. La vulnerabilidad está siendo explotada activamente -> + 2 puntos

b. Tiempo objetivo para resolver las vulnerabilidades:
i. Puntuación = >6 Crítica: La vulnerabilidad debe resolverse en menos de 30 días.
ii. Puntuación =>4 Alta: La vulnerabilidad debe resolverse en menos de 60 días.
iii. Puntuación =>2 Media: La vulnerabilidad debe resolverse en menos de 90 días.
iv. Resto: La vulnerabilidad debe resolverse cuando sea posible, y siempre antes de que transcurran 365 días desde que fuera detectada.

4. Establecer controles compensatorios:
i. En el caso de las vulnerabilidades Críticas (puntuación =>6) deberán establecerse controles compensatorios preventivos eficaces para mitigar el riesgo que esta vulnerabilidad supone hasta ser resuelta.
ii. En el caso de las vulnerabilidades con criticidad Alta (puntuación =>4) deberán establecerse controles compensatorios preventivos cuando sea posible, o al menos de detección para mitigar el riesgo que esta vulnerabilidad supone hasta ser resuelta.

5. Asignar un propietario para la vulnerabilidad: Dicho propietario será el responsable de resolver la vulnerabilidad dentro del plazo máximo asignado en función de su criticidad.

6. Análisis de soluciones: El propietario de la vulnerabilidad deberá decidir la estrategia a seguir para solventar la vulnerabilidad, documentando dicha solución adecuadamente. En caso de no hallarse ninguna estrategia eficaz y de coste razonable deberá documentarse el riesgo que supone mantener la vulnerabilidad irresoluta, debiendo ser dicho riesgo aceptado por su propietario de acuerdo con los procesos que la organización mantenga en el ámbito de gestión del riesgo.

7. Probar la solución propuesta: Se deberán hacer todas las pruebas necesarias para garantizar que la solución propuesta no supone un perjuicio para la operativa ni la seguridad del sistema o servicio a proteger o de otros sistemas o servicios relacionados. En caso contrario, deberá volverse al punto 5 y hallar una solución alternativa.

8. Resolver la vulnerabilidad: Una vez se cuenta con una solución probada y eficaz, se deberá proceder a su aplicación para resolver la vulnerabilidad en el activo o activos afectados.

9. Verificar su resolución: Una vez resuelta una vulnerabilidad, debe verificarse que su resolución ha sido eficaz y la vulnerabilidad ha sido realmente eliminada según lo esperado.

10. Lecciones aprendidas: Como último paso del proceso de gestión de vulnerabilidades se deberá documentar cualquier lección aprendida en el proceso de resolución de esta vulnerabilidad con el objetivo de que futuras vulnerabilidades que guarden alguna semejanza con ésta puedan ser resueltas de manera más eficiente.

Ejemplo

Por último, veamos un ejemplo del proceso en funcionamiento. Imaginemos que la compañía ACME ha realizado un escaneo de vulnerabilidades sobre su perímetro y ha encontrado estas tres vulnerabilidades:

[Paso 1. Detectar la vulnerabilidad]
Vuln1: Vulnerabilidad en aplicación de desarrollo propio que da soporte al servicio de generación de nóminas que está considerado crítico en la compañía.
Vuln2: Vulnerabilidad que afecta a determinadas versiones de Apache.
Vuln3: Vulnerabilidad que afecta a dispositivos de red CISCO hasta una determinada versión de IOS.

[Paso 2. Aceptar la vulnerabilidad]
El departamento de seguridad realiza un análisis de las vulnerabilidades y se da cuenta que la Vuln2 es realmente un falso positivo, por lo que las únicas vulnerabilidades aceptadas serán Vuln1 y Vuln3. Para cada una de las vulnerabilidades se documentan sus valores:
• Vuln1. CVSS 7.0. Afecta a los servidores: Serv1 y Serv2. No hay constancia de explotación.
• Vuln3. CVSS 5.0. Afecta al servidor Serv2. Hay un exploit público disponible para esta vulnerabilidad y además está siendo utilizada por diversos malware para comprometer equipos.

[Paso 3. Clasificar la vulnerabilidad en función de su riesgo]
El siguiente paso consiste en clasificar ambas vulnerabilidades según el riesgo que suponen para la organización. Siguiendo el método
Vuln1= 2 puntos por CVSS, +3 puntos por afectar a un servicio crítico= 5 puntos (Alta).
Vuln3= 1 punto por CVSS, +3 puntos por afectar a un servidor crítico + 2 puntos por estar siendo explotada activamente = 6 puntos (Crítica).
Por lo tanto, la vulnerabilidad 1 deberá ser resuelta en menos de 60 días y la vulnerabilidad 3 en menos de 30 días.

[Paso 4. Controles compensatorios]
 Para la Vuln3, dado que es una vulnerabilidad crítica se establece un control compensatorio preventivo estableciendo una política en el WAF que previene la explotación de dicha vulnerabilidad hasta que sea resuelta.
Para la Vuln1, al ser de criticidad alta se decide establecer un control de detección, activando la firma de la vulnerabilidad en el IDS para detectar cualquier intento de explotación de la misma.

[Paso 5. Asignar un propietario]
La Vuln1 es asignada al departamento de administración IT para su resolución, mientras que la Vuln3 es asignada al departamento de arquitectura IT para su resolución.

[Paso 6. Análisis de soluciones]
Tras analizar las soluciones se llega a la conclusión que la vuln1 puede ser resuelta mediante un cambio en el código de la aplicación, mientras que para la vuln3 no se encuentra una solución de coste razonable a corto plazo, puesto que su resolución requiere cambios en la arquitectura de red que no pueden abordarse con el presupuesto disponible en 2015. Por lo tanto, se realiza un análisis del riesgo que supone no resolver esta vulnerabilidad y mantener el control compensatorio hasta marzo de 2016 que es la fecha en la que se estima podrá resolverse la vulnerabilidad. Este análisis de riesgos se presenta al director financiero quien es el propietario del proceso de negocio afectado y por lo tanto propietario del riesgo a aceptar. El director financiero decide (de manera informada y quedando documentado) que el riesgo es aceptable y por lo tanto queda aprobado.

[Paso 7. Probar la solución propuesta]
Se realizan las pruebas necesarias para verificar que la solución propuesta resuelve la vuln1 y no afecta negativamente al sistema. En nuestro ejemplo, las pruebas que se realizan son:
• Realizar una auditoría de seguridad sobre el nuevo código para garantizar que no incluye nuevas vulnerabilidades.
• Realizar pruebas unitarias y pruebas de regresión sobre la nueva versión de la aplicación antes de su puesta en producción.
• Realizar una auditoría de seguridad de la aplicación en preproducción para garantizar que no incluye nuevas vulnerabilidades y que la vulnerabilidad vuln3 ha sido efectivamente resuelta.

[Paso 8. Resolver la vulnerabilidad]
Pasamos a producción la nueva versión de código o el parche que solventa la vuln1.

[Paso 9. Verificar la resolución]
Repetimos la auditoría de seguridad o el escaneo de vulnerabilidad para verificar que efectivamente, la vulnerabilidad ya no está presente en nuestra aplicación.

[Paso 10. Lecciones aprendidas]
Analizamos la causa raíz de la vuln1 para extraer las lecciones aprendidas. En nuestro ejemplo, vamos a suponer que la causa raíz de la vulnerabilidad era una falta de verificación de los parámetros de entrada en una función de la aplicación. Por lo tanto, las lecciones aprendidas son:
• Es necesario realizar auditorías de seguridad del código y de la aplicación en ejecución antes de su puesta en producción para hallar este tipo de vulnerabilidades.
• Los desarrolladores deben recibir formación específica en técnicas de desarrollo seguro.
• Guardamos la función utilizada para el filtro de parámetros de entrada para que pueda ser reutilizada en futuras vulnerabilidades similares.

Y con esto daríamos el ciclo finalizado para las tres vulnerabilidades identificadas en nuestro ejemplo.

Espero que la entrada os haya gustado y os resulte de utilidad!

Algunos "Quickwins" en seguridad de la información

En algunas organizaciones existe una fe ciega en que el mejor camino para mejorar la seguridad es gastar más y más dinero en hierro y licencias. Más firewalls, más IDS y el WAF más caro. Sin embargo, en este post me gustaría repasar tres actividades básicas para mejorar la seguridad de una organización, que no necesariamente requieren comprar ningún hardware o software adicional.

La primera de estas actividades es el bastionado de los sistemas. Bastionar o asegurar correctamente un sistema no es una tarea complicada. Existen multitud de guías específicas sobre cómo bastionar sistemas concretos, pero incluso realizando un bastionado básico se puede incrementar en gran medida la seguridad de una infraestructura sin tener que invertir un esfuerzo desmesurado en ello. Los pasos básicos a seguir para bastionar un sistema son:

• Elimina o al menos deshabilita los servicios de red y los programas innecesarios, dejando únicamente habilitados aquellos que son necesarios para que el sistema desempeñe su labor. De esta manera se reduce drásticamente la superficie de exposición del sistema.
• Revisa los usuarios existentes en el sistema, cambiando contraseñas por defecto y minimizando los permisos de cada usuario de manera que tengan los mínimos necesarios para desarrollar sus actividades.
• Documenta los servicios de red necesarios y los puertos usados por cada uno de estos servicios. Esta documentación será de mucha utilidad para diseñar las reglas a implementar en los firewalls de red.
• Mantén el sistema actualizado al último nivel de parches de seguridad publicados por el fabricante. Esta actividad es básica para prevenir que un atacante utilice vulnerabilidades conocidas para comprometer la seguridad del sistema.
• Instala y mantén un firewall en el servidor (puede ser el propio firewall de Windows o un IPtables en el caso de linux) permitiendo únicamente el tráfico entrante y saliente que sea estrictamente necesario. Filtrar el tráfico entrante permite garantizar que aunque algún servicio no necesario se haya dejado habilitado por error, éste no será accesible desde la red. Filtrar el tráfico saliente puede permitir mitigar el impacto causado por una infección de malware que intente abrir conexiones salientes, y prevenir la fuga de datos usando conexiones de red a servicios que el servidor realmente no requiere.

Otra actividad básica a desarrollar es definir, implementar y mantener un programa de gestión de vulnerabilidades adecuado para la organización.

Si queremos gestionar las vulnerabilidades de nuestros sistemas, debemos seguir los siguientes pasos básicos para su correcta gestión: detectarlas, clasificarlas, priorizarlas, asignarlas, resolverlas y verificar su correcta resolución: 

1. Detectar: Hay múltiples fuentes o vías que debemos usar para detectar las vulnerabilidades existentes en nuestros sistemas. Las más comunes serán los avisos de alerta temprana de CERTs o de los propios fabricantes, los resultados de los escaneos de vulnerabilidades periódicos que se deberían realizar sobre la infraestructura y las aplicaciones y los resultados de las pruebas de penetración que se realicen.
2. Clasificar: Una vez detectada una vulnerabilidad, el siguiente paso a realizar debería ser clasificarla según el riesgo que suponga para nuestra organización. Para ello, se deberían considerar factores como el impacto que podría suponer, y la facilidad de explotación. Dado que la resolución de vulnerabilidades es un proceso que puede llevar días, semanas o incluso meses, aquellas vulnerabilidades que sean consideradas más críticas deberían ir acompañadas de un plan de acciones compensatorias para mitigar el riesgo que suponen hasta que sean definitivamente solventadas.
3. Priorizar: Una vez clasificadas según su riesgo, deberán priorizarse. Estos es, definir un tiempo límite en el que cada vulnerabilidad debería estar resuelta. El estándar de seguridad en datos de tarjetas de pago PCI DSS propone un mes de tiempo límite para las vulnerabilidades más críticas y tres meses de tiempo límite para el resto. En cualquier caso, tanto los niveles de clasificación como los tiempos de resolución deberían adaptarse a la realidad de cada organización.
4. Asignar: El siguiente paso es asignarlas. Es decir, determinar de quien es la responsabilidad de resolver cada una de las vulnerabilidades dentro del plazo correspondiente.
5. Resolver: El responsable de resolver cada vulnerabilidad deberá encontrar la solución a la misma, seguir el proceso de la organización para la gestión de cambios, es decir, probarla adecuadamente para descartar cualquier impacto negativo derivado de ésta y proceder a su resolución.
6. Verificar: Por último, se debe verificar que la solución resuelva la vulnerabilidad de manera eficaz.

Por último, quisiera hablar de la concienciación en seguridad de la información dirigida a los empleados y proveedores de la organización.

Más de una vez he oído a profesionales de seguridad argumentando que las acciones de concienciación no son efectivas y que por mucha concienciación que se realice, el factor humano seguirá siendo el principal riesgo de cualquier organización. Mi opinión al respecto es que la concienciación sí es efectiva e indispensable,  aunque no por ello suficiente. Dicho de otro modo, es cierto que concienciar al personal no elimina los riesgos de seguridad que provienen de errores humanos pero sin duda los mitiga y en todo caso evita que los usuarios puedan escudarse tras el desconocimiento al perpetrar ciertos tipos de acciones que comprometan la seguridad de los activos de información de la organización.

Por supuesto, existen más acciones que se pueden llevar a cabo sin una gran inversión económica para aumentar el nivel de seguridad de las organizaciones, como por ejemplo segmentar correctamente la red, establecer procesos de desarrollo seguro, de gestión de cambios, de respuesta ante incidentes, etc. Sin embargo, los tres propuestos considero que son una excelente base por la que empezar a mejorar la seguridad de nuestra organización.