Julien Vehent wrote:
I think so many places don't think about the "responding to attacks" part of the equation very well.
This is true, and working in a DevOps environment means using very different tools and techniques that one would use in a old-style infrastructure. (endpoint security on immutable servers? what about serverless forensics? etc.)
At the same time, a lot of proven techniques can and should be ported to modern environments, so the book goes over the important stuff and explains how to implement it.
There's also a little novel about a security incident in chapter 10. I had fun writing, I hope it's a good read
Julien Vehent wrote:Securing DevOps is a technical book, so we talk about tools and techniques a lot! Part 1 is a complete implementation of a CI/CD pipeline and all the security components that we can fit into it. It's 100% hands on. Part 2 is also very technical but more focused on presenting tools and techniques and less on helping the reader implement them (you'll have to do homework). Part 3 is a little less focused on tool but we still present half a dozen of them in the chapter on security testing (ZAP, Scout2, bandit, gas, etc.).
So, yeah, we talk about tools a lot
2. Monitoring and responding to attacks. It is the fate of online services that they will get broken into eventually. When incidents happen, organizations will turn to their security teams for help, and a team must be prepared to react. The second phase of continuous security is to monitor and respond to threats, and protect the services and data the organization relies on, through techniques like fraud and intrusion detection, digital forensics and incident response, with the goal to increase the organization’s preparedness to an incident.
David Sachdev wrote:I have read the other threads that discuss differences between version 2 and version 3 of the book, and I have checked out the table of contents here:
Alex Theedom wrote:Hi David
Thanks for your question.
In the book, I demonstrate with plenty of code examples the new features added to Java EE 8. It includes two large chapters on the brand new security API and JSON Binding. There are some really cool new additions such as the Reactive client in JAX-RS and asyn events in CDI to name just a few. I touch on the spring framework, although version 5 does looks really interesting. When developing microservices you can develop some in Java EE, some in Spring other in GoLang or whatever best solves the problem. In terms of mixing them in one project, I suggest that there would have to be a very good reason for doing so. Perhaps some of the Spring APIs could be used with a Java EE project but making them work together might be more of a headache than its worth.
Richard Rodger wrote:Hey David,
So I’m a little radical when it comes to service discovery these days - I like to use SWIM https://asafdav2.github.io/2017/swim-protocol/
The weak point in any component model ( that’s what microservices are!) is identity. Component A has to know about component B to send B messages. A also has to know what messages B can accept.
Example: network location, rest URLs, message bus topics, kubernetes host env vars, ... all the same thing.
To remove the concept of identity, you want to be able to just send messages without knowing where to send them.
This is fundamentally impossible of course, but you can weaken identity significantly by using something like SWIM. Essentially each microservices builds its own internal, but hidden, routing table.