Secure computing

A secure computing platform is designed so that those agents who should not be able to perform certain actions cannot do them, while those agents who should be able to perform certain actions can do them. The actions in question can be reduced to operations of access, modification and deletion.

It is important to understand that in a secure system, the legitimate users of that system are still able to do what they should be able to do. In the case of a computer system sequestered in a vault without any means of power or communication, the term 'secure' is applied in a pejorative sense only.

It is also important to distinguish the techniques employed 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 utility. Consequently, most computer systems cannot be made secure even after the application of extensive "computer security" measures.

There are two different cultures of security in computing. One focuses mainly on external threats, and generally treats the computer system itself as a trusted system. See the article computer insecurity for a description of the current state of the art in this approach.

Computer security by design

The other 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 privilege separation[?], 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.

Futhermore, 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.

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. Finally, full disclosure helps to ensure that when bugs are found the "window of vulnerability[?]" is kept as short as possible.

Early history of security by design

The early Multics operating system was notable for its early emphasis on computer security by design, and Multics was possibly the very first operating system to be designed as a secure system from the ground up. In spite of this, Multics security was broken, not once, but repeatedly. This led to further work on computer security that prefigured modern security engineering techniques.

Techniques for creating secure systems

The following techniques can be used in engineering secure systems. Note that these techniques, whilst useful, do not of themselves ensure security -- a security system is no stronger than its weakest link.

Cryptographic techniques can be used to defend data in transit between systems, reducing the probability that data exchanged between systems can be intercepted or modified.

Strong authentication techniques can be used to ensure that communication end-points are who they say they are.

Secure cryptoprocessors can be used to leverage physical security techniques into protecting the security of the computer system.

Chain of trust[?] techniques can be used to attempt to ensure that all software loaded has been certified as authentic by the system's designers.

Mandatory access control[?] can be used to ensure that privileged access is withdrawn when privileges are revoked. For example, deleting a user account should also stop any processes that are running with that user's privileges.

Capability[?] and access control list techniques can be used to ensure privilege separation and mandatory access control. The next sections discuss their use.

Capabilities vs. ACLs

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.

Unfortunately, for various historical reasons, capabilities have been restricted to research operating systems and commercial OSes still use ACLs.

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.

A good example of a current secure system is EROS.

Further reading

Computer security is a highly complex field, and it is relatively immature. The ever-greater amounts of money dependent on electronic information make protecting it a growing industry and an active research topic.

See also: security engineering, authentication, cryptology, cryptography, physical security, hacking, cracking, shellcodes, electronic underground community, Defensive programming, full disclosure, INFOSEC, COMSEC

References:

• Ross J. Anderson, Security Engineering: A Guide to Building Dependable Distributed Systems, ISBN 0471389226
• Bruce Schneier, Secrets & Lies: Digital Security in a Networked World, ISBN 0471253111
• David A. Wheeler, Secure Programming for Linux and Unix HOWTO (http://www.cs.washington.edu/homes/levy/capabook/) (GFDL License)
• Paul A. Karger, Roger R. Schell. Thirty Years Later: Lessons from the Multics Security Evaluation. IBM white paper.

• Computer Security Fact Forum Framework (http://www.caplet.com/security/taxonomy/index)
• Intro to Caps (http://www.eros-os.org/essays/capintro)
• ACLs vs. Caps (http://www.eros-os.org/essays/ACLSvCaps)
• Intro to Cap Security (http://www.skyhunter.com/marcs/capabilityIntro/index)
• Why aren't Caps and ACLs equivalent? (http://www.eros-os.org/faq/basics#non-equivalence)
• Open Source Distributed Capabilities (http://www.erights.org/)
• REST and capability-based security (http://www.waterken.com/)
• The Cambridge CAP capability-based computer architecture (http://www.cs.washington.edu/homes/levy/capabook/Chapter5.pdf)
• Online book: "Capability-Based Computer Systems" by Henry M. Levy (http://www.cs.washington.edu/homes/levy/capabook/)
• Henry M. Levy - Capability-Based Computer Systems (http://www.cs.washington.edu/homes/levy/capabook/). Digital Press, Bedford, Massachusetts, 1984, ISBN 0932376223 (out of print -- text available online on author's website)