One of my first tasks after leaving 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 "must's" or "shall's" 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 they are 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 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.
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. It 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 what 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.
About the Author: For over 20 years, Dale Peterson has been on the leading/bleeding edge helping security conscious asset owners effectively and efficiently manage risk to their critical assets. He has pioneered numerous ICS security tools and techniques such as the first intrusion detection signatures for ICS that are now in every commercial product. In 2007, Dale created the S4 Events to showcase the best offensive and defensive work in ICS security and to build a community. S4 is now the largest and most advanced ICS event in the world. Dale is constantly pushing and prodding the ICS community to move faster and get better.
LinkedIn: https://www.linkedin.com/in/dale-peterson-s4/
Twitter: @digitalbond
Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.
