1

Details:

I would like to address the topic of security test plan. I can hardly find suitable material when it comes to the topic of Vulnerability test. Most of the time the information is limited to security in general, for networks, or just rudimentary.

Initial situation:

  1. I would be interested in what I have to look for within a security test plan for vulnerability test?
  2. Are there any examples for a security test plan that is designed for a vulnerability test?
2

If you're interested in relevant standards, the most relevant one is likely to be IEEE Standard 1012, which is the IEEE Standard for System, Software, and Hardware Verification and Validation. I've noticed a trend, both in standards as well as in expectations of audits, to move away from planning and describing testing to planning for and describing all verification and/or validation activities.

A planning document - whether you call it a "test plan" or a "verification plan" or a "verification and validation plan" or something else - identifies a scope of the systems of interest, the various tasks or activities, who (often at a role level) is involved in each task or activity, what resources (software, hardware, infrastructure, people external to the team) are required, and when the various activities occur.

In terms of security, the things that I would classify as "testing" for software would include the use of a dynamic vulnerability scanner and penetration testing. At a system level, you may be able to broaden the definition to include things like testing of the physical security of facilities or phishing simulations against employees. If you expand from "testing" to include all verification and validation activities, you can also include peer reviews of various work products, static analysis of the software source code, monitoring for vulnerabilities in third-party dependencies, and audits that include security policies and procedures.

Once you've identified the scope of your plan and what activities are in place, it becomes a matter of describing them. For each activity, identify who is involved in executing it, what tools they use, and what triggers it to happen. Some things may run frequently - code reviews or on-commit static analysis scans. Others may be less frequently - dynamic analysis could be related to calendar time or releases and penetration tests could be triggered by calendar time elapsing.

I'm not aware of any publicly-available test plans or verification plans. Most are highly specific to the system under development. However, IEEE Standard 1012 does go into a lot of detail as to the different verification and validation activities including those related to security and gives examples of what to consider during planning and execution of the verification and validation process activities. It may be worth obtaining a copy of it and perhaps ISO/IEC/IEEE 12207, which provides a high-level definition of many different SDLC activities and process areas.

1

Security testing services in the IT industry ensure that the application is tested for all possible threats and vulnerabilities, followed by implementing all the measures to make the product more secure.

Security Test Plan is to:

  • define security goals through understanding security requirements of the applications;
  • identifies a scope of the systems of interest,what resources (software, hardware, infrastructure, people external to the team) are required
  • identify the security threats;
  • Exposed design vulnerabilities--can be caused by an immature design or development process.
  • security vulnerabilities in the file system;
  • security vulnerabilities in the registry;
  • exposed implementation vulnerabilities that may occur because of implementation errors:- Developers who develop only their modules could unintentionally reveal data: for example, incorrect validation;

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.