// Comparaison

Designing Secure Software vs Incident Response and Computer Forensics : lequel lire ?

Deux livres de cybersécurité sur Defensive, 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
4/52014
Incident Response and Computer Forensics

Jason T. Luttgens, Matthew Pepe, Kevin Mandia

Le playbook de travail de Luttgens, Pepe et Mandia pour mener un engagement IR d'entreprise : préparation pré-engagement, acquisition de preuves, forensique réseau et host, et la discipline de gestion de projet qui sépare une réponse contrôlée d'une panique.

À 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.
Incident responders junior à senior, leads SOC et CISO qui ont besoin de la référence cross-discipline canonique sur ce à quoi ressemble un vrai programme IR de bout en bout. Le plus fort comme primer structurel — le modèle de maturité implicite dans le livre est encore la baseline de fait du champ.

À é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 voulant le tradecraft actuel sur la réponse aux attaques d'identité (AAD, abus OAuth, golden SAML), l'IR cloud spécifiquement, ou la traque moderne pilotée EDR ; le livre est largement on-prem 2014. À coupler avec des ressources cloud-IR spécifiques (blog Mandiant, runbooks AWS / Azure incident response) pour la couche manquante.

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.
  • La préparation est l'engagement : la majeure partie de ce qui détermine l'issue d'une IR est décidée avant que l'appel n'arrive.
  • La discipline acquérir-puis-analyser tient encore ; couper ce coin est ce qui produit les rétrospectives à mauvais titre.
  • Les chapitres gestion de projet du livre sont la moitié sous-estimée — la plupart des réponses ratées sont des échecs de management, pas techniques.

Comment ils se comparent

Nous notons Designing Secure Software plus haut (5/5 contre 4/5 pour Incident Response and Computer Forensics). Pour la plupart des lecteurs, Designing Secure Software est le choix principal et Incident Response and Computer Forensics un complément utile.

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 Incident Response and Computer Forensics couvrent tous les deux Defensive : les lire dans l'ordre renforce les mêmes notions sous des angles différents.

Continuer la lecture

Thématiques liées