Foglight Experience Monitor 5.8.1 - Security and Compliance Field Guide

Installation of FxM patches

FxM patches can be installed by uploading the patch file(s) from the FxM web console (click Help > Upgrade). For detailed installation instructions, see section “Updating the appliance” in the Foglight Experience Monitor Installation and Administration Guide.

Monitoring of embedded third party components

Quest Software Inc. monitors vulnerability reports produced by the United States Computer Emergency Readiness Team (US-CERT) to determine whether security flaws are discovered in third party components used by Foglight Experience Monitor. Depending upon the severity of such published vulnerabilities (as published by US-CERT), the FxM team takes specific actions, as specified in the following table.

During the investigation phase, Quest product teams determine whether the published vulnerability affects their products. Quest then releases product updates, as necessary.

Operating system security updates

As described earlier, the FxM appliance ships with the SUSE Enterprise Linux® (SLES) distribution installed. Many OS components that FxM uses are obtained directly from the SLES distribution. Others, however, are built from source and then incorporated into the FxM distribution. The following sections (SLES components and Non-SLES components) describe how security updates are handled for each type of component.

SLES commonly ships with versions of RPMs for OS components that are older than the most currently released version. Novell® backports all relevant security fixes and patches to the older versions of these components so that they have the same level of security as the latest version. Every release of FxM applies all the latest security patches released by Novell for these components. Both Novell and RedHat follow this procedure to maintain backward compatibility and avoid introducing unforeseen problems due to changed behavior in components that their customer’s applications may be relying upon. In this way, any new features implemented in newer versions do not break existing installations. Vulnerability scanning tools (for example, Nessus) report the currently installed version number of components (for example, OpenSSH) and flag them as vulnerable based upon the reporting of known vulnerabilities for those versions. These tools, however, do not have the ability to determine whether fixes for these vulnerabilities have been retrofitted into these older versions. Consequently, these alarms are typically “false positives” and do not represent true vulnerabilities.

FxM does not rely on SLES distributions for every OS component. Apache™, PHP, MySQL®, and OpenSSL are all built separately based on source obtained from sites that host these open source projects. For every major release, the FxM development team obtains the latest source, builds these projects, and incorporates the binaries into its distribution. Typically, the FxM distribution for each release contains the latest version of these components. After an FxM release is issued there are invariably vulnerabilities reported for these components. The FxM team monitors these vulnerabilities and typically issues a special one-time patch to address them, if it is determined that the issue represents a security risk for an FxM appliance. It is often the case that these vulnerabilities do not represent a security risk for FxM since many of the features in components like Apache and PHP that are commonly exploited are turned off in the FxM distribution.

Appendix: FxM and FISMA compliance

This section describes how to evaluate the FxM security features in connection with the federal information security standards recommended by NIST (National Institute of Standards and Technology) and promulgated under the FISMA (Federal Information Security Management Act):