SERIES: A Peek Inside ConfigOS MPO’s Key Features – VeraLogix ™

Written by Jamie McCoard, Development Manager, SteelCloud

MPO’s VeraLogix™ feature makes scripted compliance checks and remediations easier to adapt to real-world Windows and Linux environments by separating user-adjustable inputs from the underlying script logic. By exposing key variables (such as names, versions, paths, and toggles) in a controlled way, VeraLogix helps administrators tailor controls safely, without rewriting scripts while protecting automation integrity and enabling consistent, repeatable results at scale.

VeraLogix is an exposed variable or interchangeable input, that is designed to simplify the user experience when controls are scanned/remediated using a scripting language such as BASH or Powershell.  In isolating the custom variables from the underlying script logic, VeraLogix protects the integrity of the system’s automation capabilities and prevents potential damage caused by script logic alteration. These values are subsequently consumed directly within the scripts when a job is ran.

In our STIG and CIS Benchmarks content, we include script control parts that leverage VeraLogix to simplify accommodating guideline differences across systems. Users can also create their own custom controls, enabling them to take advantage of the platform’s powerful scripting capabilities and VeraLogix features to support flexible and efficient operational customization.

Control Case Example

• Goal: All systems must have an antivirus application installed, and in some cases a specific minimum version is required.
• Environment: Servers are using antivirus cybersecurity software, (in this article we use generic antivirus provider names as examples) “ProtectorX version 2.3”, Workstations are using “GuardY version 2.0” software or better, and the Workstations under the Quality control team must have “GuardY version 3.0” or better.

Why Use MPO’s VeraLogix?

There are two reasons for using scripts with custom variables.

1. To adjust a control’s expected condition value for a scan or remediation job.
2. To fill the need for maintaining both baseline and operational validation.

For the first reason, adjusting a control’s expected condition value for a scan or remediation job, start by editing the policy that contains the control. Because SteelCloud cannot predict the details of every environment, script-based controls may include placeholder values, such as a generic antivirus product name. Create a customized Baseline policy from the SteelCloud policy for Servers and another for Workstations, then set the correct expected values for each group.

Servers Policy	Workstations Policy

For the second reason, maintaining both baseline and operational validation, create an Operational policy for the Quality Workstations by starting from the Workstations policy. This approach allows you to check the standard baseline requirement and a stricter operational requirement, such as a higher minimum antivirus version, during the same scan. Turn on “Use Operational Compliance Value” toggle, then update the version’s compliance expectations for the Quality Workstations.

Quality Workstations Policy

When the scan runs on the Quality Workstation, both the baseline and operational checks are expected to pass.

If the workstation is running version 2.0, the baseline requirement will pass while the operational requirement will fail.

If the workstation is running version 1.0, then both the baseline and operational checks will fail for this use case.

The flexibility to define variable conditions is essential for accommodating the diverse requirements of different infrastructures.

Usage of MPO’s VeraLogix

Configuring VeraLogix within a control’s script part is performed through the Policy Manager in Forge. Begin by creating or modifying a policy, then open or add a control to edit or insert a script part. Whether you are working with Linux (Bash) or Windows (PowerShell), the syntax for defining a VeraLogix variable within a script is consistent across both platforms.

${{type|variableName|Short Display Name|Tooltip text}}

There are 4 types of VeraLogix’s that can be created for use.

1.      string – a string of text for look up and matching, represented by a textbox ${{string|av_name|AV Name|The name of the antivirus software that should exist on this system}} 2.      double – number that can include a decimal, represented by a numeric field ${{double|av_version|AV Min Version|The version or build number minimum expected}} 3.      bool – a boolean of true or false, represented by a checkbox ${{bool|av_exactMatch|Exact Version Match|This version must match exactly}} 4.      int – an integer, represented by a numeric field ${{int|av_copyright|Copyright|This version must have the copyright year or newer}}

The variable name is intended to allow reuse of its value throughout a script by referencing it with the shorthand syntax ${{variableName}}. The short display name should consist of at most three words and will appear as the field’s label. VeraLogix also supports an optional tooltip, shown when hovering over the information icon next to the label, to provide additional context about the purpose and expected use of the value.

Conclusion

VeraLogix serves as a pivotal advancement in SteelCloud’s ConfigOS MPO ecosystem, enabling organizations to extend their compliance capabilities far beyond traditional STIG boundaries. By allowing teams to easily create, customize, and automate user‑defined RMF, operational, and KIOR controls, VeraLogix provides the flexibility needed to adapt compliance to real‑world mission requirements. Its integration across MPO and Forge empowers administrators to author and deploy tailored policies using PowerShell or Bash, ensuring that actionable controls can be operationalized at scale. Ultimately, VeraLogix strengthens an organization’s ability to maintain continuous, audit‑ready compliance while reducing labor, increasing automation, and supporting evolving environments.

To learn more about other key features of ConfigOS, read this datasheet.