Un proceso puede referirse a cualquier conjunto de políticas o procedimientos que siga. Podría ser algorítmico, o podría ser simplemente políticas o procedimientos documentados que tienen lagunas o fallas. Es decir, incluso si las personas involucradas están haciendo su trabajo con la letra, y la tecnología está haciendo lo que se espera y se supone, el proceso puede abusarse o explotarse.
Para dar un ejemplo simple, digamos que una empresa tiene un sistema de tickets de mesa de ayuda que se utiliza para solicitar permisos y privilegios. Es una ocurrencia común para que se necesite información adicional en el ticket, de modo que los usuarios puedan editar los tickets que han creado, y solo puede crear un ticket como usuario registrado. El proceso es el siguiente:
- Un usuario crea un ticket, que indica a qué base de código o servidor necesita acceso.
- Alguien del equipo de seguridad verifica que se supone que el usuario solicitante tiene esos permisos, y agrega un comentario al ticket o cambia el estado del ticket para indicar que está aprobado
- Alguien del departamento de TI procesa el ticket, agregando los permisos apropiados.
En el papel, eso puede parecer superficialmente seguro, siempre que las personas estén haciendo su trabajo (por ejemplo, agregar el usuario correcto al conjunto de permisos correcto) y el sistema de tecnología / emisión de boletos sea seguro.
Pero, ¿qué pasa si usted entra como un usuario que se supone que debe tener permiso para editar la documentación de ayuda, y después de que se apruebe en el paso 2, edite el ticket para decir que necesita permiso para acceder al código fuente que dice? ¿Se supone que no debe tener acceso a una base de datos de producción que contenga información confidencial, etc.? El usuario del departamento de TI en el paso 3 puede ver el ticket, ver la aprobación y ahora tiene permisos que en realidad no se supone que tenga.
Lo que tienes es una falla en el proceso, porque la política oficial / documentada no tiene en cuenta la capacidad de editar tickets. Puede corregir la política al no permitir ediciones de tickets después de la aprobación, o al requerir que el usuario de TI en el Paso 3 vea un historial de edición del ticket, pero tal como está documentado y seguido, el proceso es fundamentalmente inseguro.
Para explicar cómo eso se vincula con la publicación del blog que vinculó, la tecnología y la automatización podrían limpiar la brecha en el procedimiento mismo. Tal vez cuando la seguridad lo aprueba, vinculan directamente el ticket al repositorio al que se supone que debe tener permiso, y se reenvía al departamento de TI como un nuevo ticket, o se automatiza por completo. Eso elimina uno de los factores humanos de error (el administrador de TI lee incorrectamente un ticket seguro y sin editar, o selecciona el nombre de usuario incorrecto), y el vacío legal del proceso (no hay verificación entre los pasos 2 y 3).