What your document control policy tells me about you

FedRAMP 20x requires every certified provider to operate a Trust Center. That isn’t just a catchy title kids, that is an indication of what the requirement is about. Trust.

I have had a lot of conversations over the last few months with providers who want to know what information they HAVE to make public. I think in most cases this is just learned behavior, but it seems to me to be the wrong question. What you should be asking is what information you CANNOT make public.

An organization that can responsibly disclose information about system architecture, components, processes, etc. is one that I am more likely to trust because they trust themselves. They have faith in their security. When thinking about system security, the best practice is to always assume your adversary will know MORE than you. Yes, it is possible that any information about your system or internal processes could be used as part of an attack. But that remains equally true regardless of how much or little information we make public. Just because you are treating something as secret or confidential doesn’t mean your adversary doesn’t know it. Systems designed with defense in depth should be able to withstand a partial compromise, detect the attack, and then close the vulnerability.

Any piece of security information that a provider feels the need to control, gate, or obscure should be treated as a vulnerability in itself. The provider’s energy should not be spent on restricting access to the documentation, but rather on mitigating the risk of exposure so that the information can be safely moved into the public view. True security is built on robust defenses and transparency, not on the hope that attackers won’t find the map. Openness fosters scrutiny, which ultimately strengthens the defenses.

Real quick before you start responding asking if I think we should post all our private keys and credentials openly, no I don’t mean that. There is a distinction here between true secrets like identity tokens and system documentation or even source code. Of course, we should do everything possible to protect our secrets, including tightly limiting access to those secrets. However, I do still think that the fact that the secret could be used to compromise the system should be tracked as a vulnerability and mitigated rather than just accepted as the normal cost of doing business. I have seen systems designed in such a way that no one ever actually sees the secret. It’s not usually worth it, but it is worth considering if it is worth it.