Fast forward to the present day. While there have clearly been advances in the writing and deployment of secure code in secure environments, I had really not seen much about testing the negative, that is, ensuring that applications do not misbehave in response to certain stimuli. That is, until I heard a presentation by Dr. Hugh Thompson, chief security strategist at People Security and subsequently chatted with him. Hugh refers to the process in terms of negative requirements, which comprise things that the system should not do and assumptions being made about the application and its environment. As an aside, the WSJ article goes on to say that, according to officials, “… the Pentagon assumed local adversaries wouldn’t know how to exploit [the vulnerability of the Predator transmissions].” Bad assumption.
Hugh and I discussed the possible explanations for the inadequacy of “negative requirements testing,” as he calls it, and “functional security assurance,” as I have been calling it. What it comes down to, in many cases, is that there are not many individuals who have the expertise to design and effect such testing. Pure functional testing requires knowledge of the business use of the systems and some rudimentary technical understanding. Pure security testing requires knowledge of threats, vulnerabilities, secure design and coding practices, fuzz testing, and security testing tools. However, negative requirements testing requires both an understanding of the business use of the systems and security threats, vulnerabilities, etc. There are very few individuals who have the latter expertise and experience. As a result, there is not much done, with the result that systems are deployed with many vulnerabilities that appear obvious in hindsight.
Hugh’s worthy mission is to address this major deficiency through training. All strength to his efforts, say I.
Popularity: 4%
