By now you've hopefully come to the conclusion that software security can be viewed as simply another feature of a software product or system. Most people probably don't want their personal financial data made public by a hacker. They would consider their spreadsheet software's ability to keep that information private a necessary feature. That feature is one that would go toward making the software a good quality product (remember our discussion of quality versus reliability in Chapter 3, "The Realities of Software Testing"?) If the software "failed" and allowed a hacker to see personal bank balances and credit card info, most users would consider that a software bug, pure and simple. REMINDER It's a good idea, here, to reiterate our definition of a bug from Chapter 1, "Software Testing Background":
And, to revisit our discussion of test-to-pass and test-to-fail from Chapter 5, "Testing the Software with Blinders On." When you test-to-pass, you really only ensure that the software minimally works. You don't push its capabilities. You don't see what you can do to break it. You treat it with kid gloves, applying the simplest and most straightforward test cases. After you assure yourself that the software does what it's specified to do in ordinary circumstances, it's time to put on your sneaky, conniving, devious hat and attempt to find bugs by trying things that should force them outtest-to-fail. As a software tester, you may be responsible for testing the software's overall security or you may just be responsible for testing that your assigned features are secure. No matter, you'll need to consider all five definitions of a bug. You won't necessarily be given a product specification that explicitly defines how software security is to be addressed in your software. Nor will you be able to assume that the threat model is complete and accurate. For these reasons, you'll need to put on your "test-to-fail" hat and attack the software much like a hacker wouldassuming that every feature has a security vulnerability and that it's your job to find it and exploit it. TIP Testing for security bugs is a test-to-fail activity and one that will often cover areas of the product that haven't been completely understood or specified. |