High-confidence design for security: don't trust—verify

33 This article describes methods for establishing confidence that implementations meet their specifications and security requirements. These methods are rigorous in nature, rely on mathematical logic, and are accessible to engineering students at the mas-ter's level. As is typical in systems engineering , various methods are used depending on what level of design is being addressed. Security Properties and Mechanisms The collection of people, keys, processes, or machines who send and receive information and who access information resources (databases, processors, printers) are called principals. Security properties typically deal with the ability of principals to access information or resources. Key security properties include: • Privacy or confidentiality: knowing which principals can read data; • Integrity: detecting corruption of information; • Authentication: knowing the identity of a principal or the source of information; • Access control: restricting the use of a resource to privileged principals; The widespread use of networks makes information security a major concern when the underlying network (for example, the Internet) is assumed to be insecure. Systems with security requirements typically must operate with a high degree of confi-dence—they must be highly assured. The task of designing and building secure systems raises a fundamental question: how do we know with confidence that our designs will be secure? Having confidence in a secure system requires having confidence in the strength of the cryptographic algorithms, the correctness of the hardware and software implementations, and knowing the implementation supports a security model. SECURITY Don't trust—verify.