Skip to main content
Version: 2.3

ARMR Mod

An ARMR Mod is a single program for an ARMR Engine. An ARMR Mod is a mandatory declaration that
defines the atomic executable unit of one-or-more ARMR Rules. An ARMR Rule cannot exist outside of
an ARMR Mod.

It is possible to define multiple ARMR Mods in a single .armr file if necessary. The example shown
below is the complete declaration of an ARMR Mod named "Security Rules". The keyword app is
used to declare an ARMR Mod, which takes a string that is used to identify this ARMR Mod with a
unique name. The unique name is also used for all events recorded by the ARMR Engine in the event log
file. Two ARMR Mods with the same name cannot be loaded at the same time. An ARMR Mod must
implement the mandatory requires() statement and contain at least one ARMR Rule. An empty ARMR Mod with no rules, as shown in the ARMR Mod Example, is not valid.

Requires

The requires() statement provides details about what is required for the ARMR Mod to run. It must be the first statement within the app, otherwise the rules will fail to load and an error will be logged in the CEF log. For now, the requires() statement only takes a single key:value pair that declares the minimum required ARMR language level to be supported by the agent for the ARMR App to run. Future versions of ARMR will support further overloading with additional requirements.

Version

The version() directive allows an ARMR developer to declare precedence between multiple ARMR Mods of the same name. When an ARMR developer commits a newer version of a mod, any older versions of the same mod will be ignored by the agent when present in the same load cycle. The version declaration is optional, but if provided, it needs to be specified before any rule is declared. Its default value when not declared is 1. In the case of multiple ARMR mods with the same name and different versions, only the mod with the highest version is committed to the agent.

version declaration is only supported since ARMR/2.3, inclusive.

Consider the following example:

app("Security Policy"):
requires(version:"ARMR/2.3")
version(2)
// some ARMR Rules
 
endapp

app("Security Policy"):
requires(version:"ARMR/2.3")
version(3)
// some ARMR Rules
 
endapp

In the above case, the ARMR mod with version 2 will be ignored and version 3 of the mod will be loaded instead. The following log message is generated for the mod with the lowest version:

in file "/tmp/example.armr": ARMR mod "Security Rules" overridden by mod with version "2"

In the case where two ARMR mods have the same version, then both mods will fail to load as they are in conflict about their name ID.

For every security event generated by a rule, the CEF extension appVersion indicates the version of its mod. See more details about CEF extensions later in the document.

ARMR Language Level

As shown in the example, this ARMR App requires a minimum ARMR language level of 2.0 to be supported by the ARMR agent. Both the version key and string value are required to be stated. The ARMR language level version is based on Semantic Versioning format of major.update. Incrementing the major value represents new functionality that is backwards incompatible with the previous release. Incrementing the update value means new functionality has been added that does not break backwards compatibility. In the case of an update, agents that are in the same major version range, but have a lower update value, will simply ignore new functionality. If either the version string is invalid or the version is unsupported, the app will fail to load and an error message will be printed to the CEF log file.

ARMR Mod Example

The following example shows a well formatted ARMR Mod, so long as at least one ARMR Rule is contained within the ARMR Mod. Please consult the ARMR Rule section for more information on available rule types.

|

app("Security Policy"):
requires(version:"ARMR/2.3")
// some ARMR Rules

endapp

|

In the example shown here, the requires() statement is missing.

|


app("Security Policy"):

endapp

|

The invalid ARMR Mod would generate an error messages in the security log file.

|

<unknown>: line 3: col 0: Invalid input: 'endapp' expecting: 'requires'

|