Seguridad por diseño - aclaración

9

Trabajo como contratista en el campo Seguridad de SI. Mi cliente actual me contrató para diseñar y aplicar una metodología para garantizar que los riesgos de seguridad se evalúen y aborden en todos los proyectos de TI. Además de esta asignación, mi cliente me preguntó ayer cuál era mi conocimiento del concepto de Seguridad por Diseño (SbD), si pensaba que se aplicaba en su organización y cómo mi misión contribuyó a esto. Respondí honestamente que, si bien tenía un entendimiento básico de lo que es SbD, no me sentía cómodo al darle una respuesta definitiva en el momento y que lo investigaría.

Lo que hice. Pero parece bastante difícil encontrar una definición concreta de SbD. Mi impresión es que, en la práctica, sé que hay un concepto real e importante detrás de estas palabras, que se utiliza principalmente como un argumento de mercadotecnia de moda que las personas ponen en sus presentaciones para complacer a la gerencia. Pero, ¿existen criterios concretos para evaluar si un proyecto / organización aplica el concepto SbD? ¿O es solo la idea de tener en cuenta los problemas de seguridad en cada aspecto del trabajo y dejar que uno decida cómo aplicar esto?

    
pregunta ero 08.03.2017 - 15:55
fuente

2 respuestas

8

Es un área un poco gris, ya que todos la interpretan de manera un poco diferente, pero los aspectos consistentes de Secure by Design incluyen:

  • una arquitectura que tiene seguridad incorporada por defecto
  • un proceso de diseño y revisión de código que tiene suficientes controles
  • desarrolladores / diseñadores / arquitectos capacitados en seguridad
  • comprobación automatizada
  • monitoreo continuo a través del desarrollo (esp DevOps)
  • control de 4 ojos

Etc.

Hace hincapié en que la seguridad se incorpore pronto, en lugar de contar con la reparación después del hecho.

Esto tiene algunos beneficios obvios, incluido un costo de ciclo de vida drásticamente reducido.

Para aclarar según el comentario de jpmc26, construir una arquitectura segura significa diseñarla para que tenga capas de protección, para evitar agujeros obvios (y también para evitar que aparezcan agujeros accidentales), para asegurarla por defecto o para cerrarla cuando fallan las cosas, para comprender los requisitos de seguridad antes de comenzar a construir, para que no sea necesario agregarlos más adelante ... etc.

    
respondido por el Rory Alsop 08.03.2017 - 16:16
fuente
2

Estoy de acuerdo con @ Comentario de Pascal : mi primer pensamiento fue que el diseño seguro implicaría tener Modos de fallos bien especificados.

O, más generalmente, para evitar cualquier comportamiento inesperado / no especificado, y asegurar que tanto el éxito como el fracaso sigan los caminos apropiados.

Posiblemente no del todo relacionado con el tema, pero revisando el Ciclo de vida de desarrollo seguro de Microsoft (que veo como un intento de hacer que Windows sea seguro por diseño, aunque después de que el diseño original haya sido creado y enviado), tienen algunos consejos útiles en el etapa de diseño de sus SDL ( enlace ) - Estoy parafraseando un poco:

  • Establecer requisitos de diseño (incluir requisitos de seguridad y privacidad)
  • Análisis y reducción de la superficie de ataque
  • Uso del modelado de amenazas

Vea también enlace .

Por lo tanto, tiendo a pensar que Secure by Design implicaría algo un poco más concreto que solo considerar la seguridad en general, pero parece que encontrar una referencia sólida para respaldar el sentimiento es un poco más difícil.

    
respondido por el iwaseatenbyagrue 08.03.2017 - 18:08
fuente

Lea otras preguntas en las etiquetas