| Red Hat Linux 7.1: The Official Red Hat Linux Reference Guide | ||
|---|---|---|
| Prev | Chapter 7. Red Hat Security Primer | Next |
Every system, from a machine used by only one person to an enterprise-level server utilized by thousands of users, should have a security policy. A security policy is a set of guidelines used to gauge whether a particular activity or application should or should not be done or utilized on a system, based on the particular objectives for that system.
Security policies between different systems can vary greatly, but the most important thing is that one actually does exist for your system - whether or not is written down in company policy manual or simply remembered.
Any security policy should be constructed using these features as guides:
Simple rather than complex — The more simple and straightforward the security policy, the more likely the guidelines will be followed and the system kept secure.
Easy to maintain rather than difficult — Security methods and tools, like everything, are subject to change based on new challenges and needs. Your security policy should be built around minimizing the impact changes will have on your system and its users.
Promote freedom through confidence in the system's integrity rather than stifling system usability — Avoid security methods and tools that unnecessarily decrease the usefulness of your system when making the system more secure. Quality security methods and tools are almost always win-win, making the system more secure while offering more choice to users wherever possible.
Recognition of fallibility rather than a false sense of security — One of the most successful ways to invite a security problem is through the belief that your system could not possibly have that problem. Rather than resting on your laurels, be eternally vigilant.
Focus on real problems rather than being overoccupied by theoretical ones — Spend your time and effort dealing with the biggest real problems and work down from there. Prioritize your efforts and plug the biggest holes first. To help determine what you should be on the lookout for first, consider turning to http://www.sans.org/topten.htm or similar web sites that detail precise security problems that really do post a threat and exactly what you can do about them.
Immediacy rather than procrastination — Fix problems when you find them and determine that they pose a risk. Don't fall prey to thinking that you can take care of this at a later time. There really is no time like the present, particularly when your system is at stake.
If you find that your security policy is so restrictive that it prevents the system from being used in the way intended, then consider sufficiently changing the policy to loosen access to the system. In the same way, if you find that your system's security is continually being compromised, you should change aspects of your security policy to restrict access. Most importantly, remember that a security policy is not a static document or idea. It must be amended as the needs of your system's objectives and users change. Continuously reconsider your current security policy in the reflection of real world requirements.