Tenga cuidado con la suplantación de identidad del usuario en aplicaciones de código bajo/sin código

El mes pasado escribí un artículo sobre la forma en que las plataformas low-code/no-code ofrecen el uso compartido de credenciales como un servicio, por qué lo hacen y cómo se ve esto desde la perspectiva de un atacante. En este artículo, me centraré en las implicaciones de ese compromiso y cómo afecta a las empresas hoy en día.

He aquí por qué compartir las credenciales de su empresa con otra persona es una mala práctica. Digamos que quiero pasar mis credenciales a un colega para consultar los registros de producción para un análisis único del comportamiento del usuario. En una empresa típica, otorgar permisos a alguien para consultar una nueva fuente de datos podría significar un largo proceso de revisión de acceso, especialmente cuando se trata de producción o datos confidenciales. Mi colega podría frustrarse fácilmente. "Todo lo que quería era hacer esta pequeña consulta única, ¡y ya he estado esperando durante un mes!" podrían decir. Podría ejecutar la consulta por ellos, pero estoy abrumado con mis propias tareas diarias y las consultas únicas tienden a complicarse.

Me queda una solución rápida: podría simplemente compartir mi nombre de usuario/contraseña con mi colega. Si obtienen un desafío de MFA, lo aprobaré con gusto. No tengo que perder el tiempo ejecutando la consulta, y mi colega se desbloquea. ¡Todos ganan! ¿Derecha?

Bueno, tendrías razón en tu análisis, pero te estás perdiendo el panorama general. Si bien es importante para la empresa que su colega realice el análisis del comportamiento del usuario, es igualmente importante, si no más, que su empresa siga cumpliendo con una gran cantidad de estándares de privacidad y seguridad y mantenga la confianza del cliente al mantener el compromiso de la empresa con la seguridad. .

Si los objetivos empresariales de alto nivel no le convencen, considere los equipos de administración central en TI o seguridad. Esos equipos basan sus operaciones y estrategias de seguridad en el hecho de que cada usuario tiene su propia identidad única. Los equipos de TI están configurando redes y políticas de acceso que asumen que cada usuario iniciará sesión desde una IP corporativa o una computadora portátil corporativa a la vez; los equipos de seguridad están correlacionando eventos en función de la identificación del usuario; los equipos de finanzas podrían agregar informes de costos por usuario y su entorno de nube personal. El intercambio de credenciales socava todas esas suposiciones, entre otras. Elimina el significado básico de una identidad en línea.

Un ejemplo del mundo real

Pasemos al mundo de low-code/no-code y examinemos un escenario del mundo real. En una gran empresa, Jane, una empleada inspirada del equipo de atención al cliente, se dio cuenta de que cuando los empleados de toda la organización participan en un caso de cliente, generalmente les falta información clave sobre el cliente, como el historial de su caso de soporte y las últimas compras. Esto degrada la experiencia del cliente, ya que tiene que explicar su problema una y otra vez mientras el caso se enruta al empleado adecuado que puede abordar el problema.

Para mejorar esto, Jane creó una aplicación que permite a los empleados de la empresa ver esta información clave sobre los clientes cuando esos empleados son parte del equipo responsable de abordar el caso de soporte del cliente. Primero, tomemos un momento para reconocer el poder del código bajo/sin código, que le permite a Jane identificar una necesidad y abordarla por su cuenta, sin pedir un presupuesto ni esperar asignaciones de recursos de TI.

Mientras creaba la aplicación, Jane tuvo que solucionar varios problemas, el mayor de los cuales eran los permisos. Los empleados de toda la organización no tienen acceso directo para consultar la base de datos de clientes para obtener la información que necesitan. Si lo hicieran, entonces Jane no tendría que construir esta aplicación. Para superar este problema, Jane inició sesión en la base de datos e incrustó su sesión autenticada directamente en la aplicación. Cuando la aplicación recibe una solicitud de un usuario, utilizará la identidad de Jane para ejecutar esa consulta y luego devolverá los resultados al usuario. Esta característica de incrustación de credenciales, como exploramos el mes pasado, es una característica clave de las plataformas low-code/no-code. Jane se aseguró de configurar el control de acceso basado en roles (RBAC) en la aplicación de modo que cada usuario solo pueda acceder a los casos de clientes a los que está asignado.

La aplicación resolvió un importante problema comercial y, por lo tanto, ganó rápidamente la adopción de los usuarios en toda la empresa. Las personas estaban felices de poder brindar un mejor servicio a sus clientes al tener el contexto adecuado para la conversación. Los clientes también estaban felices. Un mes después de que Jane creara la aplicación, ya la usaban cientos de usuarios en toda la organización, y los índices de satisfacción del cliente aumentaron.

Mientras tanto, en el SOC, se activó una alerta de gravedad alta que mostraba actividad anormal en la base de datos de clientes de producción y se asignó a Amy, una analista de seguridad experimentada. La investigación inicial de Amy mostró que un usuario interno estaba tratando de raspar toda la base de datos, consultando información sobre múltiples clientes de múltiples direcciones IP en toda la organización. El patrón de consulta era muy complejo; en lugar de un patrón de enumeración simple que esperaría ver cuando se raspa una base de datos, los datos del mismo cliente se consultaron varias veces, a veces a través de direcciones IP diferentes y en fechas diferentes. ¿Podría tratarse de un atacante que intenta confundir los sistemas de supervisión de seguridad?

Después de una investigación rápida, Amy descubrió una información crucial: todas esas consultas en todas las direcciones IP y fechas usaban una sola identidad de usuario, alguien llamada Jane del equipo de atención al cliente.

Amy se acercó a Jane para preguntarle qué estaba pasando. Al principio, Jane no lo sabía. ¿Le robaron sus credenciales? ¿Hizo clic en el enlace incorrecto o confió en el correo electrónico entrante incorrecto? Pero cuando Jane le contó a Amy sobre la aplicación que creó recientemente, ambas se dieron cuenta de que podría haber una conexión. Amy, la analista de SOC, no estaba familiarizada con low-code/no-code, por lo que se comunicó con el equipo de AppSec. Con la ayuda de Jane, el equipo descubrió que la aplicación de Jane tenía las credenciales de Jane integradas. Desde la perspectiva de la base de datos, no había ninguna aplicación; solo estaba Jane, ejecutando muchas consultas.

Jane, Amy y el equipo de AppSec decidieron cerrar la aplicación hasta que se encontrara una solución. Los usuarios de la aplicación en toda la organización estaban frustrados porque habían llegado a confiar en ella y los clientes también lo sentían.

Mientras que Amy cerró el problema y documentó sus hallazgos, el vicepresidente de atención al cliente no estaba contento con la caída de la tasa de satisfacción del cliente, por lo que le pidió a Jane que buscara una solución permanente. Con la ayuda de la documentación de la plataforma y el equipo del Centro de excelencia de la organización, Jane eliminó su identidad incrustada de la aplicación, cambió la aplicación para usar la identidad de cada usuario para consultar la base de datos y se aseguró de que los usuarios obtengan permisos solo para los casos de clientes con los que están asociados. . En su nueva y mejorada versión, la aplicación utilizaba la identidad de cada usuario para consultar la base de datos de clientes. Jane y los usuarios de la aplicación estaban felices de que la aplicación estuviera nuevamente en línea, Amy y el equipo de AppSec estaban felices de que la identidad de Jane ya no se comparte, y la empresa vio que la tasa de satisfacción del cliente comenzó a subir nuevamente. Todo estuvo bien.

Dos semanas después, el SOC recibió otra alerta sobre un acceso anómalo a la base de datos de clientes de producción. Parecía sospechosamente similar a la alerta anterior en esa misma base de datos. Nuevamente, las direcciones IP de toda la organización usaban la identidad de un solo usuario para consultar la base de datos. Nuevamente, ese usuario era Jane. Pero esta vez, el equipo de seguridad y Jane sabían que la aplicación utiliza las identidades de sus usuarios. ¿Que esta pasando?

La investigación reveló que la aplicación original tenía implícitamente compartido Sesión de base de datos autenticada de Jane con los usuarios de la aplicación. Al compartir la aplicación con un usuario, ese usuario obtuvo acceso directo a la conexión, un envoltorio alrededor de una sesión de base de datos autenticada proporcionada por la plataforma low-code/no-code. Con esa conexión, los usuarios podían aprovechar la sesión autenticada directamente; ya no tenían que pasar por la aplicación. Resulta que varios usuarios descubrieron esto y, pensando que este era el comportamiento previsto, estaban usando la sesión de base de datos autenticada de Jane para ejecutar sus consultas. Les encantó esta solución, ya que usar la conexión directamente les dio acceso completo a la base de datos, no solo para los casos de clientes a los que están asignados.

La conexión se eliminó y el incidente terminó. El analista de SOC contactó a los usuarios que habían usado la conexión de Jane para asegurarse de que descartaran cualquier dato de cliente que tuvieran almacenado.

Abordar el desafío de seguridad Low-Code/No-Code

La historia anterior es un escenario de la vida real de una empresa multinacional B2C. Se omitieron o ajustaron algunos detalles para proteger la privacidad. Hemos visto cómo un empleado bien intencionado podría compartir su identidad sin darse cuenta con otros usuarios, causando una amplia gama de problemas en TI, seguridad y el negocio. Como exploramos el mes pasado, el uso compartido de credenciales es una característica clave de low-code/no-code. Es la norma, no la excepción.

As low-code/no-code continúa floreciendo en la empresa, conscientemente o no, es fundamental que los equipos de seguridad y TI se unan a la conversación sobre el desarrollo empresarial. Las aplicaciones de código bajo/sin código vienen con un conjunto único de desafíos de seguridad, y su naturaleza prolífica significa que esos desafíos se agudizan más rápido que nunca.