Writing workable infosec policies
Writing in Computerworld, author Jennifer Bayuk offers some innovative suggestions on how best to write information security policies that are effective and workable in practice. I particularly like the way she emphasizes taking time to canvas management on their perspectives on the value and hence need to protect their information assets, drawing out management's control objectives as a prelude to drafting the actual policy statements. She's talking about an implicit risk assessment approach, I guess: I have successfully used risk workshops and so forth to achieve essentially the same ends, namely explicit management understanding and support for information security. It works.
Jennifer mentions the use of standards such as ISO27k, COBIT and the ISF Standard of Good Practice, all of which I would agree form a sound basis for developing reasonably comprehensive policy sets - in fact, it could be argued that organizations should perhaps use a synthesis of all three, plus relevant NIST SP800 standards and all applicable legal or regulatory or contractual compliance/security obligations and relevant strategic goals in relation to protecting information assets ... except that such an approach would soon get completely out of hand in practice. The true art of policy writing is to say all that needs to be said, no more, no less, clearly and in a manner that motivates the audiences to comply. Yes, audiences, for there are several.
I would however take exception to Jennifer's comment that "these documents [meaning the security standards] are inherently generic and do not state specific management objectives for security". ISO/IEC 27002 is generic, granted, but it comes remarkably close to laying out a suite of management-level security objectives (called "control objectives" in the standard) that would apply to virtually any organization. Several other standards take a similar line, and most in fact start from the position "First, managers, examine your risks and determine your information security priorities ...". The guidance they go on to offer is not meant to be prescriptive, rather it is like an a la carte menu of popular controls that, by implication, represent generally accepted good practice.
Our very own information security policy manual is based around the structure and guidance from ISO/IEC 27002. Although the whole manual is over 100 pages long, it incorporates a set of 39 management-level "security axioms" derived from 27002's 39 control objectives and threaded throughout the manual, plus a selection of 7 even higher level security principles. The axioms and principles are repeated in an appendix of just under three pages that should not be too much of a burden for management, even ADHD senior management, to consider and hopefully approve or mandate. The remaining 100-odd pages then lay out the mid-level details which are primarily aimed at information security practitioners and direcly correspond to those control objectives approved by management. There is a coherence to this design that I commend to others and I must say our policy manual is selling very well, thank you, so I submit that's the real proof of the pudding.
Finally, Ms Bayuk says next to nothing about the hardest part of security policies, which is not in fact writing them or getting them approved: it's implementing them and gaining compliance in real organizations, facing real day-to-day crises and strategic challenges, with employees and third parties who generally "have better things to do than worry about security" and would love to point the finger at Someone Else. Management simply laying down the rules is not in itself sufficient, even if (in our policy manual anyway), the CEO has a paragraph right at the start saying, basically, "This is important, do it or else". Security awareness activities provide the oil to slip the policies quietly into place. Awareness combines information provision ("This is what the policies say") with pragmatic guidance (procedures, guidelines etc.) but most of all it motivates people to do something different. Believe me, there are far more subtle forms of motivation than "Do this or else", for example finding creative angles on security topics pointing out that it is generally in employees' own best interests to behave securely. The rather negative comply-or-die-punk approach may work for some people some of the time, but on the whole, do-this-to-help-yourself-and-the-organization is a far more positive approach and an easier sell. Both types of message delivery are needed as they complement, between them pretty much covering the lot.
We have just updated our policy manual to reflect the release of ISO/IEC 27000 and continue to incorporate our understanding of good security practices at every opportunity. Even our generic policy template is very much a living document, not least because in security, someone keeps on moving the bloody goalposts!
PS Sorry for lack of blogging lately, I've just not been in a creative mood following the death of my father. They say bereavement affects people in different ways and now I think I understand what they mean.
Jennifer mentions the use of standards such as ISO27k, COBIT and the ISF Standard of Good Practice, all of which I would agree form a sound basis for developing reasonably comprehensive policy sets - in fact, it could be argued that organizations should perhaps use a synthesis of all three, plus relevant NIST SP800 standards and all applicable legal or regulatory or contractual compliance/security obligations and relevant strategic goals in relation to protecting information assets ... except that such an approach would soon get completely out of hand in practice. The true art of policy writing is to say all that needs to be said, no more, no less, clearly and in a manner that motivates the audiences to comply. Yes, audiences, for there are several.
I would however take exception to Jennifer's comment that "these documents [meaning the security standards] are inherently generic and do not state specific management objectives for security". ISO/IEC 27002 is generic, granted, but it comes remarkably close to laying out a suite of management-level security objectives (called "control objectives" in the standard) that would apply to virtually any organization. Several other standards take a similar line, and most in fact start from the position "First, managers, examine your risks and determine your information security priorities ...". The guidance they go on to offer is not meant to be prescriptive, rather it is like an a la carte menu of popular controls that, by implication, represent generally accepted good practice.
Our very own information security policy manual is based around the structure and guidance from ISO/IEC 27002. Although the whole manual is over 100 pages long, it incorporates a set of 39 management-level "security axioms" derived from 27002's 39 control objectives and threaded throughout the manual, plus a selection of 7 even higher level security principles. The axioms and principles are repeated in an appendix of just under three pages that should not be too much of a burden for management, even ADHD senior management, to consider and hopefully approve or mandate. The remaining 100-odd pages then lay out the mid-level details which are primarily aimed at information security practitioners and direcly correspond to those control objectives approved by management. There is a coherence to this design that I commend to others and I must say our policy manual is selling very well, thank you, so I submit that's the real proof of the pudding.
Finally, Ms Bayuk says next to nothing about the hardest part of security policies, which is not in fact writing them or getting them approved: it's implementing them and gaining compliance in real organizations, facing real day-to-day crises and strategic challenges, with employees and third parties who generally "have better things to do than worry about security" and would love to point the finger at Someone Else. Management simply laying down the rules is not in itself sufficient, even if (in our policy manual anyway), the CEO has a paragraph right at the start saying, basically, "This is important, do it or else". Security awareness activities provide the oil to slip the policies quietly into place. Awareness combines information provision ("This is what the policies say") with pragmatic guidance (procedures, guidelines etc.) but most of all it motivates people to do something different. Believe me, there are far more subtle forms of motivation than "Do this or else", for example finding creative angles on security topics pointing out that it is generally in employees' own best interests to behave securely. The rather negative comply-or-die-punk approach may work for some people some of the time, but on the whole, do-this-to-help-yourself-and-the-organization is a far more positive approach and an easier sell. Both types of message delivery are needed as they complement, between them pretty much covering the lot.
We have just updated our policy manual to reflect the release of ISO/IEC 27000 and continue to incorporate our understanding of good security practices at every opportunity. Even our generic policy template is very much a living document, not least because in security, someone keeps on moving the bloody goalposts!
PS Sorry for lack of blogging lately, I've just not been in a creative mood following the death of my father. They say bereavement affects people in different ways and now I think I understand what they mean.
Labels: Awareness, Governance
Links to this post:
