It's been a long time (5 years?) since I encountered this last. Despite the idea making total sense to me, I am no clearer than I was then on how to actually do this in any org I have been a part of or managed. Where does this work? How did you do it? Does it work?
I've worked on both sides and I really think it comes down to Dunbar's number [1] and thus the size of the company.
At a sufficiently small company, you can just trust people will generally do the right thing. I ask X to accomplish some compliance goal, I just trust that they'll do it right.
As the company scales, you actually know a smaller and smaller portion of the people you work with. You no longer just trust that they'll do the right thing, because you don't know them. You fix the lack of trust by adding processes that ensure the "right thing" happens, but each of those processes is a friction point. Eventually you have so many of those processes that they become the majority of the effort for a project.
That gets exacerbated by the usual turnover. People pissed off by all the processes they have to comply with will leave, and people who love having their own fiefdom will stay and double down.
That all ends in the evergreen stupidity of "spend $1,800 to have 12 people who make $150/hr argue about whether this app really needs a $5/month Aurora database".
That's a personal pet peeve, but is emblematic of the issue imo. Trust has broken down so severely that the company is willing to spend more than the lifetime cost of compute for the app to vet whether it's "necessary".
A similar vein is the "platform team" where all they do is take an open source project and wrap it in a custom DSL, so you get all the complexity and none of the searchability of the original project, plus the features are almost always a subset. I can't tell you how many times I've looked for solutions to a problem, found a snippet that will fix it, and then had to reverse engineer how to make a stupid DSL output that config.
Simple but true. I think some famous people said something about this. I think true from every vantage point. I think this is also very compatible with the parent post. Some leadership are not very good at creating good incentives. Actually, I've never been in leadership but I suspect it's also just really hard and there's potentially external factors that obviate even the best incentives.
I did some work at a large saas company where HSM as a big part of what we did. In the early days, we paid for full HSMs that we managed and eventually had to make a decision on whether or not we would used managed HSM and HSM-like services like KMS across various cloud providers.
We did an analysis across all the HSM hardware vendors and found, unsurprisingly in hindsight, that all of these hardware vendors had all the same awful security practices as every other enterprise hardware vendor, and each had vulnerabilities that leaked private key material.
The conclusion was that cloud providers fronting managed HSM had more to lose than the hardware vendors did, and would be more likely to patch and address these kinds of issues.
What surprised me was my own reaction, I thought for sure managing our own HSM hardware had to be a better guarantee over the key material, but like many things, it turned out to be unscalable security theater.
reply