Rules & Scoring

TestimoX ships with a generated built-in rule catalog that evaluates Active Directory security, health, and configuration across multiple scopes. You can also author custom rules in C# or PowerShell.

Rule Anatomy

Every rule has the following structure:

• Name -- unique identifier (e.g., DomainControllerTimeServiceStatus )
• Display Name -- human-readable title shown in reports
• Description -- what the rule checks
• Scope -- Forest, Domain, DomainController, Computer, Server, or Site
• Categories -- one or more of: Configuration, Health, Security, Cleanup, Performance, Maintenance, Vulnerability, Compliance, Monitoring, Backup
• Tags -- free-form keywords for filtering
• Cost -- execution cost hint (Light, Medium, Heavy)
• Importance -- severity from Informational (0) through Critical/Extreme (10)
• Source -- data collection function
• Tests -- one or more assertions against the collected data
• Report -- section definitions with view modes
• Guidance -- investigation steps, fix recommendations, and references

Importance Levels

Scoring

TestimoX computes a percentage score per scope group (Forest, Domain, DomainController). Each test within a rule contributes to the score weighted by its importance level. The ScoreKind property controls whether a rule affects the compliance score, the health score, or both.

Writing C# Rules with RuleBuilder

Custom C# rules use the fluent RuleBuilder API:

using TestimoX.Definitions;
using TestimoX.Execution;
using TestimoX.Testing;

public static class MyCustomRule
{
    public static Rule GetRule()
    {
        return RuleBuilder.Create(nameof(MyCustomRule))
            .DisplayName("Custom Security Check")
            .Description("Validates a custom security requirement.")
            .ForScope(Scope.Domain)
            .InCategories(Category.Security)
            .WithTags("custom", "security")
            .WithCost(RuleCost.Light)
            .WithScoreKind(ScoreKind.Both)
            .WithSource((RuleParameters p) =>
                new object[] { MyDataCollector.Collect(p.Domain!) })
            .WithReport(r => r
                .Section("Results", "$", ViewMode.Table)
                .DescriptionLastSection("Custom check results."))
            .WithGuidance(g => g.AsMarkdown()
                .Summary("Explains what this rule checks and why.")
                .HowToFix("Steps to remediate the finding."))
            .AddTest(t => t
                .Named("Check passes")
                .Where("IsCompliant").Equals(true)
                .WithImportance(Importance.High)
                .WhenTrue(TestimoStatus.Good, "Requirement is met.")
                .WhenFalse(TestimoStatus.Fail, "Requirement is not met."))
            .Build();
    }
}

Writing PowerShell Rules

PowerShell rules are scripts that return structured objects. Place them in the rules directory and they are automatically discovered:

# MyPowerShellRule.ps1
[PSCustomObject]@{
    RuleName    = 'MyPowerShellRule'
    DisplayName = 'Custom PS Check'
    Scope       = 'Domain'
    Category    = 'Security'
    Importance  = 'High'
    Source      = {
        param($ForestName, $DomainName)
        # Collect data and return objects
        Get-ADDefaultDomainPasswordPolicy -Server $DomainName
    }
    Tests       = @(
        @{
            Name       = 'Password length meets minimum'
            Property   = 'MinPasswordLength'
            Operator   = 'GreaterOrEqual'
            Value      = 14
            WhenTrue   = 'Minimum password length is 14 or more.'
            WhenFalse  = 'Minimum password length is below 14.'
        }
    )
}

Report Sections and View Modes

Each rule defines report sections with a view mode that controls how data is rendered in the HTML report:

Compliance Mapping

Rules can be mapped to external benchmarks including CIS Benchmarks, DISA STIGs, Microsoft Security Baselines, PingCastle indicators, and Purple Knight indicators. These mappings appear in the report alongside each rule's findings.