Check Details is divided into three sections: Check Info, Actions, and Additional Context.
Check Info
This is where you can find more information about a check:
1. Rule Title: The title of the rule being checked.
2. Resource Type: The type of resource.
3. Resource: The resource being checked. Clicking on (...) shows you the full resource ID, while clicking on it takes you to your cloud console for faster investigation and remediation.
4. Account Name: The account.
5. Region: The region a resource belongs to.
Actions
Here, you edit the severity or suppress a check to reflect your business situation and export it to your task manager of choice so other teams can address it within their usual workflows.
1. Severity: To assist you in prioritizing remediation, Horangi provides a severity ranking for each check based on its potential impact. For Failed checks, you can click on this to change the severity and trigger Vulnerability Management.
2. Status: The status of a check. For Failed and Suppressed checks, you can click on this to change the status of a check with Vulnerability Management.
|
Severity |
Description |
|
Critical |
Critical severity findings indicate that the discovered weakness requires immediate remediation and/or mitigation. Critical findings typically represent weaknesses that were leveraged to gain access to systems or data that commonly have financial or reputation loss factors attributed. |
|
High |
High severity findings indicate that the discovered weakness is publicly disclosed and trivial to abuse. High findings typically represent weaknesses that were leveraged to gain privileged access to networks, systems, or applications. |
|
Medium |
Medium severity findings indicate weaknesses are likely to lead to compromise but either requires other attacks to be significantly impactful, resulting in limited access, or require advanced knowledge and techniques to execute the attacks. |
|
Low |
Low severity findings indicate weaknesses that are not directly exploitable. Low findings typically require a chain of weaknesses to exploit fully, disclose non-sensitive technical information, or do not lead to any additional compromise within an environment. |
|
Informational |
Informational severity findings are reserved for weaknesses that represent a deviation from best practice or a weakness that should be reviewed because it may expose other weaknesses or lead to future vulnerability. While these weaknesses don’t directly lead to compromise, they still represent potential risk and should be addressed. |
3. Export Issue: Clicking on the three dots beside Status takes you to Export Issue, which allows you to export Check Details to an issue in Github, Gitlab, Bitbucket, or JIRA.
Additional Context
These sections contain detailed information to speed up identifying, prioritizing, and fixing issues.
Description Tab
The description tab shows you details about the rule that was checked and the potential impact of a misconfiguration.
1. Description: The description contains an explanation and background information about the check conducted.
2. Implication: The check’s potential impact if not addressed.
3. References: The references contain links to more information and context about a specific check.
Compliance Tab
Compliance shows which specific compliance regulations are relevant to that particular check.
1. Compliance Standard Header: This shows the specific compliance regulation relevant to that particular check. Clicking on this takes you to the full document of the standard (if applicable).
2. Compliance Controls: The compliance control portion describes in further detail any compliance controls that affect the check.
Recommendation Tab
The recommendation tab contains a guide on how to fix this check via the cloud console or cloud CLI (if applicable).
History Tab
The history tab details all the changes to a check over a period of time, helping you to understand when an issue was introduced, as well as any past status or severity changes.
1. Date: The date a change was done.
2. Time: The time the change was done.
3. Changes: The history of the check across scans.
4. Notes: Any notes accompanying the modifications.
Here are the list of possible changes:
- First check performed: Warden performs the check for the first time, for example when a new resource is created.
- Check now Failing: An existing passing or suppressed check is now failing, for example when someone disables MFA on their account.
- Check now Passing: A failing or suppressed check is now passing, this indicates that a misconfiguration has been fixed. For example when a security group’s inbound rules have been tightened to meet best practices.
- Check now Suppressed: A user suppresses a failing check through Vulnerability Management. For example, the user accepts the risk of having a storage bucket publicly accessible and marks it as Risk Accepted.
- Check no longer performed: The check was no longer performed, usually due to the resource no longer being detected. For example after an unused IAM user has been deleted.
- Severity changed by {User}: A user within the organization changed the check’s severity level.
- Status changed by {User}: A user within the organization changed the check’s status.