Seguro por diseño , en ingeniería de software , significa que los productos y capacidades de software han sido diseñados para ser fundamentalmente seguros .
Al comienzo del diseño de software se consideran estrategias, tácticas y patrones de seguridad alternativos, y la arquitectura selecciona y aplica los mejores, y se utilizan como principios rectores para los desarrolladores . [1] También se recomienda el uso de patrones de diseño estratégicos que tengan efectos beneficiosos sobre la seguridad , aunque esos patrones de diseño no se idearon originalmente teniendo en cuenta la seguridad. [2]
Secure by Design se está convirtiendo cada vez más en el enfoque de desarrollo principal para garantizar la seguridad y privacidad de los sistemas de software. En este enfoque, la seguridad se considera y se integra en el sistema en cada capa y comienza con un diseño de arquitectura sólida. Las decisiones de diseño de la arquitectura de seguridad se basan en estrategias, tácticas y patrones de seguridad bien conocidos, definidos como técnicas reutilizables para lograr problemas de calidad específicos. Las tácticas/patrones de seguridad brindan soluciones para hacer cumplir los requisitos necesarios de autenticación , autorización, confidencialidad, integridad de datos , privacidad, responsabilidad, disponibilidad, seguridad y no repudio, incluso cuando el sistema está bajo ataque. [3] Para garantizar la seguridad de un sistema de software, no solo es importante diseñar una arquitectura de seguridad robusta, sino que también es necesario asignar estrategias, tácticas y patrones de seguridad actualizados al desarrollo de software para mantener la persistencia de la seguridad.
Se debe suponer que se producen ataques maliciosos al software y se debe tener cuidado para minimizar el impacto. Se anticipan vulnerabilidades de seguridad, junto con entradas de usuario no válidas . [4] Estrechamente relacionada está la práctica de utilizar un "buen" diseño de software, como el diseño basado en dominio o el diseño nativo de la nube , como una forma de aumentar la seguridad al reducir el riesgo de errores de apertura de vulnerabilidades, aunque los principios de diseño utilizados no fueran originalmente concebido con fines de seguridad.
Generalmente, los diseños que funcionan bien no dependen de que sean secretos . A menudo, el secreto reduce la cantidad de atacantes al desmotivar a un subconjunto de la población amenazada. La lógica es que si hay un aumento en la complejidad para el atacante, el mayor esfuerzo del atacante para comprometer el objetivo lo desanimará. Si bien esta técnica implica riesgos inherentes reducidos, un conjunto prácticamente infinito de actores y técnicas de amenazas aplicados a lo largo del tiempo hará que la mayoría de los métodos secretos fallen. Si bien no es obligatoria, una seguridad adecuada generalmente significa que todos pueden conocer y comprender el diseño porque es seguro . Esto tiene la ventaja de que muchas personas miran el código de la computadora , lo que mejora las probabilidades de que cualquier falla se encuentre antes (consulte la ley de Linus ). La desventaja es que los atacantes también pueden obtener el código, lo que les facilita encontrar vulnerabilidades que explotar. Sin embargo, en general se cree que la ventaja del código informático abierto supera la desventaja.
Además, es importante que todo funcione con la menor cantidad de privilegios posibles (consulte el principio de privilegio mínimo ). Por ejemplo, un servidor web que se ejecuta como usuario administrativo ("root" o "admin") puede tener el privilegio de eliminar archivos y usuarios. Por lo tanto, una falla en un programa de este tipo podría poner en riesgo todo el sistema, mientras que un servidor web que se ejecuta dentro de un entorno aislado y solo tiene privilegios para las funciones requeridas de red y sistema de archivos , no puede comprometer el sistema en el que se ejecuta a menos que se respete la seguridad que lo rodea. en sí mismo también es defectuoso.
El diseño seguro debe tenerse en cuenta en todos los puntos del ciclo de vida del desarrollo (cualquiera que sea la metodología de desarrollo elegida). Existen algunas metodologías de desarrollo Secure By Design prediseñadas (por ejemplo, Microsoft Security Development Lifecycle ).
Existen estándares y legislación para ayudar al diseño seguro al controlar la definición de "seguro" y proporcionar pasos concretos para probar e integrar sistemas seguros.
Algunos ejemplos de estándares que cubren o tocan los principios de Secure By Design:
En las arquitecturas de servidor/cliente, el programa del otro lado puede no ser un cliente autorizado y el servidor del cliente puede no ser un servidor autorizado. Incluso cuando lo sean, un ataque de intermediario podría comprometer las comunicaciones.
A menudo, la forma más fácil de romper la seguridad de un sistema cliente/servidor es no atacar los mecanismos de seguridad, sino evitarlos. Un ataque de hombre en el medio es un ejemplo simple de esto, porque puedes usarlo para recopilar detalles para hacerse pasar por un usuario. Por eso es importante considerar el cifrado , el hash y otros mecanismos de seguridad en su diseño para garantizar que la información recopilada de un atacante potencial no permita el acceso.
Otra característica clave del diseño de seguridad cliente-servidor son las buenas prácticas de codificación . Por ejemplo, seguir una estructura de diseño de software conocida, como cliente y corredor, puede ayudar a diseñar una estructura bien construida con una base sólida. Además, si el software va a modificarse en el futuro, es aún más importante que siga una base lógica de separación entre el cliente y el servidor. Esto se debe a que si un programador llega y no puede entender claramente la dinámica del programa, puede terminar agregando o cambiando algo que pueda agregar una falla de seguridad. Incluso con el mejor diseño, esto siempre es una posibilidad, pero cuanto mejor sea la estandarización del diseño, menos posibilidades habrá de que esto ocurra.
{{cite journal}}: Citar diario requiere |journal=( ayuda )