[ Applies to ] StorageGuard 10.1 and later / All supported storage, backup, SAN and cloud systems / Windows and Linux deployments
Every failed check becomes a finding: one issue on one system, with the evidence that proves it and the steps to fix it. This article walks through a finding from opening it to closing it, and the actions available along the way, so the team can agree on who fixes what and by when.
In this article
Before you begin
- You know how to read the overview. See Read the Baseline Configuration overview.
Find the finding
Go to Baseline Configuration > Risks. The page lists open findings. Use the filters on the left, or Group By, to narrow the list:
| Filter | Use it to |
|---|---|
| Status | Show open and reopened findings (the default), or include completed, closed and suppressed ones. |
| Priority, Severity | Work through P1 and critical findings first. |
| Impact | Focus on one kind of weakness, such as access control, authentication, encryption or audit. |
| Labels, Security labels | Narrow to a technology, a standard such as PCI DSS, or labels your team added. |
| Check name, ID | Find every system with the same failed check, which is how you fix one issue across the estate. |
| Assignee, Due date | See your own work, or what's overdue. |
Tip: Group by Check name. One check failing on twenty systems is one remediation to plan, not twenty.
Read the finding
Open a finding to see its details:
| Section | What it contains |
|---|---|
| Description | What's wrong, the systems involved, and the finding's labels. System labels, marked with a lock, name the technology. |
| Impact | What this weakness lets an attacker do, or how it affects the environment. |
| Evidence | The raw output from the scanned system that made the check fail, so you can verify it yourself. |
| Remediation | The commands or steps that fix the issue, and the Fix it icon where one-step remediation is available. |
| Attributes | Scan date, status, severity, priority, ease of implementation, impact category, assignee, due date, resource type, when the finding opened, and any custom fields. |
| Activity | Everything that happened to the finding: opened, suppressed, resolved, reopened, closed, notes and labels added, and emails sent. |
| Notes and comments | Notes on this finding, and comments on the check itself, which show on every finding the check raises. Use check comments for guidance that applies everywhere, such as your standard remediation procedure. |
Triage: priority, effort, owner and due date
In the Attributes pane, click a field to set it:
| Field | Values | How to use it |
|---|---|---|
| Priority | P1 to P5 | How urgently it must be fixed. StorageGuard sets it from the severity; change it when the business context says otherwise, for example a high-severity finding on a lab system. |
| Ease of implementation | Easy, Medium, Hard | How much effort and risk the fix carries. StorageGuard sets an initial value; adjust it from experience. |
| Assignee | A StorageGuard user | Who owns the fix. |
| Due date | A date | When it should be done. Overdue findings are easy to filter for. |
Tip: Fix easy, high-priority findings first. Sorting by priority and then by ease of implementation gives you a queue that improves the score fastest for the least effort.
Fix it
Most findings are fixed on the storage or backup system by the team that owns it, using the steps in Remediation. For some checks, StorageGuard offers one-step remediation:
- Open the finding and go to the Remediation section.
- Click the Fix it icon.
- Review the remediation command, edit it if needed, and approve it.
- Enter the credentials of an account on the target system that's allowed to make the change. StorageGuard doesn't store them.
StorageGuard runs the command and re-validates the check. Fix it is disabled by default, is available for a subset of checks, and needs the right permissions; an administrator enables it.
Mark it complete, or close it another way
| Action | When | What happens |
|---|---|---|
| Mark complete | You've fixed the issue. | Click Mark Complete, then Complete. The finding closes if the next analysis doesn't find the issue again, and reopens if it does. |
| Suppress | The finding is an accepted exception, for this system only. | Change the status to Suppressed, indefinitely or until a date, and record the reason in the notes. See Suppress a single finding. |
| Tune the check | The check itself doesn't fit your environment, or shouldn't run on some systems. | Right-click the finding and select Check Tuning. See Tune risk detection. |
| Change a parameter | The check fails because your standard differs, such as a longer session timeout. | From the More menu next to the check name, select Edit Parameters. See Change a check parameter. |
How a finding's status changes
| From | To | When |
|---|---|---|
| — | Open | An analysis finds the issue. |
| Open | Completed | You mark the finding as fixed. |
| Open or Completed | Closed | The next scan and analysis no longer find the issue. |
| Completed or Closed | Reopened | A later analysis finds the issue again. The finding keeps its original open date. |
| Open | Suppressed | You suppress the finding. Suppressing doesn't change whether the check runs. |
A finding only closes after a new scan and analysis, so after fixing systems, run both, or wait for the scheduled ones. See Run and schedule a risk analysis.
[ Next step ]
Share findings with the people who need to act on them.
Related articles
[ Still need help? ]
Our support team can help with reviewing and remediating findings. Submit a request
Comments
0 comments
Please sign in to leave a comment.