Facebook Google Plus Twitter LinkedIn YouTube RSS Menu Search Resource - BlogResource - WebinarResource - ReportResource - Eventicons_066 icons_067icons_068icons_069icons_070

Compliance Summary

by Cody Dumont
October 30, 2015

Compliance Summary Screenshot

Managing Governance, Risk Management, and Compliance (GRC) grows more complex with each newly developed set of regulations or standards. Tenable.sc has the ability to monitor configuration compliance with a variety of standards including HIPAA, NIST 800-53, PCI DSS, and DoD Instructions 8500.2.  This dashboard shows the security manager a summary of compliance checks supported by Tenable.sc.

Performing a compliance audit scan is not the same as performing a vulnerability scan, although there can be some overlap. A compliance audit determines if a system is configured in accordance with an established policy. A vulnerability scan determines if the system is open to known vulnerabilities. Organizations can deploy and customize audit files to meet their local security policy.  Once the audit file is customized, the file can be used with Tenable.sc to manage and automate the configuration compliance process.

There are many different types of government and financial compliance requirements. While these compliance requirements are good guidelines, they often include minimal baselines.  Security baselines are lowest acceptable setting.  For example password length, many guidelines suggest a minimum length of 8 characters.  The 8 character length is based on a recommendation in early 1990’s, and with today’s computing power, it takes less than 13 minutes to crack a 8-character password with a 94 character base, while a 10 character password with 94 character base could take up to 78 days.  Organizations should exceed the minimum when possible.  SANS published a great worksheet showing the password calculation times.

The security and operations teams should review the standards.  Together, the teams should provide recommendations on hardening policies, which ideally would then be approved by management.  The compliance requirements should be mapped to business goals to ensure that risks are appropriately identified and mitigated. For more information on developing this process, please refer to the Tenable whitepaper “Maximizing ROI on Vulnerability Management”.

This dashboard provides several components for each of the compliance standard auditable by Tenable.sc using Nessus audit files. Audit files provide the results of an audit check as one of three severity levels.  The informational severity level is considered a pass.  The pass is achieved when the configuration setting matches the expected result of the audit check.  The match can be a defined value or a range of values.  The “Nessus Compliance Checks” document, available in the Tenable Support Portal, contains details on how to edit audit files.

When an audit check fails, the severity is set to high, indicating that the collected result and the expected result do not match.  A mismatch may not mean a failure.  Each failure should be reviewed and verified to ensure the expected result is correct. If the expected result is not correct, then the audit file should be modified and the scan should be run again. An analyst should evaluate medium severity level results. The analyst can determine whether the results are accurate or not.

The elements in this report use audit files (released after 1 July 2013), which incorporate the reference tag that maps many audit checks to a respective standard.  In the case of this report, the audit files must contain a string similar to '800-53|IA-5' on the reference line of the applicable audit check.

For example 'reference: CCE|CCE-8912-8,800-53|IA-5,PCI|8.5.12,800-53|CM-6'

Cross Reference Example

Please note that if you are creating your own filters and reports, the '800-53: IA-5' shown in the example is actually '800-53|IA-5' in the data query.

The dashboard and its components are available in the Tenable.sc Feed, an app store of dashboards, reports, and assets. The dashboard can be easily located in the Tenable.sc Feed by selecting category Compliance & Configuration Assessment. The dashboard requirements are:

  • Tenable.sc 4.8.2 or Tenable.sc 5.1
  • Nessus 8.5.1
  • Audit Files containing NIST references

Tenable provides continuous network monitoring to identify vulnerabilities, reduce risk, and ensure compliance.  Tenable.sc Continuous View (CV) measures compliance in real-time without human intervention, allowing the organization to identify gaps and lapses are detected and prioritized immediately. With more supported technologies than any other vendor including operating systems, network devices, hypervisors, databases, tablets, phones, web servers, and critical infrastructure, Tenable.sc CV provides the best solution for managing compliance with regulations. Tenable provides peace of mind to customers, because Tenable.sc CV detects security and compliance issues before our competitors.

Components

Compliance Summary - Indicators: This component provides an indicator for the supported compliance standards.  Each indicator will provide an easy mechanism to see a list of hosts applicable to each standard when the indicator is clicked on.

Compliance Summary - CIS, DoD & NIST Bar Ratio: This component displays a summary of CIS, DOS, NIST and other government audit standards organizations, providing a host count, and ratio bars for each severity level.

Compliance Summary - Industry Compliance Standards Ratio Bar: This component displays a summary of several audit industry standards such as COBIT, CSF, HIPAA, ISO and PCI, providing a host count, and ratio bars for each severity level.

Compliance Summary - SCAP Audit Check Ratio Bar: This component displays a summary of SCAP compliance checks.  The SCAP audit checks use STIG-IDs to report compliance status.  The component provides host count columns and ratio bars for each severity level.

Compliance Summary - 25 Day Trend: This component provides a 25-day trend analysis for all compliance checks. 

Compliance Summary - CIS, DoD & NIST Indicators: This component displays a summary of CIS, DoD, NIST and other government audit standards organizations, providing a host count and icons to indicate the presence of checks in different status.

Compliance Summary - Industry Compliance Standards Indicators: This component displays a summary of industry audit standards, such as COBIT, CCM, HIPAA, ISO and PCI.  The component provides a host count in the Systems column, and icons that indicate the presence of checks in different status.

Compliance Summary - SCAP Audit Check Indicators: This component displays a summary of SCAP compliance checks.  The SCAP audit checks use STIG-IDs to report compliance status.  The component provides a host count and icons to indicate the presence of checks in different status.

Audit File Cross References

Nessus uses audit files to check systems for compliance with a variety of standards.  The audit files are constantly being updated as new compliance standards are formalized and released.  This dashboard provides a summary for the following standards:

  • 8500.2 - DoDI 8500.2, Information Assurance (IA) Implementation.  This directive provides an overview on all information assurance configurations and implementation standards for the DoD.   The various controls are broken down into "Subject Areas" with assigned controls.  For example, DC is "Security Design & Configuration" and DCPD-1 is "Public Domain Software Controls"
  • 800-53 - NIST Special Publication 800-53 R4 Security and Privacy Controls for Federal Information Systems and Organizations provides a catalog of security and privacy controls for federal information systems and organizations.  The publication outlines a process for selecting controls to protect organizational operations, organizational assets, individuals, other organizations, and the nation from a diverse set of threats including hostile cyber attacks, natural disasters, structural failures, and human errors.
  • BSI-100-2 - The IT-Grundschutz Standards and Catalogues are a set of recommendations designed to assist an organization in achieving an appropriate security level for information throughout an organization. The Federal Office for Information Security (BSI) in Germany develops and maintains the BSI Standards, of which IT-Grundschutz is a part. This BSI standard provides methods, processes, procedures, and approaches to information security management, risk analysis, and business continuity management.
  • CAT - Findings from the STIG are grouped into three Categories (CAT) based on the severity of the weakness.  CAT I findings are those that allow an attacker to gain immediate access to a system or component, which are considered a HIGH severity.  CAT II findings are those that provide information about the system or component and therefore have a high potential of allowing unauthorized access to an intruder.  CAT III findings are those that give away enough information for an intruder to compromise the system or component.
  • CCE - Common Configuration Enumeration (CCE) provides a framework for mapping security related system configuration issues across multiple information sources and tools. An example of how CCE is used is to map configuration settings between best practice documents, for example the NIST 800-53.  CCE also helps enable the National Institute of Standards and Technology (NIST) Security Content Automation Protocol (SCAP).  
  • CCI - The Information Assurance Support Environment (IASE) uses the Control Correlation Identifier (CCI) to provide a standardized identifier and description for each of the singular, actionable statements that comprises an Information Assurance control or best practice.  CCI helps to connect high-level policies to technical configuration.
  • COBIT 5 - COBIT 5 is a business framework for governance and management of enterprise IT created by ISACA.  The framework provides globally accepted principles, practices, analytical tools and models to manage risk of information systems.  COBIT 5 also integrates other standards from ISO and other similar organizations.
  • Cloud Controls Matrix v3 (CCM-3) - The Cloud Security Alliance Cloud Controls Matrix (CCM) is specifically designed to provide fundamental security principles to guide cloud vendors and to assist prospective cloud customers in assessing the overall security risk of a cloud provider. The CSA CCM provides a controls framework that gives a detailed understanding of security concepts and principles that are aligned to the Cloud Security Alliance guidance in thirteen domains. 
  • CIS Level - The Center for Internet Security maintains a series of configuration benchmarks.  These benchmarks cover the configuration of many systems and applications.  The benchmarks have two configuration levels, Level-I and Level-II.  Level-I is practical, prudent, and provides a clear security benefit, while Level-II is more likely to negatively impact the system or application, and provide a clear security in-depth measure.
  • Cyber Security Framework (CSF) - A voluntary framework being developed by NIST for reducing cyber risks to critical infrastructure. The Framework will consist of standards, guidelines, and best practices to promote the protection of critical infrastructure. The prioritized, flexible, repeatable, and cost-effective approach of the framework will help owners and operators of critical infrastructure to manage cybersecurity-related risk while protecting business confidentiality, individual privacy and civil liberties.
  • CVE – CVE® International in scope and free for public use, CVE is a dictionary of publicly known information security vulnerabilities and exposures. CVE’s common identifiers enable data exchange between security products and provide a baseline index point for evaluating coverage of tools and services.
  • HIPAA - The Health Insurance Portability and Accountability Act of 1996 (HIPAA) Privacy Rule regulates the use and disclosure of Protected Health Information (PHI) held by "covered entities".  PHI is any information held by a covered entity, which concerns health status, provision of health care, or payment for health care that can be linked to an individual.  The information systems used to process and store PHI are to be configured with the defined guidelines covered by HIPAA.  As new audit files are created to cover HIPAA-HITECH, the audit file reference will remain HIPAA.
  • ISO/IEC-27001 - ISO/IEC 27001 is an information security management system (ISMS) standard published in October 2005 by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC). Its full name is ISO/IEC 27001:2005 – Information technology – Security techniques – Information security management systems. The ISO/IEC 27001 formally specifies a management system that is intended to bring information security under explicit management control. Being a formal specification means that it mandates specific requirements.
  • NIST_800-125a – The Security Recommendations for Hypervisor Deployment document examines the security implications of many aspects of Hypervisor Platform architectural choices and baseline functions, while also providing security recommendations for hypervisor deployments in an enterprise.
  • PCI DSS - The Payment Card Industry Data Security Standard (PCI DSS) is a comprehensive set of security standards required by major credit card companies to protect cardholder data. Every business that accepts and stores credit card data must comply with the PCI DSS.
  • SANS-CSC - The Critical Security Controls (CSCs) were created by a consortium of international agencies and experts from private industry and around the globe to simplify the most critical controls needed around all industries.  The framework takes an "offense must inform defense" approach to prioritizing controls that would have the most impact on reducing risk against real-world threats.
  • STIG-ID - The Security Technical Implementation Guides (STIGs) and the NSA Guides are the configuration standards for DoD IA and IA-enabled devices/systems. Since 1998, DISA Field Security Operations (FSO) has played a critical role enhancing the security posture of DoD's security systems by providing the Security Technical Implementation Guides (STIGs). The STIGs contain technical guidance to "lock down" information systems/software that might otherwise be vulnerable to a malicious computer attack. DISA FSO is in the process of moving the STIGs towards the use of the NIST Security Content Automation Protocol (SCAP) in order to be able to “automate” compliance reporting of the STIGs. 
    • Group-ID - Within a SCAP file are logical groupings of findings, vulnerabilities, or other items.  These groups are given a “Group ID” as a unique identifier and can hold one or more rules.  Groups have a title and description, which can describe the purpose of the group, or the rules contained within the group.
    • Rule-ID - There could be more than one rule in a group that describes what specific condition to test for a finding.  These findings could be a registry key, policy setting or descriptive text to show to an end-user.  A rule is comprised of an ID number, severity and weight.  Rules also contain a version, title and description to further elaborate the purpose of the rule.  Many times, there is a reference to a policy describing where the rule originates (e.g. a Windows 2008 R2 DISA policy).
    • Vuln-ID - Contained within a rule are “ident” XML tags that describe the specific vulnerability “number” that the rule corresponds to.  This is important as administrators, C&A teams, and others use these numbers to quickly identify vulnerabilities for systems.  Once identified, they can easily see the fix action text description and the action necessary to remediate or evaluate the vulnerability.  The “check-content” XML tag is also used to show what specific technical component needs to be checked and evaluated.  This content can be used to relay technical information to the administrators to remediate or evaluate the finding.
  • VMWare – The VMWare vSphere Security Hardening Guide provides detailed configurations to check the secure configuration of several components of vSphere.  The VMWare-ID is a nomenclature for the configuration, for example: “control-resource-usage”.  The VMWare-Profile indicates the relative increase in security provided by the guidelines, where 1 is the highest security level and 3 is the lowest.