Dependability and Security Assurance

Reading Response to Chapter 15
It would appear at first that it is easier to avoid spending time, money and putting forth effort in order to verify, validate, test and ensure the quality of a product. However this is not always the case. As stated in the book, the cost of failure can be very high, often spiraling out of control until the price in the end is much more than the cost for testing and V & V would've been. Not to mention that there can be potential risks to individuals and companies if the product is a safety critical system.

If a system is being created and distributed it is generally expected that the product has been put through its paces and is dependable and secure. Static analysis is a generally reliable method, especially for large scale systems, as executing the program is not always the most efficient or available approach. On a smaller scale, however, I believe it is not quite as approachable. For something like a side project, or school assignment it can often be easier to execute a program and visualize the results in order to see what areas require more testing attention. Static analysis leads to more formal verification that is often seen in production and in more advanced and complicated systems.

Formal verification is something that doesn't seem immediately applicable, and personally I have only seen it used in a cryptographic scope. Model checking is an approach I have seen used frequently when working with the security of a system. Lastly, Automated Program analysis is something that most programmers use every day, even if they don't realize it. Most IDEs have a small scale analysis that frequently checks for small errors in code. They generally focus on syntax and will provide the appropriate information and error messages to the programmer.

Reliability testing is also of great import; just as a system is expected to be dependable and secure, it should be reliable. Extensive testing should be conducted in an organized manner until the number of failures is statistically insignificant. This is another approach I've had a small amount of experience with in regards to Cryptography, an encryption scheme was considered successful when put through a test where the adversary would have a statistically insignificant chance of succeeding in decrypting the original message.

In general, testing of all sorts is not emphasized enough. And while emphasis is nice (and I do enjoy that we are discussing it in class) it still requires personal experience and discipline to get into the habit. It is, after all, much easier to just write code and move on.