I recently finished reading Secure by Design by Dan Bergh Johnsson, Daniel Deogun, and Daniel Sawano. I started reading it shortly after I received it as a gift from Dan Bergh Johnsson at Jfokus 2020.
Secure by Design hooked me from the beginning. Chapter 1 dives right in and shows why design matters for security and how security shouldn't be an afterthought. The authors show how developers will have a difficult time grokking security if you make them remember security-related API calls. However, if you bake security into your design and codify your security practices, developers will be more secure by default.
I liked their Java example with domain primitives so much that I used it in my Security Patterns for Microservice Architectures blog post.
Chapter 1 ends with encouragement to view security as a concern to be met rather than a set of features. Design is the guiding principle for how a system is built and is applicable on all levels, from code to architecture. Well-known security threats should drive design decisions in security architectures.
One thing I appreciate about this book is they summarized each chapter's main points at the end. Writing reviews like this one are much easier with summaries. 👍
In Part 2, there's enough domain-driven design to make you knowledgeable, but not dangerous. In Chapter 4, they cover code constructs that promote security, like immutability and validation. Domain primitives are the smallest building blocks of a secure architecture. They can contain many checks above and beyond validation that will keep your developers cranking out secure code. The next two chapters discuss maintaining the integrity of the state and reducing state complexity.
Yeah, there's a lot to digest in this book. I read it over a few months.
Chapter 8 gets into leveraging your delivery pipeline for security and testing. I love that all the code examples in this section used JUnit 5 and were up-to-date with current Java testing practices. I felt like the book was just released last week!
Chapter 9 is an excellent tour of how exceptions can be used in your architecture to indicate failures. Or better yet, design for availability with resilience, responsiveness, and graceful failure handling. The availability of your data and system should be an important security goal and is part of the CIA acronym (confidentiality, integrity, and availability).
Chapter 10 gets into cloud-native thinking and the twelve-factor app. Once you have your apps running with twelve-factor concepts, you can adopt the three R's of enterprise security: Rotate, Repave, and Repair. In short, having an architecture where everything runs in the cloud allows you to take security to the next level, and:
- Rotate secrets every few minutes or hours.
- Repave servers and applications every few hours.
- Repair vulnerable software as soon as possible (within a few hours), and a patch is available.
Part 3 is all about applying what you learned. How do you adopt domain primitives with legacy code? The authors suggest a few different options. Chapter 13 is all about microservices. I found it especially interesting to learn how logs can leak sensitive data and how logging data can be used after-the-fact to be a 2nd-level attack. The final chapter suggests guidelines for security in code reviews, challenging your design with penetration tests, and making security a source of inspiration.
Recommendation: A Strong Buy
I give Secure by Design 5 stars! ⭐️⭐️⭐️⭐️⭐️
I learned a lot of new information about designing secure systems and look forward to using this knowledge in my projects. Cheers to the book's authors: Dan, Daniel, and Daniel. I think you created an excellent security reference book that will help many developers and companies be more secure by design.