Eureka! Professor Does FST (Functional Security Testing)

I have been harping on the need to perform what I call “functional security testing,”  or FST, which is my term for testing systems to ensure that they don’t do functionally that which they are not supposed to do. This is as opposed to the more common “nonfunctional security testing,” with which we all familiar, and which includes code reviews, penetration testing, etc.

I have come up with quite a few examples of failed applications or combination of applications that would have benefited greatly from such testing. One example, which I mentioned in my May 25, 2010 Bloginfosec column “Bungee Jumps, Stock Markets and Negative Testing,” is the domino effect of missing controls in exchange and program trading systems, such as those that resulted in the “flash crash” of May 6, 2010. I also discussed the benefits that the auto industry would have derived from FST, in terms of the avoidance of failures, in my February 16 and 22, 2010 Bloginfosec columns “Negative Testing Revisited – Vehicle Control Systems,” Parts 1 and 2 respectively.

Finally, I have seen in print an example of someone who actually makes it his business to perform functional security testing, although he does not call it that. In a June 11, 2010 article in The Wall Street Journal, with the title “Web Watchdogs Dig for Flaws,” reporter Ben Worthen describes the activities of Assistant Professor Ben Edelman at the Harvard Business School “who takes it upon himself to make sure that the social-networking sites … follow their stated policies.”

The article describes Professor Edelman’s approach as follows:

“… he starts by asking himself ‘wouldn’t it be amazing if’—with the ‘if’ being things that are unlikely to occur—and then tests the ideas on several computers in his home office. [He] says he typically can test five scenarios in an hour.

In January [2010], he discovered that Google’s toolbar software, which allows users to conduct searches without visiting Google’s home page, recorded what Web pages a person viewed in some cases even after the user disabled that feature.”

Google claims that the problem, which they assured us “only affected a small number of people,” has been fixed.

It appears that the Google example could be due to data persistence in a buffer, which should have been initialized, or emptied, as soon as the feature was disabled. I personally have seen a similar problem where a customer was able to view the “administrative messages” of other customers when he accessed his own messages via a certain path. That was due to data persistence, which made me think that the Google case could be similar.

As we enter this particular space, we get into the issue of first-order, second-order, third-order FST and so on. Because the magnitude of exhaustive FST is so enormous, because of the huge number of combinations and permutations that are possible with modern complex computer systems, it becomes necessary to whittle down the scenarios in some fashion or other. I have advocated only addressing first-order FST, where the directly negative examples are listed (such as, this user should not be able to access that account). Even at this level, the number of use (or misuse) cases can be overwhelming, so I suggest a statistical sampling approach.

When it comes to second and greater order scenarios – i.e., do this, then that, then the other – the number of cases or scripts grows exponentially and only a very few such cases, on a percentage basis, can be tested cost-effectively. But, as shown in Professor Edelman’s example, such compromises can have a serious impact.

What Professor Edelman’s approach suggests to me is that human intuition may be the answer to teasing out obscure, but extremely damaging, needles from the misuse-case and abuse-case haystacks. I have written earlier about the ace tester, with whom I worked some twenty years ago, who had an uncanny sense of where misuse cases might crop up. Such a facility is worth its weight in gold (even at today’s inflated prices). But in lieu of such a person, it is well worth formalizing Professor Edelman’s approach by gathering a group of creative and knowledgeable individuals, familiar with the systems to be tested, for the purpose of brainstorming the “what if” misuse and abuse cases and letting members of the group go at it for a time determined by the criticality, dependencies, value and complexity of the applications being tested.

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*