Enseignement "Secure by Design"
Je suis architecte de sécurité et j'ai l'habitude de définir la sécurité du projet comme une spécification qui est réalisée par d'autres. J'ai récemment été chargé d'enseigner aux nouveaux codeurs comment concevoir et programmer en utilisant les principes de "Secure by Design" (et dans un proche avenir "Privacy by Design"). J'ai 30 à 45 minutes (ouais, je sais), et la conversation doit être indépendante de la langue. Cela signifie que je dois présenter des règles exploitables qui peuvent être appliquées par les développeurs Web, les développeurs d'applications et les développeurs d'infrastructure.
Je suis venu avec 5 règles de base et un supplément:
- Ne faites confiance à aucune entrée interne/externe (couvre l'assainissement, les débordements de tampon, etc.)
- Le moindre privilège pour toute entité, objet ou utilisateur
- Échec "pas de privilège"
- Sécurisé, même si le design est connu/public
- Connectez-vous afin qu'une personne qui ne connaît pas le système puisse auditer chaque action
Supplément: si vous enfreignez une règle, prouvez que l'atténuation peut survivre aux futurs programmeurs ajoutant des fonctionnalités.
Chacune de ces règles peut être complétée par des exemples de n'importe quelle langue ou application, pour des conseils spécifiques. Je crois que cela gère la plupart des principes généraux de "Secure by Design" d'un point de vue de haut niveau. Ai-je raté quelque chose?
La ressource canonique pour le concept de sécurité par conception est "La protection de l'information dans les systèmes informatiques" par Saltzer et Schroeder. L'essence est distillée dans leurs 8 principes de conception sécurisée:
- Économie de mécanisme
- Valeurs par défaut de sécurité
- Médiation complète
- Conception ouverte
- Séparation de privilège
- Le moindre privilège
- Mécanisme le moins courant
- Acceptabilité psychologique
Ces principes, énoncés en 1974, sont toujours pleinement applicables aujourd'hui.
Il sera difficile d'enseigner les principes de conception en 30 minutes. Je suis d'accord avec d'autres qui disent qu'il faut les exciter d'une façon ou d'une autre. J'ai développé le jeu de cartes "Elevation of Privilege" pour inciter les gens à la modélisation des menaces, cela pourrait être utile. ( https://blogs.Microsoft.com/cybertrust/2010/03/02/announcing-elevation-of-privilege-the-threat-modeling-game/ )
Apprendre aux gens à penser comme un attaquant est très difficile, il est plus facile de leur enseigner quelques attaques comme l'injection SQL ou les scripts intersites.
Enfin, si vous voulez essayer d'enseigner les principes, j'ai fait une série d'articles de blog illustrant Saltzer et Schroeder avec des scènes de Star Wars: http://emergentchaos.com/the-security-principles-of-saltzer -et-schroeder
Plutôt que de se concentrer sur les règles et de "suivre ces 5 règles, et vous êtes en sécurité", je me concentrerais sur l'enseignement aux développeurs des attaquants et de leur façon de penser. Vous ne pouvez pas vraiment couvrir 5 choses différentes, chacune nécessitant des connaissances approfondies pour être vraiment mise en œuvre correctement, alors pourquoi essayer?
Les développeurs à qui j'ai parlé semblent penser que le piratage est "vraiment difficile", et ne comprennent pas vraiment à quel point cela peut être facile. Expliquer ce que les gens font vraiment pour contrecarrer la sécurité peut donc être révélateur.
n exemple:
Il y a quelques années, je passais en revue un produit de génération de rapports basé sur le Web tiers et nous avions un développeur du fournisseur pour créer des rapports à l'aide du produit. J'ai posé des questions sur la sécurité et comment cela fonctionnait dans leur produit. Il a procédé à une "visualisation de la source" sur la page Web du rapport, et m'a montré comment tout était HTML dynamique, et donc impossible à pirater. Je suis resté abasourdi pendant une minute, mais je lui ai dit que ce n'était pas une sécurité vraiment réalisable, que vous ne pouviez pas faire confiance au client, bla bla bla.
Il ne m'a pas cru et a demandé comment quelqu'un pouvait pirater ce produit. J'ai réfléchi pendant une minute, j'ai dit que je connecterais le navigateur à un serveur proxy et examinerais la demande/réponse. (Aujourd'hui, je voudrais simplement utiliser le plugin de données anti-sabotage). Il a ensuite dit que ce serait "Le hack du siècle!" À ce stade, j'ai simplement levé les mains en échec, car il avait déjà décidé que son produit était "sécurisé". La seule façon de le convaincre serait de pirater son produit, ce qui ne valait pas vraiment mon temps puisque je n'allais pas acheter le produit de toute façon.
Le fait est que vous devez commencer par le besoin de sécurité et par quoi nous sommes tous confrontés. S'ils ne comprennent pas cela, c'est fini. À tout le moins, vous leur insufflerez un peu de peur, ce qui est un bon facteur de motivation. D'après ce que j'ai vu, de nombreux développeurs ne le comprennent pas vraiment, et ils doivent d'abord comprendre ce à quoi ils sont confrontés. Principalement pour pouvoir comprendre POURQUOI ils ont besoin de développer des applications sécurisées.
Intéressez les gens à la sécurité et vous pourriez en tirer quelque chose. Sinon, je crains que tout ce que vous présentez en 35 minutes ne tombe dans l'oreille d'un sourd.
Vous voudrez peut-être d'abord attirer leur attention. Une démonstration d'une attaque par injection SQL est simple, compréhensible et pourrait souligner l'importance du sujet. Vous pouvez y revenir tout au long de la présentation au fur et à mesure que vous faites valoir des points.
J'aime que vous tombiez dans des limites de confiance. Avec la validation d'entrée, je toucherais cela plus en détail. Validez d'abord la longueur, puis mentionnez la liste blanche et la liste noire. Recommandez-vous qu'ils essaient de corriger automatiquement les mauvaises données, ou si une mauvaise entrée est rejetée? Touchez les stratégies que vous recommanderiez.
En ce qui concerne le moindre privilège, cela pourrait être l'occasion d'introduire les idées de contrôle d'accès basé sur les rôles et les avantages par rapport à un système basé sur l'utilisateur.
Je pense qu'il est possible de mentionner en profondeur le principe de la défense. Le nettoyage des entrées est essentiel, mais le suivre dans le code en exigeant du SQL paramétré aiderait même si quelqu'un rate le bateau sur l'entrée.
Concernant la journalisation, assurez-vous qu'ils comprennent le delta entre un message d'erreur affiché à l'utilisateur et le contenu des fichiers journaux. Et assurez-vous qu'ils ne consignent rien de sensible.
Pensez également à discuter d'un processus de développement qui permet de s'assurer qu'ils restent sur une voie sécurisée. Assurez-vous que les revues de code par les pairs, l'utilisation d'analyseurs de code statiques et d'analyseurs dynamiques font partie de leur processus de développement. Cela peut être en dehors du cadre de la formation, mais vous pouvez leur expliquer comment les critiques et les outils contribuent à améliorer leur code.
30-45 minutes ... aïe. Vous pouvez retourner auprès de l'organisateur et demander deux ou trois jours pour voir quel type de réaction cela obtient. Ou peut-être un programme de 10 semestres ... Bref, bonne chance!
Vous avez une tâche difficile, évidemment, et toutes les considérations dont vous avez parlé vous donneront une assiette très complète. Mais je pense qu'une mention ou un lien avec le mot à la mode le plus favorisé de tout le monde, la stratégie globale de défense en profondeur moins mise en œuvre serait très utile pour travailler, si vous le pouviez. Ou, peut-être le formuler d'une autre manière, "La nécessité d'évaluer et de créer une redondance des mesures de sécurité contre tout vecteur de menace majeur donné dans n'importe quelle conception de sécurité décente."
Vous êtes en train de créer une application Web et vous êtes assez confiant d'avoir un mécanisme robuste en place pour désinfecter tous les efforts d'injection de code de votre entrée? C'est zonte. Supposons maintenant qu'un attaquant créatif trouve une faille d'implémentation à laquelle vous n'avez jamais pensé, une faille qui permet à un code vraiment méchant et puissant de se retrouver devant votre application réelle. Concevez-vous et renforcez-vous la logique de votre application avec l'idée qu'elle pourrait avoir besoin de faire face à ce scénario, ou allez-vous simplement supposer cela parce que vous avez ce que vous voyez comme un mécanisme défensif unique fort et fiable contre l'obtention de code devant votre application vous pouvez vous concentrer sur d'autres choses? Parce que la différence entre ces deux choix sera souvent la différence entre arriver à quelque chose qui pourrait être une conception de sécurité robuste et proposer ce qui sera presque certainement une conception de sécurité intrinsèquement fragile.
(Remarque: au moment où j'écris ceci, je me rends compte que l'exemple de s'appuyer sur la désinfection des entrées comme une défense parfaite n'est pas la meilleure, car dans le monde réel dans lequel nous vivons aujourd'hui, espérons que peu de développeurs compétents tomberaient dans une tentation de prendre quelque chose d'aussi imparfait que la désinfection des intrants comme une ligne de défense impénétrable et solide comme le roc. J'espère. Mais vous prenez mon point le plus large ...)