Regression Testing, Security Assessment Testing, and Testing and Evaluation of Controls

Regression Testing, Security Assessment Testing, and Testing and Evaluation of Controls

Regression Testing

Testing existing software applications to make sure that a change or addition to the application has not affected any existing functionality in a negative way is called regression testing.

Its purpose is to catch any code or bugs that may have been accidentally introduced into a new build of software or release candidate and to ensure that previously eradicated bugs continue to stay eradicated.

Security-specific regression testing can also be used to verify that a newly installed set of modifications has not re-exposed the system to previously known exploitable vulnerabilities. (Sadly, it sometimes happens that today's security patch undoes the mitigations put in place by last month's security update.)

By rerunning testing scenarios that were originally scripted when known problems were first fixed, the developer or security professional can make sure that any new changes to an application have not resulted in a regression or caused components that worked before to fail.

Security Assessment Testing

A variety of test and assessment strategies, including ethical penetration testing, can be used throughout the operational life span of an information system. These typically evaluate the present state of the system and the way it is being used which quite often has evolved beyond what the system's original requirements specified it to do.

Actual in-situ use testing and evaluation can help identify such changes and gather the data necessary to evaluate their potential contribution (negative or positive) to the overall organizational information security posture.

Security assessment testing should include focused attention on designed-in security controls, to assess they are operating correctly and that they still meet the threats being posed by the overall environment.

In particular, security assessment needs to spend some thought on choosing the right kind of test scenarios, and thus the test data, to conduct the assessment with:

• Good test data should be chosen to
• Data validation: Before and after each include all kinds of possibilities including test, review the data to ensure that data data that would challenge the acceptable has not been modified inadvertently. data ranges, various points in between,
• Bounds checking: Field size, time, date,

and data beyond what may be expected

etc. Proper bounds checking can be very by the application. Different testing effective in preventing buffer overflows.

strategies should be used to test as much as possible. This would include fuzzy

• Sanitize test data to ensure that sensitive

testing, which allows the test data to production data is not exposed to test be very random and not "expected." members that should not be allowed to view sensitive data. Test data should not

• Testing with known good data is also

be production data until preparing for required to ensure the application and final user acceptance tests, at which point, system reacts as expected. An important

special precautions should be taken to

rule to always follow is to ensure that live avoid need-to-know noncompliance. production data should never be used as

it may impact privacy and need-to-know policies. If testing with live production data cannot be avoided, then the data owner needs to be consulted, and they will have to sign off on the usage of the data for testing and to allow certain test members to possibly be exposed to very sensitive information.

• Further, usage controls strictly regulating what can be done with the data during testing will need to be negotiated between the data owner and the testing coordinator to ensure the exposure and risk to the data is managed properly; however, as a general rule, live production data should not be used.
• Clear and adequate segregation between testing and production environments must be maintained at all times. Copies of production data should be sanitized so that we ensure policy compliance. Management and stakeholders should be informed of the test results, and they also need to formally acknowledge the results of the test.