3

I'm assuming that it's a good idea to document your security protocols, response plans, and attack surfaces.

Of course, if you simply stick all of that information on GitHub (minus your secret of course), then it gives attackers a map of your system and the things that you're thinking about (and thus the things you may not have thought about).

Are there any kinds of recommendations or real-world experiences about sharing this information, or should we simply treat this information/document(s) as another attack surface (and potential target for attack)?

Wayne Werner
  • 1,755
  • 3
  • 15
  • 20
  • That's an odd combination of documents to lump together – schroeder Feb 01 '18 at 14:43
  • @schroeder Probably. I'm definitely a novice when it comes to security right now - I know it's important, and I know that there is a *lot* I don't know. But I've also seen some particularly bad examples - I don't want to be one of those. – Wayne Werner Feb 01 '18 at 14:45
  • I left an answer below but pretty much: do not give away what you don't have to. The system should not be built such that divulging information on it's design compromises it, but the less information an attacker knows, the better. – dFrancisco Feb 01 '18 at 15:07

1 Answers1

2

What you are looking for is the term "Operational Security" or "OpSec". You want to keep secret the details of what you will do, in any situation. These details give outside observers the ability to craft approaches and know how (and when) you will respond. The documents you outline are not to be classified as Public data.

The only people who should have access to this data are the ones with a legitimate "need-to-know". This basis forms all authorisations to access any data. The Public has no need to know. Many in your organisation have no need to know.

Only permit access to those who need the data in order to perform their jobs.

If you are looking for official recommendations about response plans, ISO 27035:2011 5.4.4 says:

It may also be important to keep some details of the information security incident management scheme closely held to prevent an insider from tampering with the investigation process. For example, if a bank employee who is embezzling funds is aware of some details of the scheme, he or she may be able to better hide their activities from investigators or otherwise hamper the detection, investigation of and recovery from an information security incident.

schroeder
  • 123,438
  • 55
  • 284
  • 319