6.7 Principio de Mínimo Privilegio Establece que se debe asignar a un componente o usuario solo los permisos necesarios y suficientes para realizar una acción específica. Estos permisos deben asignarse lo más tardíamente posible es decir, lo más cercano en tiempo al momento en que debe ejecutarse la acción y se deben revocar en cuanto no son necesarios. 6.8 Separación de responsabilidades y roles. Cuando un componente falle, que no afecte el resto del sistema. Este principio consiste en aislar los privilegios de los componentes para evitar que interfieran entre sí en caso de que alguno sea vulnerable. 6.9 Defensa en profundidad. Consiste en establecer controles de seguridad consecutivos que seguirán en pie independientemente de que falle alguno de ellos. Este principio de diseño aumenta notablemente la resistencia del sistema, ofrece defensa contra ataques que encadenan múltiples técnicas de explotación. 6.10 Los controles en el Cliente no son suficientes. Sin control sobre el dispositivo en que se ejecuta el código es inviable controlar su comportamiento. Cualquier control implementado en un equipo que le pertenece a terceros puede ser modificado o deshabilitado. Nunca se debe confiar en datos validados en un equipo cliente, un atacante podría manipularlos arbitrariamente. 6.11 Ayudar a los Administradores. El software no puede defenderse a sí mismo de atacantes. La aplicación debe ofrecer herramientas útiles a los administradores para analizar el comportamiento de los usuarios y detectar casos de abuso. También debe permitir conceder, analizar y revocar permisos de acceso a usuarios. Debe ofrecerse un registro de eventos de seguridad, preferiblemente con reducción de falsos positivos y ruido. Nunca mostrar información personal de los usuarios a los administradores. Se debe proteger especialmente interfaces de acceso administrativo, y considerar implementar autenticación multifactor. 6.12 Diseño sin secretos. La buena seguridad no requiere secretos. Se debe diseñar el sistema bajo la premisa de que eventualmente el público conocerá los detalles de su funcionamiento interno. Seguridad mediante oscuridad es el error de confiar en secretos como controles válidos. Existen técnicas de testeo a ciegas e ingeniería inversa para obtener información sobre el funcionamiento de sistemas teóricamente secretos. No se debe confiar en el secreto de los mecanismos como medida válida de seguridad. 6.13 Modelado de amenazas. Ofrece herramientas para estudiar y mejorar los diseños propuestos para la aplicación. Ayuda a identificar puntos débiles y fortalece la seguridad total del sistema. Ayuda a prevenir vulnerabilidades a nivel arquitectura de diseño. IF-2021-76718462-APN-DNCIB#JGM ● Se estudia el diseño tentativo del sistema, reduciéndolo a sus componentes principales. Página 14 de 35