|
| This Article | ||
| ||
| Share | ||
| Bibliographic References | ||
| Add to: | ||
 Digg  Furl  Spurl  Blink  Simpy  Google  Del.icio.us  Y!MyWeb | ||
| Search | ||
| ||
| ASCII Text | x | ||
| Herbert H. Thompson, "Why Security Testing Is Hard," IEEE Security & Privacy, vol. 1, no. 4, pp. 83-86, July-August, 2003. | |||
| BibTex | x | ||
| @article{ 10.1109/MSECP.2003.1219078, author = {Herbert H. Thompson}, title = {Why Security Testing Is Hard}, journal ={IEEE Security & Privacy}, volume = {1}, number = {4}, issn = {1540-7993}, year = {2003}, pages = {83-86}, doi = {http://doi.ieeecomputersociety.org/10.1109/MSECP.2003.1219078}, publisher = {IEEE Computer Society}, address = {Los Alamitos, CA, USA}, } | |||
| RefWorks Procite/RefMan/Endnote | x | ||
| TY - MGZN JO - IEEE Security & Privacy TI - Why Security Testing Is Hard IS - 4 SN - 1540-7993 SP83 EP86 EPD - 83-86 A1 - Herbert H. Thompson, PY - 2003 VL - 1 JA - IEEE Security & Privacy ER - | |||
Software testing is a discipline that has become pretty good at verifying requirements. Languages such as the Unified Modeling Language have made the process of moving from a specification (what the application should do) to test cases (verification that the application operates as specified) much easier. However, several types of bugs routinely escape testing. Many of these flaws are not specification violations in the traditional sense, meaning that the application might behave correctly according to requirements, but it might perform some additional, unspecified task in the process. Bugs like these would necessarily escape most automated testing because testers craft test cases to look for the presence of some correct behavior and not the absence of additional behavior. The subtle nature of most security bugs and why testing for them can be difficult is examined.