Overview

Version 2.0 adds a major new feature to opConfig: Compliance Management. The compliance engine in opConfig is very flexible and capable and this document describes how to configure and use it to assess your infrastructure.

...

Compliance management with opConfig has the following main three aspects:

• Defining Sources: 

  • Where do we get the status and configuration information from?

• Declaring Policy Rules: 

  • What are the rules to be used to assess your systems' compliance?

• Evaluation and Presentation:

  • Which systems' are or were compliant with which sets of rules? What rules are violated or conformed to? How does the assessment status change over time?

Here is a diagram of the component interactions:

...

However, as command outputs are generally unstructured plain text, it is necessary to preprocess these outputs in oder order to provide both efficient mechanisms for checking compliance with an organization's rules. The section on Configuration Parses describes how this works.

...

The configuration status document has no prescribed structure but must be representable as a JSON document - this basically means that you can use nested lists (or arrays), hashes and the usual types of singleton scalars to express and  arrange the characteristics that you consider relevant for your  your node. Naturally the structure that you choose for your parsers to produce must match up with the properties that your policy rules examine.

...

For example, your high-level policy restriction might be "No MySQL servers may not have a Web server active"; this would be translated into a set of policy statements that find systems which are active MySQL servers and tests whether there is a web server software package installed and/or the ports 80 or 443 are active.

...

All config parsers must be valid Perl scripts, and we made this choice for efficiency reasons: a language flexible enough to parse and extract information from arbitrary configuration or status command outputs would have been almost as complicated as perl but much less robust. In addition to that you will likely change your policy rules much more often than any of the parsers.

...

• All parser modules must consist of valid perl code, but don't need to be 'complete' perl Packages or Modules, or even use function definitions: the code is executed as given, sequentially, in a sandbox with a few variables and functions predefined.
• Parser modules may not contain "use Some::Other::Module;" constructs at this point.
• The  variable "$input" always corresponds to the textual input of the command to analyze. The parser may consume and destroy the contents.
• The variable "$input_structure" contains a hash reference to the structural  structural representation of the command output, IF and Only IF that command output was detected as tree-structured.
  Otherwise $input_structure is undef(ined). At this time only Open-AudIT Enterprise imports provide structured command outputs.
• The variable "$node" contains the node name in question, and "$command" is the name of the command that produced this output. This  This can be handy if you want to use one parser for two or more command types with similar outputs.
• The function '&logger("severity","some message")' can be used to create diagnostic messages for the opConfig log files. Severity must be one of "debug", "info", "warn", "error" or "fatal".
• If the parser detects an non-recoverable problem with the input then it must return a single string, containing an error message.
• If the parser has successfully analyzed an input text, it must build a tree representation of the collected  properties (a deep hash in Perl terms) and return a reference to that tree structure.

...

• Parsers currently cannot receive structured document representations for XML or HTML command outputs, only for JSON-formatted material. As a parser isn't allowed to make use of external Perl modules (e.g. an XML parser), this limits acceptable inputs to plain text or JSON. This limitation will likely be removed in a future version of opConfig.
• The output structure of a parser MAY overlap with other parsers' output hashes wrt. to the hash keys; thus a parser MAY amend another's config structure by filling in new material - but you need to note the following restrictions:
  • Overwriting of hash structure with a scalar is not  supported - the scalar value is ignored.
  • Overwriting of a scalar is not supported - the earlier value remains set and the new value is discarded. This affects only entries that have been set explicitelyexplicitly.
  • all other cases are merged sensibly (ie. scalars are added to arrays, arrays and hashes are merged, etc.)

• Because of this order dependency, parsers must be configured in order of priority.
  If you do use overlapping structures, the most specific parsers need to run first, and establish correct values, while other parsers can later only fill in the blanks. If all your parsers are written so as to create separate (sub)structures this is not an issue.

• Parsers must not  produce structure keys that contain "." (more specificalyspecifically: that contain any characters outside of a-z, A-Z, 0-9, "-" and "_") or keys that are fully numeric.
  These restrictions are necessary to make dot-style structure selector expressions possible and unambiguous.

...

While you are fine-tuning your parser behaviours, you will therefore likely want to force opConfig to reparse re-parse and re-extract the command outputs, which is of course possible:

...

At this time the policy engine provides the following pre-defined structure variables to every policy:

Structure variables can be accessed in IF, THEN and EACH statements. To do so, the structure variable name is given (including the leading "$" sign), optionally followed by further substructure accessor directives (which are deliberately similar to MongoDB's Dot Notation):

...

An IF statement can contain any number of structure access expressions, operators and Perl constructs. All structure accesses ($THISNTHAT.substruct...) are replaced as described above, then Perl is usd used to evaluate the expression. Evaluation errors (ie. syntactical mistakes) result in "Rule Error" exceptions.

...

Policy actions in THEN statements contain an arbitrary number of AND-separated ok(), exception(), CONTINUE() or LAST() expressions.

Exceptions and compliance affirmations can use arbitrary "rule name" strings. Exceptions must be given a numeric priority (0 lowest, 10 highest).

...

This command will not produce output unless there are fatal problems during the policy evaluation. All compliance assessments (and any "Rule Error" exceptions caused by benign rule problems) are stored in the database and are managed using the opConfig gui (Menu Views, Entry "Compliance Status").

Setup Sample Compliance for Cisco Devices

opConfig comes with a sample compliance policy for Cisco devices based on the NSA Cisco Best Practices document

Import the Compliance Template

/usr/local/omk/bin/opconfig-cli.pl act=import_policy name="cisco-nsa" file=/usr/local/omk/conf/compliance_policies/cisco-nsa.nmis

View the Available Compliance Templates

/usr/local/omk/bin/opconfig-cli.pl act=list_policies

The result will look like this

Copyright (C) 2012 Opmantek Limited (www.opmantek.com)
This program comes with ABSOLUTELY NO WARRANTY;
See www.opmantek.com or email contact@opmantek.com


opConfig 1.0 is licensed to Opmantek for 50 Nodes


Policy      Version   Date
cisco-nsa   1         2014-10-27T11:21:10

Run the Cisco NSA Compliance Template

/usr/local/omk/bin/opconfig-cli.pl act=check_compliance name='cisco-nsa'

View the Compliance Status

You can now check the Compliance Status in the opConfig GUI.  Access the opConfig GUI at http://YOUR_SERVERNAME/omk/opConfig, login and then from the Menu Bar "Views -> Compliance Status".

Create Compliance Report

You can now check the Compliance Status by generating a compliance report, in csv format, which shows compliance to Compliance Policies.

/usr/local/omk/bin/opconfig-cli.pl act=create_compliance_report file=/tmp/cisco-nsa_compliance.csv node='the-node-name'