Satisnet Ltd, Basepoint Innovation Centre, 110 Butterfield Great Marlings, Luton, Bedfordshire, LU2 8DL enquiry@satisnet.co.uk
+44 (0) 1582 434320

SecurityCenter Assurance Report Cards - Better Metrics for Faster Results

SecurityCenter Assurance Report Cards - Better Metrics for Faster Results

SecurityCenter Assurance Report Cards - Better Metrics for Faster Results

With the release of SecurityCenter 5.0 almost two years ago, Tenable introduced a new metric based analysis method for your vulnerability, compliance and event data – Assurance Report Cards, or ARCs. I am often asked by existing customers how ARCs can be used effectively to help track and remediate vulnerabilities or other security concerns effectively.

Anyone who has a role to perform vulnerability analysis knows the pain of properly communicating your discoveries, both good and bad, to other members of your organisation. The typical lifecycle is:

  • Scan & Discover
  • Analyse & Investigate
  • Report or create ticket
  • Wait for work to complete
  • Re-scan
  • Repeat report (and if not fixed, return to ticket)
  • Go back to step 1

The workflow diagram for the above can become rather spider-like and has no clear end; in some cases we get buried in steps 1 to 5 in a quagmire of scanning and reporting, which also means burying other members of your team in tickets and remediation steps.

Assurance Report Cards can help to streamline this scenario by showing the metrics that matter to you as a user, you as a business unit and you as an organisation. At the time a new user is added to SecurityCenter they are provided with 5 ARCs by default, shown below.

Assurance Report Cards

These five ARCs represent Tenables’ Critical Cyber Controls. As with any pre-defined security methodology these may not fit entirely within your security posture, your scanning schedule or your business requirements, so of course these ARCs are configurable or you can add new ARCs from Templates (provided by Tenable in the same manner as reports and dashboards) or completely custom ones to fit your business or processes.

The underlying language for creating or understanding ARCs is all based around your assets (there will be a separate blog soon to discuss assets in more detail).

If you want to see how the ARCs above are built, click the Options menu in the top right, and then Manage ARCs. You will then see all ARCs for all users you have permission to see (depending on how your organisation is setup with SecurityCenter you may only see ARCs for your SecurityManager). If you cannot see any that belong to just you, you can of course add your own from the Options menu.

Click on the ARC you wish to manage, and you’ll be taken to the Policy Statements that drive the ARC.

Edit Report Card

Each ARC is different, as is each policy statement driving it. If we click the Pencil icon (shown at the end of statement 1 above) we can see exactly how this statement is powered.

Maintain an Inventory of Software and Hardware

To break down the above, let’s investigate each option:

Basic

Statement: Name of the policy statement.

Display: This can be one of three options, Ratio (how many matching out of how many possible); Percentage (of total); & Compliance/Non-compliant for a simple pass or fail.

Advanced

Data Type:Either Vulnerabilities or Events. Events requires SecurityCenter Continuous View to work.

Base Filters: The core filters (assets) that we will be basing all of the policy statement from. In the case above, we are looking at “Systems Discovered Passively” OR “Systems that have been Scanned” as a Boolean pair. This means either systems that Passive Vulnerability Scanner has observed or hosts that have been probed by Nessus. Other filters can be added such as Address, MS Bulletin ID can be added to further fine tune the base filter. A Base Filter is not required to complete a Policy Statement.

Compliant Filters: The filters we should be investigating to say whether we match our compliancy “Display” above along with the condition below (more later). These can be more assets, address ranges and other common filters. In the example above, we are looking to see if we have any hosts that are NOT in the assets listed, but that do appear in the passive or scanned assets – what is there that we do not know about?

Compliant Condition: This can be a range of choices: All ; No ; Any ; > ; < ; >= ; <= ; each has other options based on the initial metric. E.G selecting “All” you can then select from: Hosts; Vulnerabilities and Ports. Selecting a value based metric such as our example above, we can choose a minimum or maximum bound to define our compliance. In our case, we will FAIL if we have more than 20% of hosts not classified as an asset.

Drilldown Filters: If we have failed, where should we be taken if we click on the policy statement on the primary ARC screen. A simple way to immediately see which hosts, in this example, are making us fail. We can then add these hosts to assets if we know what they are, or create new assets for those hosts and add them to the Compliant Filters, above. Again, these can be changed to include all manner of filters to match or extend your base filters if required.

So in summary, this rather complex looking set of statements and Boolean information actually shows you one simple thing: What does SecurityCenter know exists but has not been classified as an asset?

You can then extend this rationale to other elements:

  • What hosts do we know about that we haven’t scanned in 6 months?
  • What hosts do we have compliance information for but not vulnerabilities?
  • Are we scanning all our critical assets every month?
  • Are we remediating exploitable vulnerabilities within our business SLA period?
  • Are we investigating all privileged account lockouts reported from Active Directory?
  • Do we comply with relevant compliance governance – NIST 800; ISO 27000; PCI DSS?

You can also have personal ARCs in addition to the global ones that are just for you or your business unit:

  • How am I doing on scanning and patching the servers I am responsible for?
  • Can I prove that remediation’s are on track for my SLA?
  • Are all my servers logging into LCE correctly?
  • We need to prove quickly we are PCI Compliant, how?

One massive advantage here over standard reporting and dashboards is you define your requirements, and SecurityCenter tells you exactly where you are passing and failing in simple terms so you can address the problem areas quicker. All you need to perform in the mean-time is your regular scanning with SecurityCenter and you can be confident you will always have the latest information to power your ARCs.

If you’d like to learn more, please contact us for a one-on-one demonstration of SecurityCenter Continuous View to discuss how ARCs can help your organisation.