- Supporting Security for Unix Systems
- Develop a Security Policy
- Dedicate Resources to Security
- Monitor Security Mailing Lists
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
2. Develop a Security Policy
Defining a security policy has four components. Now that you know what's at risk and who can cause problems, you can define authorized and unauthorized access. Once you've defined authorized and unauthorized access, you need to define penalties for violating these policies. Once you've defined penalties, you need to define auditing procedures: How will you know when your policies are being violated?
After you can answer all of these questions, write it all down. Make management sign off on all of it, and make sure that everyone can read the policy. Without buy-in up and down the corporate ladder, a policy is just a worthless pile of paper (or a worthless pile of electrons, if you're into all that paperless office stuff).
Three useful resources for defining the policy are RFC 2196, the Site Security Handbook; the Cornell Computer Policy and Law Web site; and Virginia Tech's policies. The Site Security Handbook may be the driest, most boring document on the Internet, but it's a good resource for writing security policies.
The Cornell CPL site has links to policies from many institutions and some discussion of legal implications. Brad Knowles, a systems administrator at a large Belgian ISP, says, "When you talk about security, you also have to keep the law in mind. You don't want to run afoul of strict privacy laws when considering to set up intrusion detection systems, or writing programs to methodically check every file, page, link, image, movie, or other object on every server and flag it for human attention if it could potentially be questionable, but you also can't afford to be lax and let stuff slip through."
Make sure that, if you offer co-location facilities for your customers, your security policy discusses their rights and responsibilities as well. Knowles notes, "Our biggest problems have come from machines that are owned by our customers, but that are housed in our facilities. Regardless of how good or bad a job you may think we do on administering our own machines and making sure that they are secure, there's not much we can do to ensure that these customer machines are secure from outside attack, or that they won't be abused by an employee of that company."
Virginia Tech's policies are, on their face, more appropriate to a university than an ISP, but they've evolved over years and have withstood court challenges. Your site may have different problems and different challenges, but knowing what works for people is rather useful.
NOTE: Security Policy Resources
RFC 2196, the Site Security Handbook
http://www.faqs.org/rfcs/rfc2196.html
Cornell Computer Policy and Law Site
Virginia Tech Security Policy