Model | Verification | Requirements-driven Testing | Control Verification
Benefit
Verified effectiveness of your standard security controls
Activity
Conduct security tests to verify that the standard software security controls operate as expected. At a high level, this means testing the correct functioning of the confidentiality, integrity, and availability controls of the data as well as the service. Security tests at least include testing for authentication, access control, input validation, encoding, and escaping data and encryption controls. The test objective is to validate that the security controls are correctly implemented.
The security testing validates the relevant software security controls. Perform control-verification security tests manually or with tools, each time the application changes its use of the controls. Techniques such as feature toggles and A/B testing can be used to progressively expose features to broader audiences as they are sufficiently validated. Software control verification is mandatory for all software that is part of the SAMM program.
Question
Do you test applications for the correct functioning of standard security controls?
Quality criteria
Security testing at least verifies the implementation of authentication, access control, input validation, encoding and escaping data, and encryption controls |
Security testing executes whenever the application changes its use of the controls |
Answers
No |
Yes, some of them |
Yes, at least half of them |
Yes, most or all of them |
Benefit
Integration of security requirements into test scenarios
Activity
From the security requirements, identify and implement a set of security test cases to check the software for correct functionality. To have a successful testing program, you must know the testing objectives, specified by the security requirements.
Derive security test cases for the applications in scope from the security requirements created as part of the “Security Requirements” SAMM security practice. To validate security requirements with security tests, security requirements are function-driven and highlight the expected functionality (the what) and, implicitly, the implementation (the how). These requirements are also referred to as “positive requirements”, since they state the expected functionality that can be validated through security tests. Examples of positive requirements include “the application will lockout the user after six failed login attempts” or “passwords need to be a minimum of six alphanumeric characters”. The validation of positive requirements consists of asserting the expected functionality. You can do it re-creating the testing conditions and running the test according to predefined inputs. Show the results as as a fail or pass condition.
Often, it is most effective to use the project team’s time to build application-specific test cases, and publicly available resources or purchased knowledge bases to select applicable general test cases for security. Relevant development, security, and quality assurance staff review candidate test cases for applicability, efficacy, and feasibility. Derive the test cases during the requirements and/or design phase of the functionality. Testing the security requirements is part of the functional testing of the software.
Question
Do you consistently write and execute test scripts to verify the functionality of security requirements?
Quality criteria
You tailor tests to each application and assert expected security functionality |
You capture test results as a pass or fail condition |
Tests use a standardized framework or DSL |
Answers
No |
Yes, some of them |
Yes, at least half of them |
Yes, most or all of them |
Benefit
Timely and reliable detection of violations to security requirements
Activity
Write and automate regression tests for all identified (and fixed) bugs to ensure that these become a test harness preventing similar issues being introduced during later releases. Security unit tests should verify dynamically (i.e., at run time) that the components function as expected and should validate that code changes are properly implemented.
A good practice for developers is to build security test cases as a generic security test suite that is part of the existing unit testing framework. A generic security test suite might include security test cases to validate both positive and negative requirements for security controls such as Identity, Authentication and Access Control, Input Validation and Encoding, User and Session Management, Error and Exception Handling, Encryption, and Auditing and Logging. Verify the correct execution of the security tests as early as possible. If feasible for example, consider the passing of security tests as part of merge requirements before allowing new code to enter the main code base. Alternatively, consider their passing a requirement for validating a build.
For security functional tests, use unit level tests for the functionality of security controls at the software component level, such as functions, methods, or classes. For example, a test case could check input and output validation (e.g., variable sanitation) and boundary checks for variables by asserting the expected functionality of the component.
Question
Do you automatically test applications for security regressions?
Quality criteria
You consistently write tests for all identified bugs (possibly exceeding a pre-defined severity threshold) |
You collect security tests in a test suite that is part of the existing unit testing framework |
Answers
No |
Yes, for some applications |
Yes, for at least half of the applications |
Yes, for most or all of the applications |
Stream Guidance
- SAMM team guidance Google Doc
- Community guidance Google Doc
Want to contribute?
Complete this Google Form with guidance for this Stream.
To learn more about Stream guidance for the SAMM model, see the Stream guidance page.