How to Maximize the Effectiveness of Your Dynamic Testing Policies

Many types of policies govern our security management and security assessments. These policies define what to do with or how to process the results of a scan.

However, we have other policies that define what to scan, when to scan and how to scan it. The what should be everything. The when is governed by release requirements and can be scheduled. The how is much more complicated.

The how is usually a set of settings and configurations that help achieve different goals in terms of speed, completion, optimization and so on. When performing static analysis (SAST), configurations can help the scanner “understand” the application code better. For example, defining custom sanitizers and the taint propagation state of certain functions yields a more accurate set of results with less noise. In dynamic analysis (DAST), we would define navigational parameters or redundancy tuning so the scanner will “understand” their roles in the application and treat them correctly.

The configuration of the scan is improved continuously to reduce the need for manual setting of the policy. In SAST we introduced Intelligent Code Analytics (ICA) so the role of certain functions and APIs can be identified mostly automatically. In dynamic analysis (DAST) we use DOM comparison mechanisms to optimize the scan without hard limits or complex redundancy tuning.

Not static, dynamic

There is another policy that is a part of the how but is a little different. It defines which rules to use when testing an application. Specifically, we’ll talk about DAST rules.

In HCL AppScan, we call these test policies. Test policies are the set of rules used when testing an application.

Any group of rules can make up a policy: you can select a list of categories and scan for issues within those categories and/or you can select high severity issues only and test for critical flaws.

But there is another grouping that makes more logical sense for various stages of development: dynamic testing rules can be of type application, third party, or infrastructure:

• Application rules test for logical issues that would be found in the application code itself. These are vulnerabilities introduced as part of the development process, found in the code-base of the organization’s development group. Resolutions are typically a code fix or change.
• Third party rules test for issues introduced by using third-party components. These are designated by having CVEs assigned to them and resolution is typically to upgrade the relevant components.
• Infrastructure rules test vulnerabilities in the platform that runs the web application or service. These rules are relevant to the web or application server, certificates used during communications, and so on. These could also be configuration issues or issues in service applications that are a part of the server. Resolution typically would be configuration changes, often performed by a DevOps or Ops IT teams.

Decisions, decisions

When running scans at various stages of the development lifecycle, it may or may not make sense to run different sets of tests.

For example, if the server is a development server then it doesn’t make sense to run Infrastructure tests. The server is less likely to be configured correctly and you are less likely to want to fix it. However, if you’re scanning a staging or production server, then it’s critical to run these tests. You may run a scan with a test policy that includes only infrastructure tests so the result will include only those types of issues since they are often handled by someone other than the development team.

Application tests would certainly be used for continuous integration scanning. Such tests are designed to identify vulnerabilities as they are coded into the application. As mentioned, infrastructure tests should be excluded at this stage as they generate mostly noise.

Third-party components don’t change that often and introduction of these components is normally done as part of a clearly defined process. There is really no need to run all the tests all the time; set a specific time to run only those tests. Although better caught during the development stage with our Open Source Analysis (OSA), AppScan Source can catch it dynamically just in case anything slipped past.

Third-party rules tests should run periodically as new vulnerabilities can be published. In addition, third- party issues can sometimes be mitigated by turning off specific functionality that’s not needed. In that case, running a dynamic scan would validate where the functionality was disabled successfully.

Become effective

One of the important goals of security testing (aside from securing our applications and protecting our customers and our data) is efficiency and clarity. We want to be as thorough as we can be, but if we run the wrong tests at the wrong time, all we’ll get is noise. It is easy to lose focus, and in some case interest, when overwhelmed with mostly irrelevant information.

​Focusing on getting the results needed for the relevant situation and at the right time increases our efficiency in both scan time and issue triaging. Designing the correct test policy for the desired result of the scan is crucial to achieving these goals. Take the time to investigate the options for defining policies and to think about the intent of the scan and its results.

Learn More

To learn more about AppScan’s technical capabilities, please request a demo now.