One of the most dreaded terms in the world of information technology and security (IT/IS) is “documentation”. Not because it isn’t massively helpful to everyone, or really for any reason other than it is difficult and fairly time-consuming to make in the first place. But, a secret your IT staff doesn’t want you to know is just how much thorough documentation can improve almost all aspects of IT/IS. The list of things that can be optimized by thorough documentation includes such critical items as improved security, saved time, easier training, simpler cross-job backups, and many other things.
A Pen Testing Team Showed Me the Light
I haven’t been able to write a new blog post in almost three months, because towards the end of 2018 I was presented with the opportunity to work with our penetration testing delivery team to improve our processes, resource allocation, and toolset for our growing service. While this has been a big project, it has also been quite rewarding and a great learning experience. Not to mention that I was able to do some actual pen testing on live systems again and that is just plain fun.
The biggest “issue” I found was that the various pen testers on our team were each doing things just a little bit differently. They were getting the same results, and the final reports I was reviewing were all coming to the consistent conclusions. So, there wasn’t an issue with consistency and no problem with thorough assessments. But, the reason to standardize things became glaringly obvious to me about two weeks in. If I assigned the work “piecemeal” (which is the most effective way to take advantage of the pen tester’s various strengths), it led to time being lost with each assessment while the new tester reformatted the data to the format they were used to.
How Does This Apply to Non-Pen Testers?
Obviously, not many of you are managing or streamlining a pen testing team, but you are likely managing a team that is securing and maintaining your organization’s critical systems. If your team members are all doing things a little bit differently, then they are probably wasting valuable time they could devote to improving security instead of reacting to things as they occur. In order for documentation to be effective, executive-approved policies and a solid set of standards need to be in place.
First, it is crucial that there are organizational policies that are overarching guidance on various critical security matters (like passwords, email, and encryption). Just under these policies there sits a larger set of documents called standards. Standards are more specific to the environment and how the network should be configured and secured, how devices should be set up and secured, as well as various people-related standards. With these in place your staff is most likely already achieving the requirements of the policies and standards. What is often missing is the procedural documents.
Procedural documents are the step-by-step instructions for the staff to follow. These documents can be changed without as much approval as policies take and can be more specific than either policies or standards. These are essentially “living documents” and don’t force the staff into a box, but if they want to do it another way a new standard should be written or the old one updated.
The above are just a few suggestions as to how a healthy IT/IS documentation program should look. But this is a very complex topic about which there are many books and articles if you want to dive deeper into this topic (I recommend the SANS Institute as a good starting point). But, before you go trying to fix anything make sure you have first gotten a full understanding of what exists in your organization in regards to documentation. Which documents are old and need updating? Which ones are missing? If you have answers to these questions, then you can move forward to make the program better.