Vigilancia de seguridadHe recibido un boletín de seguridad. Y ahora, ¿qué?

Christopher Budd

El proceso de publicación del boletín mensual de seguridad de Microsoft, que se fundó en octubre de 2003, respondía a peticiones formuladas por clientes. Una de sus principales solicitudes era que el calendario de publicaciones de los boletines de seguridad fuera previsible. Esa regularidad y la facilidad de previsión nos han permitido afinar y mejorar nuestros procesos.

En el sitio de los boletines de seguridad de Microsoft puede encontrar el boletín de seguridad más reciente y buscar en boletines anteriores, tal como se muestra en la figura 1. En la figura 2 se muestra un boletín de ejemplo; en este caso, el correspondiente a agosto de 2006.

Figure 1** Sitio de los boletines de seguridad de Microsoft **(Hacer clic en la imagen para ampliarla)

Para muchos clientes, el boletín mensual de seguridad de Microsoft ha contribuido a fomentar procesos más maduros para la implementación de actualizaciones de seguridad de Microsoft. La certeza de que los boletines de seguridad van a publicarse en una fecha determinada ha permitido a muchos clientes generar sus propios procesos periódicos para tratarlos. Estos clientes han creado escalas de tiempo y pasos en sus propios procesos de evaluación e implementación de actualizaciones de seguridad que integran las escalas de tiempo previsibles en torno a la publicación mensual del boletín de seguridad de Microsoft. Los clientes usan ese proceso para analizar, probar e implementar actualizaciones de un modo sistemático, a fin de aumentar su nivel general de seguridad y de reducir el tiempo de inactividad y los posibles trastornos.

Figure 2** Boletín de seguridad de agosto de 2006 **(Hacer clic en la imagen para ampliarla)

Sin embargo, algunos clientes realizan la evaluación y la implementación de actualizaciones de seguridad sin seguir un procedimiento establecido. Si bien es posible implementar actualizaciones de un modo no sistemático sin experimentar problemas, no es lo que consideraríamos prácticas recomendadas para administrar actualizaciones de seguridad.

Hemos proporcionado información de utilidad acerca de cómo y cuándo publicamos boletines, pero no hemos facilitado muchas pautas acerca de lo que debería hacerse con los boletines y cómo puede integrarlos en sus procesos. Algunos clientes pueden no ser conscientes de los procesos que pueden resultarles ventajosos o de la mejor forma de crearlos.

Por ello, en esta columna señalaré los pasos y procesos que recomendamos para la evaluación e implementación de actualizaciones de seguridad. Estos pasos pueden ser seguidos por organizaciones de cualquier tamaño. Para algunas organizaciones mayores, resultará adecuado dividir los pasos entre distintos grupos, con arreglo a su estructura interna. Para organizaciones más pequeñas, todos estos pasos pueden ser seguidos por un grupo o incluso por una persona. Independientemente de la asignación de responsabilidades, todos estos pasos deben tenerse en cuenta explícitamente en sus procesos de evaluación e implementación. En la figura 3 se presenta un resumen del proceso.

Figure 3** Evaluación del boletín de seguridad y proceso de implementación **

1. Recepción de notificación de llegada

El primer paso del proceso del boletín de seguridad mensual debe consistir en asegurarse de recibir la notificación de llegada de próximas actualizaciones de seguridad. Microsoft publica información en su sitio Web alrededor de las 10:00 (hora del Pacífico, GMT -8) tres días laborables antes de la publicación mensual estándar, que es el segundo martes de cada mes; por lo tanto, la información de la notificación de llegada se publica el jueves anterior.

El objetivo de la notificación de llegada es proporcionar información que facilite la planificación con tiempo suficiente para implementar la actualización. Se procura un equilibrio entre el nivel de detalle que se ofrece y la necesidad de proteger a los clientes hasta la publicación de las actualizaciones de seguridad no divulgando datos que pudieran dar facilidades a posibles atacantes. La notificación de llegada agrega información acerca de las próximas actualizaciones por nombre de producto, sin incluir información acerca de versiones específicas (por ejemplo, Microsoft® Windows® o Microsoft Office). En cada una de estas entradas se detallan cuántos boletines se publicarán para ese producto, el nivel máximo de gravedad de esos boletines, si se precisará un reinicio para alguna de las actualizaciones y qué herramientas de detección serán de aplicación según esos boletines.

Para evitar sorpresas y reducir al mínimo las posibilidades de confusión, la notificación de llegada también proporciona información acerca de otras actualizaciones no asociadas a los boletines de seguridad que se publicarán el mismo día. De forma específica, detalla cuántas actualizaciones de alta prioridad que no son de seguridad se publicarán a través de Microsoft Update (MU) y de Windows Update (WU), así como las actualizaciones de la Herramienta de eliminación de software malintencionado de Microsoft.

Por último, proporcionaremos información acerca de los problemas que pudieran provocar retrasos en la implementación, tal como hicimos para el cambio de permiso de "Enviar como" en MS06-019.

La nueva notificación de llegada se publica cada mes; en ese momento se envía una notificación a través de Security Notification Service Comprehensive Edition (SNSCE). Tiene la posibilidad de registrarse en SNSCE.

2. Evaluación de las posibles repercusiones

Tras recibir la notificación de llegada, el primer paso debería consistir en evaluar la importancia que tendrán para su entorno las próximas publicaciones. Aunque la notificación de llegada contiene un número limitado de detalles acerca de los productos afectados, presenta información suficiente para que pueda determinar si los próximos boletines van a ser significativos para su entorno.

Por ejemplo, imagínese que en la notificación de llegada se citan dos boletines de Microsoft Exchange que tienen un clasificación de gravedad máxima crítica y exigen un reinicio. Si no ejecuta ese programa, sabrá de inmediato que esos boletines no son significativos para su entorno. Por otra parte, si ejecuta Exchange Server 2003, sabrá que el martes podría tener hasta dos boletines con clasificación de gravedad máxima y que pueden precisarse reinicios.

A efectos de planificación, piense en la notificación de llegada como una herramienta que puede ayudarle a determinar el impacto máximo posible en su organización, en cuanto a números de boletines, su gravedad y sus repercusiones en la implementación por lo que se refiere a los reinicios. Tras evaluar la relevancia y el impacto máximo posible de las actualizaciones, puede crear una programación que incluya los siguientes elementos de acción:

• Personal para evaluación de riesgos, pruebas e implementación
• Planes de pruebas y tiempo de laboratorio de pruebas
• Planes de implementación y reinicios programados (cuando proceda)

En esta fase, toda la programación será provisional, ya que la información de la notificación de llegada está sujeta a cambios. Asimismo, dado que la información de la notificación de llegada es limitada, puede realizar cambios cuando disponga de todos los detalles.

Por último, si hay información adicional, como cambios de funcionalidad, debe aprovechar el período comprendido entre la notificación de llegada y la publicación del boletín de seguridad para investigar la cuestión y evaluar las repercusiones que puede tener en su entorno. Quizá deba revisar su programación provisional a raíz de esas investigaciones.

3. Recepción de nuevos boletines de seguridad de Microsoft

El segundo martes del mes, Microsoft publica sus boletines de seguridad. Las 10:00, hora del Pacífico, es la hora prevista para la publicación. Pero, dado que se trata de un proceso largo, complejo y con muchas interrelaciones, puede llegar a retrasarse por diversos motivos. Con esta publicación, en los sitios Web de Microsoft se presentan boletines de seguridad, actualizaciones de seguridad, actualizaciones para la detección y herramientas de implementación tales como Microsoft Baseline Security Analyzer (MBSA) y Windows Server® Update Services (WSUS), así como nuevos instrumentos de detección, como la reciente versión de EST (Enterprise Scan Tool).

La página de boletines de seguridad de Microsoft admite suministros RSS. Cuando los boletines de seguridad incluyen actualizaciones, nuestro suministro RSS también se actualiza y, por consiguiente, los agregadores y los visores RSS. Además, se envía una notificación mediante SNS (Security Notification Service) y SNSCE. Las notificaciones se envían por correo electrónico y a través de avisos de MSN® Alerts.

Para conocer la disponibilidad de nuevos boletines de seguridad, debe registrarse en los distintos servicios de notificación que se ofrecen. Puede suscribirse al suministro RSS, así como a SNS y SNSCE.

4. Evaluación de la importancia de los boletines de seguridad

Es importante que asigne claramente la responsabilidad de revisar los nuevos boletines de seguridad y evaluar la importancia que pueden tener para su entorno. Como parte de esta evaluación, la información específica de los boletines de seguridad puede servirle para realizar revisiones y ajustes en su programación provisional según corresponda. Volviendo al ejemplo, si avisó al equipo de administración de Exchange de una posible actualización de seguridad crítica, pero después averigua que no afecta a Exchange Server, puede ajustar la programación de esos recursos.

Después de haber evaluado la importancia de los boletines de seguridad para su organización, podrá actuar con los que resulten pertinentes en sus procesos.

5. Evaluación de riesgos y clasificación de los boletines

En esta fase debe realizar una evaluación de riesgos de los boletines pertinentes. En organizaciones en las que las responsabilidades están distribuidas, este paso suele corresponder al grupo encargado de la seguridad. Cada boletín de seguridad de Microsoft contiene una clasificación de gravedad máxima, pero esa clasificación refleja en realidad el nivel máximo de gravedad de todas las vulnerabilidades y entre todos los productos afectados. La clasificación de gravedad de Microsoft que se aplica a su organización puede ser distinta de la clasificación de gravedad máxima indicada, en función de la gravedad del problema en las versiones de su entorno. Es importante examinar la tabla de clasificaciones de gravedad e identificadores de vulnerabilidades que aparece en el resumen ejecutivo del boletín de seguridad para conocer la información sobre vulnerabilidad específica de las versiones con las que trabaja.

Después deberá consultar información técnica adicional, como los factores atenuantes y los datos técnicos de la sección de preguntas más frecuentes de cada vulnerabilidad, para realizar los ajustes necesarios en su evaluación de riesgos con arreglo a su entorno y directivas. Es posible que las directivas también apunten a que en su evaluación se tengan en cuenta factores ambientales no técnicos, como las amenazas del entorno o la importancia de determinadas aplicaciones de la organización.

Al finalizar este proceso, debe contar con una clasificación de riesgos para cada uno de los boletines y para las actualizaciones asociadas. Siguiendo con nuestro ejemplo, el grupo de administración de Exchange puede clasificar una actualización de seguridad como de "riesgo moderado", sobre la base de los cambios detallados en el boletín de seguridad. En función de sus directivas, deberá realizar actualizaciones y cambios en su programación. Por ejemplo, quizá sus directivas dicten que para las actualizaciones de riesgo moderado se precisan uno o dos días más de pruebas que para las de bajo riesgo.

En algunos casos, es posible que sus directivas dicten que para los boletines con una clasificación de riesgo determinada también sea necesario considerar la implementación de soluciones provisionales. Podría darse el caso, por ejemplo, de que la directiva de su organización establezca que, para todas las actualizaciones de seguridad que clasifique como críticas, deba revisar e implementar soluciones provisionales cuanto antes. En esas condiciones, realizaría una evaluación adicional de riesgos con las soluciones provisionales para determinar qué debe implementarse y en qué momento.

Al final de este proceso, tendría una lista de actualizaciones para implementar en su entorno y una clasificación de riesgos para cada actualización. Además, debería tener una lista de soluciones provisionales para la implantación, que deberían usarse para actualizar su programación de pruebas e implementación. Los cambios que realice en la programación deben reflejar las escalas de tiempo especificadas en las directivas. Por ejemplo, puede existir una directiva que indique que, para todas las actualizaciones de seguridad críticas, deben implementarse soluciones provisionales en un plazo no superior a 24 horas, y que las actualizaciones deben implementarse en un plazo no superior a siete días naturales.

6. Determinación de las posibles repercusiones para la organización de las actualizaciones de seguridad y de las soluciones provisionales

Comprender la incidencia de las actualizaciones de seguridad o de las soluciones provisionales en su entorno es un paso decisivo en el proceso de evaluación. En organizaciones con responsabilidades distribuidas, este paso suele corresponder al grupo que administra los sistemas a los que afectan directamente las actualizaciones de seguridad o las soluciones provisionales.

La comprensión de las posibles repercusiones le ayuda a entender y determinar el riesgo que plantean las actualizaciones de seguridad o las soluciones provisionales. Encontrará información en el boletín de seguridad, en la sección de preguntas más frecuentes (P+F) relacionadas con la actualización de seguridad. La información acerca del modo en que la actualización de seguridad responde a la vulnerabilidad se encuentra en el apartado de detalles de la vulnerabilidad, en la sección de preguntas más frecuentes sobre la vulnerabilidad.

El objetivo de este paso consiste en determinar una clasificación de riesgos para las actualizaciones y las soluciones provisionales. Siguiendo con el ejemplo anterior, el grupo de administración de Exchange puede clasificar una actualización de seguridad como de "riesgo moderado", sobre la base de los cambios detallados en el boletín de seguridad. Con arreglo a las directivas de su organización, deberá revisar su programación. Por ejemplo, quizá sus directivas dicten que para las actualizaciones de "riesgo moderado" se precisa un día más de pruebas que para las de "bajo riesgo".

Puede que también deba reconsiderar algunas decisiones acerca de la implementación de soluciones provisionales con arreglo a las repercusiones según la clasificación de riesgos de su programación. Por ejemplo, quizá le parezca que debe prolongar las pruebas dos días más, con lo que sus sistemas quedarían desprotegidos durante más tiempo del que permiten sus directivas. En ese caso, debería replantearse la implementación de soluciones provisionales, de conformidad con sus directivas.

Por último, usará la información procedente de este paso cuando se disponga a desarrollar un plan de pruebas para las actualizaciones.

7. Definición de un plan de pruebas

Para que las pruebas resulten efectivas, deben ser sistemáticas y elaborarse en el marco de un plan coherente. Las pruebas deben orientarse a áreas más susceptibles de presentar problemas en su entorno. Dado que cada entorno es distinto, no podemos ofrecer una plantilla estándar para un plan de pruebas efectivo.

Para organizaciones con responsabilidades distribuidas, es habitual que el plan de pruebas sea diseñado por más de un grupo. El grupo que administra las tecnologías o los sistemas directamente afectados por las actualizaciones de seguridad o las soluciones provisionales puede aportar sus conocimientos específicos. El grupo de pruebas puede ofrecer experiencia en la elaboración de casos de pruebas, opciones con respecto a las herramientas de pruebas e información valiosa acerca de escalas de tiempo prácticas.

Durante esta fase debe observarse cómo afecta el plan de pruebas a la clasificación de riesgos de las actualizaciones de seguridad o de las soluciones provisionales, y realizar en consecuencia cambios en la programación de pruebas y en la implementación. Por ejemplo, si determina que no puede elaborar un plan de pruebas tan completo como desearía, tiene la posibilidad de incrementar su clasificación de riesgos, retrasar la implementación e implementar soluciones provisionales mientras tanto.

8. Desarrollo de un plan de implementación

La implementación es el proceso en el que se aplica efectivamente la protección que proporcionan las actualizaciones de seguridad o las soluciones provisionales. Dado que la implementación es realmente la meta final del proceso, la comprensión de los métodos de implementación disponibles y su inclusión en las evaluaciones es tan importante como una evaluación de riesgos de seguridad. En organizaciones con responsabilidades distribuidas, la determinación de posibles métodos de implementación de las actualizaciones de seguridad suele corresponder a los grupos responsables de la administración de la infraestructura de actualizaciones de software, como el grupo que se encarga del mantenimiento de Systems Management Server (SMS). Los grupos que supervisan tecnologías de administración de configuraciones como Active Directory pueden participar en la determinación de posibles métodos de implementación de soluciones provisionales.

En este paso, su objetivo consiste en comprender los posibles métodos de implementación y, a partir de ahí, elaborar un plan que le sirva para implementar las actualizaciones de seguridad o las soluciones provisionales. Es importante entender en este paso cómo los posibles métodos de implementación pueden repercutir en su programación y realizar los cambios necesarios. Por ejemplo, si una actualización de seguridad no es compatible con WSUS y ése es su método de implementación principal, puede determinar que necesitará dos días más para implementar la actualización. Asimismo, puede decidir implementar soluciones provisionales para procurar las protecciones necesarias durante este período de implementación.

La información relativa a los métodos de implementación se encuentra en la sección de preguntas más frecuentes relacionadas con la actualización de seguridad. Con cada solución provisional se incluye información acerca de métodos de implementación de soluciones provisionales; se asocian soluciones provisionales individuales con cada vulnerabilidad.

Así concluyen las etapas de planificación. En este punto, debe contar con una programación en la que se reflejen todos los elementos de sus evaluaciones y la planificación con respecto a los riesgos para la seguridad, la clasificación de riesgos de las actualizaciones de seguridad y las soluciones provisionales, las pruebas y la implementación. Como puede ver, estas etapas están interrelacionadas de forma compleja y no son necesariamente lineales. En algunas organizaciones, estas etapas se desarrollan simultáneamente, mientras que en otras el proceso es secuencial. Debe decidir la implementación de estos pasos con arreglo a las directivas, las necesidades y los recursos de su organización. Lo más importante de estos pasos no es una estructura y un orden específicos, sino que se asegure del flujo de información y de la capacidad de respuesta mutua entre las distintas etapas. La clave de cualquier implementación radica en mantener la flexibilidad y la adaptabilidad.

9. Prueba de actualizaciones y soluciones provisionales

En la fase de pruebas, las actualizaciones de seguridad y las soluciones provisionales se someten al plan de pruebas definido previamente en su entorno de pruebas. El objetivo en el entorno de pruebas consiste en replicar los elementos críticos del entorno de producción. Al probar las actualizaciones de seguridad o las soluciones provisionales, el esfuerzo se orienta a detectar los problemas que podrían producirse antes de la implementación en el entorno de producción.

Cuando identifique problemas durante las pruebas, deberá determinar la gravedad en cada caso y los pasos que deben seguirse para resolverlos. Quizá descubra problemas leves cuyas repercusiones resulten aceptables, mientras que otros requerirán una solución antes de que se implementen las actualizaciones. Si decide aceptar un problema, documéntelo para el personal de soporte técnico.

Para resolver el problema, tiene la opción de abrir un caso a través de los servicios de soporte técnico de Microsoft, que ofrecen asistencia gratuita para problemas relacionados con las actualizaciones de seguridad. Encontrará información acerca de cómo ponerse en contacto con los servicios de soporte técnico de Microsoft en support.microsoft.com/security. Dado que la solución de problemas puede prolongar la fase de pruebas y, por lo tanto, retrasar la implementación, antes de que se decida por resolver una problema, debe considerar las posibles repercusiones que tendría en su programación.

Cuando finalicen las pruebas y todos los problemas se hayan resuelto o documentado, podrá certificar las actualizaciones de seguridad o las soluciones provisionales para la implementación en su entorno de producción.

10. Implementación de actualizaciones y soluciones provisionales

Después de que las actualizaciones de seguridad o las soluciones provisionales hayan sido certificadas tras la fase de pruebas, puede seguir con el proceso de implementación. Durante la implementación, sírvase del plan como guía para aplicar las actualizaciones de seguridad o los cambios de configuración en los sistemas. Los grupos que participaron en el desarrollo del plan suelen ser responsables de las implementaciones reales.

Si detecta problemas en la implementación (por ejemplo, una actualización de seguridad no se instala correctamente a través de la infraestructura de administración de actualizaciones) deberá examinar el problema con detenimiento. Si el problema implica retrasos, le interesará volver a examinar opciones o considerar soluciones provisionales para proteger los sistemas.

En un situación ideal, el proceso de pruebas permitirá identificar todos los problemas que puedan surgir en la producción antes de la implementación. Sin embargo, si detecta problemas tras la implementación en el entorno de producción, deberá seguir los mismos pasos que si hubiera encontrado un problema en la fase de pruebas. Evalúe el problema y decida si aceptarlo o resolverlo.

Si las actualizaciones de seguridad se aplican correctamente, significa que las protecciones funcionan y se ha cumplido el objetivo de estos procesos. Sin embargo, si no se aplican correctamente, los sistemas seguirán siendo vulnerables.

Dado que algunos sistemas pueden no haberse actualizado correctamente, el paso final del proceso de implementación es muy importante: la auditoría de los sistemas para comprobar el éxito de la implementación. En algunas organizaciones, la auditoría correrá a cargo de un grupo independiente, a menudo relacionado con los equipos de seguridad. Se pueden usar herramientas de Microsoft, como WSUS, MBSA y SMS, para auditar la correcta aplicación de las actualizaciones de seguridad. Además, en la sección de información acerca de la actualización se indica cómo comprobar que la actualización de seguridad se ha aplicado correctamente.

Conclusión

La publicación mensual del boletín de seguridad de Microsoft le ofrece la posibilidad de implementar una planificación y procesos más regulares para la administración de las actualizaciones de seguridad. La elaboración de procedimientos y procesos regulares le ayuda a proteger mejor sus sistemas, además de reducir al mínimo la posibilidad de que surjan problemas y posibles tiempos de inactividad.

Si bien toda organización debe crear sus propios procesos exclusivos para administrar las actualizaciones de seguridad, en ellos deberían incluirse los pasos que se recomiendan en esta columna. No es necesario que tenga equipos de seguridad y actualizaciones distintos, pero debería realizar una evaluación de riesgos de seguridad y desarrollar un plan de implementación.

La planificación tiene una importancia fundamental. Con una buena planificación, los pasos que implican una actividad real, como las etapas de pruebas e implementación, discurrirán mucho mejor. Lo que, a su vez, se traducirá en mayores probabilidades de éxito del proceso de actualización de seguridad.

Christopher Budd es administrador de programas de seguridad en el centro de respuestas de seguridad de Microsoft (MSRC, del inglés Microsoft Security Response Center). Está especializado en la comunicación técnica con los profesionales de TI y de seguridad, así como con otros usuarios de software.

© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.