Application Signature Flow

Application Signatures Flow

Application Signatures performs the following activities to identify and reports applications and related topology:

Search for	Example	Results
A single word	`cat`	Topics that contain the word "cat". You will also find its grammatical variations, such as "cats".
A phrase. You can specify that the search results contain a specific phrase.	`"cat food"` (quotation marks)	Topics that contain the literal phrase "cat food" and all its grammatical variations. Without the quotation marks, the query is equivalent to specifying an OR operator, which finds topics with one of the individual words instead of the phrase.

Search for	Operator	Example
Two or more words in the same topic	`AND` `and` `+` (plus symbol) `&` (ampersand)	`cat AND dog` `"cat food"+milk` `"cat food"&"dog food"`
Either word in a topic	`OR` `or` `\|` (pipe)	`cat OR dog` `cat \| dog`
Topics that do not contain a specific word or phrase	`NOT` `not` `!` (exclamation point)	`NOT cat` `! dog`
Topics that contain one string and do not contain another	`^` (caret)	`cat ^ mouse`
A combination of search types	`( )` parentheses	`cat + (dog \| mouse)` `cat \| dog + (! mouse)`

Engine reads configuration from applicationsSignature.xml file.

Engine tries to relate discovered processes to each signature.

Engine validates and discards unmatched signatures and signatures with unsatisfied requirements.

Engine makes a decision about the number of instances of applications for each signature.

Engine creates OSH objects corresponding to applications.

Engine performs updates of application attributes by evaluating expressions using parse rules if they are present. Attribute updates may be optional or required. If a parse rule used in the expression of required attribute fails to match, the application instance is skipped. Optional attribute update has no such effect.

Engine finds all suitable plug-ins for particular application and executes them. Plug-in has ability to run additional commands with the same client, update attributes, enhance topology, and even make a decision to skip the application.

Engine forms results vector with all application objects. Also at this stage, it links application and processes with installed software and services.

Identifying application instances

Many applications support instancing - multiple independent sub-applications running on the same host. It is common for such instances to have names or other identifiers in order to distinguish them. Instancing support in Application Signatures is based on the idea that for each instance, there is a corresponding designated process running. It means there is a 1:1 relationship between the number of such processes and the number of application instances. Identifying and marking such processes in the Application Signatures configuration file enables reporting of such instanced applications. For this purpose, the main-process boolean attribute was introduced for the element process in the signatures.

The attribute main-process affects the topology of the application as follows:

When the main-process attribute is not set for any process in application-component, or is set to false (default), a single RunningSoftware CI is created, and all processes are linked to this CI.
When the main-process attribute is set to true for a process, the process is regarded as the one that identifies the application instance. The number of such processes defines the number of application instances and the number of RunningSoftware CIs created. Each instance of main process is linked to only one corresponding RunningSoftware CI. All other processes are considered 'shared' and are linked to all RunningSoftware CIs created.

Example of signature of instanced application

<Application-Component name="A" >
     <process name="P1" main-process="true" ports="None" cmdline=""
      required="true" />     
     <process name="P2" ports="None" cmdline="" /> 
</Application-Component>

Signature of application A consists of process P1 with main-process attribute set to true and process P2.
Discovered data contains 2 instances of process P1 (P11, P12) and 2 instances of process P2 (P21, P22).
Resulting topology is the following:
Two RunningSoftware CIs A1 and A2 since there are two processes marked as main.
A1 is linked to processes P11, P21, and P22.
A2 is linked to processes P12, P21, and P22.

Note Instancing for applications without designated process(es) per instance with a 1:1 relationship, is not supported.

Attribute updates and expressions evaluation

Application Signatures supports attribute updates - declarations in the signature of applications that specific attributes of reported RunningSoftware CIs should be filled with specified values. Values may be:

constants
expressions containing strings and references to values of evaluated parse rules

A parse rule is a pattern declared in the signature that is matched against the data of the applications, such as command lines or paths of the processes. Patterns of a parse rule either match or do not match. A parse rule pattern is a regex (regular expressions) pattern. When a parse rule matches, corresponding matched string or groups can be used in expressions of attribute updates. If a parse rule is declared to match against the property of process, matching of the parse rule is performed against every process, one by one until the first match.

The following is an example of signature for the Active Directory Application Mode application, where attribute update with a parse rule is used:

Active Directory Application Mode with attribute updates

<Application-Component name="Active Directory Application Mode" ci_type="adam" category="Enterprise App" vendor="microsoft_corp">
     <parse-rule id="instance_name" name="cmdline">.+\s+-sn:([\w-]
       +).*</parse-rule>
     <process name="dsamain.exe" main-process="true" ports="ldap,636,
       None" required="true" cmdline="" description="Main AD
       Application Mode process" />     
<attribute name="name" value="${instance_name(1)}" type="string" /> </Application-Component>

The flow for this signature is as follows:

Process dsamain.exe that is found on the target host allows this signature to match and produces RunningSoftware of type adam.
When the engine gets to the point of attribute updates, all parse rules are matched for this application:
- The pattern of parse rule instance_name is matched against command lines of processes found.
- The pattern uses capturing groups; the matched pattern exposes both the whole matched string and group 1 captured. This group contains the value of ADAM instance.
Expression of attribute update ${instance_name(1)} is evaluated, and it translates to a string containing the instance name of ADAM extracted from the command line,
The value is reported to attribute name of application CI.

Ports matching and reporting

The element process in the signature can specify port values that affect whether this process element matches, and what ports are reported. Ports are specified using the attribute ports: a comma-separated list of values.

The following rules apply:

If among the values of the ports attribute there is a 'None' string, the process element always matches, regardless of ports discovered for this process.
Otherwise, in order for the element process to match, the discovered process should have all corresponding ports open that are specified in the attribute.
Only ports specified in the attribute ports are reported
Application Signatures can also report all ports of the application listened to. There are two ways to enabled this:
- Only for specific application and specific process by including the keyword 'all' in the value of the ports attribute
- Globally via boolean parameter discoverAllListenPorts in the configuration file globalSettings.xml. For example:
  globalSettings.xml
```
<property name="discoverAllListenPorts">false</property>
```