Cyber Shelf

// Comparaison

Designing Secure Software vs Practical Linux 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/52021
Practical Linux Forensics

A Guide for Digital Investigators

Bruce Nikkel

La référence de Bruce Nikkel pour les analystes forensiques travaillant en post-mortem sur des images Linux : systèmes de fichiers, journalisation, logs, emplacements de persistance et la discipline chain of custody autour.

À 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 et analystes forensiques travaillant sur des systèmes Linux modernes. Nikkel couvre les internals ext4 / XFS / Btrfs, la journalisation systemd, les emplacements de persistance et la discipline chain-of-custody qui distingue la preuve des notes. La référence post-systemd dont le champ avait besoin.

À é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.
Analystes forensiques Windows-only, ou débutants sans expérience IR. Le livre suppose la fluidité système de fichiers et le confort en ligne de commande forensique.

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 forensique Linux moderne n'est pas juste « parser syslog » ; systemd, journald et le passage aux conteneurs basés overlay ont chacun créé de nouvelles classes d'artefacts.
  • Le chapitre sur l'énumération de persistance est le plus net en imprimé ; cron, timers systemd, init.d, profile files, tous nommés.
  • La plupart des charges cloud sont Linux, ce qui signifie que la majeure partie de la forensique d'incident cloud est de la forensique Linux ; le livre est la bonne référence de départ.

Comment ils se comparent

Nous notons Designing Secure Software plus haut (5/5 contre 4/5 pour Practical Linux Forensics). Pour la plupart des lecteurs, Designing Secure Software est le choix principal et Practical Linux 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 Practical Linux Forensics 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

Practical Linux Forensics

→ Alternatives à Practical Linux Forensics→ Que lire après Practical Linux Forensics

Thématiques liées

Defensive