Protecting against what? The Achilles heel of information assurance

Many have long regarded software assessment as a way to determine the correctness of software. Formal methods attempt to build in correct behavior. Techniques such as formal verification and testing attempt to demonstrate, either formally or empirically, that the software computes the specified function-whether or not the specified function is correct. Note several subtleties here. First, to employ these techniques, we need a definition of correct behavior. Without an accurate definition of what we want, we cannot confidently label an information system as defective. Second, the predominant goal of software assurance has been to demonstrate correct behavior. But as we all know, correct software can still kill you. Correct and safe behaviors can conflict since safety is a system property while correctness is a software property. We must merge these two properties if we ever hope to realize information assurance. Information assurance is similar to software assurance but covers a broader set of information integrity issues, such as information security, privacy, and confidentiality. For example, if a system can thwart attacks, whether malicious or simply unfortunate, and still provide accurate information on demand, then it provides some degree of information assurance. Information assurance also includes the traditional software “ilities” (as they are called), such as software safety, software security, reliability, fault tolerance, correctness, and so on. Put simply, information assurance is accurate enough information that is available on demand for a given application or situation