{"id":687,"date":"2006-06-24T09:42:38","date_gmt":"2006-06-24T07:42:38","guid":{"rendered":"http:\/\/www.sahw.com\/wp\/archivos\/2006\/06\/24\/los-efectos-colaterales-de-las-vulnerabilidades\/"},"modified":"2006-06-24T09:43:27","modified_gmt":"2006-06-24T07:43:27","slug":"los-efectos-colaterales-de-las-vulnerabilidades","status":"publish","type":"post","link":"https:\/\/www.sahw.com\/wp\/2006\/06\/24\/los-efectos-colaterales-de-las-vulnerabilidades\/","title":{"rendered":"Los efectos colaterales de las vulnerabilidades"},"content":{"rendered":"

Este art?culo se public? originalmente en \u00abuna-al-d?a\u00bb<\/a> de Hispasec Sistemas<\/a><\/strong><\/p>\n

Las diversas vulnerabilidades que aparecen d?a a d?a constituyen, en muchas ocasiones, ?nicamente un primer foco de exposici?n para los usuarios y las organizaciones.<\/p>\n

Si nos referimos a normativa, la gesti?n de las vulnerabilidades t?cnicas puede enfocarse de muchas maneras. La m?s empleada es posiblemente la gesti?n de vulnerabilidades seg?n ISO 17799:2005, cuyo punto 12.6 est? espec?ficamente dise?ado para estos prop?sitos, como parte vital dentro del dominio que componen la adquisici?n, el desarrollo y el mantenimiento de sistemas de la informaci?n.<\/p>\n

El control de vulnerabilidades t?cnicas se puede abordar desde diversas ?pticas complementarias y paralelas a la citada. Si nos referimos a la reciente ISO 27001:2005, se nos recomienda el establecimiento de controles que permitan reducir los riesgos debidos a la explotaci?n de vulnerabilidades publicadas.<\/p>\n

Quiz?s ser?a conveniente corregir ese matiz de la norma e incluir no s?lo las vulnerabilidades publicadas, sino tambi?n las que no lo est?n. Es que la gesti?n de TI debe tener un concepto de previsi?n que en raras ocasiones se est? utilizando cuando definimos controles para este punto de la norma. As? por ejemplo, si abordamos el control para productos de amplio espectro de uso como Mozilla Firefox o Internet Explorer, productos que sabemos que tienen un historial notorio de vulnerabilidades, es prudente prever futuras fallas, que si bien no ser?n conocidas en detalle hasta que ocurran, sabemos que tarde o temprano aparecer?n.<\/p>\n

En l?neas generales, la gesti?n de vulnerabilidades enfocada desde las buenas pr?cticas consiste en obtener informaci?n a tiempo de las vulnerabilidades t?cnicas, evaluar la exposici?n de la organizaci?n ante dichas problem?ticas y definir las acciones apropiadas para mitigar y solucionar las deficiencias t?cnicas. Para un adecuado gobierno IT no debe bastar con esperar a que los fabricantes nos pongan en bandeja los parches. Hay que extraer inteligencia y metodolog?as de previsi?n de los incidentes documentados. Este peque?o valor a?adido es el que convierte a la gesti?n de parches tradicional en una gesti?n de vulnerabilidades proactiva, acorde a las necesidades de gesti?n de riesgo que precisan las organizaciones.<\/p>\n

En muchas ocasiones, este control de vulnerabilidades termina cuando gestionamos una correcci?n primaria. Aparece un fallo en RealVNC y lo solucionamos. Aparecen fallos en OpenSSH y Sendmail y son corregidos. Sirvan estos tres ejemplos para ilustrar que esta pol?tica no suele ser suficiente, ya que los productos y servicios primarios son, en numerosas ocasiones, parte integrante de otros que heredan de los primeros los mismos estados de vulnerabilidad.<\/p>\n

Vamos a poner un ejemplo muy sencillo que clarifica esta visi?n del problema. Si se nos ha fundido una bombilla en casa y al sacar del armario un retr?ctil de 6 bombillas ?ste cae al suelo, provocando la rotura de la bombilla que hemos seleccionado para reponer la fundida, lo m?s prudente es pensar que es posible que el resto de bombillas puedan estar da?adas, as? que ser? conveniente examinar la totalidad de la caja en ese momento, para comprar nuevas bombillas en caso de que hayan quedado inutilizadas todas tras la ca?da. No parece adecuado guardar la caja sin m?s y esperar a que se funda una nueva bombilla para ver si tuvimos suerte en el primer incidente y s?lo hubo una rotura. Actuando as?, es posible que el d?a que precisemos un repuesto, no lo tengamos.<\/p>\n

Y?ndonos a casos reales, IBM Hardware Management Console (HMC), un extendido sistema de gesti?n por consola, se ve afectado de los recientes fallos declarados no s?lo para OpenSSH (relativo a la inyecci?n de comandos shell, sino tambi?n al de Sendmail (correspondiente a la corrupci?n de memoria en el manejo de se?ales). Ambas documentadas a tiempo en \u00abuna-al-d?a\u00bb y nuestro servicio corporativo de gesti?n de vulnerabilidades S.A.N.A. Aquellas organizaciones que cerraron la gesti?n de parches con los ofrecidos por los fabricantes primarios el 13 de febrero y el 23 de marzo respectivamente, fueron notificados ayer de que un producto, en este caso IBM HMC, se ve?a expuesto colateralmente por dichos problemas, con lo que la correcta aplicaci?n de controles sobre el punto 12.6 de la norma obliga a reabrir la incidencia y paliarla, siguiendo los mismos procedimientos, siempre y cuando seamos usuarios de esta soluci?n.<\/p>\n

Otro caso demostrativo es el que padece Cisco CallManager, que adolece de un salto de restricciones en RealVNC. El incidente original se remonta al 17 de mayo, pero sin embargo es ayer cuando los servicios postventa de Cisco oficializan que CallManager padece de ese mismo problema. En ambos casos, las ventanas temporales son muy amplias y por tanto, el grado de exposici?n de las organizaciones es extremo, ya que los tres problemas documentados, especialmente el de RealVNC, son de car?cter altamente cr?tico.<\/p>\n

?Es normal que los fabricantes como Cisco e IBM hayan consumido tanto tiempo en notificar la afectaci?n indirecta en sus productos? S?, es comprensible, ya que sus laboratorios s?lo resuelven problemas colaterales que no hayan sido provocados en primera instancia por desarrollos propios. Adem?s, la calidad de servicio de ambas compa??as requiere que estos efectos colaterales se prueben y verifiquen en cientos de configuraciones distintas, desplegadas para clientes en ?mbitos de TI muy dispares y sometidos a contratos de servicio con requisitos t?cnicos y legales bastante heterog?neos.<\/p>\n

Es aqu? donde tenemos que corregir a ISO 17799 e ISO 27001, y no circunscribir ?nicamente la gesti?n de vulnerabilidades t?cnicas a los problemas publicados y declarados, sino ser proactivos y, apoy?ndonos en buenos inventarios de productos internos, anticiparnos a los problemas futuros.<\/p>\n

Eso es la gesti?n de la seguridad. Previsi?n, anticipaci?n y proactividad. Atr?s qued? la gesti?n de parches pura y dura.
\n
\nM?s Informaci?n:<\/strong><\/p>\n

Cisco Security Response: RealVNC Remote Authentication Bypass Vulnerability
\nhttp:\/\/www.cisco.com\/warp\/public\/707\/cisco-sr-20060622-cmm.shtml<\/a><\/p>\n

Hardware Management Console Cumulative history and Readme for use with
\nHMC V5 R2 and V5 R2.1
\nhttp:\/\/www14.software.ibm.com\/webapp\/set2\/sas\/f\/hmc\/power5\/install\/v52.Readme.html#MH00688<\/a><\/p>\n

Grave Vulnerabilidad en RealVNC
\nhttp:\/\/www.hispasec.com\/unaaldia\/2760<\/a><\/p>\n

Importante actualizaci?n en Sendmail
\nhttp:\/\/www.hispasec.com\/unaaldia\/2707<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

Este art?culo se public? originalmente en \u00abuna-al-d?a\u00bb de Hispasec Sistemas Las diversas vulnerabilidades que aparecen d?a a d?a constituyen, en muchas ocasiones, ?nicamente un primer foco de exposici?n para los usuarios y las organizaciones. Si nos referimos a normativa, la gesti?n de las vulnerabilidades t?cnicas puede enfocarse de muchas maneras. Leer texto completo<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-687","post","type-post","status-publish","format-standard","hentry","category-seguridad"],"_links":{"self":[{"href":"https:\/\/www.sahw.com\/wp\/wp-json\/wp\/v2\/posts\/687","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.sahw.com\/wp\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.sahw.com\/wp\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.sahw.com\/wp\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.sahw.com\/wp\/wp-json\/wp\/v2\/comments?post=687"}],"version-history":[{"count":0,"href":"https:\/\/www.sahw.com\/wp\/wp-json\/wp\/v2\/posts\/687\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.sahw.com\/wp\/wp-json\/wp\/v2\/media?parent=687"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.sahw.com\/wp\/wp-json\/wp\/v2\/categories?post=687"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.sahw.com\/wp\/wp-json\/wp\/v2\/tags?post=687"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}