We have many types of policies that govern our security management and security assessments. Previously, I wrote about security policies. 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 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 role 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 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 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 these 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:
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 servers 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 these 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 these 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 test 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.
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, 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.
Connect with me on LinkedIn