Your first challenge is to understand what computer security means. This is important because security is often misunderstood. Often the term security is seen as an extension of reliability because insecure computers interrupt your dependency upon computers. Obviously, systems must be secure to be reliable, yet the term “secure” is often used incorrectly as an absolute measure of this reliability, as if nothing could ever go wrong. Security, like reliability, is not so black-and-white. Computer reliability is a probability measure of whether a system will function as intended. Computer security is concerned with managing reliability in the presence of malevolent influences.
A simple definition of a secure computer is: a system which does exactly what we want it to do and nothing that we don't want it to do even when someone else tries to make it behave differently.[1]
Of course, a breach in security can render a system unreliable and worse it can lead to data loss, information theft, and even loss of a company’s reputation. Therefore, to be reliable, an OSMS deployment must be made secure.
To understand how to secure a computer requires an understanding what can be expected of a particular system. A systems context and circumstances must be examined to assess whether a system is secure. Therefore, the idea that a system is “secure” or not needs an association with a particular system, an environment, and a degree of acceptable risk. As described in this white paper, this examination is a formal process governed by the Security Policy.
Security expectations vary according to a system's components and the threats the system faces. Security risks represent the degree to which you believe a system is resistant to threats, while considering the consequences if the system is not resistant. Unacceptably high risks can be tempered by adopting security measures until the risk level is acceptable. Fortunately, the open source community has many security-related tools, which reduce risks. Using these tools, Linux systems can fit securely and reliably into many different environments.
Each system, the environment in which it resides, and the acceptable level of risk will change over time. Therefore, the security of the system also changes and a process must be established to manage this ongoing change. Often the weakest link in security is processes that do not exist, are not implemented, or are even ignored. Guidelines and best practices do not improve security unless they are adopted into an ongoing, managed security policy.
Each tool or technique described in this white paper addresses different security issues and provides a different security level. Each is appropriate for different OSMS configurations, threat environments, and security goals. This white paper describes the simplest and least secure methods first and proceeds to the most secure, most difficult to implement, and most difficult to use methods. Your goal is to determine what methods are appropriate for your system, and then incorporate them into your ongoing security management policy.
Printable version
