API Management: Reporting Vulnerabilities to Broadcom when detected by automated scanning tools

Products

• CA API Gateway

Issue/Introduction

This article will discuss how to report and address any vulnerabilities detected in an API Management product.

Broadcom considers the security posture of its products to be paramount to developing quality software. The API Management suite — including but not limited to the API Gateway, the API Developer Portal, and the Mobile API Gateway — are tested regularly by the Broadcom Engineering team to ensure compliance with contemporary security checklists and verify that no dependencies used by these products are subject to exploitation or other vulnerabilities.

Common Vulnerabilities & Exposures (CVEs) are incredibly important to stay on top of to avoid any negative consequences to the environment. Broadcom encourages all customers to always install the latest monthly platform patch in order to address all CVEs related to third-party dependencies. It is recommended that this become part of a monthly maintenance routine.

The definition of a CVE according to mitre.org is as follows: "A CVE is a list of information on security vulnerabilities and exposures that aims to provide common names for publicly known cyber security issues. The goal of CVE is to make it easier to share data across separate vulnerability capabilities (tools, repositories, and services) with this "common enumeration."

Environment

This article applies to all CA API Management products

Resolution

Before Opening a Support Case

If an automated reporting tool or manual audit of a system implies that a security vulnerability exists on the API Gateway, then the following procedure should be executed prior to contacting Broadcom Support:

1. Check the knowledge base for known or named vulnerabilities, as Broadcom Support has already published many articles to address these already
2. Ensure the API Gateway appliance being scanned has been patched with the latest monthly platform update (also known as a security patch), hosted on the Solutions & Patches page
3. Check a CVE number against the Red Hat CVE database to ensure that the product of concern has not already been updated by Red Hat or the CentOS project
   • Red Hat Enterprise Linux 7 is equivalent to CentOS 7 when determining if affected
   • Broadcom Engineering teams rely upon upstream vendors for dependency updates. Products such as OpenSSL, MySQL, may have had updates applied to those products by vendors without modifying the version numbers of those products. This convention can unfortunately lead to false-positives by automated scanning tools. The most accurate way to know if it is a false-positive is by reviewing it in the Red Hat CVE database. 
     • Check the Additional Information section for an article on why many tools report false-positives and the "pitfalls of comparing version numbers"
4. Run the automated scan / audit again after the steps above are complete. If a genuine concern still exists, a support case should be created with as much data as possible about the environment - follow the Opening a Support Case on a CVE section below.

A note on generic security configuration recommendations by automated tools:

It should be understood that any configuration recommendations (non-CVEs) suggested by automated scanning tools are not generally recommended or encouraged by Broadcom. While in some cases the recommendation may be desirable or may work without issue, it is important to know that many of the configurations in the appliances come "out of the box" the way they are for a reason. Any changes to the configuration of such critical components such as MySQL or the appliance file system may negatively impact the environment. In addition, QA testing is done on the "out of the box" security configurations rather than any possible customizations, so there is an inherent risk to modifying any of these components. Any changes done to meet IT security policies are considered to be done "at your own risk".

Opening a Support Case

When opening a new support case to report a vulnerability, the following items should be provided up front:

• Run a DCT to collect as much data as possible from the Gateway application and OS-configuration and attach to the support case
  • If a DCT cannot be run in the environment, then the following information below should be manually collected and added to the support case:
    • Output of the following commands:
      • rpm -q ssg ssg-appliance
      • uname -a
      • dmidecode -t 1
    • A copy of the following file: /opt/SecureSpan/Controller/var/logs/patches.log
• All applicable CVE identifiers
  
  • Additionally, any applicable identifiers from other vendors or security scanning tools
• The name of the tool used to scan the CA API Management appliance
• Detailed information regarding the impact of any reported vulnerabilities, including the business impact

Additional Information

• All of the monthly platform patches are currently located on the Solutions & Patches page
• Product documentation on installing patches on an appliance Gateway
• Product documentation on understanding Gateway patches
• NIST NVD CVE database search
• Red Hat CVE database
• A great article from Red Hat on why many tools report false-positives and the "pitfalls of comparing version numbers"
  • A note from Red Hat: "In order to maintain code stability and compatibility, Red Hat usually does not rebase packages to entirely new versions. Instead, we backport fixes and new features to an older version of the package we distribute. This can result in some security scanners that only consider the package version to report the package as vulnerable. To avoid this, we suggest that you use an OVAL-compatible security scanner like OpenSCAP."