Articles in this section

Build custom checks with AI

Avatar
Oz Gabriely
  • Updated

[ Applies to ] StorageGuard 10.1 and later   /   AI assistant   /   Custom configuration checks

Storage teams often have their own configuration requirements that go beyond industry and vendor best practices, and they want to verify them across the whole environment. With the AI-assisted check builder, you describe what you want to validate in plain language, and StorageGuard builds the complete configuration check for you: the detection logic, the pass and fail conditions, and the finding that users see.

Once you save it, a custom check runs as part of risk analysis just like a built-in check.

How it works

You provide the basic details of the check and a plain-language description of what it should detect. 

The assistant then:

  1. Identifies the data to check. It finds the platform API command that exposes the setting, the field that holds its value, and which values are a violation.
  2. Writes the detection logic as a script, in Groovy, JavaScript, or awk, that reads the field and evaluates it.
  3. Proposes the finding the check reports: severity, ease of implementation, impact category, security principle, summary, description, impact, and remediation.
  4. Simulates the check on your already-scanned systems, using the configuration data StorageGuard has already collected, so you can see the results before you save anything.

You review the proposal, ask for changes if needed, and confirm. The check is saved, and from then on it runs in the standard risk analysis, alongside the built-in checks, and generates findings wherever it applies.

Before you begin

  • A StorageGuard account with permission to create custom checks.
  • The AI Assistant enabled, with an AI model configured in its settings.
  • At least one system of the target platform on-boarded and scanned, so the assistant can simulate the check on collected configuration data.

Create a custom check

The following example creates a check that verifies single sign-on (SSO) is enabled on NetApp StorageGRID.

  1. Open the AI Assistant.
  2. Type Create a custom check and send it. The assistant displays the New Custom Check — Basic Details form.
  3. Fill in the fields as described in the following table.
  4. Click Submit.
Field Description
Package Name The package the check belongs to. Custom checks are grouped in packages. Enter the name of an existing package, or a new name to create one, for example My Checks.
Check Name A short name for the check, for example SSO status.
System Type The technology the check applies to, for example StorageGRID.
What should this check detect? A plain-language description of what to verify, for example Check that SSO is enabled. See Tips for describing a check.

The New Custom Check — Basic Details form

The assistant analyzes the request and presents the proposed check. This can take a few minutes.

Review the proposed check

The proposal starts with a short explanation of the logic, followed by a table of the check's properties and finding details, the detection script, and the results of simulating the check on your already-scanned systems. In the StorageGRID example, the assistant found that GET /api/v4/private/single-sign-on returns a data.disable field, and treats true (SSO disabled) as a violation.

The proposed check: logic explanation, properties, and finding details

Part of the proposal What to check
Command The API command the check runs. Make sure it reads the setting you meant, especially if the platform has several similar settings.
Severity and classification Severity, Ease of Implementation, Impact Category, and Security Principle match how your organization rates this requirement.
Finding text The Summary, Description, Impact, Remediation, and Remediation Type are accurate and match your terminology and procedures. Users see this text in every finding the check produces.
Logic The script, labeled with its language (Groovy, JavaScript, or awk), reads the right field and returns a violation only for the values that should fail. Watch for inverted logic: a field named disable is a violation when it is true.
Simulation results The table at the end shows each system the check was simulated on and the collected data it evaluated. The simulation uses data from previous scans; no command is run on your systems. Confirm that the data contains the field the logic reads, and that the results match what you know about each system.

In the StorageGRID example, the assistant wrote the logic in Groovy. It reads the field and reports a violation when SSO is disabled:

String jsonString = data.replaceAll("(?m)^###.*", "").trim();
JsonNode json = new ObjectMapper().readTree(jsonString);
JsonNode dataNode = json.get("data");
boolean disabled = dataNode.get("disable").asBoolean();
if (disabled) {
    violationDetails.put("SSO Status", "Disabled");
    return "Single Sign-On (SSO) is disabled";
}
return "";

In this example, the script returns the finding summary when the system violates the check, and an empty string when it passes. Values added to violationDetails appear in the finding's violation details.

The rest of the proposal: remediation, detection logic, and simulation results

Note: The assistant builds the check, but you decide whether it's correct. Review the logic and the simulation results before you confirm, since the check's findings appear in reports and policies like any other finding.

Tune and save the check

The assistant ends the proposal by asking whether to create the package and save the check.

  • To change something, reply in the chat with what to change, for example Change the severity to Medium or Mention Okta in the remediation. The assistant updates the proposal.
  • To save the check, reply to confirm, for example Yes, save it.

From the next risk analysis on, the custom check runs alongside the built-in checks, generates findings where applicable, and can be included in your baseline policies.

Tips for describing a check

A clear description gets you a correct check on the first try.

Do Example
State the condition that should be true. Verify that SSO is enabled
Name the setting when you know it. Verify that the audit log level is set to Normal or higher
Include thresholds or allowed values. Verify that at least two NTP servers are configured
Check one thing per check. Create separate checks for SSO and for NTP instead of combining them.

Tip: Descriptions that say what should be true ("verify that X is enabled") produce clearer logic than descriptions that say what's wrong ("find systems without X").

Troubleshooting

Symptom Likely cause Resolution
The assistant can't identify the setting The description is ambiguous, or the platform doesn't expose the setting through an API StorageGuard reads. Rephrase the description and name the setting. If it still fails, the setting may not be available for that platform.
The assistant picks the wrong setting The platform has several similar settings. Name the exact setting, or describe where it appears in the platform's interface.
The simulation shows no systems StorageGuard hasn't collected configuration data for systems of that type yet. On-board and scan at least one system of that type, then create the check again.
A saved check never produces findings Risk analysis hasn't run since you saved the check, the check isn't included in a policy, or every system passes. Run a risk analysis, confirm that the check is enabled and in the relevant policies, and review the simulation results in the proposal.

[ Still need help? ]

If the assistant can't build the check you need, submit a request and include the platform and the description you entered.

Related articles

Comments

0 comments

Please sign in to leave a comment.