En dos posts que publiqué anteriormente, ya había mencionado el software
de código abierto
(OSS, por sus
siglas en inglés). En el primero, recuerdo
haber citado a Dale Gardner, refiriéndose al creciente uso del OSS
por parte de los equipos de desarrollo encargados de construir
aplicaciones. En el segundo, que puede servir de
introducción al post que estás leyendo ahora, abordé algunas
generalidades sobre el OSS, su diferenciación del software
propietario y
algunos de sus beneficios como estrategia empresarial. Para este post,
hemos decidido dar más espacio a la seguridad del OSS y presentar
brevemente nuestra experiencia en Fluid Attacks
.
Hace unos dos meses, Nivel4 informó que se habían filtrado los códigos fuente de las aplicaciones móviles de tres bancos mexicanos y se habían revelado en la web. Algunas personas en las redes comentaron que la causa de la filtración fue una mala configuración, y los bancos inmediatamente reportaron que no había ningún impacto en la seguridad de los sistemas y en los datos sensibles de los clientes. ¿Era eso cierto? Creo que muchísima gente comenzó a sospechar de esa seguridad en aquel momento. Por cierto, si no había nada que perder mostrando los códigos fuente, ¿por qué los ocultaban? Sin duda, estos bancos perdieron la confianza de muchos de sus usuarios y vieron afectada su reputación entre los competidores.
Las aplicaciones de los tres bancos se convirtieron inadvertidamente en OSS. Podríamos decir que sus propietarios pretendían mantener una imagen de seguridad al no hacer público el código. Sin embargo, oculto o abierto, la seguridad del código dependerá es de lo sólida y cualificada que haya sido su elaboración. Se pueden encontrar vulnerabilidades o fallas tanto en el software abierto como en el propietario, pero como compartió Bruce Byfield hace unos años, "los vendedores de software propietario son famosos por la seguridad mediante oscuridad". Ellos suelen creer erróneamente que mantener sus sistemas en las oscuras cuevas los hará más seguros. Por eso, en muchos casos, realizan pocas evaluaciones de seguridad y aplican parches a las vulnerabilidades con relativa lentitud.
Uno de los beneficios empresariales del OSS más mencionados es, en contra de la intuición de mucha gente, la seguridad. Cuando hablamos de un proyecto de OSS ampliamente reconocido en la web, podemos decir que son muchos los ojos que lo escrutan y muchas las manos que lo prueban con regularidad. En consecuencia, las posibilidades de pasar por alto los riesgos de ciberseguridad son mucho menores que cuando el proyecto es privado. Una gran comunidad con una amplia variedad de miembros puede detectar y corregir fallas y vulnerabilidades en el código mucho más rápido que un pequeño grupo de desarrolladores pertenecientes a una sola empresa.
No obstante, debo señalar que muchas empresas mantienen sus códigos en
secreto, algunos de ellos al mismo tiempo bastante bien asegurados, por
ninguna otra razón que la de preservar como propias las ideas que las
hacen únicas frente a sus competidores. Eso es comprensible. Sin
embargo, algunos ocultan solo sus partes 'esenciales' de código y
exponen el resto en la web para beneficiarse del trabajo en comunidades
abiertas. Eso es lo que, según Yevgeniy
Brikman,
por ejemplo, hace Google con su "principal diferenciador[:] su
arquitectura de búsqueda". Mientras tanto, muchas compañías que
comparten TODO el código al público en general, generando confianza por
la seguridad que proporcionan, pueden recibir ingresos por otros
medios,
incluso ofreciendo servicios
relacionados con su OSS. Ellas tienen su "salsa
secreta"
ubicada en otra parte, y aquí es donde entra Fluid Attacks
.
Fluid Attacks está a salvo fuera de la cueva
Figure 1. Fotografía por Karsten Winegeart en Unsplash
Fluid Attacks
nació directamente en el software libre
y de código abierto,
haciendo uso de él y manteniéndolo en esa condición.
Como dijo Mauricio Gomez,
cofundador de la empresa,
ellos comenzaron a trabajar directamente en Linux
y se encargaron de la creación de redes,
basadas en OSS,
antes de convertirse en un Red Team
en 2008,
el cual no ha dejado de compartir su código.
Un código que no está adherido
exclusivamente a un par de mentes privilegiadas
de las que siempre dependerá su existencia y funcionamiento.
Cada vez que alguien abandone Fluid Attacks
,
otra persona con habilidades y experiencia similares podrá relevarle,
porque la materia prima con la que trabajamos
no pretendemos dejar de compartirla.
Aparte de la colaboración que podemos recibir de personas inteligentes
de nuestra comunidad y no afiliadas
legalmente a nuestra empresa, casi todos los miembros de Fluid Attacks
pueden y son animados a revisar el código para proponer nuevas ideas
para su optimización (incluyendo la seguridad). Desde los inicios de
Fluid Attacks
hemos aprovechado el OSS como organización, y nos
hemos comprometido, con carácter recíproco, a generar nuestra
contribución a la comunidad de ciberseguridad en general.
Podría entonces alguien preguntarnos, ¿no están ustedes regalando un trabajo que tanto les ha costado? ¿No están sus competidores observando con detalle, incluso copiando, lo que ustedes utilizan para atender a sus clientes? ¿Mantener un OSS no podría significar entregar el material necesario a otros grupos de individuos para establecer nuevas empresas y más competencia para ustedes? Y, tal vez aún más importante, ¿no son ustedes muy vulnerables a los ataques de hackers malintencionados al exponer su código?
En respuesta a estas preguntas, podemos decir que lo que hemos construido hasta ahora también ha sido en parte gracias a muchas personas de todo el mundo que han mantenido el movimiento OSS. También podemos decir que nos sentimos cómodos haciendo público el conocimiento, ganando experiencia y reduciendo la duplicación de esfuerzos. Adicionalmente, nos apoyamos en nuestro principal diferenciador —que no está en el código— para distinguirnos de los viejos y nuevos competidores. (Ellos no pueden depender de nosotros para evolucionar). Como he dicho, nuestra forma de obtener beneficios no se centra en ofrecer un código, sino servicios de inteligencia humana utilizando ese código. Por último, revelar nuestro código no nos hace altamente vulnerables a los ataques, siempre y cuando este cuente con los controles de seguridad necesarios y sus vulnerabilidades se reduzcan al mínimo.
Es imprescindible tener en cuenta que el código que mostramos públicamente no es solo el mismo que utilizamos en las prestaciones de seguridad para nuestros clientes. También es el código que sirve para realizar los análisis de seguridad de nuestros sistemas y productos de forma continua (Continuous Hacking). No estamos dando a la comunidad un lote de líneas de código mediocres y a medio hacer. El material que desarrollamos y actualizamos con fervor a un ritmo acelerado es el material de nuestros analistas de seguridad en su día a día. Al mismo tiempo, es el material que puede utilizar de forma fiable cualquier persona en cualquier rincón del planeta para detectar vulnerabilidades en sistemas informáticos.
En Fluid Attacks
, entendemos que tener un código oculto no es
necesariamente mantenerlo seguro. Comprendemos que la seguridad depende
de la fuerza y la calidad del código, que preferiblemente debe ser
revisado por muchas personas y de forma continua. Por lo tanto, no
ocultamos el código. No hay ningún misterio detrás de lo que puede
hacer. Lo que mantenemos oculto y seguro son los datos sensibles de
nuestra empresa y de nuestros clientes, mediante complejos procesos de
encriptación, por ejemplo. Eso es lo que ayudamos a conseguir a muchas
empresas (descubriendo vulnerabilidades y promoviendo mejores prácticas
de desarrollo) y lo que te damos como recomendación a través de este
post.
Dentro o fuera de la cueva, tu seguridad dependerá de tu armadura, de tus armas y tus habilidades. Nosotros podemos, y la comunidad también puede, ayudarte a mejorar tu seguridad. Sal de la cueva voluntariamente (no esperes a que te saquen como a aquellos bancos). Reflejarás confianza, fuerza y transparencia ante tus seguidores, clientes o interesados. Más adelante, incluso podrás generar y facilitar aportaciones a la comunidad. Solo tienes que ponerte en contacto con nosotros.
P.D. ¡Echa un vistazo aquí en Gitlab a nuestro código!
Share
Recommended blog posts
You might be interested in the following related posts.