Far too many organizations treat the development or update of information security policies as yet another administrative...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
task that can be delegated to anyone who isn't especially busy. This is ill-advised as policies are increasingly considered legal contracts by the government and third parties. As a result, organizations are being held to the specific wording of their policies. A number of recent cases illustrate the importance of getting a wide variety of people within an organization to review the policies before they're published. These cases also indicate how important it is to establish up-front -- before policies are issued -- that the organization has both the management support and the management commitment necessary to follow through on requirements defined in the policies.
The problems at Guess came into the limelight when Jeremiah Jacks notified the firm that they were subject to a SQL injection attack. This type of attack allowed any third party to obtain names, credit card numbers and expiration dates in an unencrypted format. Not only was the company reportedly not adhering to its own policy, but Guess management reportedly ignored warnings about this vulnerability. Only when a reporter at SecurityFocus investigated the alleged weaknesses indicated by Jacks did Guess management start to make changes. An investigation by the Federal Trade Commission ensued, and Guess later agreed to a consent order that required them to attend to information security as they should have been doing all along. Meanwhile, Guess suffered significant adverse publicity and incurred unnecessary expenses.
Unless your organization wants to be the next precedent-setting case appearing in the press, be sure that:
All published policies are reviewed by a variety of legal, technical, management and public relations people before they are published.
Beyond making statements that are clearly not grounded in the technology, organizations publishing security and privacy policies should be on the lookout for black-and-white thinking. Perhaps the most common example is a policy that forbids personal use of organizational computing resources. Realistically, people will use computing systems to attend to personal matters like scheduling a baby sitter because they are required to work late. To forbid workers from using information systems in this manner only causes workers to ignore and lose respect for the policies. Having a variety of people review the wording of policies will ensure that they are both reasonable and sound.
Management has the will and commitment to follow through on the requirements defined in the policies before they are published.
As illustrated above, policies should not be at odds with the way workers actually interact with information systems. If there is a difference, then it's either time to initiate serious training and awareness efforts, or strike an agreement on how and when the involved workers or systems will move into compliance. If management isn't going to follow through and fix the disparity, then it's time to change the policy so that it's consistent with the real world.
All deviations from the policies are promptly discovered and reported through regular compliance-checking activities.
A surprising number of managers don't know if there is a variance between policies and what's happening in the organization. This is where compliance checking comes in. Compliance checking should be achieved with both manual and automated methods. Manual methods include so-called "desk checks," which involve an after hours sweep through the office, looking for passwords written down and posted in conspicuous places, confidential material that is not locked-up, etc. Automated methods include running vulnerability-identification software that checks that all internal network-connected systems are configured and managed according to both policies and standards. To be taken seriously, all policies must be supported by regular compliance checking.
All reported deviations are remedied in some way, perhaps by changing the policies themselves.
When a deviation from policy is discovered, management is legally on notice that there's a problem that needs fixing. In other words, prompt action needs to be taken in order to avoid charges of negligence. In more instances than many of us information security folk would like to admit, the action that might be most appropriate is to change the policy itself. Policies should be dynamic and regularly updated to reflect changing conditions both inside and outside the organization. A formal process for reviewing policies, developing proposed changes and obtaining management approval for proposed changes should be established and followed on a regular basis, preferably annually.
About the author:
Charles Cresson Wood, CISSP, CISA, CISM, is an independent information security consultant based in Sausalito, California. He specializes in the development of information security documents including policies, standards, procedures, and job descriptions. He is also the author of Information Security Policies Made Easy.