Cyber Shelf

// Comparaison

Designing Secure Software vs Security Chaos Engineering : 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.

Avancé
5/52023
Security Chaos Engineering

Sustaining Resilience in Software and Systems

Kelly Shortridge, Aaron Rinehart

Kelly Shortridge et Aaron Rinehart traitent la sécurité comme une propriété de systèmes adaptatifs complexes : au lieu de prévenir la défaillance, on la simule en continu et on conçoit l'organisation pour apprendre de chaque résultat.

À 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.
Architectes sécurité, SRE et ingénieurs plateforme prêts à abandonner le cadre prévention-d'abord. Particulièrement fort pour les organisations qui pratiquent déjà le chaos engineering pour la fiabilité et veulent étendre la discipline à la sécurité ; le livre est le pont.

À é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.
Praticiens en environnements fortement régulés où les fautes intentionnelles en production ne sont pas légales, ou organisations plus petites sans la maturité opérationnelle pour mener des game days en sécurité. Mauvais premier livre de sécurité aussi : il suppose que vous savez ce que sont threat models, blast radius et boucles de rétroaction.

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.
  • Sécurité et fiabilité partagent le même problème d'ingénierie racine : maintenir des systèmes complexes dans des bornes tolérables quand la surface de défaillance est non bornée.
  • Decision trees et analyse effort-vs-impact sont des artefacts opérationnalisables, pas du contenu de blog ; le livre apprend à vraiment s'en servir.
  • L'expérimentation continue est plus honnête que les exercices sur table : la production dit ce qui est vrai, les runbooks disent ce que quelqu'un aurait souhaité.

Comment ils se comparent

Designing Secure Software et Security Chaos Engineering 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.

Designing Secure Software vise le niveau intermédiaire. Security Chaos Engineering vise le niveau avancé. Lisez le plus accessible d'abord si la thématique ne vous est pas familière.

Designing Secure Software et Security Chaos Engineering couvrent tous les deux Defensive : 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

Security Chaos Engineering

→ Alternatives à Security Chaos Engineering→ Que lire après Security Chaos Engineering

Thématiques liées

Defensive