Can a system be considered truly reliable if it isn't fundamentally secure? Or can it be considered secure if it's unreliable? Security is crucial to the design and operation of scalable systems in production, as it plays an important part in product quality, performance, and availability. In this book, experts from Google share best practices to help your organization design scalable and reliable systems that are fundamentally secure.
Two previous O'Reilly books from Google--Site Reliability Engineering and The Site Reliability Workbook--demonstrated how and why a commitment to the entire service lifecycle enables organizations to successfully build, deploy, monitor, and maintain software systems. In this latest guide, the authors offer insights into system design, implementation, and maintenance from practitioners who specialize in security and reliability. They also discuss how building and adopting their recommended best practices requires a culture that is supportive of such change.
You'll learn about secure and reliable systems through:
Design strategies Recommendations for coding, testing, and debugging practices Strategies to prepare for, respond to, and recover from incidents Cultural best practices that help teams across your organization collaborate effectively
As long as you understand what this book is, it's a good book. Everyone should read the first 3 chapters and after that you should read what's relevant to you. If you read this cover to cover you're going to be bored and a lot of it is going to fly over your head, even just reading what was relevant to me, much of it was over my head.
If you have a DevSecOps role you need to read this. It is one of the three sre.google/books and whether you have SRE in your title or not doesn’t matter. Not many companies have the resources to Tink or DiRT, nor can say TLS is too heavy let’s do ALTS, or develop and build their own public CA. Seeing all that done, you will have to tolerate long boring reads and cringy terms like progressive stringency. There are quite a few case studies, lessons learned, and well-thought-tested practices here. Actually five stars is for the great content not for the reading experience. Each chapter is written by multiple different authors so they are very uneven and not edited well but only loosely coupled in five parts. Being independent of each other makes it easy to pick and choose. You may still have to skim thru parts of the other two SRE books as thee are many cross references.
This book is an excellent framework for reviewing the best ways to organize your software engineering teams around having impactful systems that can be released quickly, reliably and securely. The overall theme of the book is that reliability and security are interlinked in ways that make it easier to have productive conversations between security and product teams: when a security goal is presented as a reliability goal, the product team is more receptive and the conversation more productive. And, most importantly, it's true.
This book is organized like some of the great industry tomes: each chapter is a case-study in a specific area of interest; it can be used for the reader's specific topics of interest, in any order.
I used this book to train a new team that I formed of security and privacy newbies. We read two chapters every two weeks and worked our way through the book, meeting for an hour to discuss its themes and how those applied to our security team work (reviews, etc.). It was the best training resource that I could find.
Solid reference book for the generalist SecEng (or anyone in a security/security-adjacent role). Definitely feel like echoing others' sentiments on it being partly a publicity flyer for Big G's projects, but hey, you write a book, you call the shots. Not too heavy on technical material, but a gold mine for ideas around process.
The SRE book series welcomes a long-awaited guest to the party.
Google fills a gap in its SRE book series by integrating security into the reliability equation. As a reliable system is only useful as long as its security is guaranteed, if you have read the SRE book(s), you should definitely read this one too. But I admit I didn’t like it as much as its predecessors.
The format is similar to other Google’s SRE books (we can also cite Software Engineering at Google). We retrieve a clear separation between principles and practices. The book contributors capture how security is managed at Google but present solutions in a way that makes it possible to adapt to your infrastructure, context, and culture. But the devil is in the details.
The first problem is that by trying to abstract principles in the second part, I found chapters suffer from a lack of clarity, which impedes comprehension. That’s bad. The subjects covered by those chapters are important and you will find valuable insights, but their development is too long, too verbose. Even if there are more practical sections later in the book to illustrate these principles, I don’t think it’s acceptable to depend on later chapters to clarify the meaning. I consider it would not be a problem to put more explanations about how it works at Google even in the most abstract chapters. It will not make the book less widely applicable, quite the contrary.
The second problem concerns the scope that is probably too large. The book is massive with almost 600 pages but I think editors must have had a hard time deciding what to include, and what to leave out. They decided to focus on building secure applications. You will not find much information about network or physical security in this book. But nevertheless, it’s still too much for a single book when you have so much to bring to the table as Google has.
Don't get me wrong. This book is a great addition in the software literature. It contains many valuable lessons. I appreciate how the book draws the parallel between security and reliability, two disciplines that don't have to be treated separately. It’s just that I found this book not as great as previous Google's books.
Tons of great content. Was more focused on security than I expected, but it turned out to be useful. I was particularly surprised by how many methods that help with reliability also help with security and vice versa. I found the last chapter on culture a good read, and I'll take the analogy of horses vs zebras with me.
Great collection of tools and case studies, I added it to my handbook collection, and am recommending it a lot
This is O'Reilly published book, so editors should know better then to allow such a fluctuating level of detail and context. Why is the person telling the ancient greek Troyan Horse story, in detail, on few pages, in the middle of the SRE...
Крутая книга, как и прошлые две. Как и раньше, используемые практики, в основном, применимы для достаточно больших компаний. В общем, отличный пример "как надо". Читаешь и грустишь.
Excellent book combining security & reliability, definitely a must read for any SRE or security engineer. Some chapters are long theoretical ones, others are very practical, but they are all super relatable in terms of what they cover. It was a pure joy to read this book and learn more about DevSecOps.
A collection of chapters each co-written by a handful of authors, Building Secure and Reliable Systems (SRS) motivates with industry examples from Google and other large tech firms the push for integrated security and reliability practices within engineering teams. The first four sections of the book cover best practices, while the last section lays out a roadmap for transitioning an engineering team to a state where it can utilize best practices.
SRS appears to be aimed at senior-level managers of established and growing tech firms with the sway to push for cultural and organizational changes, which is not me. Even so, while each chapter in itself is well-structured and mostly self-contained, I cannot help but wonder if such large changes within firms truly happen without hitches from beginning to end, or if the book could be better structured to support this process by providing readers a framework to diagnose, focus, and correct the most relevant security and reliability issues with the limited time and flexibility of any technical team.
I have been revisiting these books; it is a year later, and my perspective has changed somewhat, and I haven't really understood clearly. There is a lot of information, I may have missed out on, due to some hacking. The question of what constitutes, modern enterprise software, has great interest to me. It is something I am exploring. However, being a neephyte, in this particular area, it is unclear, on some level, and some levels not, whether current practice is sound.