Risk Management and Security Testing | Software Security: Building Security In

Software security practitioners perform many different tasks to manage software security risks, such as:

Creating security abuse/misuse cases
Listing normative security requirements (and security features and functions)
Performing architectural risk analysis
Building risk-based security test plans
Wielding static analysis tools
Performing security tests
Performing penetration testing in the final environment
Cleaning up after security breaches

Three of these practices are particularly closely linkedarchitectural risk analysis, risk-based security test planning, and security testingbecause a critical aspect of security testing relies on directly probing security risks. Chapter 5 explains how to approach a software security risk analysis, the end product being a set of security-related risks ranked by business or mission impact. Chapter 2 explains how to keep track of security risks and properly manage them over time in an RMF.

The pithy aphorism "Software security is not security software" provides an important motivator for security testing. Although security features, such as cryptography, strong authentication, and access control, play a critical role in software security, security itself is an emergent property of the entire system, not just the security mechanisms and features. A buffer overflow is a security problem regardless of whether it exists in a security feature or in the noncritical GUI.

For this reason, security testing must necessarily involve two diverse approaches:

Functional security testing: testing security mechanisms to ensure that their functionality is properly implemented
Adversarial security testing: performing risk-based security testing motivated by understanding and simulating the attacker's approach

Together, these two distinct activities are a mix of white hat (security functionality) and black hat (security attack) philosophies. Security testing must mix both approaches or it will fail to cover critical areas.

Many developers erroneously believe that security involves only the liberal application and use of various security features, which leads to the incorrect belief that "adding SSL" is tantamount to securing an application. Software security practitioners bemoan the over-reliance on "magic crypto fairy dust" as a reaction to this problem. Software testers charged with security testing often fall prey to the same thinking.

It's not that we shouldn't test the crypto fairy dust to determine its potency. It's just that most security attacks ignore the security mechanisms in favor of looking for software defects anywhere in the system. Security testing needs to cover the attacker's mindset just as well as it covers security functionality.