One of my first tasks after leaving the National Security Administration (NSA) for private industry in the early ’90s was to write my new company’s information security policy. I’m not sure my previous job as a cryptanalyst left me qualified for this, but I was viewed as the security guy. So I attacked the task with vim and vigor.
That first information security policy I wrote was a thing of beauty. I scoured the Orange Book and other resources to find every security requirement that might help us prevent a security incident. I picked the most rigorous option for every security control. There was no way we were going to get hacked. Not on my watch.
The policy came in at just under 100 pages. It was completely unusable. It was completely ignored.
I’ve learned a lot about effective security governance documents since that early fail. One of the unexpected, and quite frankly most effective, lessons learned is developing the audit program in parallel with a security governance document. The actual audit has value, as well, but I believe the planning for the audit prior to policy approval is even more important.
Mandatory and auditable statements
You need to be clear about whether you are writing a mandatory policy or procedure or a helpful guideline document filled with recommendations. Mandatory security governance documents are filled with sentences that use “must” or “shall.” These are not optional good security practices that are encouraged or security controls to consider. They are firm requirements that carry consequences if they are not followed.
Security governance documents in which only some of the security requirements are considered real and enforced are unfair to all. How are the employees to know which “musts” or “shalls” are serious and which are only guidance? You risk losing the benefits of the whole policy if large portions are considered guidance rather than policy.
The key is to write a security audit test for every “must” or “shall” prior to releasing even the first full draft of the policy. There are multiple benefits to this approach:
1. You will identify security requirements that cannot be audited because it is unclear what is required. If they are unclear, it will be impossible for your people to do what you intended in the security requirement.
2. You will identify security requirements that will require a huge effort to meet. Writing the audit tests forces you to look at the practical ramifications and work necessary to meet the requirement. Typical discussions on this issue are, “Do we really expect our people to do this?” and “This is going to be a huge, ongoing investment in time and resources to meet this requirement. Is it worth it?”
Security professionals can fall into the trap of thinking every good practice should be implemented. After all, the name “good practice” or the increasingly popular “cyber hygiene” imply that not doing something is bad or dirty. Each security control is going to have an associated cost and risk reduction achieved. The audit document will help you understand this, and it may result in the easing or eliminating of some planned security controls.
3. You will identify security requirements that are difficult to audit. And conversely, you will find ways to write security requirements that are simple and automated to audit using products such as Tripwire. More on this later.
4. You will have the audit program ready on Day 1 when the policy is approved.
This last point is very different than what we see in most companies today. Internal or external audit will get tasked with a security audit, and part of their task is to figure out what to audit and how to audit. The success or failure of the audit is highly determined by the auditor’s decision on the audit program. This doesn’t serve the company, those being audited or the auditors well.
It should be clear to the audited and auditor what evidence will be required to pass each audit test as soon as the security policy is approved.
Cybersecurity audit tests
Audit tests can include interview, inspection, configuration file review, data analysis and other means. To the degree possible, using tools to generate audit data is a big plus. This reduces the time and cost of the audit. Perhaps even more important, it can provide ongoing metrics so that the security posture is something that is known and managed at all times rather than once a year after the annual audit.
The benefits of automating the generation of audit data and metrics is so great that you should consider which data sources you have during the writing of the security policy. Tripwire has compliance templates for multiple security standards such as NERC CIP. A similar approach could be taken to monitor compliance with your company’s security governance.
One last lesson from writing and auditing security governance documents: The first audit almost always goes poorly, and it should be viewed as a security awareness exercise more than an audit. The people responsible for the security requirements will then understand what is required, and it is likely that some of the security requirements will be modified. The second audit is when consequences for audit failures should begin, and progress towards compliance should be seen audit by audit.
Original content can be found at dale-peterson.com.
Do you have experience and expertise with the topics mentioned in this article? You should consider contributing content to our CFE Media editorial team and getting the recognition you and your company deserve. Click here to start this process.
