• 6 mayo, 2019
• F5 Latinoamérica
• 3

Tecnología

Intencionalmente inseguro: Malas prácticas de seguridad en la nube

Hasta febrero de este año, había cinco casos documentados de organizaciones exponiendo sus datos privados por causa de cubos S3 o bases de datos en la nube mal configurados. En realidad, no, corrijamos: por causa de cubos S3 y bases de datos en la nube configurados intencionalmente. La diferencia es importante, ya que para permitir el tipo de acceso necesario para un usuario ilegítimo para ver los cubos S3 o acceder los bases de datos, alguien debe eliminar o degradar las protecciones de seguridad que, por defecto, están puestas.

Si les llamamos mal configurada implicaría un error, del tipo que todas las personas cometen periódicamente y que pueden perdonarse. Pero estos no son errores, ya que estos recursos se han abierto de manera intencional para permitir que casi cualquier persona acceda a ellos.

Los investigadores de F5 Labs rastrearon la lista de organizaciones cuyos recursos en la nube han estado expuestos desde 2017 a causa de inseguridad intencional. El incremento de 2017 a 2018 fue un alarmante 200 por ciento. En 2019, a la fecha, con un promedio de 2.5 brechas por cada mes, esperaríamos a ver un total de 30 brechas hasta el final de este año. Pero la cifra de crecimiento de los años anteriores nos dice que nuestra estimación es, probablemente, demasiado baja. Si ese 200 por ciento de incremento se mantiene, esperamos ver al menos 90 brechas de seguridad en la nube durante 2019. Y lo que es peor: estamos seguros que nuestras listas compiladas de organizaciones están solamente raspando la parte superior del barril.

Creemos que esto es inaceptable. No sólo son datos privados expuestos, sino que algunos de ellos tienen un potencial de repercutir de manera real y muy dañina en las personas de quienes son esos datos. Usted. Nosotros. El chico en el cubículo a su derecha. La mujer bajando del autobús. El joven preparándose para universidad.

A continuación, algunos ejemplos de las brechas de seguridad:

• En 2017, un servicio de reparación de crédito expuso los datos de sus clientes. ¿Cuánto tiempo crees que tomó a estafadores descubrirlos y explotar a esas personas, cuyo único crimen fue confiar en una compañía a ayudarles a reparar sus vidas?
• En 2018, un sistema de seguridad residencial usó las mismas claves codificadas de forma rígida en sus dispositivos de su servidor de almacenamiento AWS, donde se enviaban las grabaciones que detallaban los diseños/planos de cada uno de los hogares. ¿Cuánto tiempo cree que les tomó a los delincuentes encontrar y explotar los detalles íntimos o los patrones de ocupación que pudieron descubrir sobre las casas de esos clientes?
• Más recientemente, una compañía del análisis de datos que atiende a organizaciones financieras filtró 24 millones de registros de préstamos en Estados Unidos, a través de una base de datos expuesta, sin una contraseña. Sin duda predadores, estafadores y ladrones de identidad organizaron una fiesta para celebrar.

Ninguna industria queda fuera de la lista que crece. Desde gobiernos a proveedores de servicios; desde manufactura a la política; desde las finanzas al entretenimiento, todas las industrias tienen una participación en el concurso “Quién puede perder más datos debido a malas prácticas de seguridad”. Es un concurso que nadie debería querer ganar, o incluso participar, en primer lugar.

Estamos firmemente arraigados en la economía digital. Los bits y bytes que la alimentan no sólo representan dólares o yenes o libras. Ellos representan a las personas. Las personas que realmente se ven afectadas por estas brechas de una manera que nunca podremos saber, porque no se reportan.

¿Cómo y por qué sucede esto?

¿Por qué alguien comprometería intencionalmente su seguridad al configurar los depósitos de S3 y las bases de datos en la nube, haciéndolos públicos? Según nuestra experiencia, los culpables rara vez están en el lado de las operaciones:

• Los ingenieros de redes, generalmente responsables de administrar el acceso a los sistemas a través de la red y determinar qué sistemas están orientados al público, generalmente no permiten que una base de datos sea pública.
• Los administradores de bases de datos, generalmente responsables de administrar el acceso a las bases de datos y los permisos de las cuentas, no permitirían el acceso a las bases de datos sin requerir autenticación. Asumirían políticas de contraseña con requisitos de complejidad estándar y no permitirían contraseñas débiles.
• Los ingenieros de sistemas, generalmente responsables de administrar las aplicaciones según los estándares de fortalecimiento definidos, administrarían un servidor web frente a la base de datos pública, y garantizarían que se asegurara adecuadamente con un cortafuegos de aplicaciones web.
• Los ingenieros de seguridad normalmente realizarían evaluaciones independientes de todos los sistemas y la red para garantizar el cumplimiento de la política de seguridad.

Más a menudo, el lado de desarrollo del producto puede decidir no incorporar características de seguridad ya existentes, en muchos casos porque no quieren interrumpir la fuente de ingresos, ya sea retrasando la línea de tiempo o posiblemente introduciendo nuevos errores.

Moverse a la nube les permite a los desarrolladores eludir los roles tradicionales de TI de las empresas que obviamente son necesarios, considerando el creciente número de brechas en la nube. Eso crea la tormenta perfecta para que los desarrolladores implementen sistemas con funciones de seguridad mal configuradas, no porque quieran, sino porque pueden no entender las consecuencias o pueden suponer que es improbable que ocurra una infracción.

Lo que usted puede hacer para evitar las brechas en la nube

¿Cómo solucionamos este problema? Nadie está sugiriendo que volvamos a los retrasos prolongados en la implementación de sistemas (una queja común entre desarrolladores). Tal vez, como industria, deberíamos comenzar a hablar de DevSecOps como disciplina para infundir buenas prácticas de seguridad en el desarrollo. Todos los equipos claramente deben ser incluidos en la conversación. Sólo los informes de seguridad limitados están disponibles en implementaciones en la nube predeterminadas: no hay equipos confiables de ingeniería de redes o ingeniería de sistemas para solicitar una lista de subredes y ACL, y no hay grupos y permisos de Active Directory. En la mayoría de las nubes públicas, las organizaciones necesitan comprar herramientas de auditoría de seguridad de la nube de terceros para producir los informes que el equipo de seguridad normalmente habría obtenido de sus homólogos internos.

Sí, la seguridad es difícil. Sí, la seguridad a veces ralentiza las cosas. Pero ignorar intencionalmente o degradar la seguridad porque es más conveniente o acelera el proceso es simplemente inaceptable y posiblemente muy poco ético. Las personas reales pueden ser impactadas y no solo financieramente. Eso es gente real, no sólo las encarnaciones digitales que confían a las empresas a diario.

Es hora de dejar de referirse a estas exposiciones como resultado de una mala configuración y comenzar a llamarlas lo que son: inseguridad intencional y deliberada. Más importante aún, los profesionales de InfoSec necesitan expresar estas prácticas deficientes con más firmeza. Tal vez con un recordatorio de que las prácticas de seguridad deficientes afectan a las personas y no sólo a los procesos que se utilizan para evitar o eludir.

Por Lori Mac Vittie*
Contribución adicional de Sara Boddy**

*Lori Mac Vittie es Evangelista Tecnológico principal para la nube, seguridad en la nube y las aplicaciones de F5. **Sara Boddy es líder en F5 Labs, la división de informes de inteligencia de amenazas de F5.