miércoles, 29 de junio de 2011

Una buena razón para forzar la entrada en un sistema

Buscando problemas: Brian Holyfield, cofundador de Gotham Digital.
Fuente: JR Rost


Pagar a alguien por tratar de hackear sus sistemas puede ayudarle a crear defensas contra ataques reales.


Por Tom Simonite

No todos los hackers que atacan a empresas son malos tipos; a algunos les pagan sus víctimas por hacerlo. Mediante un servicio conocido como pruebas de penetración, una empresa de seguridad intenta el acceso o control de los sistemas de un cliente con el fin de descubrir los puntos débiles que podrían ser explotados por un atacante real.

Ciertos tipos de negocios tienen la obligación legal de someterse a pruebas de penetración, aunque muchos otros están optando por ellas también, afirma Brian Holyfield, cofundador de Gotham Digital Science, una compañía con sede en Nueva York que se especializa en este servicio. Holyfield aseguró a Tom Simonite, editor de TI de Technology Review para hardware y software, que en algunos proyectos de gran tamaño, Gotham emplea a tres de sus hackers a la vez contra una empresa durante semanas.

TR: ¿Por qué son necesarias las pruebas de penetración? ¿No podría simplemente decirle a una empresa qué vulnerabilidades tendría en cuenta un atacante?

Holyfield: No buscamos vulnerabilidades estándar. La mayoría de las veces estamos en busca de vulnerabilidades a nivel de código en aplicaciones personalizadas. Todo el mundo tiene aplicaciones web hoy día, y la realidad es que el firewall no hace mucho por protegerlas.

¿Con qué tipo de empresas trabaja?

Trabajamos principalmente con la banca y las finanzas, la salud y los proveedores de software. Todos los sitios y los sistemas que aceptan tarjetas de crédito deben llevar a cabo pruebas si realizan más de un cierto número de transacciones al año. Sin embargo, muchas empresas no están obligadas a hacerlo. El mercado más grande con el que trabajamos son empresas que ofrecen software como servicio. Sus clientes les preguntan qué tipo de acciones están llevando a cabo para que el sitio sea seguro.

¿Tienen miedo los clientes por el hecho de ofrecerse como voluntarios para ser hackeados?

La primera vez que alguien pasa por esto, existe un nivel de nerviosismo e incluso paranoia. Tenemos que conseguir que dejen de lado sus egos y entiendan que no vamos contra ellos; no estamos tratando de hacer quedar mal a nadie. Cuando acabamos la prueba de penetración, generalmente los clientes están satisfechos de que hayamos encontrado el problema antes de que lo hicieran los malos de la película.

¿Cuál es un buen ejemplo entre las vulnerabilidades que han encontrado?

En un trabajo reciente, hemos comprometido un sitio web de marketing de una importante institución financiera que se estaba ejecutando en un servidor web sin parchear (unpatched). Este servidor se utilizaba como punto de partida para pasar a través del firewall y obtener conectividad a los sistemas en su red interna.

Encontramos que una de las cuentas [tomada] del servidor web (habíamos conseguido la contraseña) era también un administrador en la bóveda que almacena las contraseñas de todo el mundo para esa red. Pudimos entrar como cualquier persona. Una buena lección de todo esto es que sólo porque un sistema no es de importancia crítica no significa que el servidor tenga que ser ignorado desde la perspectiva de seguridad. Una vez que ganas acceso a la caja de perímetro, sueles tener muchas más opciones para atacar a sistemas más importantes, ya que en ese momento te encuentras detrás del firewall. La otra lección es la importancia de no usar la misma contraseña en diferentes sistemas.

Después acabar su "ataque", ¿qué le presenta al cliente?

Siempre creamos un informe escrito y capturas de pantalla e instrucciones paso a paso que se pueden entregar a un desarrollador para decirle: "He aquí cómo hacerlo". Después de la prueba de penetración, agregamos valor al dejar claro exactamente lo que hay que hacer. Las auditorías de seguridad clásicas tienden mayormente a estar basadas en cómo alcanzar las mejores prácticas.

¿Las personas que hacen esto para los tipos buenos son distintas de los tipos malos?

Se requiere no sólo conocimientos especializados, sino también un cierto tipo de persona. No es que la gente sea buena en su trabajo sino que es su hobby, es lo que viven y respiran. Tienen el deseo no sólo de entender cómo funciona algo, sino la manera de usar algo [para un propósito] para el que no fue diseñado.

Existe una línea muy fina entre alguien con esa pasión por el simple hecho del interés y el conocimiento, y una persona que va a causar daño o va a tratar de ganar dinero. Cuando estamos en busca de talento, parte de nuestro proceso de reclutamiento es una estricta verificación de antecedentes para buscar algún lado oscuro. Ha habido muchos casos en que hemos conocido a gente con mucho talento que no podíamos contratar.

¿Las prueba de penetración son cada vez más comunes?

Sí, están empezando a ser algo mucho más popular. Una señal de eso es que cada vez es más fácil obtener el permiso de los proveedores de servicios de Internet, que tienen que saber lo que va a ocurrir para que puedan entender que no es un ataque real. Hoy día, las empresas de infraestructuras como Amazon hacen que sea muy fácil. Si se tiene alojamiento en la nube de Amazon, conseguir el permiso para una prueba de penetración es tan fácil como rellenar un sencillo formulario basado en la web.

¿Podrían haber preparado las pruebas de penetración a Sony frente a los recientes ataques en los que fueron robados datos de usuario?

Una prueba de penetración se centra generalmente en la puerta principal, pero existen un montón de ventanas. Creo que Sony en realidad fue atacada de forma particular. La ingeniería social y el 'spear phishing' [la elaboración de mensajes para engañar a una persona en particular y que revele datos delicados] podrían haber sido utilizados contra personas con acceso a los datos. Poner a prueba ataques de ingeniería social es una opción dentro de las pruebas de penetración, pero la mayoría de la gente decide no hacerlo. Ya conocen los riesgos.

Copyright Technology Review 2011.

No hay comentarios:

Publicar un comentario