From time to time, the field engineering team and I see the same request cross our desks in a short period of time. This time it was how to remove certain types of audits from running when performing a vulnerability scan originating from Retina CS. The old way of doing things would have required the user to manage the scan report templates, verify the audit group the that particular scan report template was using, and then modify that audit group. This type of modification requires that the user go through the audit group and find each audit that they didn’t want to run and deselect them from that audit group. Since the audits were all focused on "default password", "default credentials", or "default user", we started searching for these audits within the Retina CS audit group management.
Realizing this wasn't a very efficient process (as we discovered many related audits we needed to disable), we were wondering if there was a simpler way to do this. Surprisingly, this kind of thing can be handled quite efficiently by Retina CS. The answer is Vulnerability Smart Rules.
The idea behind this is to utilize an existing audit group within Retina CS, say the "All Audits" group and then define what kind of audits you don’t want in your new Vulnerability Audit Group based on something like a word in the description within the audit. The example below shows how to define the rule containing our parameters for the new Vulnerability Audit Group:
Now that the audit group has been defined to not contain any audits that contain the "default user", "default creds" or "default password", we can search to ensure none of these audits are found within the new audit group created:
We can then tie this audit group to our scan report template that we want by dragging our new Vulnerability Audit Group to our audit group selection within our report ensuring that these audits will not be included:
This technique will automatically keep the Audit Group up to date with the latest audits and add or remove them when things change. It is a simple technique that shows the advance power of Retina CS and automating scans based on what checks to perform (or not perform) for your individual business needs. For more information on Retina CS, please click. The field engineers and I would be happy to show you this can reduce the time it takes to maintain your scan jobs.
Realizing this wasn't a very efficient process (as we discovered many related audits we needed to disable), we were wondering if there was a simpler way to do this. Surprisingly, this kind of thing can be handled quite efficiently by Retina CS. The answer is Vulnerability Smart Rules.
The idea behind this is to utilize an existing audit group within Retina CS, say the "All Audits" group and then define what kind of audits you don’t want in your new Vulnerability Audit Group based on something like a word in the description within the audit. The example below shows how to define the rule containing our parameters for the new Vulnerability Audit Group:
Now that the audit group has been defined to not contain any audits that contain the "default user", "default creds" or "default password", we can search to ensure none of these audits are found within the new audit group created:
We can then tie this audit group to our scan report template that we want by dragging our new Vulnerability Audit Group to our audit group selection within our report ensuring that these audits will not be included:
This technique will automatically keep the Audit Group up to date with the latest audits and add or remove them when things change. It is a simple technique that shows the advance power of Retina CS and automating scans based on what checks to perform (or not perform) for your individual business needs. For more information on Retina CS, please click. The field engineers and I would be happy to show you this can reduce the time it takes to maintain your scan jobs.
