By Cody Dumont
A common question asked by our customers is “Are we compliant with ____?” Regardless of the standard to which your organization must be compliant, the question still remains “Are you compliant?” and “Can you prove it?” In a previous blog post on Security Frameworks Based Auditing with Nessus, Justin Brown explains how to use Nessus® and compliance audit files. The compliance audit files are also supported in SecurityCenter™. The initial scanning with audit files in SecurityCenter are basically the same, but there a few differences that should be highlighted.
Updated templates in the feed
The SecurityCenter feed gets updates to the audit file template automatically whenever new files are created or existing files are updated. This means there can be new updated audit file templates each morning when you log in to your SecurityCenter. Please note, the new templates do not update the audit files you have installed from the template. But there could be a new template for you to review and potentially use to replace your existing template.
Audit file type searches
When using Nessus, each of the audit file types has a corresponding plugin ID; however in SecurityCenter, the audit file plugin ID is not used. In SecurityCenter when you install an audit file, a new plugin higher than plugin ID 1000000 is created for each check. To retain the audit file type, there is a cross reference called “auditFile”. In the Reference Information of the Vulnerability Detail List tool, you can see the auditFile value. When adding a filter for the audit file type, the XREF Type, left side of the pipe (|), is the auditFile type. To the right of the pipe (|), the XREF ID is placed. For example “auditFile|bluecoat” would locate any audit check used to audit an Bluecoat configuration. There are currently 29 auditFile types:
- adtran (Adtran NetVanta)
- amazon_aws (Amazon AWS)
- as/400 (IBM iSeries)
- bluecoat (BlueCoat ProxySG)
- brocade (Brocade FabricOS)
- checkpoint (Check Point GAiA)
- cisco (Cisco IOS)
- database (Database)
- dell_force10 (Dell Force10 FTOS)
- extreme_extremexos (Extreme ExtremeXOS)
- filecontent (Unix File Contents)
- fireeye (FireEye)
- fortigate (Fortigate FortiOS)
- hpprocurve (HP ProCurve)
- huawei (Huawei VRP)
- juniper (Juniper Junos)
- mongodb (MongoDB)
- netapp (NetApp Data ONTAP)
- ovalUnix (OVAL Unix)
- ovalWindows (OVAL Windows)
- palo_alto (Palo Alto Networks PAN-OS)
- scapLinux (SCAP Linux)
- scapWindows (SCAP Windows)
- sonicwall (SonicWALL SonicOS)
- unix (Unix)
- vmware (VMWare vCenter/vSphere)
- windowsfiles (Windows File Contents)
- windows (Windows)
- xenserver (Citrix XenServer)
Cross Reference searches
In Justin’s post, he discussed the reference line. This line is heavily used in the SecurityCenter dashboards and reports. First let’s dissect the Cross Reference filter. The Cross Reference filter, XREF in assets, can be used by entering a combination of the XREF Type (left side) and XREF ID (right side). As of SecurityCenter 5.4.0, the wild card (*) can be used with the XREF ID (right side). The XREF Type is the the acronym or shortened version of the compliance standard. For example, NIST 800-53 uses “800-53.” Some standards have different variations, for example PCI-DSS has: PCI-DSS, PCI-DSS-2.0, PCI-DSS-3.0, PCI-DSS-3.1, and PCI-DSSv3.1. As Justin and his team continue to make updates to the audit files and continue to normalize the XREF Type, many of these variations could change. If your audit files are older or were customized long ago, the reference fields may be out of date and be unable to take full advantage of the new cross references. We recommend reviewing the newly updated audit files so you receive the benefit of the new cross references.
When searching using the Cross Reference field, the XREF TYPE and XREF ID are separated by a pipe (|) character. If the filter should search for more that one XREF TYPE and ID combination, then separate the two phrases with a comma. The comma-separated field acts as a logical OR. Here are a few examples:
- Cross Reference = 800-53|AC*
- Would be a match for AC-1, AC-2, etc.
- Cross Reference = 800-53|AC-1
- Would be a match for AC-1, but not AC-11
- Cross Reference = 800-53|AC-1*
- Would be a match for AC-1, AC-11, AC-12, etc.
- Cross Reference = 800-53|SC-7 (5),800-53|SC-8
- Would match 800-53|SC-7 (5) or 800-53|SC-8
- Cross Reference = 800-53|SC-7*
- Would match 800-53|SC-7 (5), 800-53|SC-7, 800-53|SC-71, etc.
- Cross Reference = 800-53|*
- Would match anything with 800-53 any xref type
- Cross Reference = 800-53|*7
- Would match anything with XREF ID ending in 7
- Cross Reference = 800-53|S*-7
- Would match anything with XREF ID beginning with S and ending with “-7”
- Cross Reference = auditFile|windows,800-53|S*-7
- Would match anything with XREF ID beginning with S and ending with “-7” or anything with auditFile|windows present. Keep in mind that all Windows audits would match, and any Linux with 800-53|S*-7 present.
Shown below is a sample view of the Vulnerability Analysis screen for an audit result. In the lower right hand corner of the screen, you can see the Reference Information and the Cross References line. The cross reference mappings in the Reference Information section come from the Nessus scan results, while the Cross References are obtained when installing the audit file. In most cases, these two sets of data will be the same; however, if the audit file is updated, there could be some old data where the fields are not the same. When this inconsistency occurs, Tenable recommends running the audit scan again so the Nessus data will be updated.
Dashboards, reports, and ARCs
Tenable provides many dashboard, report, and ARC templates that use the cross reference fields. A recently published dashboard for HIPAA compliance provides a detailed example for using the cross reference fields. In Justin’s blog post, he discusses how an analyst can use a cross reference for one standard to map to another standard. The HIPAA dashboard uses this approach to identify systems that are compliant or not compliant with HIPAA regulations. One of the matrices HIPAA – Administrative Safeguards: Security Awareness & Security Incident Procedures (164.308 A5-A6) has a cell with the filter HIPAA|164.308(a)(5)(ii)(A),800-53|RA-3,CSF|ID.RA-3. This filter shows how the analyst can run scans with CIS audit files, and still perform audits for HIPAA, CSF, and NIST 800-53.
Tenable SecurityCenter and SecurityCenter Continuous View™ provide a unique combination of detection, reporting and pattern recognition, utilizing industry-recognized compliance standards. With more supported technologies than other vendors, SecurityCenter provides compliance support for operating systems, network devices, hypervisors, databases, tablets, web servers, and critical infrastructure.
Source:: Tenable Blog