Gestión de vulnerabilidades guía de seguridad cibernética

Todo el software moderno contiene vulnerabilidades; ya sea defectos de software que requieren parches para subsanar, o problemas de configuración que requieren actividad administrativa para resolverse.

Por esta razón, las organizaciones deben tener un proceso de gestión de vulnerabilidades que les permita saber qué vulnerabilidades están presentes dentro de su estado de TI de forma regular. Idealmente, el personal ejecutivo debería ser tan consciente de las principales vulnerabilidades en su estado de TI como de su estado financiero.

Esta guía ayuda a las organizaciones a:

Evaluar y priorizar vulnerabilidades
Identificar qué parches son más relevantes
Garantizar que los fondos y los recursos se puedan desplegar de la mejor manera.

Esta guía se centra en la gestión de vulnerabilidades de software y hardware ampliamente disponibles , que consiste en gran parte en la implementación de parches y la búsqueda de configuraciones débiles conocidas. La gestión de problemas de software de nicho consiste en el descubrimiento de problemas previamente desconocidos y, en su mayor parte, está fuera del alcance de este documento.

Esta guía asume que:

Su organización utiliza tecnología que usted es responsable de mantener segura
Tiene datos confidenciales que deben protegerse de los ataques basados en Internet
Incluso si la mayoría de sus datos no son confidenciales, la gestión de vulnerabilidades le ayudará a proteger los datos de su personal y su reputación. También disminuirá la probabilidad de que usted sea una fuente de infección posterior. Las pruebas de penetración deben usarse para validar la eficacia del proceso interno de gestión de vulnerabilidades y no lo reemplazan.

Acerca de las vulnerabilidades

La explotación de vulnerabilidades conocidas en el software sigue siendo la principal causa de incidentes de seguridad. La aplicación de parches, el proceso de aplicar actualizaciones de los desarrolladores de software, proveedores de hardware y vendedores, ya sea para mejorar la funcionalidad o para mejorar la seguridad, es una de las cosas más importantes que puede hacer para mitigar las vulnerabilidades.

¿Por qué no se solucionan las vulnerabilidades?

La práctica más segura posible sería corregir todas las vulnerabilidades tan pronto como se publique el parche relevante para los sistemas afectados. Sin embargo, existen muchas limitaciones del mundo real que explican por qué esto no es posible. Las principales razones incluyen:

Costo: actualizar servidores y estaciones de trabajo a una nueva plataforma es costoso
Interrupción: las actualizaciones interrumpen el negocio y los recursos deben retirarse de otros proyectos de TI.
Compatibilidad: es posible que las aplicaciones especializadas no funcionen de manera confiable en los sistemas operativos más nuevos (aquí se incurre en un costo doble; la aplicación debe reemplazarse además de la plataforma en la que se ejecuta)
Operaciones: las actualizaciones importantes de software son intrínsecamente riesgosas y las herramientas del usuario pueden funcionar de manera diferente

Además, la perspectiva de una actualización masiva pone nerviosos a las empresas, y es posible que no se disponga de la combinación adecuada de habilidades para planificar e implementar dicho trabajo. Los retrasos en el trabajo de actualización solo aumentan el tamaño de la tarea, haciéndola más cara y menos atractiva.

Existen muchas herramientas y recursos para ayudar a priorizar las actualizaciones y la gestión de vulnerabilidades.

Es mejor empezar poco a poco y progresar que sentirse abrumado por la tarea y no hacer nada .

A. Evaluar vulnerabilidades

Recomendamos que las organizaciones realicen una evaluación de vulnerabilidad de todo su patrimonio mensualmente . Se informan nuevas vulnerabilidades todo el tiempo y muchos proveedores de software lanzan actualizaciones en un ciclo mensual (como el 'Martes de parches' mensual de Microsoft).

Un régimen de evaluación regular es esencial para garantizar que su organización sea consciente de los riesgos presentes. No , no necesita ser dirigido por un socio externo, ni el personal requiere ningún entrenamiento especial.

Sistemas automatizados de evaluación de vulnerabilidades

Si bien el estado de los parches de software se puede recopilar utilizando paquetes de administración de activos de software, debe usar un sistema de evaluación de vulnerabilidades automatizado (VAS) para identificar las vulnerabilidades en el estado de TI de su organización. Las suites de administración de activos de software no siempre buscan bibliotecas de software vulnerables además del software instalado, y no verifican configuraciones incorrectas.

Los VAS realizan acciones contra un sistema de destino (como recopilar un banner al conectarse a un servicio de red) y luego evalúan los datos devueltos con firmas de vulnerabilidades conocidas (como el número de versión informado por el servicio de red que se sabe que tiene vulnerabilidades).

Cuando utilice un VAS, debe:

Evalúe sus sistemas desde una perspectiva externa (por ejemplo, desde Internet) y desde una perspectiva interna, asumiendo que el diseño de su sistema diferencia entre estas dos ubicaciones.
Supervise las cuentas utilizadas para ejecutar análisis de evaluación de vulnerabilidades en busca de cualquier actividad inusual. Cuando no se esté realizando una evaluación, considere deshabilitar la cuenta o cambiar las credenciales asociadas con ella.
Realice escaneos de sus redes además de escaneos específicos de sistemas conocidos, con el objetivo de descubrir dispositivos potencialmente desconocidos o no autorizados.
Tenga en cuenta que un VAS puede provocar resultados inesperados, que pueden incluir la corrupción de datos. Estos resultados son muy poco probables en sistemas relativamente modernos (los desarrollados desde 2010), pero es posible que desee probar su VAS con copias de sistemas críticos que no sean de producción antes de ponerlo en funcionamiento.

Ejecute el VAS con las credenciales necesarias para realizar una evaluación en el host, no simplemente un escaneo no autenticado. Algunos VAS usan un agente en el host, mientras que otros usan credenciales privilegiadas para autenticar y consultar el estado de los dispositivos. La elección entre estas dos opciones es una cuestión de qué es más fácil de integrar para su organización en sus sistemas. Las credenciales privilegiadas que se utilizan para realizar la evaluación de vulnerabilidades se utilizan para conectarse a una gran cantidad de sistemas en el estado, y existe el riesgo de que un atacante que ya haya comprometido un sistema dentro del estado obtenga las credenciales.

B. Triaje de vulnerabilidades

Le recomendamos que forme un 'grupo de clasificación de vulnerabilidades', compuesto por personal con conocimientos sobre los riesgos de seguridad cibernética, los riesgos comerciales y la gestión del patrimonio de TI. Este grupo debe reunirse una vez que se haya realizado una evaluación de vulnerabilidades para clasificar todas las vulnerabilidades encontradas.

El software de evaluación de vulnerabilidades normalmente asignará una clasificación de gravedad a los problemas; esta gravedad debe considerarse como parte del proceso, pero dado que no toma en cuenta ningún riesgo comercial o circunstancias atenuantes, no debe tomarse como un estándar de oro.

El grupo de triaje debe tomarse el tiempo para evaluar los problemas basándose en toda la información disponible. Tenga en cuenta que la primera vez que se realiza en un sistema, puede haber una gran cantidad de problemas que evaluar. Resista la tentación de ignorar todos los problemas que no estén marcados como "Críticos" o "Altos".

El Common Vulnerability Scoring System ( CVSS ) asigna puntuaciones numéricas a las vulnerabilidades e intenta ayudar en el proceso de clasificación de vulnerabilidades. Puede ser una herramienta útil si se usa correctamente, pero el grupo de triaje debe asegurarse de que:

No seleccione una puntuación arbitraria por encima del cual las vulnerabilidades deben fijarse, haciendo caso omiso de todos los problemas debajo de ese nivel
No tener puntuaciones de CVSS primas sin tener en cuenta factores atenuantes específicas organización o prioridades

Su proceso de clasificación debe dividir todos los problemas identificados en tres categorías: corregir , reconocer e investigar .

Los problemas de reparación son aquellos para los que se implementará un parche, una reconfiguración o una mitigación. Se debe dar prioridad a estas correcciones ( ver más abajo ), y se les debe dar una fecha en la cual se implementarán.

Los problemas de reconocimiento son aquellos que, por el motivo que sea, decides no resolver en la actualidad. Existen razones válidas para no resolver de inmediato una vulnerabilidad, y deben registrarse, junto con el razonamiento para reconocerla y una fecha de revisión. Si el nivel de riesgo que presentan es suficientemente alto, registre el problema en un registro de riesgos. La justificación para reconocer un problema, y no solucionarlo, debería ser suficiente para justificar la decisión tomada en caso de que la vulnerabilidad se explote en el futuro.

Los problemas de investigación deben usarse solo como un estado temporal en el que el grupo de triaje no pueda categorizarlos como ' arreglar ' o ' reconocer '. Esto puede deberse a que se desconoce el costo de resolver el problema, o hay varias soluciones posibles y se requiere más trabajo para identificar cuál funciona mejor. El software de evaluación de vulnerabilidades no es infalible y pueden producirse falsos positivos. Cuando se sospeche esto, se debe realizar una investigación antes de eliminar el problema. Los plazos para los problemas de esta categoría dependerán de la probable gravedad del problema.

La decisión de solucionar o dejar un problema es, en el fondo, una decisión empresarial y cada organización tiene su propio apetito por el riesgo.

C. Priorizar las correcciones de vulnerabilidades

Debe priorizar las vulnerabilidades concentrándose en los problemas que:

Son accesibles para la mayor cantidad de atacantes potenciales y tendría el mayor impacto si se explotara

El número de atacantes potenciales depende de la accesibilidad de la vulnerabilidad (por ejemplo, ¿es accesible desde Internet o solo desde una red segura?) Y la complejidad de la explotación. Si hay exploits disponibles públicamente, entonces el número de posibles atacantes es mucho mayor que si se conoce una debilidad, pero los atacantes tendrían que desarrollar su propio código de exploits.

El impacto de la explotación consiste tanto en el impacto técnico como en el impacto empresarial . Por ejemplo:

Impacto técnico : un problema que podría permitir una denegación de servicio generalmente se considera un impacto menor que un problema que le daría a un atacante la capacidad de ejecutar su propio software en el sistema de destino.
Impacto comercial : una vulnerabilidad en un sistema de procesamiento de pagos es mayor que una en un sistema de reserva de salas de reuniones

A continuación, se proporciona un conjunto de pautas de muestra para decidir qué problemas deben solucionarse.

Paso 1: decide lo que necesitas arreglar

Prioridad 1 : Reparar los servicios de Internet y las aplicaciones web estándar que pueden explotarse automáticamente en Internet sin interacción del usuario (o atacante).

Asegure cualquier servicio al que se pueda acceder directamente desde Internet y para el que existan vulnerabilidades conocidas, explotables y graves. Los escáneres de vulnerabilidades pueden filtrar aquellos que tienen exploits conocidos y son 'altos' o 'críticos' (en términos de su impacto negativo potencial).

Incluya cualquier aplicación web lista para usar; si contienen vulnerabilidades conocidas, son altamente vulnerables a la explotación, incluida la explotación automatizada no dirigida.

Prioridad 2 : Repare las aplicaciones web específicas o específicas que puedan explotarse en Internet sin interacción del usuario (o atacante).

Aplicaciones web seguras a medida (es decir, cualquier cosa que ejecute código en un sitio web que no se haya comprado a un proveedor o que no provenga de un proyecto de código abierto importante). Estas aplicaciones web están cada vez más sujetas a ataques.

En primera instancia, priorice los servidores accesibles desde fuera de su entorno.

Prioridad 3 : solucionar problemas que pueden explotarse en Internet con una interacción mínima del usuario (vulnerabilidades de la estación de trabajo, descargas no autorizadas, ataques basados en correo electrónico).

Proteja las estaciones de trabajo de los usuarios contra descargas no autorizadas y ataques basados en correo electrónico. La protección de los navegadores web y las aplicaciones comunes de los usuarios es fundamental aquí.

No es necesario que actualice el sistema operativo de inmediato, aunque las versiones anteriores de Windows no son compatibles con las aplicaciones más nuevas. Usted tendrá que actualizar el tiempo.

Prioridad 4 : Solucionar problemas que pueden explotarse en Internet con la ingeniería social de los usuarios (aplicaciones maliciosas descargadas de la web o enviadas por correo electrónico). Estos ataques requieren que sus usuarios participen, por ejemplo, descargando un archivo infectado o haciendo clic en un enlace o un archivo adjunto en un correo electrónico de phishing, por lo que debe proteger sus sistemas en consecuencia.

Establezca una lista de denegación de aplicaciones simple utilizando la Política de restricción de software en Windows XP o AppLocker en Vista y versiones más recientes de Windows. Esto evitará que los usuarios puedan ejecutar fácilmente programas que hayan descargado o que hayan recibido un correo electrónico (ya sea a propósito o por error). Consulte nuestra Guía de seguridad de dispositivos para obtener información más detallada.

En Windows XP, bloquee todas las aplicaciones que ejecutan los usuarios desde C: \ Documents and Settings , y todas las carpetas que contienen.

Para Windows Vista y versiones posteriores, bloquee todas las aplicaciones que ejecutan los usuarios desde C: \ Users y todas las carpetas que contienen.

Paso 2: decida qué puede permitirse arreglar

Probablemente encontrará más problemas que pueda solucionar. Decidir qué puede permitirse arreglar es una decisión de alto nivel. Este no es un problema de TI; este es un riesgo comercial .

La toma de decisiones prioritarias deberá combinar los siguientes factores:

lista de prioridades arriba
costo directo
costo en molestias al personal
disponibilidad y costo de la solución a corto plazo
costo y disponibilidad de recursos calificados
costo de respuesta y recuperación ante incidentes (incluidas las multas impuestas)
daño a la reputación
Registre las razones de las decisiones tomadas. Para cualquier problema en el que se tome la decisión de no solucionar el problema, sino reconocerlo, se debe establecer un plazo para revisar esta decisión. La decisión de no solucionar el problema debe tomarse a un nivel lo suficientemente alto como para que la persona que toma la decisión pueda defenderla si se explota una vulnerabilidad en el futuro.

Fecha actualización el 2021-07-05. Fecha publicación el 2021-07-05. Categoria: ciberseguridad Autor: Oscar olg Mapa del sitio Fuente: ncsc