Community

Assessing the security risk of your containers with Vulnerability Advisor

Share this post:

As of May 23rd IBM Bluemix Container Service now provides a native Kubernetes operations experience while removing the burden of maintaining master nodes. Kubernetes itself is based on the Docker engine for managing software images and instantiating containers. Get the details.

We announced the launch of the Vulnerability Advisor (VA) service for IBM Containers at DockerCon 2015. Since then, VA has been continuously scanning thousands of customer images daily and reporting to our users discovered security issues on their containers in several dimensions, including vulnerabilities, compliance issues, security misconfigurations, and malware findings.

In the current version of VA, a vulnerability assessment report includes the list of packages which are affected by known vulnerabilities. By checking this report, the user can take action to remediate issues by updating/reconfiguring/disabling discovered vulnerable packages. When a user has hundreds of images and containers, the remediation tasks could be a big task. Some vulnerabilities may be quite severe while others are relatively less impactful. Priority must be given to remediate vulnerabilities with higher risk.

New Risk Analysis Capability

In this release, we extended VA to provide users with a clear, quantitative risk assessment of their container images and running containers that is based on well-established industry standards. We present this in a new “Risk Rating” view that helps users understand the criticality of each vulnerability and the security risk of each container, which will in turn help them prioritize their remediation actions. In this post, I will introduce this new Risk Analysis capability with an example report for one of my images deployed on the Bluemix Container Service.

RA-Critical

This figure shows the new Risk Analyis view of VA. The list of packages affected by discovered vulnerabilities are listed in the table at the lower part of the page. The list is ordered with respect to the risk level of each vulnerability, with the more critical items on top. The risk rating of the vulnerability is shown in “Risk” column. This rating can be one of “Critical”, “High”, “Middle”, “Low”, or “No CVE ID”.

This rating is determined by the following steps.

  1. Affected packages are identified by using security alerts from vendors. For example, Ubuntu Security Notice (USN) includes which packages are affected and what their vulnerabilities are.
  2. USN includes CVE ID for each vulnerability. CVE (Common Vulnerabilities and Exposure) is a standard dictionary of publicly known vulnerabilities and exposures, and CVE ID is uniquely assigned to each vulnerability by NVD (U.S. National Vulnerability Database).
  3. From each CVE ID, we determine the detailed information of the corresponding vulnerability. The information format is standardized as CVSS (Common Vulnerability Scoring System), which provides a way to capture the principal vulnerability information and scoring in both numeric and textual representation. It also provides translation from numeric score to qualitative representation. “Risk” column values such as low, medium, high and critical, show the severity rating of base score that is defined in the CVSS v3 specification. This helps the users have a clear understanding of the severity of their vulnerabilities and prioritize their vulnerability management processes.
  4. VA leverages IBM XForce Exchange API  to access detailed, curated information on each CVE. XForce Exchange provides the actual CVSS scores and the details for each CVE ID, such as:
    • CVSS Base Rating: characteristics of a vulnerability that are constant over time and across user environments.
    • CVSS Temporal Rating: the characteristics that may change over time but not across user environments.

The two side-by-side tables on top of the Risk Analysis view present these two ratings the detailed dimensions of each rating. We discuss these below.

CVSS Base Rating

The left-hand side of the Risk Analysis view shows the CVSS Base Rating of an Image or a Container. This is derived by computing maximum CVSS Base Rating among all packages. The CVSS Base Rating for a package is derived by the maximum CVSS Base Rating among all CVEs which affects the package vulnerability. For example in the figure above, the CVE-2016-0718 is maximum CVSS Base Rating among all the listed CVEs. The CVSS Base Rating is composed of the following metrics (specified in the CVSS specification.)

  • Attack Vector: This metric implies how the attack is conducted. The metric value could be:
    • Network: the attack is remotely exploitable.
    • Adjacent: the attack is limited to the same shared network.
    • Local: the attacker’s path is via read/write/execute capabilities.
    • Physical: physical access is required for successful attack.
  • Attack Complexity: This metric implies how much condition must be satisfied beyond attacker’s control. The metric value could be:
    • Low: special precondition is not required.
    • High: much precondition must be satisfied.
  • Privileges Required: This metric implies the level of privileges attacker must possess before attack. The metric value could be:
    • None: no privilege is required.
    • Low: some basic user privilege is required.
    • High: sufficient administrative privilege is required.
  • User Interaction: This metric implies the requirement to interact users other than the attacker. The metric value could be:
    • None: the attack does not require any user for success.
    • Required: the attack requires a user to take some action.
  • Confidentiality: This metric measures the impact to the confidentiality of the information. The metric value could be:
    • High: There is total loss of confidentiality.
    • Low: There is some loss of confidentiality.
    • None: There is no loss of confidentiality within the impacted component.
  • Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. The metric value could be:
    • High: There is a total loss of integrity.
    • Low: Modification of data is possible, but the attacker control or amount of modification is limited.
    • None: There is no loss of integrity within the impacted component.
  • Availability: This metric measures the impact to the availability. The metric value could be:
    • High: There is total loss of availability.
    • Low: There is reduced performance or interruptions in resource availability.
    • None: There is no impact to availability within the impacted component.

CVSS Temporal Rating

The right-hand side of the Risk Analysis view shows the CVSS Temporal Rating of an Image or a Container, as shown in the figure above.  This is determined by CVSS Temporal Rating which corresponds to the CVE which gives the maximum CVSS Base Rating in the left hand side. For example in the figure above, CVSS Temporal Rating for CVE-2016-0718 is shown in the right hand side. The CVSS Temporal Rating is composed of the following metrics:.

  • Exploitability: This metric implies the attack is widely exploitable in the current state. The metric value could be:
    • High: Automated attack tools exist or the details are widely available.
    • Functional: Functional exploit code is available and works in some situations.
    • Proof-of-Concept: Proof-of-concept exploit code is available or attack is not practical for most systems.
    • Unproven: No exploit code is available, or an exploit is theoretical.
    • Not Defined: (This rating implies this metric is not relevant. )
  • Remediation Level: official fix is available? Or no solution is available?
    • Unavailable: There is either no solution available or it is impossible to apply.
    • Workaround: There is an unofficial, non-vendor solution available.
    • Temporary Fix: There is an official but temporary fix available.
    • Official Fix: A complete vendor solution is available.
    • Not Defined: (This rating implies this metric is not relevant. )
  • Report Confidence: the degree of confidence and the credibility of the technical detail.
    • Confirmed: Detailed reports exist, or functional reproduction is possible.
    • Reasonable: Significant details are published, but not fully covered.
    • Unknown: There are reports of impacts that indicate a vulnerability is present.
    • Not Defined: (This rating implies this metric is not relevant.)

Risk Score Calculation

Numeric value for each metric is also defined in CVSS.

Metric Metric Value (Numeric Value)
Attack Vector Network (0.85) > Adjacent Network (0.62) > Local (0.55) > Physical (0.2)
Attack Complexity Low (0.77) > High (0.44)
Privilege Required None (0.85) > Low (0.62) > High (0.27)
User Interaction None (0.85) > Required (0.62)
C,I,A Impact High (0.56) > Low (0.22) > None (0)
Exploit Code Maturity Not Defined (1) > High (1) > Functional (0.97) > Proof of Concept (0.94) > Unproven (0.91)
Remediation Level Not Defined (1) > Unavailable (1) > Workaround (0.97) > Temporary Fix (0.96) > Official Fix (0.95)
Report Confidence Not Defined (1) > Confirmed (1) > Reasonable (0.96) > Unknown (0.92)
Confidentiality, Integrity, Availability Not Defined (1), High (1.5) > Medium (1) > Low (0.5)

 

The actual score for above metrics that are available from XForce Exchange API is provided from XForce Threat Intelligence Research in IBM. Then, CVSS Base Score and temporal score can be recomputed  using the CVSS v3.0 Equations, and transformed to the ratings in qualitative form used in the VA report.

If a package is affected by multiple vulnerabilities, we assign maximum of those scores as package risk score.  We translate numerical score into categorical score, for example, “Critical”. If multiple packages in a system are affected, we take the highest risk category and display it at the top left corner of the VA report. Two bar graphs show the detail risk rating (base metrics and temporal metrics) of the vulnerability with the highest risk category. When you bring your mouse pointer over the individual bars, you can see the detailed rating for each score which is reported from XForce Exchange API. The figure below is another example of VA report which shows “Meduim” risk rating.

RA-medium

CVSS information from XForce Exchange API helps prioritize risk on vulnerability and helps provide a better understanding of the risk posed by a vulnerability to the organization.


Log on to Bluemix today and try out the Vulnerability Advisor capabilities with vulnerability risk analysis extension by XForce Exchange API.

Sign up for Bluemix. It’s free!

More Compute Services Stories

IBM Cloud Log Analysis – Now Available in Germany and Sydney!

Starting today, IBM Cloud Log Analysis expands its availability from US-South to include the Germany and Sydney regions. Empower your DevOps team with IBM Cloud Log Analysis. Gain insights into your environment to quickly detect, diagnose, and identify issues. Keep your log data and your application workloads safeguarded on a centralized cloud class economical storage solution. Visit us in the IBM Cloud Catalog.

Continue reading

Simplify binding your IBM Cloud services to serverless Functions

Introducing a new command for the IBM Cloud Functions CLI plug-in to make it easier to configure your actions to have access to your IBM Cloud service credentials. The new service command is a convenient way to make your IBM Cloud service credentials available to your Cloud Functions code at run time. The new command helps with a form of secret management for your IBM Cloud services within the context of IBM Cloud Functions.

Continue reading

Cloud Foundry Day – London England, Nov 29th

Come join us for a "Cloud Foundry Day", a free educational conference and networking event with talks by Cloud Foundry community members, industry leaders, and Cloud Foundry Developers. Hosted by Dr. Julian Friedman, IBM Open Source Development Lead, code contributor and a leader in the Cloud Foundry community, and joined by renown speakers in the Cloud Foundry community. Enjoy some great topics, good conversations, food and beer!

Continue reading