Un incidente reciente en el que un hacker aburrido encontró una lista de 1,5 millones de personas en la lista de exclusión aérea de la TSA sentadas sin protección en un servidor expuesto a World wide web ha puesto de ease, una vez más, la práctica arriesgada de utilizar datos de producción e información confidencial en entornos de desarrollo.
El hacker suizo «maia arson crimew» descubrió recientemente la lista TSA en un servidor de automatización de código abierto Jenkins que pertenece a CommuteAir, una compañía aérea con sede en Ohio que apoya las operaciones de United Airlines en vuelos regionales. En comentarios a Daily Dot, el primero en informe sobre el incidente — ella dijo que encontró la lista de exclusión aérea mientras buscaba servidores Jenkins expuestos a Internet utilizando el motor de búsqueda Shodan, y notificó a la compañía sobre el problema.
Abiertamente Accesible
La lista, alojada en un archivo de texto llamado «NoFly.csv», contenía los nombres de más de 1,5 millones de personas a las que el gobierno de EE. UU. ha prohibido volar por motivos de seguridad. La TSA pone la lista a disposición de las aerolíneas de todo el mundo para que puedan evaluar a los pasajeros que tengan la intención de volar desde, hacia o sobre los EE. UU..
Day by day Dot citó a maia arson crimew, que se describe a sí misma como una «investigadora de seguridad», diciendo que también había encontrado credenciales de unos 40 cubos de Amazon S3 pertenecientes a CommuteAir en el mismo servidor. Una de esas credenciales la llevó a una foundation de datos que contenía información confidencial, como números de pasaporte, números de teléfono y direcciones postales, pertenecientes a unos 900 empleados de CommuteAir.
Erik Kane, gerente de comunicaciones corporativas de CommuteAir, en un comunicado de prensa describió la fuga como resultado de un servidor de desarrollo mal configurado.
“El investigador accedió a archivos que incluían una versión obsoleta de 2019 de la lista federal de exclusión aérea que incluía el nombre y apellido y la fecha de nacimiento”, dijo Kane. «Además, a través de la información encontrada en el servidor, el investigador descubrió el acceso a una base de datos que contiene información de identificación personal de los empleados de CommuteAir».
Una investigación inicial mostró que no se expuso ningún otro dato del cliente, y agregó que CommuteAir inmediatamente desconectó el servidor afectado después de que el pirata informático informara a la empresa sobre el problema, señaló Kane.
“CommuteAir informó la exposición de datos a la Agencia de Seguridad de Infraestructura y Ciberseguridad, y también notificó a sus empleados”, se lee en el comunicado.
Uso de datos confidenciales para pruebas y desarrollo
El incidente es un ejemplo de las cosas que pueden salir mal cuando las organizaciones permiten el uso de datos de producción o información confidencial en entornos de desarrollo y prueba, en este caso, un servidor Jenkins.
Los equipos de command de calidad y los desarrolladores a menudo cortan y pegan datos de producción sin procesar en sus entornos cuando prueban, desarrollan o preparan aplicaciones porque ofrece una forma menos costosa, más rápida y más válida de hacer las cosas en comparación con el uso de datos de prueba. Sin embargo, los expertos en seguridad han advertido durante mucho tiempo que la práctica está llena de riesgos, porque los entornos de desarrollo y prueba generalmente carecen de los controles de seguridad que están presentes en un entorno de producción en vivo.
Los problemas comunes incluyen permisos excesivos, falta de segmentación de la pink, administración de parches deficiente y una falta normal de conocimiento de los requisitos de privacidad de datos.
Las preocupaciones sobre los problemas de seguridad, privacidad y cumplimiento relacionados con la práctica, de hecho, han empujado a muchas organizaciones a tomar precauciones adicionales, como enmascarar, ofuscar o cifrar datos de producción sensibles y en vivo antes de usarlos para pruebas o desarrollo. Muchos simplemente usan datos ficticios como sustitutos de los datos reales al probar o preparar el application. Aun así, la práctica de utilizar datos de producción sin procesar e información confidencial en la configuración de desarrollo y prueba sigue siendo bastante generalizada según los expertos en seguridad.
«Lamentablemente, las pruebas con datos de producción son muy comunes», dice John Bambenek, principal cazador de amenazas de Netenrich. «Simplemente, crear datos de prueba creíbles y a escala a menudo es complicado, especialmente cuando se trata de conjuntos de datos únicos». Los equipos de prueba a menudo quieren que sus pruebas representen el mundo authentic tanto como sea posible, por lo que es una tentación muy natural usar datos de producción, dice.
Patrick Tiquet, vicepresidente de seguridad y arquitectura de Keeper Stability, dice que los servidores DevOps a menudo tienden a ser objetivos principales para los atacantes porque generalmente están menos protegidos que los servidores de producción en vivo. Aboga por que las organizaciones eviten el uso de datos de producción en entornos que no son de producción, sin importar cuán benignos puedan parecer los datos.
«El uso de datos de producción en sistemas de desarrollo aumenta el riesgo de divulgación de esa información, porque en muchas organizaciones, los sistemas de desarrollo pueden no estar tan protegidos como sus sistemas de producción», dice Tiquet.
Las organizaciones que permiten la práctica deben reconocer el hecho de que muchas regulaciones de privacidad de datos requieren que las entidades cubiertas apliquen controles específicos para proteger los datos confidenciales, independientemente de dónde puedan existir en el entorno o cómo se utilicen. El uso de datos de producción en un entorno de desarrollo podría violar esos requisitos, dice Tiquet.
«Exponer datos confidenciales no solo puede exponer a una organización a litigios o problemas relacionados con el gobierno según los datos, sino que también puede conducir a una erosión de la confianza del cliente», advierte. «Si bien hay muchos pasos que las organizaciones pueden tomar para proteger sus entornos de prueba, como el enmascaramiento y el cifrado de datos, el más importante será incluir a los equipos de seguridad en la configuración y administración continua de los servidores DevOps».
