Visualización de la Información aplicada a SegInfo.

¿Qué hace el área de Seguridad Informática/Información? ¿Cuál es el nivel de protección? ¿Vamos mejor o peor? En cada empresa el área de seguridad de la información tiene el reto de justificar su existencia y mostrar valor al negocio. Es difícil (de)mostrar el nivel de seguridad actual corporativo (malo-regular-bueno) ya que muchas veces el dinero destinado para la seguridad se ve como un gasto, y es hasta que sucede un incidente mayor que la seguridad pasa a verse como una inversión porque su valor se puede “ver” y/o percibir.

¿Por qué la seguridad se percibe como un gasto? ¿Por qué en varios casos la alta dirección no ve “inmediatamente” el valor de los recursos humanos y materiales destinados a mantener e incrementar el nivel de seguridad hacia el activo de la información? Una de las principales causas que yo identifico es porque muchos de los que estamos metidos en esto de la seguridad de la información somos incapaces de demostrar el valor que aporta nuestra área.

La seguridad de la información tiene una extraña propiedad que es: cuando es efectiva, muchos no le ven su utilidad y no ven cómo es que les está ayudando (y no es su culpa). Por ejemplo, tenemos un antivirus actualizado que nos cuesta ($) mantener. ¿Y luego qué? ¿Qué pasaría si me infecto de un virus poco/mucho peligroso? ¿De qué me salvó? ¿Qué me pudo haber pasado? ¿Cuántos códigos maliciosos detuvo? ¿Eran peligrosos? ¿Qué significa “peligroso” y cuáles son las consecuencias? ¿Puedo comprar un producto más barato y suficientemente eficiente?

Retomando el punto inicial: ¿Cómo (de)mostrar el valor que aporta la seguridad de la información? Leyendo un artículo de la revista de la BBC me topé con el tema de “Visualización de la Información”, y me pregunté si estos conceptos no se podrían aplicar al área de seguridad informática/información.

En el artículo mencionado, David McCandless (http://twitter.com/mccandelish/) propone convertir y transformar datos en imágenes fácilmente comprensibles. Esto sería una excelente manera de que la alta dirección pudiera por ejemplo revisar y analizar los indicadores de seguridad informática o las métricas de seguridad arrojadas por diversas herramientas/procedimientos.

Por ejemplo, el estándar 27001 en su cláusula 4.2.2 inciso d) nos pide definir cómo se medirá la efectividad de los controles seleccionados para proteger los activos dentro del alcance establecido y especificar cómo es que estas medicines serán usadas para evaluar la efectividad de los controles y producir resultados comparables y reproducibles. La visualización de la información sería una gran ayuda para representar toda o parte de estas métricas.

La visualización de la información retoma especial importancia en estos tiempos cargados de datos y me atrevo a decir que la visualización de la información aplicada a la seguridad de la información es un campo casi inexplorado. Existen un par de libros como por ejemplo “Applied Security Visualization” o “Security Metrics” que me agradaría mucho leer y que de hecho lo pienso hacer en el primer Q del siguiente año; también está el sitio de interés: manyeyes.alphaworks.ibm.com. Porque a pesar de que hagas bien tu chamba de seguridad, si no puedes demostrarle al resto tu esfuerzo y el valor otorgado, se preguntarán para qué estás ahí. Percepción es realidad.

Seguridad en el Uso del Software Libre.

¿Deben las empresas usar software libre? Esa ya no es la pregunta, sino más bien: ¿Bajo qué criterios se debe usar el software libre? Uno de esos criterios es la seguridad, y es a lo que nos enfocaremos a lo largo de esta lectura.

SW libre: una realidad.

No invertiremos párrafos enteros analizando si se debe de usar o no el software libre en las corporaciones, ya que en las grandes y las pequeñas su uso es una realidad: desde algunos módulos en códigos de desarrollo, pasando por librerías y claro está, aplicaciones. Desde robustas soluciones como JBoss, hasta programas como FireFox o librerías de Java, difícilmente una organización podría afirmar que se mantiene “libre” del software libre. Inclusive el Departamento de la Defensa de los EUA lejos de negar una realidad, la acepta y mejor decide establece las reglas para su uso (DoD Guidance Regarding Open Source Software).

Ahora bien, entremos en materia. La seguridad del software libre presenta una:

Problemática.

+ El código del software libre está disponible para que “n” personas (principalmente desarrolladores/analistas de seguridad) lo analicen y verifiquen su seguridad, identificando debilidades para su corrección. Lo cierto es que si bien el código está disponible, no hay ninguna garantía de que sea revisado y/o corregido. Tampoco se puede asegurar que el código se revisó por personas conocedoras en la materia. Un código popular como Linux será retomado ciertamente por gente que tratará de identificar sus debilidades, pero no podemos esperar la misma suerte para todo tipo de librerías, miles de rutinas y objetos disponibles en Internet y listos para ser usados en las empresas.

+ No hay un indicador de que el software libre sea más seguro que el software comercial. Ambos casi siempre tienen el objetivo de ser funcionales, mas no necesariamente seguros. ¿En dónde hay más debilidades: en el código libre o comercial? No me atrevería a inclinarme a favor de uno u otro, hay de todo en ambos mundos: los hay con “n” debilidades y los hay con un número reducido de éstas.

+ El código del software libre, al estar disponible, tiene más riesgos ya que al poder ver sus “entrañas”, se pueden descubrir “fácilmente” sus debilidades. Pues bien, como es sabido, no se tiene disponible el código de aplicaciones comerciales y también se pueden identificar debilidades si uno sabe lo que hace.

+ Al estar disponible el código fuente, es posible alterarlo para insertar una puerta trasera o un troyano y (por ejemplo) re-publicarlo en otro sitio para que se baje. Por otro lado, se supone que el software comercial “jamás” traería una puerta trasera si uno lo adquiere legalmente del fabricante; al menos eso dice la teoría.

+ El software libre no siempre tiene un responsable y muchas veces nos podemos encontrar con comunidades sin nada más que buenas intenciones y que se encargan de actualizar el software para corregir vulnerabilidades. No hay a quien reclamarle (o no es práctico hacerlo) ni a quien exigirle. En el software comercial, habrá un fabricante o proveedor con quien inclusive exista un contrato de por medio. Uno de los casos excepcionales podría ser por ejemplo el software libre de RedHat donde hay sí hay una entidad responsable con quien se pueden hacer tratos formales.

Ok, qué hacer?

Ya vimos un panorama resumido de la problemática que se puede presentar en relación a la seguridad del software libre; pues bien, y ahora qué hacemos? ¿Cómo lo incorporamos de manera segura al desarrollo corporativo?

+ Registro del SW libre usado en la empresa. Nos referimos a tener identificado claramente dónde se está usando el software libre dentro de la empresa: ¿es un módulo dentro de un código? ¿Es una librería? ¿Es una aplicación? Se debería de saber en todo momento ubicar este software dentro del SW desarrollado en la corporación. El objetivo de tenerlo identificado es que será mucho más sencillo actualizarlo cuando exista una nueva versión que dé solución a debilidades. Otra ventaja sería poder identificarlo ante una auditoría (ok, creo ningún auditor en México lo pediría, sólo digo que si yo lo fuera, lo haría) : -).

+ Analizarlo con una herramienta automatizada sería un “must”. En el mercado existen diversas herramientas que revisan el código fuente en busca de vulnerabilidades; se pueden encontrar varias opciones en el “Gartner Magic Quadrant for Static Application Security Testing”. La idea sería correrle una de estas herramientas al código y tomar una acción adecuada con las debilidades encontradas.

+ Capacitación en codificación segura. Idealmente todos los desarrolladores deberían estar capacitados en cómo codificar de manera segura para evitar vulnerabilidades. Y al menos uno de ellos debería de estar mucho muy bien capacitado y más que desarrollar, su papel se convertiría en el de “revisor”. ¿Todo esto suena como a un “sí claro, con qué dinero”? Ok, por eso usé la palabra “idealmente”. Y por cierto, aunque es la medida que menos podría ser llevada a cabo de las aquí mencionadas ($), realmente es una de las opciones más beneficiosas.

+ Reputación. ¿Se podría tener un listado de las fuentes (sitios) confiables desde donde se puede bajar software libre? Tal vez este listado se crearía y mantendría entre el área de seguridad y la de desarrollo.

+ Documentación de características de seguridad. ¿El desarrollador que puso a disposición el software libre se preocupó por documentar las características de seguridad de su código? Esto sería un indicador de que al menos existe esta preocupación por parte del creador y nosotros podríamos revisar esas características para ver si son adecuadas para el negocio.

+ Contacto para solucionar debilidades. Si alguien en Internet encuentra una debilidad en el código del software libre, es posible contactar exitosamente al creador o comunidad del SW para informarle de la debilidad con el fin de que se le dé solución? Si no se puede establecer contacto, nos quedaríamos con una pieza de SW libre desactualizado y sin mantenimiento: cualquier debilidad identificada probablemente no se solucionaría (a menos que sea retomada por alguien más). Si no hay manera de contactar, no hay intención de actualizar.

+ Preferir código fuente sobre binarios: al menos con el código fuente tenemos la oportunidad de revisarlo; con los binarios no sabes lo que estás bajando (o es mucho más difícil averiguarlo).

+ Nessus y Wireshark. No está de más que una vez que el software libre se pone en operación se le pase un Nessus a ver si lograra encontrar alguna debilidad y por otro lado poner un sniffer como Wireshark para ver si -en un periodo de algunos días- el código instalado no ha llamado a la nave nodriza.

Conclusiones (al fin).

¡Uf! Sí que fue una entrada extensa, pero de vez en cuando no hace daño (espero no haberlos aburrido). He descrito algunos puntos de la problemática de usar software libre de manera segura en las corporaciones; no todas pueden ser relevantes para todo tipo de empresas y claro, se pueden encontrar más. Lo mismo para las medidas propuestas, algunas aplican, otras no. De todo lo que se leyó, qué te sirve a ti para tu empresa? Eso es lo más importante. O si nada te sirve pero te preocupó el tema para discutirlo en tu empresa, me doy por bien servido. Nos vemos en línea www.twitter.com/FaustoCepeda.

Documentos de Interés:

Fortify: CISO's Guide To Open Source Software Security.

SANS: Security Concerns in Using Open Source Software for Enterprise Requirements.

Coverity: Scan Open Source Report 2009.

Secure Programming for Linux and Unix HOWTO: Is Open Source Good for Security?

Fortify: Open Source Security Study.

“Jailbreikea” e inféctate.

¿Por qué tanto lío por el primer gusano para iPhone? Eso es lo primero que pensé al enterarme la semana pasada de esta noticia, pero en seguida supuse que lo “primero” siempre llega a los titulares, aunque realmente no represente un riesgo importante.

El SANS reportó el 8-11-09 sobre el primer gusano para iPhone, el cual infecta teléfonos con ciertas características:

+ Que estén “jailbreikeados” (término que se refiere a dispositivos hackeados para obtener libertad de instalar lo que se quiera sin interferencia del fabricante).

+ Que cuenten con el servicio de SSH (Secure SHell) habilitado y también que conserven la contraseña por default “alpine”.

En una entrevista con “ikee”, quien aparentemente es el creador del gusano, se establece que la intención del cracker es infectar teléfonos en Australia, pero hay indicios de que la infección ha aparecido en otros países.

Al momento de infectar, el gusano termina el servicio de SSH para prevenir que otros gusanos utilicen este medio para lograr infecciones exitosas y por otro lado cambia la imagen del fondo del teléfono. Y eso es todo (bastante simple). ¿Peligroso? Por sí mismo no, pero pone un precedente.

Ahora bien, en mi opinión, este tipo de noticias se deben de poner en contexto y no alarmarse e ir gritando por ahí que el iPhone es muy inseguro y que ya se le debe de poner un antivirus urgentemente; esto último es lo que algunas compañías antivirus les gustaría hacernos creer y de hecho un par de ellas andan cacareando aquí y allá este noticia, será que ya vieron un nicho?

Si tuviera un iPhone sin “jailbreikear”, no me preocuparía por el momento y lo seguiría usando con singular alegría; tal vez me preocuparía más el hecho de perderlo en caso de que ahí recibiera mi correo de la empresa o que tuviera otro tipo de datos sensibles.

Y para los que tienen un “jailbreak”, tal vez la recomendación sería darle un vistazo a sus contraseñas que tienen por default.

Finalmente, se ha enaltecido (¿indebida/innecesariamente?) la labor del creador de este gusano al identificar y anunciar su cuenta de Twitter y la de MySpace. No es un rockstar y de hecho viendo su código, no demostró una gran pericia. Pero sin lugar a dudas, conseguirá un buen número de followers, eso que ni qué. A ver si el largo brazo de la ley no lo sigue también, pero a su casa para acomodarle un susto (él mismo ya lo notó: “Which has kinda got me worried about legal implications?”).

Agrega Seguridad Total 2009 a tu Lista.

¿Deberíamos contar con Total Security 2009? Sólo si deseamos pagar $79.95 dólares por un scareware que se adelanta un paso al resto del código malicioso de su especie. Quien se haya enfrentado a los muy molestos Antivirus 2009 o SpywareGuard sabrá que no es nada grato tenerlos en el sistema. Y sin embargo, el Total Security 2009 es una pizca más molesto.

Todo empieza con la instalación de un programa (*.exe) con un extraño e incoherente nombre que puede llegar por diversas vías (adjunto en correo, bajado de Internet, etc.) y que tiene un icono de candado muy apropiado. Una vez que se ejecuta el infame programa en una computadora sin antivirus o con antivirus pero desactualizado, la “magia” empieza.

Total Security 2009 intercepta y bloquea absolutamente cualquier programa del sistema a excepción de Internet Explorer. ¿Office, Firefox, Adobe Reader? Olvídenlos, al querer arrancarlos aparece una ventanita que insta al usuario a comprar el “producto” Total Security 2009 a un precio de $79.95 dólares, con posibilidad de desembolsar $19.95 más en caso de que se desee un servicio “premium”. Lo único que se puede arrancar es Internet Explorer para hacer el pago correspondiente vía Internet con tarjeta de crédito.

En pocas palabras, han secuestrado a nuestra computadora, ya que no se pueden acceder a los documentos o los programas del equipo. A menos, claro está, que se pague por la “protección” de Total Security 2009, que más bien es un rescate por recuperar nuestros datos y programas.

Eso sí, una vez que se hace el pago, recibimos un código que amablemente nos permitirá hacer uso de nuevo (y en adelante) del equipo.

Si alguien ha sido víctima de esta Seguridad Total 2009 y tenía un antivirus actualizado, sería mejor pensar en la conveniencia de seguir con esa marca de antivirus. Por otro lado, si estaba desactualizado, supongo que tendremos más cuidado en el futuro. Pero si ya nos infectamos, qué podemos hacer?

Una opción es apagar Windows y encenderlo a modo prueba de fallos; una vez ahí, instalar/actualizar el antivirus y tratar de limpiar el sistema. Una segunda opción es introducir los códigos que exige el sacareware pero sin pagar el rescate: Panda ha publicado estos códigos que deberían de servir para desbloquear el equipo y posteriormente limpiarlo. Otra opción que me encontré en la red es instalar Linux o usar OS X para evitar estos problemas J.

Agrega Seguridad Total a tu lista, pero a la de programas indeseados que ni son seguros ni totales.