The primary objective of security tests is to ensure that a control is functioning properly. The tests could be a combination of automated scans, penetration tests using tools, and manual attempts to reveal security flaws. It's important to note that security testing isn't a one-time activity and should be performed at regular intervals. When planning for testing of security controls, the following factors should be considered:
- Resources (hardware, software, and skilled manpower) available for security testing
- Criticality rating for the systems and applications protected by the controls
- The probability of a technical failure of the mechanism implementing the control
- The probability of a misconfiguration of a control that would endanger the security
- Any other changes, upgrades, or modifications in the technical environment that may affect the control performance
- Difficulty and time required for testing a control
- Impact of the test on regular business operations
Only after determining these factors, a comprehensive assessment and testing strategy can be designed and validated. This strategy may include regular automated tests complemented by manual tests. For example, an e-commerce platform may be subjected to automated vulnerability scanning on a weekly basis with immediate alert notifications to administrators when the scan detects a new vulnerability. The automated scan requires intervention from administrators once it's configured and triggered, so it is easy to scan frequently.
The security team may choose to complement automated scans with a manual penetration test performed by an internal or external consultant for a fixed fee. Security tests can be performed on quarterly, bi-annually, or on an annual basis to optimize costs and efforts.
Unfortunately, many security testing programs begin on a haphazard and ad hoc basis by simply pointing fancy new tools at whatever systems are available in the network. Testing programs should be thoughtfully designed and include rigorous, routine testing of systems using a risk-based approach.
Certainly, security tests cannot be termed complete unless the results are carefully reviewed. A tool may produce a lot of false positives which could be eliminated only by manual reviews. The manual review of a security test report also helps in determining the severity of the vulnerability in context to the target environment.
For example, an automated scanning tool may detect cross-site scripting in a publicly hosted e-commerce application as well as in a simple help-and-support intranet portal. In this case, although the vulnerability is the same in both applications, the earlier one carries more risk as it is internet-facing and has many more users than the latter.