The backbone of any organization's Internet security is not an impenetrable firewall or strong cryptography; rather, it is a solid information security policy that is understood and enforced properly. While security policies are often written as a response to a tactical technical project that will potentially put corporate data at risk, a good security policy should come first - a reflection of strategic priorities and assets.
No security technology is perfect, and the policy itself may be the only barrier to undesirable actions, as well as the roadmap to improving corporate security. In our experience in reviewing security policies and working with the development process, we have compiled some tips from the most successful policies:
Be legal. While this may sound obvious, many policies are heavily influenced by technologists who are not aware of laws covering employee rights, statutes in different localities and many other legal issues. A security policy with many sound provisions may be totally invalid if it contains some poorly written sections or lacks the proper disclaimers.
Be clear. A good policy should not only do a good job of describing the rules; it should provide clear examples of usage guidelines for the organizational users and technical staff alike. One of the best approaches we have seen is a set of FAQs that cover the most common issues in everyday language. Questions like "What do I need to do if I want to work on data files at home?" and "What do I do if an employee is trying to guess passwords?" are good ways to make the policy real, and increase the likelihood that it will be adopted in actual practice. Also make the consequences for a violation of policy clear. Trying to get into someone else's personal files may be fun, but not if certain termination is the outcome.
Orientation. When and how employees and contractors get information about the security policy is critical. It is now becoming very common to integrate the security policy into new employee orientations. But this, of course, leaves out dealing with existing employees or interim changes to the policy. Publishing the policy in a conspicuous place on the Intranet and providing notification about policy changes are helpful. Tying policy review to regularly scheduled events, either in offline events such as staff meetings, or online events such as password expiration, can also aid in communication of the facts.
Define IT's boundaries. Often, the information technology department's tools for detecting improper Internet usage are precise in terms of who violated the policy when, and in what ways. Overzealous IT employees, however, can sometimes take what seems to be irrefutable evidence of a violation and contact the user in question. This can create a dangerous situation worse than the actual violation. While technical enforcement should mean immediate termination of illegal FTP connections, station lockouts, etc., the IT department should be trained to provide notification to the appropriate management and not put themselves in the position of judge and jury.
Define standards for countermeasures. While a solid security design and implementation will provide automatic countermeasures to certain security violations, standards must be put in place to clarify how quickly IT must respond manually to other issues, such as shutting down systems under attack, applying bug fixes, upgrades, etc. If a security exploit has been found and published for your organization's firewall, how long do you wait before applying the remedy?
Cover the usage of data, not just the corporate network. As your data travels, policy must travel with it. If a user is working on a company file on their home PC, do they need to encrypt it with PGP on the hard drive? Are users allowed to access the corporate network from airport kiosks? Many corporate security policies neglect the company's public Web site when it is outsourced. However, this is corporate data and should be protected as such. While a corporate firewall may prevent outside access to engineering's R&D site, your marketing department may be publishing some of this information on the public Web site.
Share portions of your policy with a trusted partner. You need to be careful about this, but a highly trusted partner can provide a sanity check for your policy. This person can even tell you if they are receiving some of your data in violation of your policy.
Many of the points I've made refer to the importance of having Human Resources and legal counsel involved in the formulation of a security policy. It won't be successful without them. When there is a need to implement a technology for which no policy has been defined as yet, it is not always necessary to get legal oversight first. But it does mean that project approval needs to be granted from a fairly senior level and an interim policy needs to be in place while formal review occurs.
There are two certain consequences to poor security policies: a lack of compliance and a lack of productivity. Employees looking for shortcuts to get their work done will violate policy, and others will be intimidated by the policy and avoid tasks they should be doing. A well-written policy should protect your organization and empower your workers.
RELATED LINKS
E-mail policy
Network World, 03/15/99.
Writing a security policy
Network World, 03/10/99.
Archive of Network World on Security newsletters
Network World Security Alert will keep you up to date on the latest security holes and patches, with daily updates from key vendors, security organizations and Network World reporters. See the latest dispatches from the security here.
