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!
