InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Gradual decay of compliance status based on duration since last report

IP.com Disclosure Number: IPCOM000201551D
Publication Date: 2010-Nov-15
Document File: 2 page(s) / 43K

Publishing Venue

The IP.com Prior Art Database


Systems management products (like IBM's Tivoli Provisioning Manager and Tivoli Endpoint Manager) and security compliance management products (such as IBM Tivoli Security Policy Manager) generally apply policies to endpoints such as servers, desktops, laptops or mobile devices. Periodically, these endpoints are subjected to compliance checks, where the applicable policies are evaluated by agents on the endpoints, and any non-compliance is reported. The compliance status of each endpoint is stored at the server, and usually displayed in some tabular, graphical or aggregated form on the product's dashboard. This compliance status only changes when the agent makes the next report. Although agents may be configured to evaluate and report compliance status at frequent intervals, there is no guarantee that the agent will run at the specified frequency and successfully send a report. If an endpoint was in compliant state earlier and became non-compliant because of some configuration change, this may not be detected because of an agent failure, or because the endpoint was powered down, or even because the agent cannot communicate with the server any more (e.g. its PKI certificate has expired). Since an administrator using the dashboard typically monitors hundreds of endpoints, she is not likely to notice a few such endpoints that are stuck in "green" state. Thus, compliance issues may go undetected and unremediated. This article proposes a solution to this problem.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 01 of 2

Gradual decay of compliance status based on duration since last report

There are various types of products that apply policies to devices, and monitor them for compliance with those policies. Systems management products like Tivoli Provisioning Manager (TPM) and Tivoli Endpoint Manager (TEM) have policies dealing with OS and software configuration, patch levels, mandatory/prohibited software, etc. Security policy products usually deal with security settings on endpoints, such as password strength, screensavers, firewall settings, antivirus software, etc.

The typical architecture for these products involves a server where the policies are defined, and a set of agents installed on the endpoints that are responsible for monitoring / enforcing policy compliance. A policy is authored by an administrator and applied to selected (groups of) endpoints. Next, either the server pushes the policy to all the agents on the selected endpoints, or in some architectures (like TEM), each agent periodically contacts the server and asks for the set of policies applicable to its endpoint. Each policy typically specifies a periodicity of evaluation -- how frequently it should be evaluated. At those intervals the agent performs whatever actions are necessary to check policy compliance (e.g. a software inventory scan, or a scan of registry settings). The policy status is then reported to the server over the network.

In some cases, if non-compliance is detected, the agent may also have the logic necessary to fix the problem -- e.g., if a screensaver password isn't set, the agent can enable it. In other cases, it may require coordination between the agent and server to fix the problem -- e.g., the agent may need to request the server for a set of patches that are missing from the endpoint, download them, and then apply them to the endpoint. In yet other scenarios, manual intervention may be necessary to fix the problem -- e.g., if a production server needs to be patched, the administrator may first need to negotiate a change window with the application owner.

There are many failure modes possible, where the agent does not report the compliance status at the expected interval. The agent itself may have failed, or the endpoint may be powered down (a common issue with laptops). The agent's PKI certificate may expire, leading to an inability to set up a secure communication link with the server. Intermittent network failures or unavailability (again, with laptops or mobile devices) may also prevent agent-to-server communication. If the previous compliance report from the agent was "green", this means that the server's view of the endpoint remai...