<?xml version="1.0" encoding="ISO-8859-15"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comentarios en: 10 errores frecuentes en la gestión de actualizaciones de seguridad</title>
	<atom:link href="http://www.sahw.com/wp/archivos/2008/09/01/10-errores-frecuentes-en-la-gestion-de-actualizaciones-de-seguridad/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.sahw.com/wp/archivos/2008/09/01/10-errores-frecuentes-en-la-gestion-de-actualizaciones-de-seguridad/</link>
	<description>Seguridad de la Información y Auditoría de Sistemas</description>
	<lastBuildDate>Thu, 11 Mar 2010 13:45:40 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>Por: Webeando 2.0 &#171; Mundo Binario</title>
		<link>http://www.sahw.com/wp/archivos/2008/09/01/10-errores-frecuentes-en-la-gestion-de-actualizaciones-de-seguridad/comment-page-1/#comment-49134</link>
		<dc:creator>Webeando 2.0 &#171; Mundo Binario</dc:creator>
		<pubDate>Sat, 06 Sep 2008 21:33:51 +0000</pubDate>
		<guid isPermaLink="false">http://www.sahw.com/wp/?p=1602#comment-49134</guid>
		<description>[...] el mundillo de la seguridad, Sergio Hernando hizo un extenso e interesante post respecto a los 10 errores frecuentes en la gestiÃ³n de actualizaciones de seguridad. Desde Dragon Jar nos dejan algunas definiciones interesantes sobre los hackers. Por un mundo [...]</description>
		<content:encoded><![CDATA[<p>[...] el mundillo de la seguridad, Sergio Hernando hizo un extenso e interesante post respecto a los 10 errores frecuentes en la gestiÃ³n de actualizaciones de seguridad. Desde Dragon Jar nos dejan algunas definiciones interesantes sobre los hackers. Por un mundo [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Por: Sergio Hernando</title>
		<link>http://www.sahw.com/wp/archivos/2008/09/01/10-errores-frecuentes-en-la-gestion-de-actualizaciones-de-seguridad/comment-page-1/#comment-49051</link>
		<dc:creator>Sergio Hernando</dc:creator>
		<pubDate>Mon, 01 Sep 2008 21:42:45 +0000</pubDate>
		<guid isPermaLink="false">http://www.sahw.com/wp/?p=1602#comment-49051</guid>
		<description>Sebastián,

Gracias por la aportación a ti también. Como bien dices, los servicios de alertas suelen ser limitados, y no están integrados plenamente en las organizaciones, lo que plantea los problemas que hemos comentado. 

En caso de que el trabajo se haga en casa, los administradores, efectivamente, asesorados por el personal de seguridad, que son los que deben decidir qué parchear y cómo, deben aplicar los parches sugeridos disponiendo de la máxima información posible. Siempre es bueno que los administradores conozcan los parches, pero quienes deben conocerlos en profundidad, en términos de aplicabilidad, conveniencia y resolución de conflictos de seguridad, son los administradores de seguridad.

Un saludo, y al igual que le decía a Mini en el comentario anterior, me alegro de que te haya gustado el texto :)</description>
		<content:encoded><![CDATA[<p>Sebastián,</p>
<p>Gracias por la aportación a ti también. Como bien dices, los servicios de alertas suelen ser limitados, y no están integrados plenamente en las organizaciones, lo que plantea los problemas que hemos comentado. </p>
<p>En caso de que el trabajo se haga en casa, los administradores, efectivamente, asesorados por el personal de seguridad, que son los que deben decidir qué parchear y cómo, deben aplicar los parches sugeridos disponiendo de la máxima información posible. Siempre es bueno que los administradores conozcan los parches, pero quienes deben conocerlos en profundidad, en términos de aplicabilidad, conveniencia y resolución de conflictos de seguridad, son los administradores de seguridad.</p>
<p>Un saludo, y al igual que le decía a Mini en el comentario anterior, me alegro de que te haya gustado el texto :)</p>
]]></content:encoded>
	</item>
	<item>
		<title>Por: Sergio Hernando</title>
		<link>http://www.sahw.com/wp/archivos/2008/09/01/10-errores-frecuentes-en-la-gestion-de-actualizaciones-de-seguridad/comment-page-1/#comment-49050</link>
		<dc:creator>Sergio Hernando</dc:creator>
		<pubDate>Mon, 01 Sep 2008 21:38:10 +0000</pubDate>
		<guid isPermaLink="false">http://www.sahw.com/wp/?p=1602#comment-49050</guid>
		<description>mini,

Gracias por el comentario, me alegra ver puntos de vista distintos al mío :)

Te doy la razón en que efectivamente, las amenazas se han incrementado y sofisticado, y que por tanto, la probabilidad de daño es cada vez mayor. Nadie discute ese punto. Creo que es obvio que ante un evento crítico, por ejemplo un 0 day en una máquina expuesta al tráfico anónimo y un agujero listo para explotar, hay que actuar rápido. En estos casos también se puede analizar el riesgo y hacer una prueba en cuestión de poco tiempo, pero lo que prima es cerrar el grifo, y ya afinaremos la cañería. Este modus operandi tiene cabida en lo expuesto, aunque es secuencial, como tú mismo explicas.

Aún en estos supuestos, hay que tener en cuenta que en el caso de una máquina expuesta deberían existir otros mecanismos que mitiguen el riesgo y que permitan no tener que precipitarse en la solución de un problema, como por ejemplo, cortafuegos, sondajes IDS e IPS y segmentación de redes adecuada, con lo que tirarse al charco &quot;a lo loco&quot; puede ser precipitado. Cada caso requerirá el conveniente estudio, qué duda cabe.

El post está más orientado a la gestión ordinaria de parches, aquella en la que sí podemos articularla con cabeza, pensando qué hacer y escogiendo entre las distintas opciones, y en la que el riesgo primario no es un atacante externo o interno descontrolado, sino echar abajo una producción por no hacer las cosas bien.

Ah, y por cierto, me alegro que encuentres los últimos contenidos más de tu agrado. Espero que la línea sea continuista en este sentido :)

Un saludo,</description>
		<content:encoded><![CDATA[<p>mini,</p>
<p>Gracias por el comentario, me alegra ver puntos de vista distintos al mío :)</p>
<p>Te doy la razón en que efectivamente, las amenazas se han incrementado y sofisticado, y que por tanto, la probabilidad de daño es cada vez mayor. Nadie discute ese punto. Creo que es obvio que ante un evento crítico, por ejemplo un 0 day en una máquina expuesta al tráfico anónimo y un agujero listo para explotar, hay que actuar rápido. En estos casos también se puede analizar el riesgo y hacer una prueba en cuestión de poco tiempo, pero lo que prima es cerrar el grifo, y ya afinaremos la cañería. Este modus operandi tiene cabida en lo expuesto, aunque es secuencial, como tú mismo explicas.</p>
<p>Aún en estos supuestos, hay que tener en cuenta que en el caso de una máquina expuesta deberían existir otros mecanismos que mitiguen el riesgo y que permitan no tener que precipitarse en la solución de un problema, como por ejemplo, cortafuegos, sondajes IDS e IPS y segmentación de redes adecuada, con lo que tirarse al charco &#8220;a lo loco&#8221; puede ser precipitado. Cada caso requerirá el conveniente estudio, qué duda cabe.</p>
<p>El post está más orientado a la gestión ordinaria de parches, aquella en la que sí podemos articularla con cabeza, pensando qué hacer y escogiendo entre las distintas opciones, y en la que el riesgo primario no es un atacante externo o interno descontrolado, sino echar abajo una producción por no hacer las cosas bien.</p>
<p>Ah, y por cierto, me alegro que encuentres los últimos contenidos más de tu agrado. Espero que la línea sea continuista en este sentido :)</p>
<p>Un saludo,</p>
]]></content:encoded>
	</item>
	<item>
		<title>Por: Sebastián</title>
		<link>http://www.sahw.com/wp/archivos/2008/09/01/10-errores-frecuentes-en-la-gestion-de-actualizaciones-de-seguridad/comment-page-1/#comment-49049</link>
		<dc:creator>Sebastián</dc:creator>
		<pubDate>Mon, 01 Sep 2008 16:13:10 +0000</pubDate>
		<guid isPermaLink="false">http://www.sahw.com/wp/?p=1602#comment-49049</guid>
		<description>Paaahhh... pedazo de post! Es un tema muy interesante y justamente el otro día discutíamos algunos de estos conceptos aquí en el trabajo.

Por un lado, entiendo el punto de vista que plantean en el comentario anterior. Yo creo que depende del caso habrá que aplicar rapidamente el parche o hacer una evaluación de impacto como corresponde.

Por otro lado, lo que me interesa comentar es el putno de los servicios de alertas, ya que yo creo que la información que brindan muchos de ellos es escasa. Como vos decís, el nobre de la vulnerabilidad, las versiones afecatadas y muchas veces hasta ahí llegamos.

En ese caso, creo que los administradores deben tomarse el trabajo:
1. uscar un servicio que brinde información más completa.
2. o bien de hacer una búsqueda por varios sitios web para conocer mejor el parche y el problema.

En fin, es un tema muy complejo y, como todo, deberá adaptarse la gestión al tamaño y características de la organización.

¡Felicitaciones por el post!</description>
		<content:encoded><![CDATA[<p>Paaahhh&#8230; pedazo de post! Es un tema muy interesante y justamente el otro día discutíamos algunos de estos conceptos aquí en el trabajo.</p>
<p>Por un lado, entiendo el punto de vista que plantean en el comentario anterior. Yo creo que depende del caso habrá que aplicar rapidamente el parche o hacer una evaluación de impacto como corresponde.</p>
<p>Por otro lado, lo que me interesa comentar es el putno de los servicios de alertas, ya que yo creo que la información que brindan muchos de ellos es escasa. Como vos decís, el nobre de la vulnerabilidad, las versiones afecatadas y muchas veces hasta ahí llegamos.</p>
<p>En ese caso, creo que los administradores deben tomarse el trabajo:<br />
1. uscar un servicio que brinde información más completa.<br />
2. o bien de hacer una búsqueda por varios sitios web para conocer mejor el parche y el problema.</p>
<p>En fin, es un tema muy complejo y, como todo, deberá adaptarse la gestión al tamaño y características de la organización.</p>
<p>¡Felicitaciones por el post!</p>
]]></content:encoded>
	</item>
	<item>
		<title>Por: Mini</title>
		<link>http://www.sahw.com/wp/archivos/2008/09/01/10-errores-frecuentes-en-la-gestion-de-actualizaciones-de-seguridad/comment-page-1/#comment-49047</link>
		<dc:creator>Mini</dc:creator>
		<pubDate>Mon, 01 Sep 2008 15:09:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.sahw.com/wp/?p=1602#comment-49047</guid>
		<description>Hola hola
Yo pensaba más o menos como has escrito. Sin embargo ahora lo veo de otra manera. Las condiciones actuales son de una red hostil. Se libera un parche y en cuestión de días, a veces horas, ya aparece un exploit que ataca a los sistemas vulnerables.
En esta situación hay que minimizar el daño. Si empezamos con análisis de impacto, planes de pruebas, estrategias de desplieugue, etc. llegaremos tarde: el sistema ya habrá sido atacado para cuando queramos aplicar un parche. 
Como te decía, me he vuelto un pragmático. Ahora aplico los parches en mi red inmediatamente siguiendo una progresión. Comienzo con unos pocos sistemas no críticos, poco después aumento el número de sistemas parcheados, poco después comienzo a incluir servidores más importantes, etc. 
Mi plan es tener los parches aplicados en 24h máximo. 
Sé que puede parecer arriesgado, sobre todo desde un punto de vista de auditoría. Antes yo también pensaba así, pero hoy la situación ha cambiado: he asumido que va a haber daños. Y me he preguntado ¿qué es lo que prefiero? ¿que me claven un cuchillo en el brazo o que me disparen en el pecho? 
Un saludo
Los contenidos del blog han mejorado en las últimas semanas deasde mi punto de vista.</description>
		<content:encoded><![CDATA[<p>Hola hola<br />
Yo pensaba más o menos como has escrito. Sin embargo ahora lo veo de otra manera. Las condiciones actuales son de una red hostil. Se libera un parche y en cuestión de días, a veces horas, ya aparece un exploit que ataca a los sistemas vulnerables.<br />
En esta situación hay que minimizar el daño. Si empezamos con análisis de impacto, planes de pruebas, estrategias de desplieugue, etc. llegaremos tarde: el sistema ya habrá sido atacado para cuando queramos aplicar un parche.<br />
Como te decía, me he vuelto un pragmático. Ahora aplico los parches en mi red inmediatamente siguiendo una progresión. Comienzo con unos pocos sistemas no críticos, poco después aumento el número de sistemas parcheados, poco después comienzo a incluir servidores más importantes, etc.<br />
Mi plan es tener los parches aplicados en 24h máximo.<br />
Sé que puede parecer arriesgado, sobre todo desde un punto de vista de auditoría. Antes yo también pensaba así, pero hoy la situación ha cambiado: he asumido que va a haber daños. Y me he preguntado ¿qué es lo que prefiero? ¿que me claven un cuchillo en el brazo o que me disparen en el pecho?<br />
Un saludo<br />
Los contenidos del blog han mejorado en las últimas semanas deasde mi punto de vista.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
