Capítulo 3

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
 Capítulo 3

Prueba, corrección e informe ...................................................................................................76

Resumen...............................................................................................................................................77

ii
 Capítulo 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
 Capítulo 3

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 http://weblog.infoworld.com/enterprisemac/archives/2006/08/is_windows_inhe.html.

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
 Capítulo 3

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
 Capítulo 3

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
 Capítulo 3

 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
 Capítulo 3

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
 Capítulo 3

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
 Capítulo 3

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
 Capítulo 3

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 http://www.ca.com/securityadvisor para conocer las
últimas vulnerabilidades.

68
 Capítulo 3

¿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
 Capítulo 3

¿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 http://www3.ca.com/securityadvisor/
SANS Institute en http://www.sans.org
SecurityFocus BugTraq en http://www.securityfocus.com
Open Source Vulnerability Database en http://www.osvdb.org/
Secunia en http://www.secunia.com
Mitre CVE en http://www.cve.mitre.org/
US-CERT en http://www.us-cert.gov/
Crypto-Gram en http://www.counterpane.com/crypto-gram.html
Network World en http://www.networkworld.com
Information Week en http://www.informationweek.com
Information Security en http:///www.infosecuritymag.com
SC Magazine en http://www.scmagazine.com/home/index.cfm
Journal of Computer Security en http://www.csl.sri.com/programs/security/jcs/

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
 Capítulo 3

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
 Capítulo 3

 Τ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
 Capítulo 3

 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
 Capítulo 3

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 http://www.ca.com/securityadvisor para conocer las
últimas vulnerabilidades.

68
 Capítulo 3

 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
 Capítulo 3

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
 Capítulo 3

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
 Capítulo 3

Planificación
Durante la etapa de planificación, los administradores de sistemas y los analistas de seguridad
determinan cuál es el mejor método de corrección. Es posible que se utilicen diferentes enfoques
dentro de la misma organización para responder a la misma amenaza. Los activos de mayor
prioridad pueden garantizar respuesta inmediata con protección, parches instalados manualmente
o reconfiguraciones realizadas por el equipo de sistemas y los administradores de aplicaciones.
Es posible que a los activos de menor prioridad se les aplique un parche a través de un sistema de
distribución de software y se implementen durante períodos menos importantes.
En general, un plan de corrección incluirá:
 Una lista priorizada de los activos a los que se les aplicará un parche o se los
reconfigurará por algún riesgo o situación crítica
 Un programa para implementar el plan
 Una serie de instrucciones para preparar e instalar el parche o los cambios de
configuración
 Una serie de instrucciones para verificar que el parche o cambio de configuración haya
dado resultado
 Planes para manejar una situación cuando falle el parche o la configuración
Una vez que se determina un plan de corrección, se puede comenzar con la prueba.

Prueba
Durante la etapa de prueba, se ejecuta el plan de corrección en los sistemas iniciales. Los parches
y cambios de configuración se prueban por tipo de activo. Según la importancia del tipo de
activo, las pruebas pueden variar desde relativamente simples hasta complejas, incluyendo:
 Reiniciar un servidor o una máquina de un cliente para verificar el nivel del paquete de
servicios que se muestra en el reinicio
 Verificar los parámetros del archivo de configuración y registro
 Ejecutar los informes de activos para hacer un inventario de los componentes de un
servidor o cliente
 Ejecutar escaneos de red o pruebas de penetración
 Ejecutar los paquetes de prueba en aplicaciones importantes para garantizar que el cambio
no ha afectado a otros activos de software
Si se producen fallas en esta etapa, el proceso retrocede hasta la etapa de planificación. Si no se
pueden encontrar configuraciones o parches alternativos, es posible que la organización se vea
forzada a correr el riesgo relacionado con la vulnerabilidad, limitar el uso de componentes
vulnerables o reemplazar los activos vulnerables.

 No todas las versiones del plan de corrección necesitan ser evaluadas de inmediato. A pesar de que
el diagrama del ciclo de vida muestra una sola transición de la prueba a la implementación, es
posible que haya múltiples ciclos de corrección y prueba. Los planes diseñados para los activos de
mayor prioridad posiblemente se prueben e implementen en primer lugar, para luego continuar con
los planes destinados a los activos de menor prioridad.

72
 Capítulo 3

Corrección
Los parches y cambios de configuración verificados son implementados durante la etapa de
corrección. Los parches y cambios de configuración son distribuidos e instalados de acuerdo con
el plan priorizado. El Gráfico 3.3 muestra una lista típica de tarea de implementación.

Gráfico 3.3: Los sistemas de implementación automatizada pueden quedar en espera y distribuir los parches
de acuerdo con los planes de corrección.

Cuando no existen parches o éstos no funcionan con algunos activos, se implementa otra
protección. A diferencia de los pasos de corrección en las respuestas ad hoc, un paso de
corrección administrado se ejecuta de acuerdo con un plan y generalmente se encuentra
respaldado por métodos de distribución automatizados. Las pruebas previas reducen la
posibilidad de que haya problemas y la necesidad de deshacer los parches. Después de la
corrección, los administradores de sistemas continúan con la etapa final del ciclo de vida de la
administración de vulnerabilidades: informe.

73
 Capítulo 3

Informe
La etapa de informe consta de tres pasos:
 Verificar que los parches y los cambios de configuración sean efectivos
 Μedir el progreso
 Determinar los niveles de cumplimiento
Los pasos de verificación en esta etapa son similares a los utilizados en la fase de prueba. No
todos los procedimientos que se ejecutaron en la etapa anterior necesitan ser ejecutados en este
momento. Por ejemplo, las pruebas de penetración que se realizaron en un entorno de prueba
podrían ser demasiado molestas en un entorno de producción. Ocurre lo mismo cuando los
activos de mayor valor se han desconectado y deben ser reestablecidos para su funcionamiento lo
antes posible.
El objetivo de la corrección es reducir el perfil general de riesgo de una organización. Durante la
etapa de informe, los administradores de seguridad evalúan el impacto general de la corrección:
 ¿En qué medida se ha mitigado el riesgo? ¿Podría medirse según la popularidad, la
simplicidad y el impacto de las vulnerabilidades?
 ¿Qué vulnerabilidades existen todavía?
 ¿Hay otras vulnerabilidades que necesitan una atención inmediata?
La administración de vulnerabilidades es una parte esencial del cumplimiento de mantenimiento.
Algunas regulaciones [tales como la ley Gramm-Leach Bliley, la Ley de Portabilidad y
Responsabilidad del Seguro Médico (HIPAA) y la Organización Internacional para la
Estandarización (ISO) 17799] definen las normas de cumplimiento que pueden compararse con
los informes de corrección y otros datos recolectados por los agentes que informan sobre activos.
El Gráfico 3.4 muestra un ejemplo de un informe de cumplimiento.

74
 Capítulo 3

Gráfico 3.4: El cumplimiento puede ser medido según los grupos de activos y el nivel de cumplimiento
requerido.

El ciclo de vida de la administración de vulnerabilidades se basa en la premisa de que un

software complejo y una infraestructura de TI son y seguirán siendo vulnerables a las amenazas
de seguridad. En vez de ser incidentes aislados, los ataques son acontecimientos comunes que
crecen en número, gravedad y tasa de distribución. La respuesta metódica que se describe en este
capítulo y las herramientas de seguridad adecuadas permiten a las organizaciones controlar el
nivel de riesgo al que están sujetas. Como se muestra en el siguiente escenario, con el personal,
los procesos y la tecnología adecuada, una vulnerabilidad que se genera rápidamente puede ser
administrada de manera efectiva.

75
 Capítulo 3

Escenario de administración de vulnerabilidades

Epsilon Medical Management es un servicio ficticio de administración médica que brinda
servicios de administración de registros para prácticas médicas pequeñas y medianas. Como una
compañía de atención médica, Epsilon Medical Management debe cumplir con las
regulaciones de la HIPAA, incluyendo aquéllas relacionadas con la administración de
vulnerabilidades. Como parte de este esfuerzo, la empresa ha implementado un proceso de
administración de vulnerabilidades.

Monitoreo de amenazas emergentes

Epsilon Medical Management se suscribe a un servicio de administración de seguridad que
notifica a los clientes sobre vulnerabilidades emergentes. Esta suscripción respalda los esfuerzos
de monitoreo de la empresa, implica ahorro de tiempo y de esfuerzo de investigación y garantiza
información de alta calidad. Inmediatamente después de que se liberó el gusano Sassar, los
administradores de sistemas de Epsilon Medical Management recibieron por correo electrónico
una notificación sobre la amenaza enviada por el servicio de administración de seguridad.

Análisis y notificación
El administrador de sistemas responsable de los servidores de Microsoft en la organización
revisó la información detallada brindada por el servicio de administración de seguridad y la
información que estaba disponible en el sitio web de Microsoft. Después de validar la amenaza,
el administrador de sistemas ejecutó un informe de activos para correlacionar la vulnerabilidad
con los servidores de la empresa. Descubrió que aproximadamente 200 servidores estaban
afectados, de los cuales 15 eran servidores de producción esenciales. Dada la gravedad de la
amenaza, el administrador del sistema incrementó la respuesta y notificó al CIO y al
departamento de cumplimiento. También se notificó a los contactos técnicos en los sitios para
clientes que había un proceso de administración de vulnerabilidades en curso y que se
desarrollaría un plan de corrección en el corto plazo.

Determinación de prioridades y planificación

El administrador de sistema y el CIO luego revisaron una lista priorizada de los activos
afectados. El informe se generó desde un centro de depósito de administración de
vulnerabilidades que incluye una base de consulta de vulnerabilidades y un inventario de activos.
Decidieron aplicar inmediatamente un parche proporcionado por Microsoft a los 15 servidores
importantes. A los 185 servidores restantes se les aplicaría un parche la semana siguiente durante
la próxima ventana de mantenimiento programada.

Prueba, corrección e informe

El administrador de sistema y su personal probaron el parche en el laboratorio de TI en tres
configuraciones diferentes encontradas en los 15 servidores importantes. No se detectaron
problemas y se programó el parche en el sistema de distribución de software. Como se aplicaron
los parches, el administrador de sistema verificó que el parche haya dado resultado.
El administrador de sistema y el CIO luego siguieron los lineamientos del departamento de
cumplimiento y revisaron los informes de cumplimiento específicos de la HIPAA generados a
76
 Capítulo 3

partir del sistema de administración de vulnerabilidades. En base a la información adicional de

los expertos en cumplimiento, el CIO reprogramó parches en varios servidores pendientes para
llevarlos nuevamente a un cumplimiento anterior al que se programó originalmente.

Resumen
Las vulnerabilidades y las amenazas forman parte del panorama de administración de
información; prepararse para responder ante ellas no es una cuestión opcional. Los objetivos de
negocio clave detrás de la administración de vulnerabilidades incluyen el cumplimiento de
regulaciones, la continuidad empresarial y la protección de activos. Los profesionales de TI
y de seguridad ya no son los únicos que impulsan la administración de vulnerabilidades; los
directores y ejecutivos de las organizaciones son más concientes de la necesidad de implementar
una administración de seguridad.
Al igual que otros aspectos de la tecnología de la información, las vulnerabilidades y amenazas
deben ser administradas con un proceso bien definido que equilibre los costos y los beneficios.
El proceso de administración de vulnerabilidades descrito en este capítulo se ha desarrollado a
partir de las mejores prácticas para tratar las vulnerabilidades. El proceso no es una solución
definitiva, las vulnerabilidades y amenazas nos acompañarán en el futuro inmediato; sin
embargo, obtiene los beneficios combinados de las personas, los procesos y las tecnologías. El
resultado es un proceso permanente que puede medirse y mejorarse con el tiempo.

77