StorageGuard FAQ

[ Applies to ] StorageGuard 9 and later / All supported storage and backup systems / Technical FAQ

Answers to the questions storage, backup and IT infrastructure security teams ask most often about StorageGuard: what it is, how it is deployed and operated, how it collects data, how findings are prioritized and kept current, and how it fits with the tools you already run. Each answer links to the detailed article where one exists.

About StorageGuard

What is StorageGuard?

StorageGuard is Core6's Storage Security Posture Management (SSPM) platform. It secures enterprise storage and backup environments by continuously assessing configuration posture and exposure: it automatically collects configuration data across platforms and identifies misconfigurations, drift from approved baselines, deviations from vendor hardening guidelines, compliance gaps and ransomware-protection weaknesses - so that the systems holding your production data and your recovery copies can withstand ransomware and other cyberattacks, and so that you can prove it.

In practical terms, StorageGuard:

• Collects configuration from block and SAN arrays, NAS, object storage, software-defined storage (SDS) and HCI, AI and parallel file storage (PFS), SAN fabrics, storage management hosts, backup software and data-protection appliances - agentless, read-only, over the vendors' own APIs.
• Analyzes it against thousands of built-in checks derived from vendor hardening guides, security advisories and CVEs, industry frameworks (NIST, CIS, PCI DSS, FFIEC, NERC CIP, DORA, NIS2, HIPAA and others) and Core6's own research - covering authentication and multi-party authorization, role mapping to directory groups, weak and unused protocols and services, plaintext communication, encryption, immutability, secure time synchronization, audit logging and more.
• Builds a configuration repository: every analysis task stores a full snapshot of each system's configuration, giving you a current inventory and a history to compare against; see Does StorageGuard keep a repository of current and historical configuration?
• Compares intent with reality: you define the target configuration baseline for each platform and StorageGuard verifies, on every analysis task, that the systems still match it - detecting drift, preventing it from going unnoticed, and guiding remediation back to the baseline.
• Reports findings with context: which system, which setting or vulnerability, how severe, whether an exploit is practical, what compensating controls exist, and the exact remediation steps - and flags upcoming end-of-support (EOS) events for platforms and versions in your estate.
• Helps you prepare for audits and prove compliance with industry standards, regulatory requirements and cybersecurity frameworks; see Can StorageGuard help me prepare for and prove configuration compliance?
• Feeds your existing tooling - ServiceNow, Jira, SIEM, Armis, REST API. Organizations that have an approved LLM can optionally connect StorageGuard to it and work with findings in natural language; see Does StorageGuard include AI?

StorageGuard is built for storage and backup teams first - the people who own these systems - and gives IT infrastructure security, risk and audit teams the visibility they have historically lacked for this layer. Supported platforms are listed in the support matrix.

↑ Back to top

What problem does StorageGuard solve?

Storage and backup systems hold all of an organization's production data and every copy it would use to recover - snapshots, replicas, backup sets. They are the last line of defense in a ransomware event, which is exactly why attackers go after them first. Yet most organizations have far less visibility into the security posture of this layer than into servers, endpoints or cloud workloads. The reasons are structural:

• Existing tools do not cover this layer. Vulnerability scanners, endpoint protection and configuration-management tools are built for servers, endpoints and applications. Storage and backup appliances run proprietary operating environments with vendor-specific APIs and CLIs and cannot host an agent, so those tools see little more than a management IP address.
• A knowledge gap. Securing Fibre Channel zoning, NAS exports, snapshot immutability, backup catalogs or storage management planes requires domain expertise that security teams rarely have and storage teams rarely have time to apply systematically.
• No repeatable validation. Hardening is usually a one-off project. Configurations drift, new advisories arrive weekly, and nobody re-checks.

The result: production storage and backup estates typically carry significant misconfigurations and unpatched vulnerabilities, accumulate more over time, and do not meet the baselines their own vendors publish. The organizations that adopt StorageGuard usually arrive from one of these starting points:

• An audit finding or internal requirement to control configuration drift across storage and backup environments.
• Regulations and frameworks such as NIST, DORA, NIS2, PCI DSS and NERC CIP that require a continuous configuration baseline and drift management process across IT infrastructure - storage and backup included - with coverage of current best practices and the latest vendor and industry guidance, not a one-time hardening exercise.
• Recognition that manual reviews or home-grown scripts for configuration validation no longer scale and cannot be relied on.
• A push to tighten security hardening, patching and continuous validation in response to AI-accelerated threats and exploitation.
• Concern that configuration weaknesses and vulnerabilities exist today, unknown, and are quietly accumulating.
• The need to continuously validate intent versus reality - the approved target baseline against what is actually configured - as storage and backup systems change over time.

StorageGuard answers all of these with the same mechanism: a target configuration baseline per platform, continuous automated validation of every system against it, drift prevention through early detection and alerting, and guided remediation - owned by the storage and backup team and visible to security and audit.

↑ Back to top

How is StorageGuard different from vulnerability scanners?

General-purpose vulnerability management tools are built for the host, network and application layers: they discover operating-system and application CVEs across servers, endpoints, network devices and web applications, at scale. StorageGuard is built for the storage and backup layer, and the two are complementary rather than competing.

Many StorageGuard customers run both: their vulnerability scanner for the host estate, StorageGuard for storage and backup, with findings from both flowing into the same ticketing and SIEM tools. See Which ITSM, SIEM and security tools can StorageGuard integrate with?

↑ Back to top

How is StorageGuard different from the native security capabilities of storage management solutions?

Storage management solutions are built first for capacity, performance, monitoring, observability and health. Many now add a security assessment or hardening score, and those are useful - but they typically track a handful of headline settings (data-at-rest encryption, MFA, a few protocol options) rather than a robust, evolving hardened baseline. StorageGuard does not replace the vendor's management plane; it adds the depth, breadth and consistency that native tools are not designed for:

↑ Back to top

Does StorageGuard include AI?

StorageGuard works fully without AI, and all AI-related capabilities are disabled by default. Nothing AI-related runs, and no AI-related connection is made, unless your organization explicitly chooses to enable it.

For organizations that want to benefit from AI-powered capabilities, StorageGuard 10 and later can be integrated with the LLM your organization already has and has approved - an enterprise LLM subscription or a model hosted inside your own environment. Core6 does not bring or operate any LLM or GPU infrastructure and does not route StorageGuard data to any AI service of its own. StorageGuard only connects to the endpoint you configure, under your contract, your data boundary and your cost control.

The integration is implemented as a StorageGuard MCP server (Model Context Protocol). A StorageGuard administrator enables it by installing the MCP server package and entering your LLM details under Settings > Interfaces > MCP; see Configure the StorageGuard AI Assistant. Once enabled, there are two ways to use it:

• The built-in AI Assistant - a chat panel inside the StorageGuard interface with pre-built prompts for hardening status, baseline compliance, exposure to a given advisory, and report or summary generation.
• Your own AI application - an MCP-capable client your organization already uses, connected to the StorageGuard MCP server.

When enabled, the AI capabilities can be used to:

• Ask questions in plain language - which systems are exposed to a specific advisory, which NAS shares allow anonymous access, what changed on an array since last week.
• Explain a finding and its remediation in the context of your environment.
• Build a remediation plan scoped to what matters (critical findings only, hardening, or vulnerabilities) - StorageGuard 10.1 and later.
• Draft custom checks from a plain-language description, including the detection script and finding metadata.
• Score the risk of configuration changes recorded by Change Control (separate setting, StorageGuard 10.1 and later).
• Generate executive summaries and report narratives.
• Trigger evaluations from your own AI workflows via MCP - for example, "evaluate our exposure to this new advisory".

Guardrails apply throughout: the assistant operates under the StorageGuard user's role and system scope, never accesses storage or backup systems directly, never sees scan credentials, communicates over TLS, and every interaction is logged for audit. The integration can be disabled again at any time.

↑ Back to top

How does StorageGuard help against Mythos-class models and AI-accelerated cyberattacks?

AI has accelerated every stage of an attack. Frontier models find exploitable weaknesses in firmware and appliance software at a pace no human research team can match; the same class of models now drives discovery of exposed systems, lateral movement and execution inside the environment. Vendors use these models to find and fix flaws faster, so the volume of advisories for storage and backup platforms is rising sharply, while the time from disclosure to first exploitation has collapsed from months to days, and in some cases to before disclosure.

The consequence is that weaknesses are found quickly - by defenders and attackers alike - and hardening and vulnerability response can no longer be periodic projects. They have to run continuously, and nowhere more than on mission-critical systems like storage and backup, where a successful attack removes the ability to recover. StorageGuard addresses this on two fronts:

Reducing the attack surface before an exploit exists

• Hardening and baseline drift prevention reduce the risk of exploitation. A vulnerability in a service that is disabled, an interface that is not exposed, or an account that is locked down is far harder to exploit. StorageGuard validates every system against your target configuration baseline on every analysis task, so hardening that was applied stays applied.
• Rapid identification and remediation of security misconfigurations reduces risk. Weak or unused protocols and services, plaintext channels, over-privileged roles, missing MPA, disabled immutability or audit logging are surfaced with step-by-step remediation and, where you choose, Fix It workflows - closing the openings an AI-driven attacker would find first.
• Drift and change visibility. Change Control records configuration changes per asset and flags unauthorized ones, so a port opened during troubleshooting or a retention lock removed does not stay that way unnoticed.

Accelerating vulnerability response when an advisory lands

• Frequent knowledgebase updates deliver new advisory, CVE and hardening checks as they are published, applied automatically if you choose. See How do I update the StorageGuard knowledgebase?
• Rapid advisory impact analysis. For each advisory StorageGuard shows which of your systems are affected by model and version, whether the vulnerable component or service is actually enabled, how exploitable it is, and how severe the impact would be - so you act on real exposure first.
• Mitigating configurations, side by side with the patch. Alongside the remediating patch or software update, StorageGuard shows which mitigating configurations are already in place and which could be applied now - vendor-documented workarounds and hardening settings that reduce exposure until the update can be scheduled. Patching storage and backup systems needs maintenance windows; mitigation usually does not.
• Automation at machine speed. Fix It workflows, the REST API, webhooks and ITSM integrations close the loop without waiting on manual processes, and organizations that have integrated StorageGuard with their own LLM can trigger advisory evaluations and remediation planning from their own AI workflows.

For the background and current figures, see the Core6 blog post Hardening Is Continuous and the on-demand webinars on securing storage and backup in the AI era.

↑ Back to top

Why securing storage and backup matters

Why is it important to secure backup?

Backup systems and the data they manage are the final line of defense against ransomware and destructive attacks. If they are compromised, the snapshots, backup sets and replicas you rely on for cyber-recovery are gone or cannot be trusted, and the organization is left negotiating with the attacker. Modern ransomware operations target backup infrastructure deliberately and early - disabling jobs, deleting or expiring catalogs and repositories, and exfiltrating backup data before encrypting production.

Backup software, backup servers, media servers and data-protection appliances ship with many settings that are not secure by default and depend on the operator to harden: administrative access and MFA, service accounts, encryption, immutability and retention locks, network isolation, API and protocol exposure, logging. Without continuous validation, those gaps persist unnoticed until an attacker finds them.

↑ Back to top

What could go wrong if I don't harden my storage?

If storage systems are not strictly secured, an attacker who reaches the data or management plane can delete, encrypt, corrupt, alter, leak or simply make unavailable the volumes, file systems and buckets they hold. The blast radius is measured in petabytes and hundreds of applications at once, because storage is shared.

Storage arrays also keep the snapshots, replicas and clones that are the fastest recovery path from any incident. A compromised management interface, an over-privileged account, an unprotected replication link or a snapshot policy that is not locked means those copies can be destroyed in the same action that destroys production - leaving no quick way back.

↑ Back to top

What could go wrong if I don't harden my backup?

If backup data or the backup management layer is not secured, attackers can delete, expire, corrupt or encrypt the backups as part of the attack - often days before the ransomware payload is triggered, so that the first symptom you see is the ransom note, not the missing backups. Without a clean, recent and verified copy, the organization has no feasible way to restore data and dependent services, and the only remaining options are to pay or to rebuild from nothing.

Common weak points include backup consoles reachable from the general network, shared or default administrative credentials, backup repositories that are writable from compromised hosts, disabled or misconfigured immutability, unencrypted backup traffic and catalogs, and no alerting on job deletion or policy changes.

↑ Back to top

How does StorageGuard help with ransomware protection?

StorageGuard does not detect or block ransomware in flight - that is the job of your EDR, NDR and the native anomaly detection in your storage and backup platforms. What StorageGuard does is make sure the storage and backup layer is hardened and configured so that ransomware cannot destroy your ability to recover, and that the native anti-ransomware features you have paid for are actually switched on and configured correctly. For example, StorageGuard validates that:

• Snapshots, replicas, backup images and backup sets required for recovery are immutable, retention-locked, isolated and otherwise protected.
• Vendor ransomware-protection features - ransomware and anomaly detection, snapshot locking, SafeMode-style protection, user-behavior analysis, antivirus integration - are enabled and configured according to the vendor's guidance.
• Data volumes, NFS exports, SMB shares and object buckets have restricted access lists and least-privilege permissions.
• The storage and backup management planes are hardened: strong authentication and MFA, multi-party authorization (MPA) for destructive operations such as deleting snapshots or lowering retention, role separation with correct mapping of roles to Active Directory groups, no default or shared accounts, administrative access restricted to management networks.
• Weak and unused protocols and services are disabled, and no management, replication or backup traffic runs over plaintext channels.
• Backup systems themselves are hardened and isolated, with encryption, secure communication and protected catalogs.
• Time is synchronized from secure, authenticated sources, so retention locks, immutability windows and audit timestamps cannot be defeated by tampering with the clock.
• Audit logging captures the events that give early warning of an attack: failed logins, privilege changes, policy and retention changes, mass deletions.
• Published ransomware-recovery guidance from your storage and backup vendors, and the relevant controls in NIST, CIS and sector frameworks, are implemented.
• CISA #StopRansomware guidelines are implemented.

Findings are mapped to the Baseline & Hardening Library levels so you can start with the essentials and progress to a fully fortified configuration, and every subsequent analysis task confirms the hardened state has not drifted.

↑ Back to top

What does StorageGuard do for NAS devices?

Network-attached storage holds a large share of an organization's unstructured data - user and departmental shares, application data, and increasingly AI training sets and model artifacts - and is very often also the target for backups. Because NAS shares are reachable from thousands of endpoints over SMB and NFS, a NAS device is both a high-value target and an efficient way for malware to spread. Ransomware campaigns have targeted NAS platforms directly for years, and a compromised NAS that also stores backups removes both production data and the means to recover it.

StorageGuard supports the NAS capability of the major enterprise platforms, including NetApp ONTAP, Dell PowerScale, Dell Unity and PowerStore, Hitachi NAS and VSP One File, Everpure (Pure Storage) FlashBlade, HPE, Infinidat, VAST Data, Nasuni and CTERA, alongside the data-protection appliances that expose NAS targets (Dell PowerProtect DD, HPE StoreOnce and others). See the support matrix for the current list. For NAS, here are examples of areas analyzed by StorageGuard:

Every finding comes with vendor-specific remediation steps, and the NAS baseline is re-validated on every analysis task so that configuration drift is caught early.

↑ Back to top

Deployment and architecture

How is StorageGuard deployed?

StorageGuard is deployed on-premises, inside your network, with no agents on the storage or backup systems. It consists of a master server (web interface, risk engine, API), a PostgreSQL (recommended) or Oracle database (on the master or a separate host), optional collector servers for remote sites and segmented networks, and the optional MCP server for AI capabilities. See StorageGuard Deployment Components.

Choose the platform that fits your operations:

For organizations with multiple data centers, StorageGuard collectors are deployed close to the storage and backup systems and report to the central master, giving one consolidated view of posture across sites. Collectors can connect to the master over an SSH tunnel where network policy requires it (StorageGuard 10.1 and later).

StorageGuard-on-Demand is a one-time assessment delivered by Core6 or a channel partner, using the same software - deployed on a VM in your environment, or run from the partner's environment over a VPN - to produce a point-in-time report.

↑ Back to top

Does StorageGuard require an agent?

No. StorageGuard is agentless. It connects to each storage and backup system over HTTPS or SSH with read-only credentials and uses the vendor's own management API and CLI to collect configuration. Nothing is installed on the arrays, appliances or backup servers, nothing is changed on them, and there is nothing to maintain on them. Introducing StorageGuard therefore comes down to deploying the StorageGuard server and providing, for each system, an account capable of running read-only API calls - stored in StorageGuard or retrieved from your privileged-access management solution.

↑ Back to top

How long does it take to install StorageGuard?

Installation on a prepared Windows or Linux host takes under 20 minutes. Once the server is up, you enter credentials for the storage and backup systems you want to assess and run the first analysis task. Findings, remediation guidance and compliance status are available as soon as the first task completes - typically within the first hour for a POC scope.

For proof-of-concept and assessment activity, a pre-installed virtual appliance (OVF) is available on request.

↑ Back to top

Where can I find sizing guidelines for StorageGuard?

Sizing for the master server, database and collectors is published in StorageGuard Installation Requirements, by number of storage and backup systems in scope. As a reference point, a master server with a co-located database for up to 50 systems needs 8 vCPU, 48 GB RAM and 300 GB of SSD storage; collectors start at 2 vCPU, 16 GB RAM and 75 GB. For estates above 1,000 systems, or if you are unsure how to count systems, contact Core6 Support and we will size it with you.

↑ Back to top

What are the technical requirements for a StorageGuard POC?

A proof of concept needs three things: a host for StorageGuard, network reachability to the systems in scope, and read-only credentials.

StorageGuard host

• Windows: Windows Server 2022 or 2025, 64-bit, English edition and locale, local administrator rights for the installation.
• Linux: Ubuntu 22.04 LTS or later, Debian 11 or later, RHEL 9 or later, or SLES 15 SP3 or later, with Docker Engine and Compose or Podman and Podman Compose.
• Resources for a POC scope (up to 50 systems, database on the same host): 8 vCPU, 48 GB RAM, 300 GB SSD (two disks: operating system plus a separate StorageGuard drive). Full tables are in StorageGuard Installation Requirements.
• If preferred, a pre-installed virtual appliance (OVF) can be provided on request.

Network

• The StorageGuard host must reach the management interfaces of the systems in scope, typically over HTTPS (443) and/or SSH (22), plus vendor-specific ports listed in StorageGuard Network Port Requirements.
• Users reach the StorageGuard web interface over HTTPS on port 8443.
• No internet access is required. If you want automatic knowledgebase updates during the POC, allow outbound HTTPS to the Core6 update location, directly or through a proxy.

Credentials

• An account capable of running read-only API calls on each storage and backup system in scope. The role or privileges required per platform are listed in StorageGuard Scan Requirements.
• Optionally, retrieve those credentials at run time from CyberArk or HashiCorp Vault instead of storing them in StorageGuard.

↑ Back to top

Does StorageGuard require access to the cloud or external connections?

No. StorageGuard is installed on-premises and runs fully inside your network. All analysis takes place on your StorageGuard server; configuration data never leaves your environment, and Core6 has no access to it.

Two optional capabilities involve outbound connections, both off by default and both under your control:

• Automatic knowledgebase updates - if enabled, StorageGuard downloads update packages from a secure Core6 location, directly or through your proxy. Otherwise updates are applied manually. See How do I update the knowledgebase?
• AI capabilities - disabled by default. If your organization chooses to integrate StorageGuard with its own, already-approved LLM, StorageGuard connects only to that endpoint: a model hosted inside your environment involves no external connection at all; an enterprise LLM subscription involves the outbound connection your organization has already sanctioned. Core6 brings no LLM of its own and never routes data through its services.

↑ Back to top

Data collection and platform coverage

How does StorageGuard collect configuration data?

StorageGuard runs scheduled (or on-demand) analysis tasks. In each task it connects to every system in scope with its credentials and gathers configuration:

• Primarily through the vendor’s management API over HTTPS (REST, and the native APIs some platforms expose), using read-only roles.
• CLI over SSH, or WinRM for Windows-based backup servers, as a complement - for data the API does not expose, using built-in command sets or commands you define yourself for custom checks.

All calls are read-only and are executed one at a time per system. The collected data is analyzed on the master server against the risk knowledgebase and your baseline policies, and results are available in the web interface, reports and API when the task completes.

Credentials can be stored encrypted in StorageGuard or retrieved at run time from your privileged-access management solution - CyberArk (Credential Provider or Central Credential Provider) and HashiCorp Vault are supported natively, so scan accounts are never stored outside the vault.

Distributed environments: StorageGuard collectors can be placed in remote data centers or in segments behind a firewall, collect from the local systems and send the results to the central master - over the collector port or an SSH tunnel. Per-platform connection details are in StorageGuard Scan Requirements.

↑ Back to top

What is the footprint of the configuration collection?

Collection from a single storage or backup system takes between roughly 20 seconds and a few minutes, depending on the platform and the size of its configuration. During that time StorageGuard issues read-only API requests and commands serially, one at a time, with negligible impact on the system's CPU and on the network. The volume of data collected per system ranges from about 50 KB to a few MB.

• Only system configuration is collected - no business data, no file contents.
• StorageGuard does not scan files on disk and does not perform any kind of full-disk or content scan.
• Nothing is written to the target system.

↑ Back to top

What kind of information does StorageGuard collect?

StorageGuard collects the configuration and inventory information of storage and backup systems: model, version, firmware and patch level, licensed and enabled features, services, interfaces, ports and protocols, volumes, pools, LUNs, file systems, exports, shares and buckets, snapshots and replication, backup policies, jobs, repositories and retention, users, roles, groups and access lists, authentication and directory settings, zoning, encryption, audit and logging configuration, remote-support settings, network and time configuration, and other security-relevant options.

No business data is collected. See What is the footprint of the configuration collection?

↑ Back to top

Does StorageGuard keep a repository of current and historical configuration?

Yes. Every analysis task stores a complete, structured snapshot of each system's configuration in the StorageGuard database, on-premises, alongside the analysis results. Over time this builds a versioned configuration repository for the whole storage and backup estate - something most organizations have never had for this layer. It is what makes several StorageGuard capabilities possible:

• Inventory on demand. A current, searchable view of every system, version, feature, volume, share, policy and role across vendors, available in the interface and through the REST API - no need to log in to each management console.
• Change Control. A per-asset timeline of what changed, when, and whether the change was authorized, with point-in-time comparison between any two snapshots.
• Comparison and golden copies. Compare a system against its own earlier state, against another system, or against a designated golden copy to find deviations before they become findings.
• Drift detection and prevention. Intent versus reality is evaluated against history as well as against the baseline, so a setting that was correct last month and silently changed is caught.
• Audit evidence and forensics. Auditors can be shown the configuration as it was at any retained point in time, and after an incident the repository answers "what did this system look like before?" without relying on the compromised system.
• Custom checks against collected data. New or AI-drafted checks can be simulated against configuration already in the repository, without re-collecting from the systems.

Only system configuration and inventory are stored - no business data - and retention of historical snapshots is controlled by the StorageGuard administrator.

↑ Back to top

Where can I find the latest support matrix?

The current list of supported storage, backup and data-protection platforms, by vendor and category, is on the Core6 website: StorageGuard support matrix. Per-platform connection and credential requirements are documented in StorageGuard Scan Requirements.

Don't see what you are looking for? Contact us with your question, request or feedback about the support matrix.

↑ Back to top

What platforms are on the StorageGuard roadmap?

The support matrix is updated frequently - new platforms and new versions of supported platforms are added in nearly every release (see the release notes). Roadmap items are marked as such on the support matrix.

If you have a requirement for a platform that is not listed, or want to know when a roadmap item is planned, contact us - customer requirements are a primary input to our platform prioritization.

↑ Back to top

Checks, findings and knowledgebase updates

Can I create my own configuration checks for storage and backup?

Yes. Custom checks are a first-class part of StorageGuard and are commonly used to codify internal standards, audit requirements or vendor settings that are specific to your environment. They run alongside the built-in checks in every analysis task and appear in findings, reports and compliance views like any other check.

Custom checks are also the natural place to encode your own target configuration baseline - the intended state of a platform in your environment - so that intent versus reality is validated continuously. Two ways to build them:

• AI-assisted (StorageGuard 10.1 and later, only for organizations that have integrated StorageGuard with their own LLM). Describe the condition in plain language - for example, "flag any ONTAP SVM where SMB signing is not required". The assistant identifies the relevant API command and field, writes the detection script, proposes the finding title, severity and remediation text, and simulates the check against configuration data already collected so you can validate it before saving. See Build custom checks with AI.
• Manually. Define a custom collection command (API or CLI) if the data is not already collected, write the detection logic in Groovy, JavaScript or awk, and set the finding metadata. Checks can be grouped into packages and enriched with custom fields for ownership, ticket references or internal control IDs.

The Core6 Customer Success team is glad to help define and review custom checks.

↑ Back to top

How are StorageGuard findings prioritized?

Every finding carries a severity, and StorageGuard adds the context that tells you whether it deserves attention now.

Vulnerabilities and security advisories

• CVSS base score and vector (v3.1 and v4.0) and the vendor's impact rating.
• Exploitability - whether a working exploit or proof of concept is publicly available, and whether the vulnerability appears in known-exploited catalogs such as CISA KEV.
• Applicability - whether your specific model and version are affected, and whether the vulnerable component, service or protocol is actually enabled on the system.
• Compensating and mitigating configurations - whether vendor-documented workarounds or hardening settings that reduce exposure are already in place, which lowers the effective risk until the patch is applied.

Security configuration findings

• Severity assigned by the Core6 research team, based on the potential impact of the misconfiguration on the storage or backup system and on recoverability.
• The priority given by the originating source - vendor hardening guides, NIST, CIS, DISA STIG, ISO and sector frameworks.
• The hardening level the check belongs to in the Baseline & Hardening Library (Essentials through Fortified), so you can sequence work from foundational controls upward.

You can override priority on individual findings or in bulk, exclude findings with a documented justification, and use labels and custom fields to route findings to the right owners. Organizations that have integrated StorageGuard with their own LLM can additionally have a remediation plan drafted, scoped to critical findings, hardening or vulnerabilities.

↑ Back to top

Can StorageGuard help me prepare for and prove configuration compliance?

Yes. Regulations and frameworks increasingly require a continuous configuration baseline and drift management process across IT infrastructure, with evidence that current best practices and the latest guidance are applied - and auditors now look at storage and backup specifically. StorageGuard covers both halves of that requirement for the storage and backup layer:

Prepare

• Built-in mapping to standards. Checks are mapped to industry standards, regulatory requirements and cybersecurity frameworks including NIST (CSF, SP 800-53, SP 800-171), CIS Controls, PCI DSS, FFIEC, NERC CIP, DORA, NIS2, HIPAA, CRI and others, as well as to each vendor's hardening guidelines, so a framework requirement translates directly into concrete settings on each platform.
• Approved configuration baselines. Define the target baseline per platform (or adopt a Baseline & Hardening Library level), apply it consistently across sites, and let every analysis task re-validate it - the continuous drift-management process the frameworks ask for.
• Your own controls. Add custom checks for internal policies and control IDs, and tailor reports to the format your auditors expect.
• Guided remediation. Each gap comes with step-by-step remediation and, where you choose, Fix It workflows and ITSM tickets, so you close findings before the audit rather than explaining them during it.

Prove

• Evidence with every result. Each check records what was collected, when, from which system and why it passed or failed, giving auditors the evidence trail rather than a self-attestation.
• Compliance reporting. The Configuration Compliance report shows posture by framework, platform, site or CI group; executive summary reports (Baseline Configuration Overview, Vulnerabilities Overview, Assets Overview) give leadership and auditors the headline view. Reports are produced in PDF, Word, CSV or JSON, can carry your or your partner's logo, and can be scheduled and delivered automatically.
• Change and exception history. Change Control records who changed what and when, with authorized and unauthorized marking; excluded findings carry a documented justification; the event log records StorageGuard activity itself.
• Current guidance, demonstrably. Frequent knowledgebase updates mean the baseline you report against reflects the latest advisories and hardening guidance - see How do I update the StorageGuard knowledgebase?

StorageGuard also tracks end-of-support (EOS) events for the platforms and versions in your estate, which several frameworks treat as a compliance condition in its own right.

↑ Back to top

How do I update the StorageGuard knowledgebase?

StorageGuard supports two update modes for its knowledgebase of checks, advisories and scan definitions:

• Automatic. StorageGuard connects to the secure Core6 update location on a schedule, downloads the latest package and applies it - directly or through a proxy you configure. Enable it and set the proxy under the auto-update options in Settings (StorageGuard 9.2.9 and later cover advisories, configuration checks and scan definitions in the same package).
• Manual (default). Subscribe to Core6 update notifications, download the package from the Core6 support portal and import it in a few steps. See How to import a knowledgebase update into StorageGuard.

Either way, the next analysis task evaluates every system against the updated content.

↑ Back to top

Integrations

Can StorageGuard integrate with ServiceNow?

Yes. StorageGuard includes a built-in, configurable ServiceNow integration that creates incident or problem tickets from findings. You set the ServiceNow authentication details, map assignment groups to StorageGuard labels (for example by platform, site or owner), filter which findings generate tickets, and choose automatic or manual ticket creation. Ticket references are kept with the finding, and StorageGuard's Fix It workflows can raise the change request in ServiceNow before a remediation is applied.

Atlassian Jira is supported in the same way. See the StorageGuard Integrations section for set-up guides.

↑ Back to top

Which ITSM, SIEM and security tools can StorageGuard integrate with?

Set-up guides for each are in the StorageGuard Integrations section. Have an integration need that is not listed? Contact us - the Customer Success team will help you connect StorageGuard to your security and IT operations stack.

↑ Back to top