Cyber Shelf

// Comparaison

Designing Secure Software vs Threat Modeling : lequel lire ?

Deux livres de cybersécurité sur AppSec, comparés honnêtement : à qui s'adresse chacun, ce que chacun fait de mieux, et lequel lire en premier.

Intermédiaire
5/52021
Designing Secure Software

A Guide for Developers

Loren Kohnfelder

Loren Kohnfelder, l'auteur PKI original, sur comment tisser la pensée sécurité à travers exigences, design, implémentation et opérations plutôt que de la boulonner à la fin.

Intermédiaire
5/52014
Threat Modeling

Designing for Security

Adam Shostack

L'introduction de praticien d'Adam Shostack à la modélisation des menaces : STRIDE, arbres d'attaque, et comment intégrer la pratique au cycle de vie logiciel réel.

À lire si

Développeurs seniors et architectes qui écrivent déjà bien le code et veulent maintenant concevoir des systèmes qui n'expédient pas de CVE. Kohnfelder est l'auteur qui a littéralement écrit le papier X.509 ; le livre est la sagesse de design d'une carrière en 312 pages.
Quiconque conçoit des systèmes et veut livrer moins de bugs en production. La modélisation de menaces est la pratique de sécurité à plus fort levier pour les développeurs ; ce livre l'a enfin rendue enseignable.

À éviter si

Débutants ou lecteurs voulant du tooling hands-on. Le livre est niveau design : principes, patterns et études de cas. À coupler avec des livres niveau implémentation pour la vue ligne de code.
Lecteurs qui veulent une checklist rapide ou un one-pager. Shostack est exhaustif : STRIDE, arbres d'attaque, diagrammes de flux de données, kill chain, le tout avec des exemples filés. Survoler le livre est un gâchis.

Points clés

  • Secure-by-design est principalement éviter les pièges ; l'énumération du livre des erreurs communes-mais-fatales est la checklist mentale la plus nette qu'un concepteur puisse porter.
  • Les frontières de confiance sont le concept unique le plus utile en design sécurisé ; le livre vous apprend à les voir dans n'importe quelle architecture.
  • La plupart des débats sécurité dans les organisations d'ingénierie se résolvent en une poignée de compromis répétés (défense en profondeur vs simplicité, blocage vs logging, fail-open vs fail-closed) ; le livre les nomme et fournit le langage pour la conversation.
  • STRIDE est une fonction de forçage pour la pensée systématique, pas un modèle complet ; le livre apprend quand l'utiliser et quand changer de cadre (arbres d'attaque, personas attaquants, kill chains).
  • La plupart des « outils de threat modeling » sont du tableur-avec-diagrammes ; le vrai bénéfice est la conversation que ces outils structurent, pas le document.
  • Le threat modeling tient dans agile et fonctionne au tempo de la revue de PR une fois pratiqué trois ou quatre fois ; le livre l'argumente à coups d'exemples.

Comment ils se comparent

Designing Secure Software et Threat Modeling sont tous deux notés 5/5 dans notre catalogue. Choisissez selon vos préférences thématiques et de style, plutôt que sur la note.

Les deux livres ciblent un public de niveau intermédiaire : le choix se fait sur la thématique, pas la difficulté.

Designing Secure Software et Threat Modeling couvrent tous les deux AppSec, Defensive, Threat Modeling : les lire dans l'ordre renforce les mêmes notions sous des angles différents.

Continuer la lecture

Designing Secure Software

→ Alternatives à Designing Secure Software→ Que lire après Designing Secure Software

Threat Modeling

→ Alternatives à Threat Modeling→ Que lire après Threat Modeling

Thématiques liées

AppSecDefensiveThreat Modeling