Capítulo 3. Prueba, corrección e informe...76 Resumen...77

Transcripción

1 Capítulo 3: Medidas de prevención: corrección y administración de vulnerabilidades...55 Tipos de vulnerabilidades...55 Vulnerabilidades de software...55 Vulnerabilidades de configuración...56 Respuesta ante vulnerabilidades...57 Respuestas ad hoc...57 La aplicación de parches no implica administración de vulnerabilidades...58 Activos faltantes...58 Vulnerabilidades de configuración faltante...58 Prueba deficiente de impacto...59 Documentación inadecuada de administración de cambios...60 Administración deficiente del proceso...61 Determinación deficiente de prioridades...61 Respuestas administradas...61 Marco para comprender la administración de vulnerabilidades...62 Cuáles son los activos de la organización?...63 Cuáles son las vulnerabilidades que amenazan a la organización?...64 Cuáles son los riesgos de las vulnerabilidades?...64 Cuál es el costo para compensar las vulnerabilidades?...65 Procesos en la administración de vulnerabilidades...66 Ciclo de vida de la administración de vulnerabilidades...66 Monitoreo...67 Análisis de activos y vulnerabilidades...69 Notificación...70 Prioridad...70 Planificación...72 Prueba...72 Corrección...73 Informe...74 Escenario de administración de vulnerabilidades...76 Monitoreo de amenazas emergentes...76 Análisis y notificación...76 Determinación de prioridades y planificación...76 i

2 Prueba, corrección e informe...76 Resumen...77 ii

3 Declaración de derechos de autor 2006 Realtimepublishers.com, Inc. Todos los derechos reservados. Este sitio contiene material que ha sido creado, desarrollado, o autorizado por, y publicado con el permiso de Realtimepublishers.com, Inc. (los Materiales ). Además, este sitio y todos los Materiales están protegidos por leyes internacionales de derechos de autor y de marcas comerciales. LOS MATERIALES SE PRESENTAN EN EL ESTADO EN QUE SE ENCUENTRAN Y ESTÁN DISPONIBLES SIN GARANTÍA DE NINGÚN TIPO, YA SEA EXPRESA O TÁCITA, INCLUYENDO SIN LIMITACIÓN, CUALQUIER GARANTÍA IMPLÍCITA DE COMERCIABILIDAD, IDONEIDAD PARA UN FIN ESPECÍFICO, TÍTULO O DE NO VIOLACIÓN. Los Materiales se encuentran sujetos a cambios sin previo aviso y no representan un compromiso por parte de Realtimepublishers.com, Inc. o los patrocinadores de su sitio web. En ningún caso, Realtimepublishers.com, Inc. o los patrocinadores de su sitio web serán responsables por errores u omisiones técnicas o editoriales de los Materiales, incluyendo sin limitación, cualquier daño directo, indirecto, accidental, especial, ejemplar o consiguiente que resulte del uso de cualquier información incluida en los Materiales. Los Materiales (incluyendo sin limitación, textos, imágenes, audio y/o videos) no pueden copiarse, reproducirse, reeditarse, cargarse, publicarse, transmitirse o distribuirse de ningún modo, de manera total o parcial; excepto que una copia se descargue para uso personal y no comercial en la computadora de un solo usuario. En relación con tal uso, no puede modificar ni ocultar ningún derecho de autor u otra notificación de propiedad. Los Materiales pueden incluir marcas comerciales, marcas de servicios y logos que son propiedad de terceros. Usted no está autorizado para utilizar estas marcas comerciales, marcas de servicios o logos sin el previo consentimiento por escrito de dichos terceros. Realtimepublishers.com y el logo de Realtimepublishers están registrados en la Oficina de Patentes y Marcas Comerciales de EE. UU. (US Patent & Trademark Office). Todos los nombres de servicios o productos son propiedad de sus respectivos propietarios. Si tiene alguna pregunta sobre estos términos o si desea más información sobre materiales de licencias de Realtimepublishers.com, comuníquese con nosotros por correo electrónico a info@realtimepublishers.com. iii

4

5 Capítulo 3: Medidas de prevención: corrección y administración de vulnerabilidades Las vulnerabilidades de la seguridad fueron en una época tema de discusión solamente entre los administradores de sistemas y los profesionales de seguridad, pero ahora aparecen en los titulares de publicaciones comerciales y de noticias a nivel mundial. Los periodistas recomiendan no utilizar un explorador web conocido por sus vulnerabilidades. Las personas que publican blogs están tomando conciencia sobre las vulnerabilidades de los diferentes sistemas operativos (SO). Este aumento en la toma de conciencia destaca la importancia y el impacto de las vulnerabilidades de la seguridad de la información. El personal técnico ya no es el único grupo preocupado por la administración de vulnerabilidades. El tema del cumplimiento de la seguridad está adquiriendo importancia en todas las áreas organizacionales, inclusive en la junta de directores de la empresa. En este capítulo se comienza con un análisis de los tipos de vulnerabilidades y dos enfoques amplios para responder a los mismos: enfoque ad hoc y administrado. Luego, se presentará la evolución de los enfoques administrados. A continuación se discutirá el ciclo de vida de la administración de vulnerabilidades y se explorará cada etapa en forma detallada. El capítulo concluye con un escenario de ejemplo que demuestra la necesidad de una administración efectiva de las vulnerabilidades. Para ver un ejemplo de la frustración que sienten los que publican blogs con respecto a las vulnerabilidades del sistema operativo, consulte Es Windows inherentemente más vulnerable a los ataques de malware que los SO X? (Is Windows inherently more vulnerable to malware attacks than SO X?) en Tipos de vulnerabilidades Las vulnerabilidades provienen de los errores en las aplicaciones de software o de los activos configurados incorrectamente; son defectos inherentes del software o configuraciones incorrectas del sistema que permiten que los códigos maliciosos comprometan a un activo. Si se explotan, las vulnerabilidades pueden generar, de múltiples maneras, un impacto en las organizaciones: desde perjudicar la continuidad de los negocios hasta afectar la confianza de los clientes. Vulnerabilidades de software Existen varios tipos de vulnerabilidades de software. Algunos son el resultado de errores no intencionales en el código. Por ejemplo, las prácticas de programación deficientes, tales como la falta de verificación de la longitud de las cadenas, que antes de almacenarlas en arreglos de caracteres de longitud fija, crean avenidas para ejecutar códigos maliciosos dentro del contexto de los programas legítimos (cuando se almacena en el arreglo una cadena más larga que la longitud designada se produce un desbordamiento del búfer y el código del programa legítimo puede ser reemplazado por el código malicioso). Otra fuente de vulnerabilidades de software es el uso intencional de una rutina de puerta trasera o una conexión de mantenimiento, el cual es un código que el desarrollador agrega a su programa para permitir un acceso tardío al omitir los mecanismos de control de acceso. Otras vulnerabilidades son inherentes al diseño de una aplicación. 55

6 La facilidad con la cual los spammer (programas de correo electrónico masivo) y los phisher (programas de correo electrónico fraudulento) pueden falsificar direcciones de envío de correo electrónico se debe al diseño del protocolo simple de transferencia de correo electrónico (SMTP). Este tipo de vulnerabilidad no se debe a un error, sino a una elección en el diseño. En algunos casos, estas elecciones de diseño son equivocaciones; en otros casos, la vulnerabilidad es el resultado de un uso imprevisto del sistema. Además, los diseñadores de sistemas se ven forzados a realizar elecciones para equilibrar la funcionalidad, el costo, los recursos limitados de redes e informática y otras limitaciones. Las vulnerabilidades pueden surgir de estas limitaciones externas en el diseño del sistema. Las prácticas sólidas de ingeniería de software, como por ejemplo las revisiones de códigos, mitigan las vulnerabilidades provocadas por los errores no intencionales y el código de puerta trasera. Las limitaciones relacionadas con el diseño son más difíciles de mitigar, pero pueden administrarse con una combinación de tecnología (como un software de filtrado de contenido) y procesos (por ejemplo, políticas bien definidas y procedimientos para administrar correos electrónicos). Vulnerabilidades de configuración Los errores de configuración también pueden crear vulnerabilidades en los activos de información. Por ejemplo, muchos clientes de correo electrónico admiten mensajes de correo electrónico con formato HTML, incluyendo cadenas. Los creadores de virus han aprovechado estas características para ofrecer su carga útil. Un cambio en los parámetros de configuración de cliente de correo electrónico puede prevenir este tipo de artificio. Otros aspectos de configuración son más complejos. En una organización, se pueden utilizar simultáneamente servidores de seguridad, redes privadas virtuales (VPN), filtros de contenido, sistemas de prevención de intrusos y software de antivirus. Los requisitos de negocio establecen que estos sistemas de seguridad deben configurarse para que los usuarios puedan utilizar de manera efectiva sus aplicaciones. Este requisito puede ocasionar la introducción de prácticas menos seguras en nombre de la productividad del usuario: Apertura de puertos en el servidor de seguridad que de otra manera no se abrirían Uso de una versión vieja de un cliente de red privada virtual (VPN) que es menos segura pero, compatible con otros activos Configuración de parámetros de filtrado de contenido con menos control de lo que es aconsejable Incluso, si un sistema no está configurado correctamente, un hacker puede revelar estas configuraciones incorrectas y penetrar el primer nivel de protección. Después de ingresar, el hacker puede ejecutar diferentes tipos de secuencias para determinar cuáles son los sistemas vulnerables y obtener ventajas de acceso a las aplicaciones esenciales de la empresa. Las dependencias entre los activos pueden limitar las opciones de configuración e introducir vulnerabilidades de manera no intencional. Estas vulnerabilidades pueden corregirse perfectamente con otras configuraciones sin restringir la funcionalidad empresarial de las aplicaciones. 56

7 Respuesta ante vulnerabilidades Como se analizó anteriormente, las vulnerabilidades son provocadas por errores de programas, limitaciones en el diseño y configuraciones incorrectas. La responsabilidad de administrar estas vulnerabilidades debe recaer sobre los programadores, los diseñadores y los administradores de sistemas. No es cierto? Sí y no. Sí porque los programadores y diseñadores deben utilizar prácticas sólidas de ingeniería de software que minimicen los fallos. Sí porque los diseñadores deben anticipar los intentos de utilización maliciosa de los sistemas que diseñan. Sí porque los administradores de sistemas deben comprender de qué manera operan entre si los activos y cómo las dependencias entre activos afectan el perfil de seguridad de la infraestructura informática de una organización. El problema es que los profesionales de TI utilizan todas estas prácticas. Sin embargo, las vulnerabilidades continúan existiendo y proliferándose. Entonces, Sobre quién recae la responsabilidad? Las organizaciones pueden destinar numerosos recursos para prevenir las vulnerabilidades. Los programadores, diseñadores y administradores de sistemas deben ofrecer aplicaciones funcionales que operen de acuerdo con los requisitos de negocio. Para que esto pueda llevarse a cabo deben ajustarse a los límites de tiempo y presupuesto. La prevención de vulnerabilidades es un aspecto importante de cualquier proyecto de instalación, desarrollo y configuración, pero no es el único aspecto importante. Si la decisión implica ofrecer un sistema que genere ingresos en el tiempo estipulado y de acuerdo con el presupuesto indicado, o retrasar la presentación del sistema por 2 meses para verificar las vulnerabilidades; Con qué frecuencia una empresa elegirá la última opción? No es factible esperar que se eliminen todas las vulnerabilidades durante el desarrollo y la instalación. Las organizaciones deben asumir que las aplicaciones de producción tienen vulnerabilidades, aunque hayan sido evaluadas. Por lo tanto, este asunto se convierte en un tema sobre cómo responder a estas vulnerabilidades. Respuestas ad hoc Uno de los enfoques para administrar las vulnerabilidades es simplemente lidiar con cada una de ellas a medida que se conocen. Este tipo de enfoque ad hoc no tiene un método formal pero sigue un patrón general que incluye: 1. Informarse sobre las vulnerabilidades 2. Buscar un parche 3. Descargar un parche 4. Aplicar el parche 5. Contactar en lo posible a otros administradores para consultar sobre las vulnerabilidades y el parche 6. Asumir que se ha mitigado la vulnerabilidad Además del hecho de que el parche no es una administración de vulnerabilidades, existen varios problemas con este enfoque: Aumento de las probabilidades de activos faltantes Aumento de las probabilidades de pasar por alto vulnerabilidades de configuración 57

8 Ausencia de pruebas minuciosas de impacto Producción inadecuada de la documentación de administración de cambios Administración deficiente del proceso Determinación deficiente de prioridades Cada uno de estos elementos es una desventaja significativa en la administración de vulnerabilidades. La aplicación de parches no implica administración de vulnerabilidades En primer lugar, y con mayor importancia, la aplicación de parches no ofrece una respuesta a todas las vulnerabilidades. Sin un procedimiento metódico para controlar las vulnerabilidades, una organización no puede verificar si todas las vulnerabilidades conocidas en la amplia comunidad de TI se han mitigado en su entorno. Algunas vulnerabilidades son provocadas por errores de configuración. Por lo tanto, es posible que no exista un parche para corregirlas. De hecho, existen múltiples vulnerabilidades que no se solucionan con la aplicación de un parche. La aplicación de parches es una parte de la administración de vulnerabilidades, pero no el proceso entero. Activos faltantes El enfoque ad hoc no garantiza la aplicación de parches en todos los activos vulnerables. Sin un inventario de software y hardware, inclusive información de versión, los administradores de sistemas no pueden garantizar la mitigación de vulnerabilidades en toda la organización. Por ejemplo, un administrador de bases de datos (DBA) puede conocer todos los servidores oficiales de bases de datos y aplicarles parches. Lo que el DBA no sabe es que varios equipos de desarrollo están ejecutando servidores de desarrollo no oficiales en sus estaciones de trabajo. El enfoque ad hoc dejaría a estos sistemas vulnerables y expondría a la organización a los riesgos de que un atacante manipule estos servidores. La realidad es que sin conocer sus activos, usted no podrá determinar sus riesgos. Vulnerabilidades de configuración faltante Los parches son versiones corregidas de códigos de aplicación; no se aplican a las vulnerabilidades de configuración. Los enfoques ad hoc para la administración de vulnerabilidades dependen de la existencia de parches para determinar la existencia de una vulnerabilidad. Por ejemplo, un administrador de sistemas puede creer por error que todas las vulnerabilidades conocidas han sido mitigadas luego de ejecutar un procedimiento de actualización del sistema operativo (SO). Estos procedimientos maximizan algunas partes del proceso de aplicación de parches pero no evalúan los problemas de configuración. Los servicios de parches de los proveedores no se aplican a las vulnerabilidades relacionadas con las dependencias entre varios activos. De manera individual, un fallo en un servidor de seguridad del proveedor y una vulnerabilidad en la aplicación de bases de datos de otro proveedor, quizás no representen un riesgo significativo. Sin embargo, cuando se utiliza un servidor de seguridad en una subred en una aplicación de bases de datos, las vulnerabilidades combinadas pueden crear un riesgo mucho más severo. El descubrimiento y el conocimiento de las vulnerabilidades relacionadas con la dependencia requieren de un proceso de investigación metódica. 58

9 Prueba deficiente de impacto Otro problema con la administración ad hoc de vulnerabilidades es la ausencia de una prueba de impacto. Generalmente se entiende que los medicamentos tienen efectos secundarios. Los médicos equilibran los beneficios médicos de los medicamentos con los efectos adversos inherentes a los mismos. Ellos sólo recetan medicamentos cuando los beneficios compensan los efectos secundarios. La mitigación de vulnerabilidades debe seguir un proceso análogo. Antes de aplicar un parche, los administradores de sistemas deben comprender: Exactamente cuál es la vulnerabilidad a tratar Cuáles son los requisitos previos para instalar el parche Cuáles son las aplicaciones u otros activos afectados por el cambio Cómo restaurar un sistema si el parche falla o afecta de manera adversa a otros activos Ninguno de estos criterios se incluye en los procedimientos ad hoc. Alcance del parche Los sistemas operativos más utilizados, tales como los productos de la familia de Microsoft Windows, cuentan con un amplia variedad de características utilizadas sólo por una fracción del número total de usuarios de SO. Por ejemplo, la característica Escritorio remoto compartido en NetMeeting (Microsoft NetMeeting Remote Desktop Sharing) se incluye como parte de los sistemas operativos de Windows. Esta herramienta permite a usuarios autorizados obtener acceso al escritorio de otra máquina durante una sesión de NetMeeting. Las organizaciones que utilizan NetMeeting deben mantener los parches actualizados para este servicio, ya que es una ruta expuesta para comprometer los servidores y escritorios. Si no se utiliza NetMeeting, el servicio debe deshabilitarse para que no haya necesidad de aplicar parches. Teóricamente, la aplicación de parches en un servicio no utilizado no debería afectar el perfil de seguridad de un sistema. Sin embargo, existe el riesgo de que un parche introduzca vulnerabilidades nuevas y aún desconocidas. Al igual que la receta de medicamentos, la aplicación de parches implica equilibrar beneficios y riesgos. Requisitos previos para el parche Los parches están diseñados para versiones específicas de software. El diseño de estos parches puede incluir suposiciones sobre el sistema meta al cual se aplica. Además de conocer el alcance de un parche, los administradores de sistemas deben comprender los requisitos previos para instalar un parche. Si no se cumplen con los requisitos previos, es posible que el parche no pueda mitigar la vulnerabilidad meta, o bien que pueda introducir otras vulnerabilidades o fallos en el sistema en el que fue aplicado. Es posible probar los programas de instalación de parches para asegurar que se cumplan con los requisitos previos, pero los administradores de sistemas no deberían confiar únicamente en los procedimientos de prueba que se llevan a cabo fuera de su propio entorno. Efectos de un parche en otras aplicaciones Cuando se descubre una vulnerabilidad en una aplicación, la mejor forma de corregirla puede requerir un cambio en el código compartido por varias aplicaciones. Una vulnerabilidad en un explorador web, por ejemplo, puede requerir un cambio en un módulo de biblioteca compartido que también es utilizado por los clientes de correo electrónico. Un parche de una vulnerabilidad 59

10 ftp puede cambiar un módulo que ha sido utilizado también por un paquete de emulación de terminal de un tercero. Antes de instalar un parche en un código compartido, es prácticamente imposible saber de qué manera se verán afectadas todas las demás aplicaciones. Incluso en las organizaciones con administración de cambios y procesos de verificación de dependencia desarrollados, existen dependencias desconocidas. Los proveedores no tienen expectativas de revelar los detalles de sus propios software, incluso la información sobre los servicios de sistemas operativos utilizados. Aun cuando es posible verificar dependencias de bajo nivel (por ejemplo, con aplicaciones de fuentes abiertas), las limitaciones reales de tiempo y recursos hacen que sea poco probable realizar dicha verificación. Realizar pruebas de parches en un entorno controlado que refleje la infraestructura de producción, equilibra la necesidad de entender el impacto de un parche sin incurrir en costos extraordinarios de verificación de información detallada sobre dependencias. Restauración después de un fallo de parche Los parches no siempre se instalan correctamente: Al igual que otros software, los parches pueden contener fallas o no funcionar con determinadas configuraciones. En el proceso de descubrimiento de una falla, el procedimiento de instalación de un parche puede tener configuraciones de registro sobrescritas, configuraciones modificadas de aplicaciones y bibliotecas compartidas reemplazadas. Por lo tanto, el sistema permanece en una condición inestable. Algunos sistemas de administración de parches suministran procedimientos de recuperación que pueden deshacer los efectos de un parche. Si estos procedimientos no se encuentran disponibles o no funcionan, es posible que deba restaurarse el sistema con aplicación de parches desde el respaldo. En tiempo como estos, los administradores de sistemas no desean depender de una combinación de procedimientos ad hoc y pensamientos optimistas para recuperar sus sistemas. Probar los parches en un entorno controlado puede identificar problemas imprevistos y prevenir consecuencias adversas. Desafortunadamente, la administración ad hoc de vulnerabilidades no ofrece dicha prueba. Documentación inadecuada de administración de cambios Algunas vulnerabilidades son tan severas que requieren una acción inmediata. Por ejemplo, el gusano SQL Slammer se expande en minutos por grandes secciones de Internet. Cuando los administradores de sistemas se enfrentan a los ataques en escala de un SQL Slammer, su primera prioridad es la de proteger la infraestructura de TI. Es posible que se desconecten los servidores y los segmentos de red del resto de la red de la organización. Dichas acciones constituyen sólo una solución parcial. Si no funcionan los servidores de producción, la primera prioridad es la de aplicarles parches o reconfigurarlos para volver a conectarlos en línea. Si se hace necesario aplicar parches en múltiples servidores o si deben reconfigurarse, pueden existir leves variaciones en el proceso a través de los servidores. Las diferentes revisiones del SO o la aplicación pueden requerir diferentes versiones del parche o diferentes parámetros de configuración. El modo fire drill inducido por la administración ad hoc de vulnerabilidades deja poco espacio para documentar los distintos procedimientos de parches. Desafortunadamente, la falta de documentación adecuada prolonga los problemas del enfoque ad hoc. Sin una documentación adecuada sobre los cambios, la próxima vez que una vulnerabilidad represente una amenaza, las personas responsables deberán realizar un inventario de los 60

11 antecedentes de parches de los sistemas o arriesgarse a aplicar parches con información insuficiente. Éstas son opciones deficientes para un administrador de sistemas. Administración deficiente del proceso Los procesos ad hoc son difíciles de controlar, mejorar o duplicar. Es probable que la documentación, al conservarse, sea inconsistente. En algunos casos, un administrador puede documentar los detalles técnicos de la vulnerabilidad pero escribir poco sobre las configuraciones individuales del sistema; en otros casos pueden documentarse los cambios realizados en los parámetros del sistema pero faltará información sobre la versión de software. La documentación integral y consistente es de gran ayuda para la administración de vulnerabilidades; sin embargo, generalmente esta documentación no se realiza. La documentación sólida que describe lo que debería hacerse y lo que se ha hecho para mitigar las vulnerabilidades es esencial para mejorar la respuesta de la organización ante las vulnerabilidades. La documentación que describe cómo se mitigó una vulnerabilidad y cuánto tiempo se necesitó para cada tipo de sistema, proporciona las métricas básicas para comprender el nivel de esfuerzo que controla este aspecto de administración de seguridad. Determinación deficiente de prioridades Otra desventaja de la administración ad hoc de vulnerabilidades es la determinación deficiente de prioridades. Sin duda alguna, no todos los activos poseen el mismo valor para una organización. Un sitio web con información sobre el producto y los antecedentes de la empresa es importante pero no tan esencial como un sistema de procesamiento de pedidos de producción. Parte de una administración efectiva de vulnerabilidades es la de priorizar activos según el valor del activo y la criticidad del proceso comercial que ese activo respalda. De igual manera, los enfoques ad hoc no priorizan en base a las amenazas y el riesgo. El software espía (spyware) y el spam son molestos para los usuarios y consumen recursos, pero no son tan perjudiciales como las amenazas combinadas y los rootkit. El conocimiento del nivel de riesgo que presentan las diferentes amenazas y la determinación de prioridades de acuerdo con las mismas es un elemento esencial de la administración efectiva de vulnerabilidades. Los enfoques ad hoc no determinan prioridades de manera efectiva y continua. La administración ad hoc de vulnerabilidades tiende a centrarse en la tecnología: si existe un parche, aplíquelo. Esta actitud refleja una perspectiva a corto plazo de las vulnerabilidades: que cada vulnerabilidad es de alguna manera una anomalía y una vez que se haya lidiado con ella ya no será un problema. Los enfoques administrados más desarrollados tienen una perspectiva a largo plazo. Respuestas administradas El supuesto básico que subyace en las respuestas administradas es que las vulnerabilidades existen y continúan existiendo y las organizaciones reconocerán este hecho y controlarán mejor las consecuencias de las amenazas con una respuesta que se fundamenta en las personas, los procesos y las tecnologías. Las respuestas administradas son sistemáticas. Los administradores de sistemas no necesitan reinventar un proceso de administración de vulnerabilidades cada vez que se da a conocer una nueva amenaza. Las respuestas administradas se centran en el proceso y no en la tecnología. No cabe duda de que la tecnología es un elemento esencial de las respuestas 61

12 El monitoreo de los activos es una función del proceso general de la Administración de contenidos empresariales (ECM). La misma información que se recolecta para la ECM respalda la etapa de monitoreo de la administración de vulnerabilidades, inclusive: Las descripciones de hardware para los servidores, clientes y dispositivos de redes Los sistemas operativos, incluyendo las versiones y los niveles de parches Las aplicaciones de software, incluyendo las versiones y los niveles de parches Los cambios de las configuraciones predeterminadas Las arquitecturas del sistema En un mundo ideal, las políticas de ECM estarían bien definidas y se cumplirían completamente. En la realidad, los cambios no oficiales en la infraestructura de TI pueden introducir las vulnerabilidades que no se reflejan en la documentación y los procesos de ECM. Los programadores podrían instalar un servidor de aplicaciones y un software de portal para respaldar sus proyectos de desarrollo. Un grupo de consultores que trabajan en una sala de conferencias durante una semana pueden decidir que instalar un punto de acceso inalámbrico es una mejor opción que tener cables de red que interfieran en la sala de conferencias. Los administradores de vulnerabilidades no pueden depender de la precisión e integridad de la documentación de ECM. Se necesita un método más dinámico. Se utiliza el descubrimiento de dispositivo automático para identificar los activos en una red y recolectar la versión de software y la información del nivel del parche. Las herramientas de descubrimiento de red pueden escanear los rangos de las direcciones de IP, identificar los S, detectar los dispositivos de protocolo simple de administración de redes (SNMP) y detectar los dispositivos inalámbricos no autorizados y otros activos en una red. Estas herramientas exploran activamente los dispositivos en la red en vez de depender de una base de datos de dispositivos reconocidos; por lo tanto son esenciales para monitorear de manera efectiva los activos. La etapa de monitoreo también implica supervisar la liberación de parches nuevos y los cambios de configuración. Los proveedores son la fuente principal de parches; por lo tanto, las organizaciones deben monitorear los sitios de soporte de los proveedores o suscribirse a un servicio de notificación. Obviamente, la falta de un parche no garantiza que un sistema esté libre de vulnerabilidades. Los administradores de sistemas deben monitorear regularmente las vulnerabilidades y el impacto que pueden tener estas vulnerabilidades en sus organizaciones. El monitoreo de vulnerabilidades consiste en varios procesos: Investigación ad hoc: como se mencionó anteriormente, las nuevas vulnerabilidades se descubren constantemente. A pesar de que las vulnerabilidades para programas populares, tales como Microsoft IE y Linux reciben atención en los medios, cualquier aplicación puede contener vulnerabilidades. Se han encontrado vulnerabilidades en herramientas de negocio que no se han adoptado ampliamente, tales como herramientas de informes de inteligencia de negocio, portales empresariales y servidores de aplicaciones. Cualquier herramienta o aplicación utilizada dentro de una organización debe considerarse susceptible de vulnerabilidades y por lo tanto, debe monitorearse. La base de datos de vulnerabilidades del Asesor de seguridad de CA (CA Security Advisor) contiene una amplia lista de vulnerabilidades. Ingrese a para conocer las últimas vulnerabilidades. 68

13 Cuáles son los activos de la organización? La administración de vulnerabilidades depende de un inventario preciso de los activos. Este inventario incluye hardware, software, archivos de configuración, arquitecturas del sistema, procesos de integración de aplicaciones, procesos de flujo de trabajo y otros activos de información tangibles e intangibles. Es importante destacar que la información sobre cómo utilizar un activo es importante para la administración de vulnerabilidades. Por ejemplo, un servidor Linux puede ser utilizado como un servidor ftp para transferencias de archivos dentro de la empresa. Este tipo de uso generalmente se considera una operación de baja prioridad al determinar el pedido de aplicación de parches. Sin embargo, el mismo servidor ftp, puede utilizarse para representar extractos nocturnos de un sistema mainframe, destinados al almacenamiento de datos. En este caso, el servidor ftp funciona como una parte esencial de los procesos de inteligencia de la empresa que deben ejecutarse durante la noche. Las personas responsables de aplicar parches y reconfigurar servidores necesitarán tener en cuenta esta información al priorizar las reparaciones de vulnerabilidades. Del mismo modo, comprender de qué manera no se utilizan los activos puede ser útil para la administración de vulnerabilidades. Por ejemplo, considere una aplicación de correo electrónico que tiene una vulnerabilidad creada por la capacidad de ejecutar JavaScript dentro de un cliente de correo electrónico. Si una política implementada por la empresa determina que las secuencias se deshabiliten en todos los clientes de correo electrónico, la amenaza que representa la vulnerabilidad se reduce de manera significativa. Los administradores de sistemas aún pueden aplicar parches para corregir el fallo, pero al hacerlo no se obtendría la misma urgencia como si se habilitara la secuenciación. 63

14 Cuáles son las vulnerabilidades que amenazan a la organización? Estar actualizado con respecto a las vulnerabilidades es un desafío significativo. El conocimiento de los activos específicos dentro de una organización limita el alcance de lo que se debe verificar, pero aún así el alcance y la cantidad de vulnerabilidades puede ser desconcertante. Las vulnerabilidades no se limitan a escasos tipos de aplicaciones o a una cantidad pequeña de proveedores. Todo el software complejo no podrá librarse de las vulnerabilidades en un futuro cercano. Recursos de información sobre vulnerabilidades Para estar actualizado con respecto a las vulnerabilidades, los administradores de sistemas y los profesionales relacionados necesitan investigar constantemente el tema. Para hacerlo, verifique los sistemas operativos y los sitios web de proveedores de aplicaciones, los sitios web de soluciones para la seguridad de la información, los grupos de correspondencia de seguridad y las publicaciones de profesionales. En la siguiente lista se destacan algunos recursos: Computer Associates CA Security Advisor en SANS Institute en SecurityFocus BugTraq en Open Source Vulnerability Database en Secunia en Mitre CVE en US-CERT en Crypto-Gram en Network World en Information Week en Information Security en SC Magazine en Journal of Computer Security en Desafortunadamente, la verificación de vulnerabilidades demandan mucho tiempo y los resultados pueden ser inconsistentes. Es probable que un administrador con poca experiencia no sepa cómo buscar vulnerabilidades o quizás puede considerar erróneamente una vulnerabilidad severa como una de menor gravedad. Además, un administrador con poca experiencia puede inscribirse para recibir un sinnúmero de alertas de correo electrónico y pasar varias horas buscando información que no es relevante para las tecnologías de la organización. La información pública sobre las vulnerabilidades puede ser inexacta (por motivos intencionales o no intencionales); por lo tanto, necesita verificación. Internet proporciona un caudal de información sobre vulnerabilidades, pero resulta difícil encontrar la información específica que usted necesita. Cuáles son los riesgos de las vulnerabilidades? Los riesgos relacionados con una vulnerabilidad van desde los estrechamente enfocados y fáciles de reparar hasta los ampliamente propagados y difíciles de mitigar. Los riesgos técnicos son en varios modos los más fáciles de comprender y controlar. Si un servidor web tiene una vulnerabilidad que permite a los atacantes ejecutar un código con privilegios de administrador o 64

15 raíz, cualquier sistema que ejecute ese servidor web y cualquier sistema que confíe en el sistema comprometido están en riesgo. Los privilegios de administrador o raíz le permitirán a un atacante obtener acceso total para copiar, eliminar y cambiar cualquier información en sistemas vulnerables. Este riesgo es obviamente crítico y es fácil de comprender y cuantificar. Los riesgos empresariales son más difíciles de evaluar. Si una aplicación de bases de datos es vulnerable a un ataque de inyección SQL y se roba la información contable del cliente, cómo afectará esto a la empresa? Los clientes, se transformarán en víctimas del robo de identidad? Cuánto tiempo les tomará a los clientes resolver cualquier reclamo por fraude relacionado con el robo? Cómo afecta esto a la marca de la empresa en la mente de los clientes? Cuánto le costará a la empresa investigar y entablar una acción judicial por el delito? Ciertamente, no existen reglas precisas para evaluar los riesgos de vulnerabilidad. De todos modos, se deben categorizar los riesgos. Una categorización básica de riesgos basada en un esquema bajo, medio y alto es una herramienta administrativa efectiva (consulte el Gráfico 3.1). Después de comprender el riesgo relativo, la próxima pregunta que se hacen las organizaciones se relaciona con el costo. Gráfico 3.1: Al combinar el inventario y la información de utilización de activos, una organización puede generar listas priorizadas en base a los riesgos. Cuál es el costo para compensar las vulnerabilidades? El costo total para compensar las vulnerabilidades comprende varios costos constitutivos: Τarifas de mantenimiento de software u otros costos relacionados con la compra de parches 65

16 Τiempo del personal dedicado a investigar, probar, categorizar, analizar el impacto potencial, validar una vulnerabilidad y correlacionar los activos afectados Τiempo del personal requerido para probar un parche o una nueva configuración Costo de oportunidad de reasignar al personal de operaciones o desarrollo para aplicar parches o reconfigurar los sistemas Pérdida de productividad mientras se aplican parches y reconfiguran aplicaciones El costo de mantenimiento de software generalmente se establece anualmente como un porcentaje de los costos de software original. Los contratos de mantenimiento generalmente incluyen soporte técnico, actualizaciones de nuevas versiones y parches. El mantenimiento es un servicio obligatorio para los sistemas de producción; por lo tanto, desde una perspectiva de administración de vulnerabilidades, se puede considerar como un costo fijo. Los otros costos constitutivos de las vulnerabilidades son variables y están sujetos a un mayor control administrativo. Como se ya mencionó, las vulnerabilidades de investigación demandan mucho tiempo y están sujetas a resultados inconsistentes. Los servicios de investigación de vulnerabilidades de seguridad pueden reducir los costos y brindar una mejor calidad de información. El tiempo requerido para aplicar parches y configurar sistemas está directamente correlacionado con el nivel de esfuerzo manual requerido. Los paquetes de distribución de software pueden automatizar algunos de estos procesos y reducir el tiempo que el personal dedica a instalar los parches. Al reducir el tiempo necesario para investigar las vulnerabilidades, al mejorar la calidad de la información sobre las vulnerabilidades y al reducir el tiempo que se requiere para instalar los parches, una organización puede minimizar los demás costos variables: los costos de oportunidad para el personal de TI y la pérdida de productividad para el personal de operaciones. Procesos en la administración de vulnerabilidades La administración de vulnerabilidades se basa en la integración de las personas, los procesos y la tecnología. Hemos visto que las respuestas ad hoc, con énfasis en los aspectos técnicos de la administración de parches no cuentan con procesos formales que puedan supervisarse para ser mejorados con el correr del tiempo. La sección anterior de este capítulo describió las características de las respuestas administradas. Ahora nos concentraremos en el ciclo de vida de la administración de vulnerabilidades. Ciclo de vida de la administración de vulnerabilidades El ciclo de vida de la administración de vulnerabilidades es un proceso que comienza antes de que se conozca una vulnerabilidad específica y finaliza después de que se hayan mitigados las vulnerabilidades. El modelo integral comprende ocho fases: Monitoreo Análisis Notificación Prioridad 66

17 Planificación Prueba Corrección Informe Como se muestra en el Gráfico 3.2, la mayoría de las etapas conducen a la etapa subsiguiente. En dos momentos del ciclo de vida, durante el análisis y la prueba, es posible que el ciclo se vea afectado. El análisis de una vulnerabilidad puede determinar que una vulnerabilidad no representa una amenaza suficiente para justificar el tiempo y el esfuerzo de corrección. Los parches o los cambios de configuración pueden fallar durante la prueba. En ese momento, el proceso vuelve a la fase de planificación para revisar el parche o el proceso de reconfiguración. Las siguientes secciones exploran cada etapa en detalle. Gráfico 3.2: El ciclo de vida de la administración de vulnerabilidades incluye ocho etapas primarias y dos etapas auxiliarias. Monitoreo La etapa de monitoreo del ciclo de vida de la administración de vulnerabilidades se centra en la identificación de activos, tecnologías y niveles de versiones nuevas o existentes, parches existentes y cambios de configuración. Además, esta etapa apunta a nuevas vulnerabilidades o actualizaciones sobre las vulnerabilidades, tales como información nueva sobre el riesgo de vulnerabilidades, los métodos de corrección o las tecnologías recientemente impactadas. 67

18 El monitoreo de los activos es una función del proceso general de la Administración de contenidos empresariales (ECM). La misma información que se recolecta para la ECM respalda la etapa de monitoreo de la administración de vulnerabilidades, inclusive: Las descripciones de hardware para los servidores, clientes y dispositivos de redes Los sistemas operativos, incluyendo las versiones y los niveles de parches Las aplicaciones de software, incluyendo las versiones y los niveles de parches Los cambios de las configuraciones predeterminadas Las arquitecturas del sistema En un mundo ideal, las políticas de ECM estarían bien definidas y se cumplirían completamente. En la realidad, los cambios no oficiales en la infraestructura de TI pueden introducir las vulnerabilidades que no se reflejan en la documentación y los procesos de ECM. Los programadores podrían instalar un servidor de aplicaciones y un software de portal para respaldar sus proyectos de desarrollo. Un grupo de consultores que trabajan en una sala de conferencias durante una semana pueden decidir que instalar un punto de acceso inalámbrico es una mejor opción que tener cables de red que interfieran en la sala de conferencias. Los administradores de vulnerabilidades no pueden depender de la precisión e integridad de la documentación de ECM. Se necesita un método más dinámico. Se utiliza el descubrimiento de dispositivo automático para identificar los activos en una red y recolectar la versión de software y la información del nivel del parche. Las herramientas de descubrimiento de red pueden escanear los rangos de las direcciones de IP, identificar los SO, detectar los dispositivos de protocolo simple de administración de redes (SNMP) y detectar los dispositivos inalámbricos no autorizados y otros activos en una red. Estas herramientas exploran activamente los dispositivos en la red en vez de depender de una base de datos de dispositivos reconocidos; por lo tanto son esenciales para monitorear de manera efectiva los activos. La etapa de monitoreo también implica supervisar la liberación de parches nuevos y los cambios de configuración. Los proveedores son la fuente principal de parches; por lo tanto, las organizaciones deben monitorear los sitios de soporte de los proveedores o suscribirse a un servicio de notificación. Obviamente, la falta de un parche no garantiza que un sistema esté libre de vulnerabilidades. Los administradores de sistemas deben monitorear regularmente las vulnerabilidades y el impacto que pueden tener estas vulnerabilidades en sus organizaciones. El monitoreo de vulnerabilidades consiste en varios procesos: Investigación ad hoc: como se mencionó anteriormente, las nuevas vulnerabilidades se descubren constantemente. A pesar de que las vulnerabilidades para programas populares, tales como Microsoft IE y Linux reciben atención en los medios, cualquier aplicación puede contener vulnerabilidades. Se han encontrado vulnerabilidades en herramientas empresariales que no se han adoptado ampliamente, tales como herramientas de informes de inteligencia empresarial, portales empresariales y servidores de aplicaciones. Cualquier herramienta o aplicación utilizada dentro de una organización debe considerarse susceptible de vulnerabilidades y por lo tanto, debe monitorearse. La base de datos de vulnerabilidades del Asesor de seguridad de CA (CA Security Advisor) contiene una amplia lista de vulnerabilidades. Ingrese a para conocer las últimas vulnerabilidades. 68

19 Escaneo de la red y prueba de penetración: las organizaciones que toman conciencia sobre la seguridad también prueban su infraestructura para detectar vulnerabilidades. Técnicas tales como el escaneo de la red y la prueba de penetración pueden descubrir debilidades en los activos y los dispositivos de seguridad que protegen el perímetro de la red. Estas pruebas pueden brindar información detallada y específica del sitio que no se encuentra disponible a través de servicios de información de seguridad de terceros; sin embargo, estas pruebas pueden tener un costo. Debe saber que la prueba de penetración y los métodos relacionados son intrusivos y pueden afectar las operaciones normales. Si un sistema tal como un router es vulnerable a un ataque de denegación de servicio (DoS), probar dicha vulnerabilidad producirá un ataque DoS. Monitoreo basado en agentes: los proveedores responden a los límites de escaneo de redes y prueba de penetración al desarrollar mecanismos de monitoreo menos intrusivos. Los monitoreos basados en agentes implementan agentes de software en activos que puedan realizar con precisión inventarios de software, parches y configuraciones. Luego se compara esta información con una base de consulta de vulnerabilidades y parches reconocidos. Este tipo de monitoreo puede identificar inmediatamente las vulnerabilidades de un activo sin un servicio que genere desorganización. Monitorear las vulnerabilidades requiere la atención de múltiples fuentes de información, tanto dentro como fuera de la organización. Análisis de activos y vulnerabilidades Analizar los activos y las vulnerabilidades es la segunda etapa del ciclo de vida de la administración de vulnerabilidades. Consta de dos pasos: Validar las nuevas vulnerabilidades Correlacionar las vulnerabilidades con los activos Los comentarios sobre vulnerabilidades se propagan de varias maneras. Con una creciente atención en las vulnerabilidades y amenazas por parte de los medios de comunicación, las fuentes de información generales en línea pueden ser la primera información que obtenga un profesional de TI sobre una vulnerabilidad. A pesar de que esta información generalmente es creíble, se deben confirmar las vulnerabilidades con expertos en seguridad que sean reconocidos, tales como Mitre CVE, US-CERT o los proveedores de aplicaciones de seguridad. Una vez confirmada, se debe correlacionar la vulnerabilidad con activos reconocidos. La pregunta crucial es: Qué activos están afectados? El tiempo puede ser limitado, por lo tanto esta correlación debe generarse desde un centro de depósito de activos. Este informe no debe ser compilado manualmente después de que se valide la vulnerabilidad. 69

20 Vulnerabilidad del día cero Mientras se descubren las vulnerabilidades, los proveedores se mueven rápidamente para aplicar parches o brindar soluciones temporales, pero es probable que esta acción no sea suficiente. Una preocupación importante entre los profesionales de seguridad es que surja una amenaza inmediatamente después del descubrimiento de una vulnerabilidad (antes de que haya un parche disponible). Las vulnerabilidades que se explotan el día en que se hacen conocidas se han denominado vulnerabilidades del día cero. Tenga en cuenta el hecho de que los proveedores deben estudiar una vulnerabilidad, desarrollar opciones para compensar el fallo, evaluar el impacto de cada opción, elegir una estrategia de compensación, implementar y probar la solución y luego liberar el parche o cambio de configuración. Mientras tanto, los atacantes pueden compartir información sobre la vulnerabilidad y aplicar paquetes de herramientas malware para desarrollar virus, gusanos y otras amenazas que explotan la vulnerabilidad. Una vez que la vulnerabilidad se hace conocida, comienza la carrera de la explotación frente al parche. En algún momento durante la fase de análisis, es posible que una organización determine que la vulnerabilidad es lo suficientemente amenazante como para continuar con el proceso. De lo contrario, es posible que los administradores de sistemas determinen que la vulnerabilidad fue corregida en un parche anterior, que no se aplica a la versión de un programa en uso o que el problema informado no era una vulnerabilidad real después de todo. Notificación La tercera etapa en una respuesta ante vulnerabilidad es la notificación de las partes afectadas. Éstas pueden incluir: Los administradores de sistemas Los administradores de seguridad Los administradores de redes Los administradores de aplicaciones Los administradores de riesgos Los administradores de empresas que dependen de sistemas vulnerables En caso de que haya amenazas que se propaguen rápidamente o que sean especialmente graves, es posible que se incrementen las notificaciones para incluir al director de informática (CIO), los gerentes de una línea de negocios (LOB), los socios, los clientes y otros directivos cuyas funciones podrían verse afectadas. Prioridad Priorizar es un paso esencial en la administración de vulnerabilidades. Los profesionales de TI pueden estar saturados con información de seguridad no procesada. A veces, todos los activos parecen ser vulnerables. Cómo puede uno clasificar estas amenazas y centrarse en los temas más importantes? La clave está en centrarse en el riesgo asociado con cada vulnerabilidad relativa a cada activo. Los investigadores de seguridad han desarrollado métricas para evaluar el riesgo de explotación de una vulnerabilidad en base a tres factores: popularidad, simplicidad e impacto. 70

21 La popularidad es una medida del grado de extensión de una vulnerabilidad y las amenazas correspondientes, y describe la frecuencia existente o potencial de explotación de la vulnerabilidad. Cuanta más popularidad tenga, más se verá afectada su organización. La simplicidad es una medida del grado de facilidad en que se explota una vulnerabilidad o el esfuerzo necesario para explotarla. Algunos ataques contra sistemas requieren un mayor esfuerzo de explotación que otros. Algunos artificios sólo requieren la introducción de una serie de comandos, mientras que otros implican compilar código y ejecutar el programa resultante según un conjunto explícito de condiciones. Las vulnerabilidades de JavaScript en los exploradores web podrían ser explotadas por un script-kiddie con poco conocimiento de programación; mientras que una vulnerabilidad en servicios de redes, tales como un nivel de sockets seguro (SSL), puede ser tan arcana y compleja que sólo podría ser explotada exitosamente por desarrolladores de redes experimentados. El impacto mide la medida en que un atacante puede obtener un acceso a un sistema y la gravedad que esta amenaza supone para la organización. Esta consideración es el factor principal que tiene en cuenta el estado interno de una organización. Qué servicios están amenazados? Los servidores de producción, son importantes para las operaciones diarias amenazadas? De ser así, cuáles son las consecuencias del fallo de seguridad? Podrían ser ingresos perdidos, falta de cumplimiento o molestias para los empleados, socios comerciales y clientes? Claramente, priorizar las vulnerabilidades requiere una visión amplia de las prioridades de la organización. Los factores determinantes incluyen consideraciones empresariales y técnicas. 71