In the 5-day SANS Institute course called "Legal 523," Law of Data Security and Investigations, I teach these general tips for how to write infosec policy for an organization. These tips are equally applicable to responding to a cyber security questionnaire from a regulator, a cyber insurer or a corporate customer.
1. The organization is wise to have some kind of written Risk Assessment. For a less-complex organization, the Risk Assessment need not be very long, but a Risk Assessment shows the organization is evaluating infosec risk (such as risk of breach of credit card data) and setting priorities based on that risk.
2. The organization is wise to identify a high officer as having responsibility for overseeing privacy and data security.
3. As I explain in the course, I like this statement as an accurate, overarching rule of infosec policy: "Company strives to maintain a reasonable, continuous process for implementing, reviewing, improving and documenting security and privacy in information technology. This process places more emphasis on the never-ending professional efforts of Company's IT staff than on paperwork, recognizing perfection is impossible." I like making clear in all policies that the quoted language is the ultimate policy, and everything else is subordinate to that quoted language.
4. As I teach in the course, I am wary of any statements of absolute in policy. When an organization says that the organization "will" or "must" or "shall" do anything in IT, the organization is setting itself up for potential failure. No organization can always do any particular IT thing. Therefore, I prefer using words like "the organization strives …" or "the organization aspires …". And of course, if an organization says that it strives or aspires to do some thing, then the organization should in fact work hard to do that thing.
5. An organization can responsibly require staff to do certain things (assuming those things are in fact achievable). For instance, an organization can require staff to maintain passwords that meet certain characteristics. (Example: "Each staff member must have a password for that is no shorter than 12 characters.")
6. In my experience, the bigger problem is not whether an organization fails to cover particular topic X or topic Y in written policy. Instead, the problem is that the organization writes too many policies, which are too long, too hard to read, and too prescriptive and are disconnected from the reality of the fluid, dynamic challenges of modern infosec. The best standard is nimble, never-ending "professional attention" by the infosec team rather than satisfaction of a checklist covering particular topics (firewall, anti-virus, intrusion detection etc.).
7. Published "privacy policies" need to be carefully written so as not to promise privacy or security that is unrealistic.
The foregoing ideas are applicable generically. An organization subject to particular laws or threats may need to behave differently.
I welcome comments. I know some smart people will disagree with me on some of the ideas above.
-Benjamin Wright
1. The organization is wise to have some kind of written Risk Assessment. For a less-complex organization, the Risk Assessment need not be very long, but a Risk Assessment shows the organization is evaluating infosec risk (such as risk of breach of credit card data) and setting priorities based on that risk.
3. As I explain in the course, I like this statement as an accurate, overarching rule of infosec policy: "Company strives to maintain a reasonable, continuous process for implementing, reviewing, improving and documenting security and privacy in information technology. This process places more emphasis on the never-ending professional efforts of Company's IT staff than on paperwork, recognizing perfection is impossible." I like making clear in all policies that the quoted language is the ultimate policy, and everything else is subordinate to that quoted language.
4. As I teach in the course, I am wary of any statements of absolute in policy. When an organization says that the organization "will" or "must" or "shall" do anything in IT, the organization is setting itself up for potential failure. No organization can always do any particular IT thing. Therefore, I prefer using words like "the organization strives …" or "the organization aspires …". And of course, if an organization says that it strives or aspires to do some thing, then the organization should in fact work hard to do that thing.
5. An organization can responsibly require staff to do certain things (assuming those things are in fact achievable). For instance, an organization can require staff to maintain passwords that meet certain characteristics. (Example: "Each staff member must have a password for that is no shorter than 12 characters.")
6. In my experience, the bigger problem is not whether an organization fails to cover particular topic X or topic Y in written policy. Instead, the problem is that the organization writes too many policies, which are too long, too hard to read, and too prescriptive and are disconnected from the reality of the fluid, dynamic challenges of modern infosec. The best standard is nimble, never-ending "professional attention" by the infosec team rather than satisfaction of a checklist covering particular topics (firewall, anti-virus, intrusion detection etc.).
7. Published "privacy policies" need to be carefully written so as not to promise privacy or security that is unrealistic.
The foregoing ideas are applicable generically. An organization subject to particular laws or threats may need to behave differently.
I welcome comments. I know some smart people will disagree with me on some of the ideas above.
-Benjamin Wright
No comments:
Post a Comment