The open source tool setup_scanner enables high-volume programmatic provisioning of QualysGuard scanners before deployment to virtualization infrastructure scanners. Setup_scanner was published on GitHub by Qualys' Jeffrey Leggett.
What’s your name and title?
Jeffrey Leggett, API and Integrations Product Manager at Qualys.
Besides living and breathing Qualys, how do you enjoy spending your free time?
I am an avid CrossFitter and mountain biker. Sleeping and eating rank up there, too.
Tell us more about what your scanner appliance app does.
I’m building an entire automated scanner deployment process for a customer to deploy thousands of scanners — one in every one of their retail stores.
Make your Qualys data your own by synchronizing it locally. Though report templates are an easy way to set up and distribute that data, they are typically not flexible enough to meet the unique requests from unique teams that crop up over time. Synchronizing your Qualys data locally and enabling all teams in your organization to query it locally, will give you the most scalable access to your data.
Mark Alvarez’s submit_ticket script on GitHub is an open source QualysGuard integration app that makes remediation tracking in CA Service Desk easy. Mark described it in detail in the document, CA Service integration app, also known as "Managing Gazillion Vulnerabilities".
1. Tell us your name and recent infosec titles you’ve carried.
My name is Mark Jayson Alvarez. For the past 10 years of my career, my job title has gone through several incarnations. I used to be a “Security Engineer”, a “Systems Engineer, Security”, an “IT Security Administrator”, “IT Security Consultant”, and now my job title says that I am an “Information Security Analyst”. My favorite of all though is when I was still called a “Science Research Specialist” in my first job (a fancy term for Systems Administrator). And since you’ve asked, other titles that I’ve had but never really used except in my CVs are CISSP, CISA, CEH, CISM.
<strong>Multiple scanner appliance selector</strong> is an open source tool written by Michael Calvi that automates the dynamic assignment of scanners to QualysGuard target hosts. The tool helps increase scanning efficiency across large networks. Given the niche problem Michael chose to solve, I wanted to learn more about it.
As 2013 comes to a close, enterprise partnerships and mergers and acquisitions in the techsector have continued to occur at billion dollar levels. One can infer there is much to gain from adding the confidential intellectual properties of others. The true puzzle is understanding if the intellectual properties are, in fact, truly confidential. After all, what is the value in acquiring trade secrets if they are not secret?
Let’s assume you know where every host in your environment is. Wasn’t that a nice thought? The reality is probably that your environment is constantly changing. Knowing is half the battle, so performing this network reconnaissance is essential to defending it.
Tag, you’re mapped!
A common use case for performing host discovery is to focus scans against certain operating systems. This can be done a numberof ways in QualysGuard, historically via maps or light scans followed by a manual workflow. Today, QualysGuard’s asset tagging can be leveraged to automate this very process. By dynamically tagging hosts by their operating system, one can split up scanning into the following:
Frequent light scans that update QualysGuard with the current mapping of your network via dynamic asset tags.
Targeted complete scans against tags which represent hosts of interest.
We step through how to set up your QualysGuard to do exactly this below.
The Terminator exposed it, the DARPA Grand Challenge rewards it, and Selenium puts its future in your hands. "It" is man versus machine… well, sort of. With Selenium, you are in control. Why link Selenium to the Terminator? Because it is that powerful.
As explained in the blog post above, Selenium scripts are often used to automate complex web app interactions such as authentication when scanning them via QualysGuard Web Application Scanning. Here we introduce a different use-case where we automate a QualysGuard subscriber’s interaction with the QualysGuard Vulnerability Management user interface, in order to demonstrate a best practice and make it easy to adopt — simply by running a Selenium script.
Make it happen
In a previous blog post about customizing Scorecard Reports, a fellow community member came up with a pretty good list of criteria of vulnerabilities to watch out for. Let’s take a closer look at creating a dynamic search list tailored to externally facing hosts. For such hosts, an initial starting point for discovering their "worst off the worst" vulnerabilities are those with the following criteria:
Remote (no authentication necessary) vulnerability.
Associated with a penetration testing toolkit (such as CORE or Exploit-DB).
Confirmed, severity 5 (easy segue to "game over").
Now I can show you screen shots of how to create this, but it’s so much easier to just create a Selenium script — by the way, it’s easier for you to run the script, too!
Open Firefox, log in to QualysGuard. While in QualysGuard, make sure you do not already have a search list with the name, "Remote exploit-available confirmed sev5 (Selenium)", or the script will error out.
From Firefox, Tools menu –> Selenium IDE
From Selenium IDE, File –> Open –> Open test case –> "create/Selenium test case, QualysGuard, create dynamic search list – remote exploit-available confirmed sev5.html". Check out the source, it is commented so you can see how it breaks apart building the search list.
Optional step. The script works at any speed, but if you would like to actually watch it work, I recommend slowing the execution down. Drag the speed bar from Fast to Slow so it’s easier to follow the script.
We are ready to run the script, also known as a test case in Selenium. Click on the "Play current test case" button. (Note this will play the test case that is shown in the right column under "Table | Source".)
Congratulations! You now have the dynamic search list we architected from our example. It’s called "Remote exploit-available confirmed sev5 (Selenium)".
You should see the dynamic search list under the "Search Lists" subtab (blue bar).
Note the criteria is optimized for externally facing hosts, as we described above:
Make it actionable
Pretty neat stuff, huh? But a search list on its own is not the most useful. Let’s create a report template that builds on it. Scratch that, let’s automate building of a report template that uses it.
Make sure you are still logged into QualysGuard inside of Firefox.
The test case creates a report template named "Remote exploit-available confirmed sev5 (Selenium)". So you want to make sure you do not already have a report template with the same name.
Load up the test case ("create/Selenium test case, QualysGuard, create report – remote exploit-available confirmed sev5.html") in the Selenium IDE. Check out the source, it is commented to explain how it accomplishes building the report.
Run it! It works at any speed.
After the test case completes, you will have a report template that uses the dynamic search list we just created.
Note the template filters against the search list we just created:
Make it easy
Now that we have built individual test cases for creating a search list and report template, let’s merge them into one step. Rather than copy and pasting the rows from one script into another, the Selenium IDE offers a much cleaner way via test suites.
Test suites offer a more coupled integration of test cases. This enables visible separation for troubleshooting individual test cases, while remaining transparently functional as a whole to the user. When we want to run a test suite, we click a different button from the Selenium IDE:
Let’s get started on running one together.
Confirm you are still logged into QualysGuard.
Before we recreate the report template and search list, we will need to delete the existing ones, as QualysGuard requires unique names of each. You can either delete them manually, or run the test suite, "Selenium test suite, QualysGuard, delete remote exploit-available confirmed sev5 report.html" that does it for you — try it, it’s not just for the lazy! Remember to click on the play button with multiple lines to its right, and it will delete both the report template and the search list.
Open the test suite, "Selenium test suite, QualysGuard, create remote exploit-available confirmed sev5 report" that combines the above test cases.
Run the entire suite. It will start to create the search list from the first test case, and then automatically progress to create the report template from the second test case.
Congrats! You now have both a search list and report template. Easy, huh?
Make yours the next big hit
Now that we are able to create search lists and report templates associated with those search lists in one simple step, what’s next? Collaborate! Share your favorite search list, or report template, or both. Feel free to comment the criteria, or QIDs (one can also automate creation of static search lists, too).
If you are feeling ambitious, and want to create Selenium scripts of these reports, feel free to modify the ones we demoed. I am here to help if you have questions, just comment on this post. To get things started, I shared one more test suite that you may find useful (great for creating policies in Remediation):
You can find the above script (and more to come!) by searching for the tag, selenium_script. Help us grow QualysGuard automation by contributing! If you need help or have a request, just comment on this post… I’ll be back.
For Operations teams that have a patching cycle in place, it makes sense to align their vulnerability reporting with their patching cycle, so that they can show which vulnerabilities were remediated by each patching cycle. Since scanning and reporting can’t always be timed with the patching cycle, one solution is to create a report that excludes vulnerabilities that were published within a given patching cycle.
With the recent release of QualysGuard 7.4, it’s possible to create a dynamic search list based on publish date, i.e. a report that aligns with the patching cycle:
Advanced Search Capabilities for Dates in the Vulnerability Knowledge Base and Search Lists: Now users can create search queries such as “past 60 days” or “past month” for the Published Date, Service Modified Date and User Modified Date, so it becomes easy to generate reports that only focus on a specific time frame such as the past month, without the need to manually edit the filters.
With this capability, we can also create a report to exclude the vulnerabilities published after a specific date, basically the inverse. So let’s do an example together. We will create a technical report that excludes vulnerabilties older than 30 days.
Creating Reports Based on Dynamic Search Lists
First create the dynamic search list, and within the List Criteria, modify the Publish attribute to the number of days you wish to exclude from your report. Below is an example search list to find vulnerabilities published in the last thirty days:
Now we create a report template to exclude vulnerabilities found from this search list.
Note that bullet for Complete is enabled. This sets the base scope of vulnerabilities. From this set of vulnerabilities, we remove "Vulnerabilities published from the last 30 days". One can tweak this report (Save As… is great for this) to cater to the report audience. For example, create a report template for just MSFT vulnerabilities, and exclude any vulnerabilities that were published in the last thirty days–you do not need to create a separate search list for the Exclude QIDs.
Showing management progress in your vulnerability management program is a sure fire way to help remove the stigma of being the "bad news bearers" team. Progress, of course, can be a daunting task when the number of new vulnerabilities per year reached thousands years ago. One way to attack this problem by getting the most bang for your buck is by remediating the most prevalent vulnerabilities — this can also reduce the average time per host for vetting the vulnerability.
QualysGuard’s Scorecard Report
QualysGuard offers a report, what we call a scorecard report, to filter out exactly this information. The scorecard report’s default setup is to display the most prevalent confirmed vulnerabilities from severity 3 on up. What may make the most sense to your organization is to reveal the most prevalent confirmed severity 5 vulnerability, as these are the most dangerous — not to mention severity 5 vulnerabilities include kiddie scripts, what a way to get owned!
Severity
Level
Description
Serious
Intruders may be able to gain access to specific information stored on the host, including security settings. This could result in potential misuse of the host by intruders. For example, vulnerabilities at this level may include partial disclosure of file contents, access to certain files on the host, directory browsing, disclosure of filtering rules and security mechanisms, denial of service attacks, and unauthorized use of services, such as mail-relaying.
Critical
Intruders can possibly gain control of the host, or there may be potential leakage of highly sensitive information. For example, vulnerabilities at this level may include full read access to files, potential backdoors, or a listing of all the users on the host.
Urgent
Intruders can easily gain control of the host, which can lead to the compromise of your entire network security. For example, vulnerabilities at this level may include full read and write access to files, remote execution of commands, and the presence of backdoors.
Let’s step through how to edit the scorecard report to make it more useful to you. In this example, we will edit the scorecard report to only show the most prevalent severity 5 vulnerabilities.
First open up the Scorecard Report wizard.
Now select the included "Most Prevalent Vulnerabilities Report", then click the "Edit" button in bottom left.
In the Filters section, change the Confirmed Vulnerability Type.
Click Save As…
Name the scorecard something more useful now that we’re only showing confirmed severity level 5 vulnerabilities.
Now run your new report by clicking on the run button instead of the edit button.
After the fix, show it off!
Post remediation, give your operations team credit by focusing on the number of vulnerabilities remediated, rather than the number of types of vulnerabilities. What this means is, communicate the total number of hosts for each vulnerability, rather than "we eradicated these ten vulnerabilities" from the top ten report.
Not only is the total a more accurate metric of your security posture, but it is also a much higher number, too! Gains communicated like this will foster a more positive relationship between you and Operations, as well as with management.
