Introduction

In large enterprise deployments of QualysGuard, Business Units are often used to create autonomous user groups. Users with the Manager role start creating the the Asset Groups for use by the Business Units, typically with users in the Unit Manager role.

This is often a side effect of how the Business Units were configured but it is not the normal or recommended behavior for QualysGuard.

This article presents a best practice for Business Unit creation that will grant full configuration flexibility to both Managers and Unit Managers within their respective perimeters.

How-To

Consider the following configuration:

There are two business units, one for France and one for Germany. Jack Doe, who is the Manager for the subscription, has created 4 objects: 2 Asset Groups ("DE" and "FR") and two Business Units ("Business Unit FR" and "Business Unit DE").

The "Asset Group FR" becomes the Asset Group that is used to define the full perimeter for "Business Unit FR". Likewise, "Asset Group DE" defines the full perimeter for "Business Unit DE".

The Business Unit Managers Jenny Doe and Jessica Doe then follow the company's naming convention to create the Server and Workstation Asset Groups for their perimeter. They do this based on the IP addresses that were made available to them from the Manager, as defined by the Asset Groups "FR" and "DE".

Given this set-up, the Manager is free to use or change the Asset Groups of the Business Units, even if they belong to Jane or Jessica. Such as:

add IPs to the Asset Group "FR_servers", provided the IP was first added to "FR" Asset Group,

remove IPs from the Asset Group "DE_workstations",

run a report against "FR_servers" and "DE_servers" to compare.

The Unit Managers in turn are free to edit (add/remove) IPs to their Asset Groups as they see fit.

If, on the other hand, the Manager Jack Doe were to have created the Asset Group "FR_servers" and then assigned it to "Business Unit FR", then the user Jane Doe would not be able to edit it, i.e. remove IPs or add IPs. All maintenance of the Assets in the Business Units would then inevitably become the responsibility of the Manager, Jack Doe.

Edit 15May2015: New illustration to show that Asset Groups are now visible from within the Business Units.

We are slowly moving away from Asset Groups. In some situations I would like to have a "Business Unit" more along the lines of service responsibility. For instance, we have a group that takes care of all the Network equipment such as CISCO; so creating a TAG that based on the OS contains CISCO labels the asset which then grants the users of the CISCO group access to review those assets would be desirable.

That is a very interesting question and what is “right” will depend on what works best for you.

First off: Business Units are a meta-container for access control. The Asset Groups define a perimeter of machines/targets. The Business Units tie these machines/targets to users.

So what you might be looking for is to define a perimeter with Tags, instead of with Asset Groups.

As of writing (April 2018) this is not yet possible in Vulnerability Management, whilst some Qualys applications (such as Web Application Scanning) already define perimeters with Tags.

Vulnerability Management is expected to allow for the definition of access control with Tags in 2018.

Let’s take a look what we can do in the meantime.

Dynamic Tags, where you could automatically Tag a resource as being a Cisco device and therefore in the scope of the networking team, already exist. Such Tags are assigned post scan, based on the findings of a preceding scan.

A key feature of the Business Unit is the possibility for Unit Managers to add targets/machines to a subscription (as well as new users). However, in the situation that you describe, you don’t necessarily know something is in-scope until it has been scanned.

Since you only want items included in a perimeter that users are permitted to run reports against, this particular feature of the Business Unit (which would allow users to expand their view beyond their permitted scope) might not actually help you.

In the short-term, I’d suggest looking at using Dynamic Tags that trigger on the detected OS to mark the targets/machines that are in-scope. Then use our API to synchronize an Asset Group to contain the same assets. This would essentially mean running a query to remove all IPs from an Asset Group, then obtain a list of IPs with a given tag, which you then assign to this same Asset Group. Your reporting users are created with the “Reader” role and are assigned this one Asset Group.

In the future, when Qualys will natively offer access control based on Tags, you can then discontinue the use of the API.

No problem for me to do it just did not know if any other users had the same issue.

Although we are doing more to push data into Splunk to correlate with other data sets and then create dashboard, tickets or whatever the various teams want. I can automate most things in Qualys to the extent the API and my creativity and other data allows but then it is becomes something else to take care of.

As everyone here uses the if I get hit by a bus; never win the lottery; then they would probably just discontinue the scripts.