Software Reliability
There is no question that software reliability is a requirement of most software development projects. Reliability, however, is often very narrowly defined. In the security world reliability is great label to describe how a system (application or otherwise) handles a variety of unexpected conditions that are not at all driven by normal use cases. There is a laundry list of useful techniques to measure a system’s reliability from the context of security. These are almost the complete opposite of how a normal QA cycle is run. Yes, there are performance testing aspects in the overall cycle, but these are still focused on the narrow definition of reliability
This narrow definition of reliability is focused on what I call positive availability. It takes the known and valid operations of a system as defined by the use cases and attempts to find situations where that system’s implementation deviates from what is expected. You’ll notice the change from reliability to availability. This is intentional because software reliability is so narrowly defined in this context that it appears to be nothing more than ensuring the availability of the system and its information through this sort of examination. I know I shouldn’t have to say this, but I’m not saying that this process is bad or not useful. It is useful. What it isn’t, though, is comprehensive.
This gets even more interesting because many times reliability is not viewed as a security concern. To some, security is the management of identities, assertion of these identities and the entitlements that these entities should receive. This is a grave mistake. Reliability is at the very core of security. Measuring how software protects confidentiality, maintains integrity and provides availability is the the primary task of security. Just as the process of “positive availability” is limited so too is the idea that security is only about managing and enforcing entitlements. And so, because of this, we have this chasm. The software process stops at positive availability and labels a project reliable. The security process stops at entitlements and labels the same project secure.
To provide the most utility the reliability that is measured by development projects should include negative availability. As for security, it needs to expand to meet the needs of not only who gets to what, but also how the application is structured and implemented with this same negative availability in view. I use the term negative availability to describe that vague process of examination where standard use cases are twisted and bent. Instead of trying to find if an application breaks through standard usage this process tries all forms of manipulation that are not defined in requirements and designs to find defects. The aim of this type of defect hunting is to find a failure in confidentiality, integrity and availability mechanism of software. Because standard use cases attempt to communicate how software should operate this sort of negative availability uses that source material to see if the software has protected itself when things do not go as expected. Typically software is not constructed with this in mind.
We quickly see that my negative availability moniker isn’t inclusive enough. Once a flaw is found in software through this sort of testing it isn’t always the loss of availability that is the result or even the goal. The fact remains, however, that this sort of testing and examination is crucial to understanding how reliable an application really is. It is dangerous to presume that software is reliable when it does not focus on this negative availability. It is as dangerous, if not more so, to presume that an application is secure because identities and entitlements are managed properly when no review of the software’s construction and operation is performed.