Best Practices for a Web Application Scanning Program at Scale

Document created by Leif Kremkow Employee on Jul 5, 2017Last modified by Leif Kremkow Employee on Jul 13, 2017
Version 4Show Document
  • View in full screen mode

Credits: I'd like to thank Mathieu Doulcet for having shared with me how he built his Web Application Scanning program, which provides the basis for this field-tested recommendation.


Introduction: Qualys Web Application Scanning is able to perform well even in large deployments, where there are many users that are interacting with many web application targets. The organizational model that is used to structure the assets within Qualys will significantly impact how efficiently you can make use of the service. Ideally, the various tasks of the life cycle of managing scanning in Qualys should be broken up according to domains of responsibility to leverage the skills of the multitude of people who will act upon Qualys.


Abstract: Tags are the cornerstone of a successful access control model in Qualys Web Application Scanning. Perimeters are defined by Tags and objects are associated to these perimeters with these same Tags. Objects are private by default and only become shared amongst users when Tagged. A well prepared Tag hierarchy will ensure that scan actions and consolidated reports are easily produced. Wrongly implemented, the Tag based access control coupled with the permissions grouped together into roles can allow users to elevate their privileges beyond their designated scope.


Sketch an Organization Chart

First, create a model of your organization on paper. You’ll most likely already have an internal organizational chart of how the various resources, business lines, and offices are organized and named. Within this model we’ll need to identify the “end users” who are actually responsible for web sites and web applications. This will be the starting point from where we start integrating Qualys Web Application Scanning features with high level concepts to build a real world configuration in the service.


The fundamental building block, or functionality, that we will be working with is the Asset Tag. To allow users to group resources together we use the Asset Tag, or "tag" for short. Tags are assigned to objects in Qualys (user accounts, web applications, etc.) and allow us to act upon a number of assets simply by referring to the tag.


Once Asset Tags have been assigned, objects can be grouped, and roles or permissions can be assigned. See the example below, where we have quick access to all internal systems, using the “Internal” tag that might be assigned them. Likewise, we can use this tag to limit a user to interacting with only these "Internal" resources.


List of web applications tagged "Internal Systems"

Using a Tag to define scope

Small Team of Experts

In many organizations a small team has all the responsibility for managing the scanning and reporting. Because the team is so small there is more to be lost by breaking up the team into silos and areas of responsibility than if they are left to organize themselves. In this case it is likely best that all users be at the "Administrator" or "root" user level by setting the "Allow user full permissions and scope" flag for each of them. See the setting below:


Allow user full permissions and scope


Asset Tags do not serve to restrict the scope of a user. Instead, they are used to consolidate the results from various scan targets into one report or to launch a scan against a multitude of targets.


The Asset Tags are used to group and organize the resources in the account.



Hierarchical / Pyramidal Model

A top layer of users supervise the usage of the service whilst a management layer of users ensure the service is used according to internal policies. The bulk of daily operations is with the end users in remote business units who are tasked with adding targets, running scans, reading/analyzing results, and ensuring issues are fixed.



Type 1


Solicits Qualys Support and TAM for help.
Supports Type 2 users.

Create/edit/remove organizational perimeters.

Create/edit/remove Type 1, 2, or 3 accounts.

Type 2

"Local Administrator" and "Scanner"

Solicits Type 1 users for account administrative functions and support.

Provides organizational support to type 3 users.

Create/edit/remove/configure assets for scanning.

Create/edit/remove/configure scanning of assets.

Create/edit/remove/configure reports of assets.

Type 3


Solicits Type 2 users for help.Create/edit/remove/configure reports of assets.


The following would be the sort of organization chart we could build with such a strategy:













Type 1 User Accounts - the "Administrators"

Amongst the Primary Contact account holder, these users have total control over the subscription. There will be at least one such user, perhaps more. To ensure the expertise is preserved and readily available, it is a good practice to have multiple people in this role. In large organizations, there may even be a named Type 1 user account holder for a given geographical zone or line of business.


This account is by default entitled to "Allow user full permissions and scope". Users holding this account are akin to a "root" or an "Administrator" account and to be used with caution.


Full Permissions and Scope


In this role you should find one user who acts like a pivot between Qualys and the internal user-base. Problems that internal training and/or documentation cannot address would be addressed to the Type 1 user, who in turn will work with Qualys if need be.


The operational tasks that a Type 1 would be executing are:

  • Create/edit/remove Type 2 and 3 user account and assigning them their Role and Tag that defines their perimeter.
  • Adjust global settings such as the connection whitelists or scan expulsion black lists.
  • Create the hierarchy of Tags to best match the corporate organization structure.
  • Define a naming convention for the objects in Qualys.
  • Create user Roles to reflect which users will be grated which privileges.


These types of users should also be checking that the service is being used correctly. Key points to review on a frequent basis are:

  • Have objects been named according to the naming convention? This applies to Web Applications, Tags, Scans, Options Profiles, and Reports.
  • Have all Web Applications been tagged correctly? The web applications needs to carry the correct tags to be in the correct place in the hierarchy of assets. There is a risk that a Web Application that has no tag is “private” to the user who created it and invisible to others.
  • Are web applications actually being scanned? The last “Scan Date” should not have a date too far in the past.
  • Are scans finding results? The “# Pages” count should be some reasonable number (not “0” for example).
  • Finding single-shot assets or user accounts. Generally speaking, for scanning to be useful, it needs to be performed at least twice: once to find problems and then a second time to confirm that the problems found before have been fixed. Furthermore, successfully launching a scan requires a minimum of tuning (such as for the configuration of Authentication Records). Therefore, any target that is not being scanned 3 times a year is not truly participating in the vulnerability management program and possibly consuming a licensing for no tangible benefit.


Type 2 User Accounts - the "Local Administrator" or "Scanners"

Users in a local/business process or information system that are tasked with securing the infrastructure should be provided with Type 2 accounts.


The creation, modification, and destruction of scanning targets will be delegated to local teams. This does generate some noise when tags are not assigned or assets are named incorrectly. Type 2 users are generally expected to oversee this activity to ensure that the integrity of the organizational model is preserved.


This type of user is typically charged with:

  • Adding web applications as an Asset to Qualys. This includes configuration the scanner and creating Authentication Records to enable through scanning of a target. User of Type 3 are generally expected to be as close as reasonably possible to the developers or business owners of a web application such that they have a business understanding of how the target application works.
  • Configuring the scans of the assets in their perimeter. Whether manually launched or scheduled these users can work with the business process owners to identify when would be the best moment to scan the targets.
  • Running reports against the targets in their perimeter. The purpose of this program is to generate actionable data to improve the security posture of the scanned targets. It is therefore vital that the people closest to the target and the business process owner produce actionable reports.


Type 3 User Accounts - the "Readers"

Depending on the complexity of the organization it is at times relevant to have users that are only able to read data. Accordingly, these users will be limited to a given scope via a set of named tags, but unlike Type 2 users, this population will only be able to generate reports from existing scan results.


This type of user is typically charged with:

  • Running reports against the targets in their perimeter. The purpose of this program is to generate actionable data to improve the security posture of the scanned targets. It is therefore vital that the people closest to the target and the business process owner produce actionable reports.


Permissions per User Type



Type 1

Type 2

Type 3

Vulnerability Management Module




Web Application Scanning Module

Allow user full permissions and scope

Allow user view access to all objects





User Permissions




Edit User

Create User Role

Edit User Role

Delete User Role

Access Role Management Section

Asset Management




Tag Permissions




Create User Tag

Edit User Tag

Delete User Tag

Modify Dynamic Tag Rules

Asset Management Permissions




Manage Asset Data Connectors

Create Asset

Delete Asset

Read Asset

Update Asset

Web Application Scanning




WAS Asset Permissions




Purge Web Asset

Create Web Asset

Edit Web Asset

Delete Web Asset

View/download Selenium Script sensitive contents

Edit Web Application URL

Select and Lock/Unlock Scanner Appliance

Scanner Appliance Permissions




Edit Scanner Appliance

WAS Scan Permissions




Launch WAS Scan

Cancel WAS Scan

Delete WAS Scan

WAS Schedule Permissions




Create WAS Schedule

Edit WAS Schedule

Delete WAS Schedule

WAS Configuration Permissions




Create WAS Option Profile

Edit WAS Option Profile

Delete WAS Option Profile

Create WAS Password Bruteforcing List

Edit WAS Password Bruteforcing List

Delete WAS Password Bruteforcing List

Create WAS Search List

Edit WAS Search List

Delete WAS Search List

Create Proxy

Update Proxy

Delete Proxy

Create DNS Override

Update DNS Override

Delete DNS Override

Create Report Schedule

Update Report Schedule

Delete Report Schedule

Create Request Parameter Set

Update Request Parameter Set

Delete Request Parameter Set

Edit Global Exclusion

WAS Catalog Permissions




Edit Web Application Catalog

Edit Web Application Catalog Entry

Add to Subscription Web Application Catalog Entry

Access Web Application Catalog

WAS Burp Permissions




Access Burp Section

Import Burp Report

Update Burp Report

Download Burp Report

Delete Burp Report

Ignore Burp Finding

Purge Burp Findings

WAS Remediation Permissions




Ignore findings

Update findings

Retest vulnerabilities and sensitive content

WAS Authentication Record Permissions




Create Authentication Record

Update Authentication Record

Delete Authentication Record





Reporting Permissions




Create Report

Edit Report

Delete Report


Hierarchy of Assets

The Roles and Scopes within Qualys will determine what a user is able to do and what resources they may act upon.


The Tags will offer a mechanism by which to organize the assets. It is important for companies to determine how they are organized and define a method by which to map this into Qualys’ Tag system.


Note that Qualys is not prescriptive in how this mapping is done or how the organizational tree is normalized.


To illustrate how multiple organizational models can coexist in the same account, see the below example Tag hierarchy for the “ACME” company.


Example Tag Hierarchy


The Tags within Qualys are hereditary. This means that Tag “POSIX” is a branch of Tag “HQ”, which in turn is a branch of the root Tag “All ACME”. A report against Tag “POSIX” will only include resources Tagged “HQ”. However, a report run against “All ACME” will automatically include everything tagged “HQ” and “POSIX”.


This applies to launching reports that automatically consolidate results. Likewise, this applies to access control. A User who will have been given access to the Scope “POSIX” will only be able to see the resources tagged with “HQ”. Another user who might be given the “HQ” scope will be also be able to act upon the assets tagged “POSIX” and “Microsoft”.


The Tags “Asset Groups”, “Business Units”, “Cloud Agent”, and “Malware Domain Assets” are automatically generated hierarchies from other services. In best practice presented here, they should not be used to access control definition.


Foot Notes

IPs and Web Apps are not the same

IPs and WAS applications are not organized in the same fashion.


IPs are subject to Asset Groups, Business Units. Qualys defines the Roles (Manager, Unit Manager, Scanner, Reader) for users to control what users are able to do.


Web Applications are subject to Asset Tags and user definable Permission profiles, i.e. Roles.


The two do not functionally overlap and access control needs to be applied simultaneously in different ways to organize assets.


Perimeter ControlPermission Control
Vulnerability Management
Scan targets are IP addresses.

Asset Group

  • The service will ensure that any IP address that is added is also in the appropriate Asset Group.
  • There is no nesting of Asset Groups within each other.
Qualys defined Roles: Manager, Unit Manager, Scanner, Reader.

Web Application Scanning

Scan targets are URLs.

Asset Tags

  • The service does not force the user to set tags on web applications.
  • There is a hierarchy of Tags allowing perimeters to be nested within each other.
Users may redefine Qualys default Roles or create their own.


Asset Tags are Global

Objects (Options Profiles, Web Applications, Schedules, …) are private by default. When an object is created, it is not Tagged, and therefore visible only to the user who created the object.


So that resources can be shared across multiple users, the user creating the asset must assign the proper Tag to the object.


Asset Tags are Global

The hierarchy of Tags of a subscription only exists once and is shared across all users.


Due to this, it is recommended that there be a policy and procedure around who is permitted to create Tags, how the Tags should be used, and a naming convention. The closer you get to end users (Type 2, 3, and 4 in our example), the less this population should need to create tags. Instead, they should simply be using the Tags provided by others.


From the moment that a user is permitted to create Asset Tags, this user can create them anywhere and name them anything.


This often leads to people to not respecting the hierarchy and/or the naming convention due to either not being aware of the side effects, or thinking that this is only a quick exception that is later forgotten about.


As a result it pollutes the organization and assets are created twice because people can't find the original asset.


No Ticketing System in Web Application Scanning

Qualys Web Application Scanning does not currently offer a ticketing system as is found in the Vulnerability Management module (where it is called "Remediation").


Like the Vulnerability Management system, Qualys Web Application Scanning is able to track changes in scan reports to highlight New, Fixed, or Ignored vulnerabilities.


Users should build report templates that allow them and their teams to see where their vulnerabilities are and measure progress when fixing them.


Single Use Applications

Many users will want to scan something just once - this generally leads to people adding/configuring all sorts of things outside of the projects policies and procedures.


Scanning something once should not be allowed. This will consume a license for little added value.


In order to build a vulnerability management system, targets need to be scanned multiple times. Typically at least twice: once to detect the status of the vulnerable target and once to follow-up to confirm any vulnerabilities that were found previously have been fixed.


If there are authenticated scans, there are likely to be a few more scans just to configure and fine tune the authentication records.


Any application that is only scanned once a year is unlikely to produce value in a process that is supposed to iteratively improve the security of the information system by progressively resolving vulnerabilities.


You need a clean-up process

You should expect to clean-up the Qualys subscription:

  • Tags: Are they on the right branch? Have they been named according to the naming convention?
  • Web Applications: Are there duplicates? Are they named according to the naming convention? Is the target being scanned? Is the scan finding pages?
  • Perimeter: Is everything that should be scanned being scanned?
  • Users: Are there any stale user accounts? Are there Roles being created/assigned that do not follow architecture/strategy defined?
1 person found this helpful