Browse Prior Art Database

eXtended Signatures for SW management Disclosure Number: IPCOM000124567D
Original Publication Date: 2005-Apr-28
Included in the Prior Art Database: 2005-Apr-28
Document File: 3 page(s) / 74K

Publishing Venue



The present publication discloses the concept of SW extended signatures (XSS), a kind of SW signature that encompasses the traditional "file-based" SW signature, and a related evaluation engine (XSE). Both extended signatures and the evaluation engine are extensible, and this allows to leverage future "knowledge driven discovery" for SW resources, by extending XSS, and implementing a related XSE plug-in.

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

Page 1 of 3

eXtended Signatures for SW management

Problem Statement

    Patch management is one of the hottest issues in system management today, specifically in the arena of Microsoft platforms: patches are released very often, and manual management requires a very large effort, especially in large organizations where the number of machines is high.

    Patch management and more in general SW recognition both relies on an initial step of understanding which SW and related patches is already available in a target machine.

    Sometimes this Inventory activity can be done by querying native registries about registered SW, however such registries may have not been updated about SW changes and removals. Alternatively, exploiters products can embed 3rd party scanning engines (e.g. Microsoft Baseline Security Analyzer) which approach is however prone to complex runtime dependencies and more general issues.

    Moreover, SW recognition engines, in order to be able to recognize SW, have to consume a "SW recognition catalog" that expresses how a particular SW or patch can be recognized. The methodology used today in Tivoli Knowledge Base (a.k.a. SW Catalog) is too simple as it relies on name/size of one or more files, eventually on a registry attribute, in order to have the legacy Inventory/License Management agent be able to infer that a specific SW is in place.

    With this approach it's difficult to detect recent SW installation (e.g. SW version is included inside the file-header), and can't be used to detect SW patches, where, in general, different patches (think about MS security patches) often changes the same artifact (e.g. a file, like a runtime library) and detecting SW with just name/size would conduct to "false-negative" hits.

CIT (Common Inventory Technology) Solution

More in general, a robust SW signature, should be composed of a set of predicates (extension of a common abstract predicate) like: a fileExist-predicate (name/size), a fileHeader-predicate (found file has specific header info), a registry-predicate, etc.

    The Boolean evaluation and composition of such predicated that compose the "eXtended Software Signature" XSS, can be evaluated from a plug-able "eXtended Signature Evaluator" XSE, to infer different conditions, like:

· SW Identified from a given signature is "installed" (with specific attributes)
· SW Identified from a given signature is "running"
· SW Identified from a given signature is missing but not needed (security compliance management)

as long as signature manufacturer has modeled such conditions using the XSS schema.

The XSS format, is designed to be extensible and able to host signature


Page 2 of 3

definitions coming from different sources, like LiveUpdate Servers, legacy Tivoli KB (a.k.a. simple-signatures), other unix catalogs, etc.

    The evaluation of such eXtended Signatures will not require 3rd party engines, but only a version of the eXtended Signature Evalua...