Far too many organizations treat the development or update of information security policies as yet another administrative 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.
Consider the case of Guess Jeans. Guess.com included a privacy policy that assured users their personal information would be "stored in unreadable, encrypted format at all times." Clearly, the writer of this policy didn't understand much about computers or networks. It is not technically possible to keep information in an unreadable and encrypted format at all times, because the data must be readable and unencrypted in order to be used to place orders and perform other necessary activities. What the policy should have said was that "all personal information in transit over the Internet would be sent in encrypted format."
The problems at Guess came into the limelight when Jeremiah
Requires Free Membership to View
SearchSecurity.com members gain immediate and unlimited access to breaking industry news, virus alerts, new hacker threats, highly focused security newsletters, and more -- all at no cost. Join me on SearchSecurity.com today!
Michael S. Mimoso, Editorial Director
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.
MORE SECURITY POLICIES TIPS BY CHARLES CRESSON WOOD:
- Learn how to build a corporate culture of policy compliance.
- Read how centralized information security training is a key to policy success.
- Learn how to employ action-forcing mechanisms to encourage policy compliance.
Unless your organization wants to be the next precedent-setting case appearing in the press, be sure that:
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.
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.
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.
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.
This was first published in July 2004