Control Verification

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 & Access Control, Input Validation & 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

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.