Patch Auditing

New Nessus Report Consolidates Missing Patches

by Paul Asadoorian
May 7, 2013

Keeping tabs on missing patches is one of the challenges faced by everyone responsible for managing systems. Regardless of platform, there are a plethora of patches to be applied. The new Nessus “Patch Report” plugin provides an actionable report that displays a list of consolidated patches that need to be applied to become fully patched.

Scanning and Patch Auditing VMware Using Nessus

by Paul Asadoorian
May 6, 2013

To help you discover all the components of your virtual environment, Tenable has several Nessus plugins to detect virtualization servers, discover vulnerabilities, and enumerate VMs (both active and inactive). Nessus supports remote vulnerability identification and local patch auditing of VMware vSphere ESX/ESXi and vCenter.

Linux/UNIX Patch Auditing Using Nessus

by Paul Asadoorian
April 16, 2013

Nessus can check that your Linux and UNIX systems are up-to-date with the latest patches. Tenable has released more than 1,000 plugins this year that check for local Linux and UNIX operating system's missing patches. This includes kernel patches and security updates to software packages being maintained by each distribution.

New Nessus Plugins Audit Your Patch Management System Effectiveness

by Paul Asadoorian
January 30, 2013

Nessus integrates with many popular patch management solutions, including IBM Tivoli Endpoint Manager (TEM), Red Hat Network Satellite server, Microsoft WSUS / SCCM, and VMware Go. The new Nessus "Patch Management Windows Auditing Conflicts" and "Patch Management Auditing Satisfied" plugins automatically cross-reference vulnerabilities from credentialed patch audits with patch information from your patch management system on the same asset, reporting discrepancies in a single report.

Nessus Patch Management Integration Now Supports IBM Tivoli Endpoint Manager

by Paul Asadoorian
October 16, 2012

Nessus and SecurityCenter now support Tivoli Endpoint Manager (TEM) as a patch management platform in which patch-level information can be extracted for given scan targets.

Nessus Patch Management Support

We are pleased to announce new support for IBM Tivoli Endpoint Manager (TEM) for Patch Management (formerly known as BigFix). This new capability allows us to use the information gathered by TEM from systems where we may not have credentials or we’re unable to reach such systems over the network. The TEM integration is configured similarly to our integration with other patch management solutions where credentials and the server IP address/hostname are provided so Nessus can retrieve the patch information for the hosts targeted in the scan.

In addition to TEM, Nessus and SecurityCenter also integrate with the following popular patch and system management solutions:

  • Microsoft Windows Server Update Services (WSUS)
  • Microsoft System Center Configuration Manager (SCCM) 2007
  • Red Hat Network Satellite Server
  • VMware Go (formerly known as Shavlik)

In order to make use of this feature, be certain you've configured TEM properly. Refer to this discussion post for more information and instructions.

If a Security Control Falls in the Forest...

by Paul Asadoorian
July 16, 2012

Many guidelines and compliance standards state that in order to be "secure" or "compliant" all of your systems must be patched. Turns out that this is easier said than done. Just when you believe your systems to be patched, something fails and patches seemingly disappear. We can then apply the "falling off" principal to several other areas of information technology, such as web applications, configuration management, and antivirus software. How do security controls in these areas fall off? Read about how this might happen and what you can do to help correct the problems.



Monitoring Internet-facing Servers with SecurityCenter & Nessus

by Paul Asadoorian
May 4, 2012

Covering All Your Bases

Internet-facing servers are a popular attack target: They are accessible to everyone on the Internet and can easily be probed for vulnerabilities. Based on exposure alone, Internet-facing servers present a higher risk of becoming compromised. This risk needs to be mitigated if organizations must provide access to services such as web, mail, and VPN connectivity. It is therefore important that these servers are regularly assessed for potential vulnerabilities (and more important that something is done to remediate the vulnerabilities). This blog entry provides guidance for some basic security issues which are important to monitor on Internet-facing servers, such as:

  1. Maintaining Patches - It is important to keep up-to-date with patches in general, and with systems that are exposed to the Internet, fixing both local and remote vulnerabilities are particularly important. For example, a web server may contain a vulnerability which allows an attacker to gain a shell with the privileges of the running user (e.g., www-data). If local vulnerabilities are present, the web server vulnerability can quickly lead to the attacker gaining root-level privileges. With this level of access, attackers have a much better chance to cover their tracks and hide their presence within the system. Therefore, ensuring all available security patches are installed on your systems is important.
  2. Easily Exploitable Web Application Vulnerabilities - If you've ever monitored the logs of an Internet-facing web server, you know attacks against applications are frequent. Application testing involves many different processes and techniques, but you don't want to give attackers any low-hanging fruit. It is important to test your applications before they are put in production, but also continue to monitor for vulnerabilities in production. Several automated tools in use by attackers exploit flaws, such as SQL injection, on a regular basis. Once the application is on your production system, it is important to regularly assess it to stay ahead of the curve and remediate the vulnerabilities before attackers get to them.

  3. Exposed Services - Internet-facing servers ideally offer a limited number of services, since they do not need to support a wide range of services that an internal development server would offer. This makes it easier to scan and identify vulnerabilities and detect any new services which may crop up. Firewalls are often deployed to provide an extra layer of protection for systems exposed to the Internet and ensure that only required services are permitted. Scanning these hosts on a regular basis will quickly identify any new services that are running or mistakes made in firewall configuration which may unintentionally expose an internal service or server.


Three Types of Client-side Exploits

by Ron Gula
February 28, 2012

We often hear about vulnerabilities in client software, such as web browsers and email applications, that can be exploited by malicious content. The repeated stories about botnets, infected web sites, and viruses which infect us with malicious documents, movies, and other content have ingrained the concept of an exploitable client in our minds. Unfortunately, client software can also be targeted with attacks from compromised servers accessed by the clients, and some client software actually listens for connections. In this blog entry, we will discuss auditing client software for vulnerabilities and describe the three different types of client-side exploits and how they can impact the risk of your network.

Real-time Enterprise Exploitability Trending

by Ron Gula
February 13, 2012

Penetration tests are typically a point-in-time exercise to determine if a remote adversary or malicious insider can compromise systems that contain sensitive data. Most organizations do not conduct penetration tests on a daily basis. Instead they schedule them annually, quarterly, or in some cases monthly. Penetration tests procured on a consulting engagement are often limited to key systems and assets rather than the entire network of systems. This diminishes the value of the penetration test as the results quickly become outdated and may not be relevant to new systems or recent network changes. However, by correlating the availability of exploits with a continuous monitoring program to identify vulnerabilities, an organization can have a better idea of how “exploitable” they are on a real-time basis.

Microsoft Patch Management Integration with Nessus - Part 1 WSUS

by Paul Asadoorian
December 16, 2011

This is the first post in a two-part series that will cover how to configure Nessus and/or SecurityCenter to integrate with Microsoft's patch management software.

WSUS Patch Management Integration

Windows Server Update Services (WSUS) is available from Microsoft to manage the distribution of updates and hotfixes for Microsoft products. WSUS server 3.0 SP2 supports management of patches for the products listed here, as well as Windows 7 and Windows server 2003 SP2 patches. If you are not familiar with WSUS it is freely available to Microsoft customers as part of your Windows server licensing agreement. A great article that covers all aspects of planning, deployment, and configuration is Windows Server Update Services Learning Roadmap Community Edition.

Nessus and SecurityCenter have the ability to query WSUS to verify whether or not patches are installed on systems managed by WSUS and display the patch information through the Nessus or SecurityCenter. When performing scans with the WSUS patch management plugins enabled and configured please note the following:

  • Credentials entered into the policy take priority - If you've entered credentials into the scan policy and they are valid for a target system, Nessus will login and perform credentialed scanning without querying the WSUS server data.

  • WSUS is queried when credentials fail - If credentials are not valid for a target system, or credentials are not entered at all into the policy at all, the WSUS server will be queried to obtain patch information for those targets. This also applies to other policy settings that may cause a credentialed scan to fail, such as the remote registry or administrative shares settings.
  • The WSUS plugin communicates only with the WSUS server - The WSUS plugin makes a connection to the WSUS server IP/hostname and port specified in the policy configuration (see below in the "Patch Management WSUS Preferences"). This is an important point, as the Nessus server(s) will require access to your WSUS server, which could mean making firewall rule changes to allow the connections. However, this is a significant advantage as your target systems do not need to communicate with the Nessus server directly, which means host firewalls and remote registry settings will not get in the way of a patch audit.
  • Patch information is only as up-to-date as your WSUS server - The data returned to Nessus by WSUS is only as current as the most recent data that the WSUS server has obtained from its managed hosts.

Pages