All Posts in Qualys Technology

473 posts

Filtering Frameworks within Policy Compliance

Do you ever want to see the control mappings in a report without doubling or tripling the size of the report? What about excluding certain control mappings from the control API to limit data exported? With the release of QualysGuard 6.17, users can now filter the frameworks at the subscription and/or report level within Policy Compliance.

The Need for Framework Filtering

The current control knowledgebase includes over 6,700 configuration checks mapped to dozens of frameworks, including the Center for Internet Security (CIS) benchmarks, the Control Objectives for Information and related Technology (CObIT) 4.0 and 4.1, the Health Insurance Portability and Accountability Act (HIPAA), etc.  These extensive mappings create a large number on control/mapping pairs available in the subscription.  For the majority of organizations that require only a subset of this data, the current data is too large to consume.

Filtering Frameworks with Policy Compliance

In order to limit the number of control/mapping pairs, QualysGuard 6.17 introduces the capability to limit which frameworks are displayed in the subscription and/or reports.  Each filter is described in detail below:

Subscription Filter

A subscription level filter will reduce the number of frameworks available for view in the subscription, which includes control search, reports, and the control API. Applying this filter will not filter the Controls knowledgebase, just the framework mappings visible in the subscription.

All available frameworks are enabled by default in the subscription. Change which frameworks are visible by selecting Setup/Frameworks… from the menu. Once the frameworks have been filtered, the following areas of the subscription will be affected:

  1. The Control API will limit the framework mappings in the output when the parameter “details=All” is set.
  2. The Search dialog within the Controls knowledgebase will limit the framework mappings based on the subscription settings.
  3. The Report Templates will limit the framework mappings based on the subscription settings if the Glossary or External Mappings sections are selected.

Report Template Filter

Frameworks are filtered in reports based on the subscription settings, but this feature also allows additional filtering in reports. The report level filter will reduce the number of frameworks available in the reports only.

All available frameworks in the subscription are enabled by default in reports. Change which frameworks are visible by selecting the new tab, Frameworks, in the report template.  Once the frameworks have been filtered, reports using this template will only show the selected frameworks in the Glossary or External Mappings sections, if selected.

Demo and Technical Paper

To see a demo of these steps, please view the Filter Framework Demo.

For full technical details on Filter Frameworks, please download the QualysGuard Tips and Techniques, Filter Frameworks Document.

Notifying Users of New Controls

Ever wonder when new controls are published for Policy Compliance?  You’re not alone.  With the rapid increase in Policy Compliance Control IDs (CIDs) over the past year, many customers wanted a more proactive notification of new content.  We have heard you loud and clear.  With the release of QualysGuard 6.16, users can now receive weekly or monthly email notifications for new and modified CIDs within Policy Compliance.

Setting Up Control Notification

Control Notification is not enabled by default. To receive email notifications for new and modified CIDs, perform the following steps:

  1. From the Tools section, select User Accounts
  2. Edit the User Account that wants to receive Control Notifications
  3. Click on Advanced
  4. Under Notification Options, select Weekly or Monthly for Latest Controls

Notification Options

Figure 1: Edit User: Latest Controls Notification

Receiving Control Notifications

After enabling Control Notifications, the user will receive an email summarizing the new and modified CIDs for Policy Compliance.

Control Notification Email

Figure 2: Control Notification: Email

In addition, a .CSV file is attached to the email with additional information.

Control Notification CSV

Figure 3: Control Notification: .CSV File


To see a demo of these steps, please view the Control Notification Demo.

PCI Version 2.0 SAQs Now Available

On November 18th the PCI Security Standards Council published version 2.0 of the Self Assessment Questionnaires (SAQs).  These updated documents now align with the new version 2.0 of the PCI Data Security Standard.

The changes to the SAQs mostly involve minor refinements and clarifications, but one major change is the inclusion of a new type of SAQ: C-VT.  This SAQ is a simplified version of SAQ C that is targeted at merchants who use virtual terminals to process payments.  The SAQ defines a virtual termals as:

a web-browser based access to an acquirer, processor or third party service provider website to authorize payment card transactions, where the merchant manually enters payment card data via a securely connected web browser. Unlike physical terminals, virtual terminals do not read data directly from a payment card. Because payment card transactions are entered manually, virtual terminals are typically used instead of physical terminals in merchant environments with low transaction volumes.

Note that data is not read directly from the card, so no card readers or other swipe devices.  The most accurate representation of a qualifying merchant would be someone at a personal computer typing in card numbers and getting authorization codes from a provider like Authorize.Net or Paypal.

Version 2.0 of the SAQs become available in January of 2011, but merchants can still choose to use version 1.2 instead throughout 2011 (you may not mix SAQ versions and DSS versions, however; everything must be either 1.2 or 2.0).  Version 1.2 of both the DSS and the SAQs expire on December 31st of 2011.

In order to provide the most flexibility for merchants, QualysGuard PCI has added support for all version 2.0 SAQs, including wizards to help choose the proper SAQ version (A,B,C,C-VT,D), help text to provide guidance when completing the questionnaire, and full support for the milestone-based prioritized approach to the SAQs.  Version 1.2 of the SAQs is also supported throughout 2011 for merchants choosing to use that version.

We hope you find the new capabilities helpful in achieving PCI compliance, and look forward to hearing your feedback.

More technical resources are available at QualysGuard PCI.

Qualys BrowserCheck: New Linux Support and More Plugins

As we approach the peak of the holiday online shopping season, Qualys BrowserCheck adds new features to help Internet users better protect their browsers.  With today’s new release, Qualys BrowserCheck increases the range of browsers it scans, including Linux browsers, beta releases of browsers, and more plugins.  BrowserCheck also reports zero-day vulnerabilities and makes it easier to upgrade out-of-date plugins.

Here’s a round-up of the new features:

  1. Linux Support: BrowserCheck adds support for Firefox, Chrome, and Opera on Linux to its current support of major browsers on Windows and Mac OS X.  See supported browsers for details.
  2. Plugin / Add-on Support: BrowserCheck adds checks for additional plugins and add-ons. The new checks extend support to Linux for the most popular plugins like Adobe Reader, and add support across all relevant platforms for plugins like DivX Web Player. See supported checks for details.
  3. Beta Browser Support: Qualys BrowserCheck now scans beta versions of browsers including Internet Explorer 9, Firefox 4, Chrome 9 and Opera 11. See supported browsers for details.
  4. Zero-day Vulnerabilities: Sometimes a vulnerability exists, but there is no fix (yet) for it.  Qualys BrowserCheck now detects these zero-day vulnerabilities and points to any available advisories containing recommended workarounds. When the fix becomes available, BrowserCheck is updated to display the Fix-it Button with a link to the download containing the fix.
  5. Easier Upgrades: Wherever possible, we are updating Fix It button links in the scan results to point directly to the download that fixes the vulnerable plugin or add-on, rather than the homepage for the plugin or add-on. This makes it easier to quickly upgrade and protect your browser from the vulnerability.

Thanks to the BrowserCheck users who have reported feedback or enhancements. Your input helps us identify areas of improvement, and have certainly been a factor in today’s release. We encourage you to continue letting us know how BrowserCheck is working for you.

Making Passwords More Secure

Even after you implement policy compliance checks to enforce best practices for strong passwords, your users can still create insecure passwords. They may not be able to create passwords with eight or fewer characters or with only alphabetical characters. But as long as their passwords conform to the policies you implement, your users can create passwords that match their user name or company name. And those passwords are among the easiest to guess.

To prevent this type of password vulnerability, your policy compliance scans need to check the actual passwords of your users, not just the rules governing the passwords they can create. Three of these password auditing checks are now available in QualysGuard 6.15 Update:

  1. CID 3893Empty passwords
    This control identifies user accounts with empty passwords.
  2. CID 3894 – Password matches user name
    This control identifies passwords that match the actual user name or the user name in upper- or lower-case.
  3. CID 3895 – Password matches an entry in the password dictionary
    This control identifies user accounts where the password is equal to an entry in the user-defined password dictionary.

To access your passwords, the scanning engine uses a dissolvable agent on Windows systems to collect user password information from target hosts. The dissolvable agent securely sends the passwords to the scanner for analysis and securely erases its copy of passwords after it completes the tests.

Using Password Auditing

Enable Password Auditing

Password Auditing is not enabled in compliance scans by default. To use this feature, create or edit a compliance profile with the following settin:

  1. Enable Password Auditing controls

    Password Auditing - Compliance Profile
    Figure 1: Compliance Profile : Enable Password Auditing

  2. Accept the dissolvable agent

    Password Auditing - MLDA
    Figure 2: Compliance Profile : Accept Dissolvable Agent

  3. Configure a password dictionary.

    Password Auditing - Custom Dictionary
    Figure 3: Compliance Profile : Configure Custom Dictionary

Run Compliance Scan

Launch or schedule a compliance scan on the hosts that you want to scan for password auditing controls. Select a compliance profile with Password Auditing enabled, and optionally a password dictionary defined.

Add Password Auditing Controls to Policy

Add the three new password auditing controls (Control IDs 3893, 3894 and 3895) to a new or existing compliance policy. These controls are supported for Windows and Unix technologies.

Run Compliance Report

Generate compliance reports to compare the data gathered on your hosts during your compliance scan to the expected values defined in your compliance policy. Each user account that violates a Password Auditing control appears in the Actual field of your report.


Figure 4: Compliance Report with Password Auditing controls

Demo and Technical Paper

To see a demo of these steps, please view the Password Auditing Demo.

For full technical details on Password Auditing, please download the QualysGuard Tips and Techniques, Policy Compliance: Password Auditing Document.

Verizon 2010 PCI Compliance Report

By now, most of you have either read or are aware that Verizon released it’s 2010 Data Breach Investigations Report.  It details the specifics on data breaches and how effective (or ineffective) the the controls are that are being used as countermeasures at organizations that have suffered a breach.  This report slices and dices the data about any which way you can think of and consequently it’s very enlightening.  It calls into question many of the traditional controls that security administrators have used for years and makes one wonder whether or not they actually help at all.  If you have a few minutes, I encourage you to read it.  It can be found here: 

Verizon 2010 Data Breach Investigations Report

However, that is not why I wrote this article as that has been well documented already.  What people might not be aware of is that Verizon also recently released a companion report Verizon 2010 Payment Card Industry Compliance Report.  In this report, Verizon has compiled data surrounding their PCI clients and broken the research down into subcategories and the specifics of the PCI DSS.  As far as I know, this is the first large scale effort at compiling PCI data detailing what customers are doing effectively, what they are not, and then correlating that against actual breaches. 

For those of you that have worked with PCI for any period of time, you are well aware of the debate that rages on as to whether or not the DSS actually makes organizations more secure.  Rather than delve into that argument, I’d prefer to highlight what the data from the report suggests.  According to the report, organizations that suffered a breach were 50% less likely to be compliant than a normal population of PCI clients (clients that are moving towards compliance but have not yet been validated as compliant).  So while the data suggest that organizations that have been validated as PCI compliant are less likely to suffer a breach, some still do get breached.  So, does this mean that PCI works, or doesn’t work?  I’d be interested in hearing your opinions on that.  Feel free to leave comments with any thoughts you may have.

If you are interested in reading the report in it’s entirety it can be downloaded here:

Verizon 2010 Payment Card Industry Compliance

Happy Reading!


Qualys freemium services

Malware Detection service provides automated malware detection on externally facing web sites, automated alerts when malware is found, identification of vulnerable code, Behavioral and Static Analysis methods, no software to install or update. Try it out:
BrowserCheck service allows you to validate the security of your browser and plug-in, and receive suggestions on how to fix identified security holes -  Currently supports IE, Firefox, Google Chrome, Safari, Opera, and Camino. Try it out:
SSL Labs service allows you to test the implementation of SSL on your Internet based web sites.  Try it out at free at:
Qualys SECURE Seal – The Qualys SECURE Seal shows visitors that your web site is maintaining a rigorous and proactive security program.  It incorporates Qualys' Vulnerability, Web Application Scanning, Malware, and SSL scanning capabilities in one.  Sign up for a free trial at
The Qualys SECURE Seal service is currently in beta and when it goes live it will be a paid service.  However, the other services in the list will remain free.  We encourage you to signup and leverage our free services, especially BrowserCheck.  This is a service that you can share with family members and colleagues to improve the security of their browsers and help safely browse the web.  Malware Detection will also help you ensure you’re not unknowingly serving up malicious code to your use base.
Our customers have given us a very positive response, so I encourage you to try them out.  Also, feel free to share these at your leisure.

Qualys has been busy over the past few months; releasing a number of transparent updates to the QualysGuard Enterprise and PCI portals, rolling out the Qualys Community site, enhancing our free training courses and launching a number of free services.  I am writing this post to summarize the different free services that we offer.  Our customers have given us a very positive response, so I encourage you to try them out.  They are as follows:

  • Malware Detection service provides automated malware detection on externally facing web sites, automated alerts when malware is found, identification of vulnerable code, Behavioral and Static Analysis methods, no software to install or update. Try it out:
  • BrowserCheck service allows you to validate the security of your browser and plug-in, and receive suggestions on how to fix identified security holes -  Currently supports IE, Firefox, Google Chrome, Safari, Opera, and Camino. Try it out:
  • SSL Labs service allows you to test the implementation of SSL on your Internet based web sites.  Try it out at free at:
  • Qualys SECURE Seal shows visitors that your web site is maintaining a rigorous and proactive security program.  It incorporates Qualys' Vulnerability, Web Application Scanning, Malware, and SSL scanning capabilities in one.  Sign up for a free trial at

The Qualys SECURE Seal service is currently in beta and when it goes live it will be a paid service.  However, the other services in the list will remain free.  We encourage you to signup and leverage our free services, especially BrowserCheck.  This is a service that you can share with family members and colleagues to improve the security of their browsers and help safely browse the web.  Malware Detection will also help you ensure you’re not unknowingly serving up malicious code to your use base.


PCI DSS 2.0 is out!

The PCI SSC today released a new version  (2.0) of the Data Security Standards. The previous version  1.2.1 was released July 2009. I attended the PCI council community  meetings in September and October where the council went over the  changes with the key stake holders in the process. While the change from  1.x to 2.0 might seem like a big change, in reality most of the changes  are minor clarifications or some additional guidance. The council has  settled on a 3 year update cycle to the DSS and seems like the major  version of DSS with will revved up every three years so expect PCI DSS  3.0 in October 2013. This does show that the standards have matured  enough now that major changes are not required regularly.
The council also talked about the work they are doing to look at  emerging technologies like end-to-end encryption, tokenization and  virtualization. You will see that some of the changes in this version  already reflect recognition of the new technologies and I am sure more  updates will be coming in these areas. The SSC now has a dedicated Chief  Technology Officer who is actively working to make sure the DSS stays  in step with rapid changes in technology.

The key dates associated with the new requirements are

  • October 28, 2010 – PCI DSS 2.0 published. Merchants get the opportunity  to go through the new requirements. The council also updated the  Navigating DSS guide and relevant changes to the Self Assessment  Questionnaires (SAQ)
  • January 1, 2011 – PCI DSS 2.0 becomes effective. Merchants can chose  to validate compliance against version 2.0 or 1.2.1 after this date.  Remember that merchants can’t mix and match some requirements from 1.2.1  and some from 2.0
  • December 31, 2011 – PCI DSS 1.2.1 is retired and can no longer be used to validate compliance against.

Essentially for all of 2011 you can use either version as long as you are fully done with your assessment before end of 2011 if you decide to use 1.2.1

Of the various changes in the DSS the following really peaked my interest …
Requirement 6.2 : Assign risk ranking to vulnerabilities (Internal scanning)
    DSS requires merchants to have a vulnerability management program in  place to identify and fix vulnerabilities discovered in the cardholder  data environment (CDE). With 1.2.1 the merchants were required to patch  and rescan internal networks until 'passing results are obtained'. This  was a bit unclear as to what exactly a 'passing result' is and did not  account for the criticality of the systems within the CDE. Now the SSC  is going to require that merchants come up with a risk ranking for these  vulnerabilities based on industry best practices like CVSS. At minimum  there should be process in place to make critical high risk  vulnerabilities as "HIGH". In simple terms you should look at how  critical is the impact of the vulnerability itself and does it appear on  a critical component in your CDE. A low severity vulnerability on your  database storing cards might be HIGH and a high severity vulnerability  on a backend router might be a LOW.

     While the council has left it open for merchants and assessors  to agree upon which scoring methodology to use, in reality I expect  most merchants to use CVSS 2.0 scoring with its base, temporal and  environmental components to decide what is HIGH. While this does put an  extra burden on the merchant, the good news is that once you have the  process in place you only need to fix the HIGH vulnerabilities to pass  validation for 11.2 internal scanning requirement. While it is still  recommended to fix all vulnerabilities this at least helps prioritize the  work load.

     Note that this is a requirement after June 30, 2012. Recognizing the  extra work needed to put process in place the council has given this  extra time. Till then this is a best practice and you can chose to  follow what is currently in 1.2.1.

     It’s important to remember is that this  scoring and fixing requirement does not apply to 11.2 external scanning  to be performed by ASV every quarter. All vulnerabilities identified by  ASV as failing PCI must be remediated within that quarter and rescanned  till ASV passes the merchant.

Requirement 2.2.1 Virtualization and one primary function per server

      In DSS 1.2.1 the requirement was to implement only one primary function  per server. e.g. Not implement web server function and database server  function on same 'server'. It was not clear in a virtualized environment  if two virtual machines (VMs)

running on the same physical hardware box was considered as two primary functions per 'server'. Now in 2.0 the council makes it easy by saying that in virtualized environments you can have multiple VMs on same physical box as long as each image implements one primary function. So you can have a VM for a webserver and a VM for a database server running side by side but you can’t have one VM with a webserver and database  server on the same image. This should definitely accelerate the use of  virtualization in PCI CDE since clarity for compliance was an issue that  was holding back the adoption of virtualization.

Requirement 6.5 Secure application development best practices

     DSS 2.0 is not tied to OWASP guidelines anymore. There is now room to  use other industry best practices like OWASP, CWE Top 25, CERT Secure  Coding, etc.

Requirement 1.3.5 Outbound traffic from CDE to IPs outside DMZ
     Language in DSS 1.2.1 seemed to indicate that there was no room to have  any outbound connection from CDE to ips outside DMZ even of legitimate  reasons like transmitting encrypted information from one network to  another over SSL port 443. DSS 2.0 says merchants can have outbound  access open as long as there is legitimate reason and the access has  been explicitly authorized by the merchant.

Requirement 4.1.1 WEP as security control

     DSS 1.2.1  indicated there should be no WEP in the CDE at all after June 30, 2010.  But DSS 2.0 has modified the language to say mere presence of WEP in CDE  does not fail you as long as the WEP is not used as the security  control. You can have WEP in the CDE as  long as it is considered like an open wire. This means you need to have  another level of encryption to protect data sent across a WEP  connection, it can’t be plain text because you have WEP. e.g. sending data over SSL on a WEP wireless connection would seem to be ok.

Requirement 8.3 Use of two-factor authentication

      You might find it funny but some merchants were using the same authentication method twice, and folks that is NOT two-factor authentication. Having two different passwords is NOT two-factor authentication. To illustrate that think of a stealth key logger installed on your computer that will be able to steal both your passwords to login and steal data. Because of this,  the council makes it clear you need to have TWO different methods of the following implemented. 1) Something you know, like a password. 2) Something you have, like a token or smart card 3) Something you are like biometric data.

All in all we see the number of merchants adopting PCI increasing.  The council has done a great job at being reactive and responsive, in  an open community based effort, to get the standards to a mature state.  Now they are attempting to stay ahead of the curve with new technologies  in a dedicated effort working with industry leaders. Ultimately we  expect DSS 2.0 to help merchants improve the security of their PCI  networks while providing flexibility with their compliance efforts given  the many different implementations that are out there.

Please post your thoughts on the new version … what do you think?

** The views expressed in this blog are a reflection of the author’s  thoughts on this topic. They should not be considered an authoritative  interpretation of the new or old DSS for purpose of compliance.

QualysGuard adds VeriSign Identity Protection

Hi!  My name is Corey, I have a dog named Sparky, and I really like chocolate.   You now have everything you need to guess my password.

This isn’t a surprise, of course.  Over the last several years research has shown that passwords are often easily compromised:

One good solution to these password issues is to use two-factor authentication, where a user is required to both know something (i.e. your username and password) and have something (such as a generated code from a key fob).  Your debit card is a good example of this:  You need to both know your PIN code and have the physical card in order to access the bank account it protects.   Two-factor authentication has become more readily available over the last few years, and is now a capability that many security-oriented companies are actively pursuing.

Consequently, I’m thrilled to announce that Qualys is now making VeriSign Identity Protection (VIP) two-factor authentication available to all QualysGuard users at no charge, providing an additional layer of protection to keep your data secure.

Subscription Managers can require VIP for all accounts, or individuals can opt-in as desired.  Enabling it for an account is simple with just three steps:

  1. Obtain a credential from VeriSign.  Like QualysGuard, VeriSign VIP is a software-as-a-service offering with no server software to deploy or hardware to manage.  I prefer using their phone-based credential, but their toolbar is also a good choice (as are key fobs for those who like having a physical token); see the complete list of supported devices.
  2. Login to QualysGuard and edit your user settings.  Click “Advanced” and you’ll see the following under the “Options” tab:VIP Activation
  3. Click “Register Credential” and provide the codes requested.Credential Registration

You’re now ready to use VIP Authentication for logging in to QualysGuard.  You’ll still use your username and password (what you know) but will be prompted to provide the code from your credential (what you have) to complete the login process:

VIP Login

Don’t worry if you can’t access your token (who hasn’t left their phone on the kitchen table?); you can request a one-time password that will grant access within the next hour.

We’re excited to help lead the effort to replace passwords with better authentication methods, and look forward to hearing from you on how we can continue to improve our service.  In the meantime, feel free to take that chocolate bar without any guilt!

Trusted scans simplified with Cyber-Ark PIM Suite integration

May 18, 2017: Please refer to Better Trusted Scanning with Qualys-CyberArk Integration.

April 29, 2013: Edited with new screenshot.

Trusted scans collect more detailed vulnerability information than “un-trusted” remote scans. That’s not surprising: with a trusted scan, the QualysGuard scanner logs into the target machine and reads configuration data including registry values and configuration files on the file system, just like a regular user session could. QualysGuard uses the configuration data to verify whether or not certain vulnerabilities exist. When running un-trusted remote scans, QualysGuard collects data by pinging network-accessible services on the target machine and interpreting the responses.  QualysGuard then reports security issues that a remote attacker might use to access those systems. This approach misses local vulnerabilities such as those requiring user interaction from the browser or email client. Also, the response sometimes indicates the machine has a potential vulnerability, but not whether it is a confirmed vulnerability. Often a configuration value available via a trusted scan is required to determine if the potential vulnerability can be ignored or should be classified as a confirmed vulnerability.

For policy compliance, QualysGuard always performs trusted scans because system configuration data is required to verify compliance checks, such as password strength. For vulnerability management (VM) scans, QualysGuard administrators can choose either trusted or remote scans. But they often perform remote scans, even though they would benefit from the more detailed data collected in trusted scans.

In large organizations where thousands of machines are scanned regularly for vulnerabilities, managing passwords is a challenge. Currently administrators must manually provide QualysGuard with login credentials for each asset to be scanned.  Password policies add more complexity; for example if a password ages out and gets changed, then those changes must be passed to QualysGuard so that its passwords remain current. The teams in charge of managing the scans usually don’t own the scanned machines.

Better Manageability with Cyber-Ark Integration

Using QualysGuard integration with Cyber-Ark Privileged Identity Management (PIM) Suite, management is simplified because organizations no longer need to store a copy of their passwords in QualysGuard. QualysGuard stores a pointer to the location of the password information in the Cyber-Ark Enterprise Password Vault® of the PIM suite, and the scanner appliance requests the password when it needs to perform the trusted scan.  Because passwords are maintained in the Cyber-Ark Enterprise Password Vault®, the organization can change passwords at will or by using any policy via Cyber-Ark without having to worry about synchronizing those changes to QualysGuard.


Increased Security, Control and Audit of Login Credentials

While QualysGuard has industry-leading protections on the data it stores, some organizations that are particularly sensitive to password controls now have the assurance the QualysGuard no longer needs to store passwords centrally.  In fact, an organization could set up a password policy to change its passwords via Cyber-Ark PIM Suite immediately after each password is used by QualysGuard to perform a trusted scan.

To revoke access, an administrator only needs to disable one user in Cyber-Ark  instead of changing the relevant password on each target machine. Cyber-Ark can also store an audit trail of all uses to the login credentials.

How it Works

Configurating Trusted Scans: Without the Cyber-Ark integration, an admin configures QualysGuard with the logins and passwords that will be used for the trusted scans. With the Cyber-Ark integration, the admin configures QualysGuard with the Cyber-Ark Enterprise Password Vault® server and the correct safe within the vault where the passwords are stored (see Figure 1) and the Windows or Unix authentication record specifying an authentication vault for a specific trusted scan (see Figure 2).


Figure 1 – Create a Cyber-Ark authentication vault record in QualysGuard


Figure 2 – Create a Windows or Unix authentication record specifying the use of an authentication vault

Running Trusted Scans: When the scan is ready to run, QualysGuard sends a request to the scanner appliance to run the trusted scan.  Instead of specifying the password of the target machine, QualysGuard specifies the IP address of the Cyber-Ark Enterprise Password Vault® server and the name of the safe.  The scanner appliance then passes this information to Cyber-Ark and requests the password for the given username, which it uses to log into the target machine and perform the trusted scan.  After performing the scan, the scanner deletes every trace of the password and sends the scan results back to QualysGuard. The process is done.

Better Information for Stronger Security

For organizations that currently perform trusted scans, password management is now easier and more secure. This integration will hopefully encourage organizations to expand their trusted scanning across their global assets to collect better vulnerability and compliance data from their systems.