Software Security Testing

1. Software Security Testing Bruce Potter, Booz Allen Hamilton Gary McGraw, Cigital

2. Testing for security • Standard software testing is generally indifferent to the intent of the failure – whether it is malicious or not • Testing for security is different than functional testing since there can be an intelligent adversary actively trying to subvert the system for fun or profit • Security testers should ideally be able to think like an attacker • Needs to be more involved than functional testing and black-box testing of front-end of the system

3. Risk Management • Examines the likelihood of a successful attack and its impact • These metrics can be used to prioritize and rank the available resources to address them • A vulnerability is a flaw or bug that can be used to cause damage to the system • Taxonomies of vulnerabilities have been created by researchers • Attackers have become more sophisticated • Has altered the likelihood of successful attacks against systems • Race conditions and two-stage stack-based buffer overflows becoming more prevalent at the time of the paper

4. Implementation and Design Vulnerabilities • Implementation-level vulnerabilities are easier to detect and change • The strcpy(char *, char *) function does not perform bounds checking and can enable a stack-based buffer overflow • Use strncpy(char *, char *, int) function instead which limits the number of bytes copied from the source string to the destination string • Design-level vulnerabilities require domain knowledge to address and are difficult to automate • Error-handling in an object-oriented system • Object sharing and trust issues • Unprotected data channels • Insufficient access control mechanisms • Lack of auditing and logging • Timing errors

5. Security-Annotated Software Development Lifecycle

6. Perception of Security • “Software security is not security software” • Can provide false sense of security • Some developers mistakenly believe that adding cryptography is panacea for security • Software can use security mechanisms but still be insecure • Uses crypto but still has insufficient access control • Hard-coded credentials that can be extracted from the binary to decrypt the ciphertext • Fail to validate SSL certificates

7. Approaches for Security Testing • Functionality testing the security mechanisms • Can be performed by standard testing organizations • Risk-based security testing and emulating an attacker approach to subvert the system • Can be performed by hackers and penetration testers • Hacking books and workshops can inform testers and developers of potential security threats so that they code more defensively and test more aggressively • Security testing should be fundamental and built into the software development lifecycle • Security testing is inadequate in some organizations due to time and resource constraints

8. Outside->In to Inside->Out • Focus on security testing and risk management for software inside the LAN in addition to mechanisms to prevent access to attackers • Also addresses insider thread

9. White Box and Black Box Testing • White-box testing is aware of the the internals of the software and has access to the source code which provides a fuller understanding of the software • More amenable to static analysis and instrumentation • Static analysis examines artifacts of the software without executing it • Black box testing is unaware of the software internals and provides various inputs and examines the responses • Provide malicious and malformed input and examine for a fault which may manifest as a security vulnerability • Software binary not required if testing is performed over the network

10. Java Card Security Testing • Enhanced payment cards with additional storage and computational abilities • Goal is to decrease fraud and abuse and authenticate transactions and identification • Providing security in an evolving technology is difficult • Credit card companies perform thorough security testing • Early involvement of the security community for Java Card • They perform risk-based security testing • Focus on secure design so the cards can function properly in the face of attacks

11. Automated Security Testing • Authors worked on security testing of the Global Platform/Java Card security initiative • Cigital created a test suite to mostly automate the testing • Low-level testing of the class codes, commands, and crypto • High-level testing used hostile Java Card Applets • Most cards passed the low-level functional security tests • Each tested card displayed a fault for the high-level tests • Some faults manifested as security vulnerabilities

12. Java Card: Lessons Learned • Java cards require that transactions are atomic so they can be rolled back if they fail • High-level attack scenarios • Not aborting or committing transactions • Filling the transactions buffers • Performing nested transactions • Discovered vulnerabilities were patched prior to public use • Security should be integrated into the software development lifecycle • Less costly to fix and less harm to the end user when security is not an afterthought