Enseñanza “Secure by Design”

El recurso canónico para el concepto de diseño seguro es "La protección de la información en sistemas informáticos " por Saltzer y Schroeder. La esencia se destila en sus 8 principios de diseño seguro:

1. Economía del mecanismo
2. valores predeterminados a prueba de fallos
3. Mediación completa
4. diseño abierto
5. Separación de privilegios
6. Mínimo privilegio
7. Mecanismo menos común
8. aceptabilidad psicológica

Estos principios, establecidos en 1974, siguen siendo plenamente aplicables en la actualidad.

Será difícil enseñar los principios de diseño en 30 minutos. Estoy de acuerdo con otros que dicen que hay que entusiasmarlos de alguna manera. Desarrollé el juego de cartas "Elevation of Privilege" para que la gente se entusiasme con el modelado de amenazas, podría ser útil. ( enlace )

Enseñar a las personas a pensar como un atacante es un gran desafío, es más fácil enseñarles sobre algunos ataques como la inyección de SQL o las secuencias de comandos entre sitios.

Por último, si quieres intentar enseñar principios, hice una serie de publicaciones del blog que ilustran Saltzer y Schroeder con escenas de Star Wars: enlace

En lugar de centrarme en las reglas y "seguir estas 5 reglas, y estás seguro", me concentraría en enseñar a los desarrolladores sobre los atacantes y cómo piensan. Realmente no puedes cubrir 5 cosas diferentes, cada una de las cuales requiere un conocimiento profundo para realmente implementarse adecuadamente, ¿por qué intentarlo?

Los desarrolladores con los que he hablado parecen pensar que la piratería es "realmente difícil", y realmente no entienden lo fácil que puede ser. Entonces, explicar lo que realmente hace la gente para frustrar la seguridad puede ser revelador.

Un ejemplo:

Hace unos años, estaba revisando un producto de informes basado en la web de terceros y tuvimos un desarrollador del proveedor para crear algunos informes utilizando el producto. Pregunté por la seguridad y cómo funcionaba en su producto. Procedió a hacer una "fuente de vista" en la página web del informe y me mostró cómo todo era HTML dinámico y, por lo tanto, era imposible de acceder. Me quedé estupefacto por un minuto, pero le dije que esto no era realmente una seguridad viable, que no puedes confiar en el final del cliente, bla, bla, bla.

No me creyó y preguntó cómo alguien podría hackear este producto. Pensé por un minuto, dije que conectaría el navegador a un servidor proxy y examinaría cuál era la solicitud / respuesta. (Hoy solo uso el plugin de datos de sabotaje). Luego dijo que esto sería "¡El ataque del siglo!" En este punto, levanté las manos en señal de derrota, ya que él había decidido que su producto era "seguro". La única forma de convencerlo sería hackear su producto, lo cual no valía la pena porque no iba a comprar el producto.

El punto es que debe comenzar con la necesidad de seguridad y con lo que todos estamos en contra. Si no entienden eso, se acabó el juego. Como mínimo, les inculcarás un poco de miedo, lo que es un buen motivador. Por lo que he visto, muchos desarrolladores no "entienden" realmente, y necesitan entender primero a qué se enfrentan. Principalmente para poder entender POR QUÉ necesitan desarrollar aplicaciones seguras.

Haga que las personas se interesen realmente por la seguridad, y es posible que obtenga algo de ello. De lo contrario, me temo que todo lo que presente en 35 minutos caerá en oídos sordos.

Es posible que desee llamar su atención primero. Una demostración de un ataque de inyección SQL es simple, comprensible y puede subrayar la importancia del tema. Puede referirse a él a lo largo de la charla mientras hace puntos.

Me gusta que te metas en los límites de confianza. Con la validación de entrada, lo golpeé con más detalle. La validación de longitud primero, luego mencione la lista blanca y la lista negra. ¿Recomienda que intenten arreglar automáticamente los datos erróneos o debería rechazarse la entrada incorrecta? Toca las estrategias que recomendarías.

Con respecto al privilegio mínimo, esta podría ser una oportunidad para presentar las ideas del control de acceso basado en roles y las ventajas sobre un sistema basado en usuarios.

Creo que hay una oportunidad para mencionar el principio de defensa en profundidad. El saneamiento de la entrada es crítico, pero seguirlo en el código al requerir SQL parametrizado ayudaría incluso si alguien pierde el bote en la entrada.

Con respecto al registro, asegúrese de que entiendan el delta entre un mensaje de error que se muestra al usuario y el contenido de los archivos de registro. Y asegúrate de que no estén registrando nada sensible.

También considere discutir un proceso de desarrollo que ayude a garantizar que permanezcan en un camino seguro. Asegúrese de que las revisiones de código de pares, el uso de analizadores de código estático y los analizadores dinámicos sean parte de su proceso de desarrollo. Esto puede estar fuera del alcance de la capacitación, pero podría enseñarles cómo las revisiones y las herramientas ayudan a mejorar su código.

30-45 minutos ... ay. Puede volver al organizador y solicitar dos o tres días, ver qué tipo de reacción se produce. O tal vez un programa de 10 semestres ... De todos modos, ¡buena suerte!

Obviamente, tienes una tarea difícil y todas las consideraciones de las que has hablado te darán un plato muy completo. Pero creo que alguna mención o vinculación con la estrategia general de defensa en profundidad más favorecida de todos, implementada con menos frecuencia sería muy valiosa para trabajar, si pudiera. O, quizás, expresarlo de otra manera, "La necesidad de valorar y crear redundancia de medidas de seguridad contra cualquier vector de amenaza importante en cualquier diseño de seguridad decente".

Estás creando una aplicación web, y estás bastante seguro de que tienes un mecanismo robusto para sanear cualquier & Todos los esfuerzos de inyección de código de su entrada? Eso es bueno. Ahora suponga que un atacante creativo encuentra una falla de implementación que nunca pensó, una falla que permite que un código realmente desagradable y poderoso se ponga delante de su aplicación real. ¿Estás diseñando & refuerce la lógica de su aplicación con la idea de que podría tener que enfrentar ese escenario, o simplemente va a suponer que, debido a que tiene lo que ve como un mecanismo de defensa único y fuerte contra el código delante de su aplicación, puede cambiar su centrarse en otras cosas? Debido a que la diferencia entre estas dos opciones a menudo será la diferencia entre llegar a algo que podría ser un diseño de seguridad sólido en lugar de lo que seguramente será un diseño de seguridad inherentemente frágil.

(Nota: mientras escribo esto, me doy cuenta de que el ejemplo de confiar en el saneamiento de insumos como una defensa perfecta no es la mejor, porque en el mundo real en el que vivimos hoy, con suerte, pocos desarrolladores competentes caerán en una tentación de tomar algo tan conocido como muy imperfecto como el saneamiento de entradas como una línea de defensa sólida e impenetrable como una roca. Esperemos. Pero usted toma mi punto más amplio ...)