Right, so I decided to just read the chapter to better understand what Max means. He's right in the way that in both depth and breadth of measures, (but I'd argue mostly depth, that's also what the "3 vpns" comment is about) there must be an end to your scope or you will just make it impossible to do anything and you'll mess up. On top, security goes principally at the cost of functionality, so he is also right that the further you drive it the more complex and the less functional your operational environment becomes.
What I'd push back against: I think that the diminishing returns do not apply to precision, but only to the extent of the scope, and most significantly to depth and much less to breadth: if you need to secure something there are easy(ish) to define limits to what and whom is in-scope. That scope is often fairly static if it is well reasoned. Then you make informed decisions and you test everything you want to do before you do it against that scope. If you mess up, and leak something critical once, you need to reset, because you cannot unleak. And resets are disruptive, expensive events. So you want to prevent that. The biggest mistake is taking that leak as residual risk inside the must-secure scope and letting it sit.
Right, so I decided to just read the chapter to better understand what Max means. He's right in the way that in both depth and breadth of measures, (but I'd argue mostly depth, that's also what the "3 vpns" comment is about) there must be an end to your scope or you will just make it impossible to do anything and you'll mess up. On top, security goes principally at the cost of functionality, so he is also right that the further you drive it the more complex and the less functional your operational environment becomes.
What I'd push back against: I think that the diminishing returns do not apply to precision, but only to the extent of the scope, and most significantly to depth and much less to breadth: if you need to secure something there are easy(ish) to define limits to what and whom is in-scope. That scope is often fairly static if it is well reasoned. Then you make informed decisions and you test everything you want to do before you do it against that scope. If you mess up, and leak something critical once, you need to reset, because you cannot unleak. And resets are disruptive, expensive events. So you want to prevent that. The biggest mistake is taking that leak as residual risk inside the must-secure scope and letting it sit.
Data is fluid.