Seguro por diseño , en ingeniería de software , significa que los productos y capacidades de software se han diseñado para ser fundamentalmente seguros .
Las estrategias, tácticas y patrones de seguridad alternativos se consideran al comienzo de un diseño de software, y la arquitectura selecciona y aplica los mejores, y se utilizan como principios rectores para los desarrolladores . [1] También se recomienda utilizar patrones de diseño estratégicos que tengan efectos beneficiosos sobre la seguridad, aunque esos patrones de diseño no se diseñaron 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 la 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 robusto. Las decisiones de diseño arquitectónico de seguridad se basan en estrategias, tácticas y patrones de seguridad bien conocidos definidos como técnicas reutilizables para lograr preocupaciones de calidad específicas. Las tácticas / patrones de seguridad brindan soluciones para hacer cumplir los requisitos necesarios de autenticación , autorización, confidencialidad, integridad de los 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 (prevista), sino que también es necesario mapear estrategias, tácticas y patrones de seguridad actualizados para el desarrollo de software a fin de mantener la persistencia de la seguridad.
Espere ataques
Se debe suponer que ocurren 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 dirigido por dominios o el 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 fueron originalmente concebido con fines de seguridad.
Evite la seguridad a través de la oscuridad
Generalmente, los diseños que funcionan bien no se basan en ser secretos . A menudo, el secreto reduce el número de atacantes al desmotivar a un subconjunto de la población de amenazas. La lógica es que si hay un aumento en la complejidad para el atacante, el esfuerzo del atacante aumenta para comprometer al objetivo. Si bien esta técnica implica riesgos inherentes reducidos, un conjunto virtualmente infinito de actores y técnicas de amenazas aplicados a lo largo del tiempo hará que la mayoría de los métodos de secreto fallen. Si bien no es obligatorio, la seguridad adecuada generalmente significa que todos pueden conocer y comprender el diseño porque es seguro . Esto tiene la ventaja de que mucha gente está mirando el código de la computadora , lo que mejora las probabilidades de que se detecten antes las fallas (consulte la ley de Linus ). Los atacantes también pueden obtener el código, lo que les facilita la búsqueda de vulnerabilidades .
Menos privilegios
Además, es importante que todo funcione con la menor cantidad de privilegios posible (consulte el principio de menor privilegio ). Por ejemplo, un servidor web que se ejecuta como usuario administrativo ("root" o administrador) puede tener el privilegio de eliminar archivos y usuarios que no pertenecen. 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 los privilegios para las funciones de red y sistema de archivos requeridas , no puede comprometer el sistema en el que se ejecuta a menos que la seguridad que lo rodea esté en sí mismo también defectuoso.
Metodologías
El diseño seguro debe ser una consideración en todos los puntos del ciclo de vida del desarrollo (cualquiera que sea la metodología de desarrollo que se elija).
Existen algunas metodologías de desarrollo seguras por diseño predefinidas (por ejemplo , ciclo de vida de desarrollo de seguridad de Microsoft ).
Ciclo de vida de desarrollo de seguridad de Microsoft
Microsoft emitió una metodología y una guía basada en el modelo de espiral clásico .
Estándares y legislación
Los estándares y la legislación existen para ayudar al diseño seguro controlando la definición de "seguro" y proporcionando pasos concretos para probar e integrar sistemas seguros.
Algunos ejemplos de estándares que cubren o tocan los principios de Secure By Design:
- ETSI TS 103 645 [5] que se incluye en parte en el Gobierno del Reino Unido "Propuestas para regular la ciberseguridad de los productos inteligentes para el consumidor" [6]
- La serie ISO / IEC 27000 cubre muchos aspectos del diseño seguro.
Arquitecturas de servidor / cliente
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 están, 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 dirigirse directamente a los mecanismos de seguridad, sino rodearlos. Un ataque de hombre en el medio es un ejemplo simple de esto, porque puede 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 se va a modificar 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 entra un programador y no puede comprender claramente la dinámica del programa, puede terminar agregando o cambiando algo que puede 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 hay de que esto ocurra.
Ver también
Referencias
- ^ "Un catálogo de debilidades de la arquitectura de seguridad". 2017 IEEE International Conference on Software Architecture (ICSA) . doi : 10.1109 / ICSAW.2017.25 .
- ^ Manning (2019). Seguro por diseño . ISBN 9781617294358.
- ^ "Cultivando un lenguaje de patrones (por seguridad)". ¡Adelante! 2012: Actas del Simposio internacional de ACM sobre nuevas ideas, nuevos paradigmas y reflexiones sobre programación y software : 139–158. Octubre de 2012. doi : 10.1145 / 2384592.2384607 .
- ^ Dougherty, Chad; Sayre, Kirk; Seacord, Robert C .; Svoboda, David; Togashi, Kazuya (octubre de 2009). "Patrones de diseño seguro". doi : 10.1184 / R1 / 6583640.v1 . Cite journal requiere
|journal=
( ayuda ) - ^ "ETSI TS 103 645" (PDF) .
- ^ "Documento de política: propuestas para regular la seguridad cibernética de los productos inteligentes del consumidor - solicitar opiniones" .
enlaces externos
- Programación segura para Linux y Unix HOWTO
- Preguntas frecuentes sobre la programación segura de UNIX
- Las 10 mejores prácticas de codificación segura
- Seguridad por principios de diseño