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

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

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

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

Security-Annotated Software Development Lifecycle

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

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

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

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

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

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

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