The means traditionally taken to realize this objective is to attempt to create a secure computing platform, designed so that agents (users or programs) can only perform actions that have been allowed. This involves specifying and implementing a security policy. The actions in question can be reduced to operations of access, modification and deletion. Computer security can be seen as a subfield of security engineering, which looks at broader security issues in addition to computer security.
In a secure system the authorised users of that system are still able to do what they should be able to do. While one might be able to secure a computer beyond misuse using extreme measures (locked in a vault without any means of power or communication for example), this would not be regarded as a useful secure system because of the above requirement.
It is important to distinguish the techniques used to increase a system's security from the issue of that system's security status. In particular, systems which contain fundamental flaws in their security designs cannot be made secure without compromising their usability. Consequently, most computer systems cannot be made secure even after the application of extensive "computer security" measures. Furthermore, if they are made secure, often it is to the detriment of usability.
There are two different approaches to security in computing. One focuses mainly on external threats, and generally treats the computer system itself as a trusted system. This philosophy is discussed in the computer insecurity article.
The other, discussed in this article, regards the computer system itself as largely an untrusted system, and redesigns it to make it more secure in a number of ways.
This technique enforces the principle of least privilege to great extent, where an entity has only the privileges that are needed for its function. That way, even if an attacker has subverted one part of the system, fine-grained security ensures that it is just as difficult for them to subvert the rest.
Furthermore, by breaking the system up into smaller components, the complexity of individual components is reduced, opening up the possibility of using techniques such as automated theorem proving to prove the correctness of crucial software subsystems. Where formal correctness proofs are not possible, rigorous use of code review and unit testing measures can be used to try to make modules as secure as possible.
The design should use "defense in depth", where more than one subsystem needs to be compromised to compromise the security of the system and the information it holds. Subsystems should default to secure settings, and wherever possible should be designed to "fail secure" rather than "fail insecure" (see fail safe for the equivalent in safety engineering). Ideally, a secure system should require a deliberate, conscious, knowledgeable and free decision on the part of legitimate authorities in order to make it insecure. What constitutes such a decision and what authorities are legitimate is obviously controversial.
In addition, security should not be an all or nothing issue. The designers and operators of systems should assume that security breaches are inevitable in the long term. Full audit trails should be kept of system activity, so that when a security breach occurs, the mechanism and extent of the breach can be determined. Storing audit trails remotely, where they can only be appended to, can keep intruders from covering their tracks. Finally, full disclosure helps to ensure that when bugs are found the "window of vulnerability" is kept as short as possible.
Some of the following items may belong to the computer insecurity article:
Within computer systems, the two fundamental means of enforcing privilege separation are access control lists (ACLs) and capabilities. The semantics of ACLs have been proven to be insecure in many situations (e.g., Confused deputy problem). It has also been shown that ACL's promise of giving access to an object to only one person can never be guaranteed in practice. Both of these problems are resolved by capabilities. This does not mean practical flaws exist in all ACL-based systems — only that the designers of certain utilities must take responsibility to ensure that they do not introduce flaws.
Unfortunately, for various historical reasons, capabilities have been mostly restricted to research operating systems and commercial OSes still use ACLs. Capabilities can, however, also be implemented at the language level, leading to a style of programming that is essentially a refinement of standard object-oriented design. An open source project in the area is the E language *.
The Cambridge CAP computer demonstrated the use of capabilities, both in hardware and software, in the 1970s, so this technology is hardly new. A reason for the lack of adoption of capabilities may be that ACLs appeared to offer a 'quick fix' for security without pervasive redesign of the operating system and hardware.
The most secure computers are those not connected to the Internet and shielded from any interference. In the real world, the most secure come from operating systems where security is not an add-on, such as OS/400 from IBM. This almost never shows up in lists of vulnerabilities for good reason. Years may elapse between one problem needing remediation and the next.
A good example of a current secure system is EROS. But see also the article on secure operating systems. TrustedBSD is an example of an opensource project with a goal, among other things, of building capability functionality into the FreeBSD operating system. Much of the work is already done.
The term "trusted" is often applied to operating systems that meet different levels of the common criteria, some of which are discussed above as the techniques for creating secure systems.
A computer industry group led by Microsoft has used the term "trusted system" to include making computer hardware that could impose restrictions on how people use their computers. The project is called the Trusted Computing Group (TCG). See also Next-Generation Secure Computing Base.
Computer security is a highly complex field, and it is relatively immature, except on certain very secure systems that never make it into the news media because nothing ever goes wrong that can be publicized, and for which there is not much literature because the security details are proprietary. The ever-greater amounts of money dependent on electronic information make protecting it a growing industry and an active research topic.
Computer security | Electronic commerce | Secure communication
Sigurnost računara | Seguretat informàtica | Computersicherheit | Seguridad informática | Komputika Sekureco | Sécurité informatique | Sicurezza informatica | אבטחת מחשב אישי ברשת | Computerbeveiliging | コンピュータセキュリティ | Bezpieczeństwo teleinformatyczne | Segurança de computadores | Počítačová bezpečnosť | Datasäkerhet | Безпека мережі
This article is licensed under the GNU Free Documentation License.
It uses material from the
"Computer security".
Home Page • arts • business • computers • games • health • hospitals • home • kids & teens • news • physicians • recreation• reference • regional • science • shopping • society • sports • world