stringtranslate.com

Seguro por diseño

Seguro por diseño , en ingeniería de software , significa que los productos y capacidades del software han sido diseñados para ser fundamentalmente seguros .

Al comienzo del diseño de un 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 fomenta el uso de patrones de diseño estratégicos que tengan efectos beneficiosos sobre la seguridad , incluso aunque esos patrones de diseño no se hayan ideado originalmente teniendo la seguridad en mente. [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 incorpora al sistema en cada capa y comienza con un diseño de arquitectura sólido. 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 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 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 sólida prevista, sino que también es necesario mapear estrategias, tácticas y patrones de seguridad actualizados al desarrollo de software para mantener la persistencia de la seguridad.

Esperar ataques

Se debe asumir que se producen ataques maliciosos al software y se deben tomar precauciones para minimizar el impacto. Se anticipan las vulnerabilidades de seguridad, junto con la entrada no válida del usuario . [4] Estrechamente relacionada está la práctica de utilizar un "buen" diseño de software, como el diseño impulsado por el dominio o el diseño nativo de la nube , como una forma de aumentar la seguridad al reducir el riesgo de errores que abran vulnerabilidades, incluso aunque los principios de diseño utilizados no se concibieron originalmente con fines de seguridad.

Evite la seguridad a través de la oscuridad

En general, los diseños que funcionan bien no dependen de ser secretos . A menudo, el secreto reduce la cantidad 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 mayor esfuerzo del atacante para comprometer el objetivo lo desalentará. 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 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 muchas personas miran el código fuente , lo que mejora las probabilidades de que se encuentren fallas 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 para explotar. Sin embargo, generalmente se cree que la ventaja del código fuente abierto supera la desventaja.

Menos privilegios

Además, es importante que todo funcione con la menor cantidad de privilegios posible (consulte el principio del mínimo privilegio ). 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 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 a su alrededor también sea defectuosa.

Metodologías

El diseño seguro debe tenerse en cuenta en todos los puntos del ciclo de vida del desarrollo (independientemente de la metodología de desarrollo elegida). Existen algunas metodologías de desarrollo Secure By Design predefinidas (por ejemplo, Microsoft Security Development Lifecycle ).

Normas y legislación

Existen normas y leyes que ayudan al diseño seguro controlando la definición de "seguro" y proporcionando pasos concretos para probar e integrar sistemas seguros.

Algunos ejemplos de normas que cubren o abordan los principios de seguridad por diseño:

Arquitecturas 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 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 no es atacar directamente los mecanismos de seguridad, sino eludirlos. Un ataque de intermediario es un ejemplo sencillo de esto, porque se puede utilizar para recopilar detalles con el fin de hacerse pasar por un usuario. Por eso es importante tener en cuenta el cifrado , el hash y otros mecanismos de seguridad en el diseño para garantizar que la información recopilada de un posible atacante no permita el acceso.

Otra característica clave para el 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 agente, 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 un programador llega 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 habrá de que esto ocurra.

Véase también

Referencias

  1. ^ Santos, Joanna CS; Tarrit, Katy; Mirakhorli, Mehdi (2017). "Un catálogo de debilidades de la arquitectura de seguridad". 2017 IEEE International Conference on Software Architecture Workshops (ICSAW) . págs. 220–223. doi :10.1109/ICSAW.2017.25. ISBN. 978-1-5090-4793-2.S2CID 19534342  .
  2. ^ Dan Bergh Johnsson; Daniel Deogun; Daniel Sawano (2019). Diseño seguro . Publicaciones Manning. ISBN 9781617294358.
  3. ^ Hafiz, Munawar; Adamczyk, Paul; Johnson, Ralph E. (octubre de 2012). "Desarrollo de un lenguaje de patrones (para seguridad)". Actas del simposio internacional de la ACM sobre Nuevas ideas, nuevos paradigmas y reflexiones sobre programación y software . págs. 139–158. doi :10.1145/2384592.2384607. ISBN 9781450315623. Número de identificación  S2C17206801.
  4. ^ Dougherty, Chad; Sayre, Kirk; Seacord, Robert C.; Svoboda, David; Togashi, Kazuya (octubre de 2009). "Patrones de diseño seguros". doi :10.1184/R1/6583640.v1. {{cite journal}}: Requiere citar revista |journal=( ayuda )
  5. ^ "ETSI TS 103 645" (PDF) .
  6. ^ "Documento de política: Propuestas para regular la ciberseguridad de los productos inteligentes de consumo: convocatoria de opiniones".

Enlaces externos