> This can either mean one of a few things: These environments don’t exist at all, there aren’t many of them, or they don’t see incidents that would warrant involving IR folks like myself.
What are these secrets store? Do they exist?
> This can either mean one of a few things: These environments don’t exist at all, there aren’t many of them, or they don’t see incidents that would warrant involving IR folks like myself.
What are these secrets store? Do they exist?
Sometimes, it's as simple as a shared password store (I've used one powered by GPG, for example). This is better than YOLO password policy, but not by much: humans still see individual keys.
If you want to be really fancy, you authenticate the human and then decide what they get to do, in a centralized fashion. This is often tricky to do, because you either don't have the funds to do that if you're small, or you have too many services to interact with if you're big. (Many organizations get pretty close -- I'm told that the DoD pretty much authenticates everything with smart cards, for example.)
Sometimes, it means a more automated system where software authenticates instead of a human, and it gets e.g. a certificate. Usually this is still always the same certificate, though; so the main difference is that it's a human versus a machine authenticating.
Sometimes, it means an HSM (hardware security module). These are secure physical devices that perform cryptographic operations for you, so that the key stays on the device.
I fail to see how it is secured. (Though, I can understand that it is less bad than a YOLO policy).
> Many organizations get pretty close -- I'm told that the DoD pretty much authenticates everything with smart cards, for example.
I've been at a place with RSA SecurID (smart card and OTP) + active directory account as SSO authentication for everything (use one or both for 2FA). It was nice and well done.
- It knows how to encrypt and store secrets securely. Having one specialized application have an opinion on how to do that is much better than having a hundred ones that do it incidentally. The central one will be audited and monitored. The hundreds will invariably mess it up.
- It tracks who accessed a secret and when. This is critical information for remediation and ongoing scope reduction. Knowing who accessed what, when gives you the context for why; all three tell you how to further reduce the authority that application has.
- It can generate "minimal" credentials on-demand. I.e. a new key that only lets you access what you need and for a limited amount of time.
- It can encrypt things on behalf of the requester, such that the requester never sees the key. That is good, because it can be one-way. It is also good because if a service is compromised, the compromise may be detected and remediated (access revoked) before all data is dumped and compromised. Having the secret store lets you do e.g. rate limiting and centralized monitoring, for example.
- Secret stores can know how secrets are linked; making it easier to do revocation, and easier to determine the impact of a breach or misuse incident.