What is an Exception Request?
The Vulcan Platform allows organizations to apply their risk-acceptance policy on vulnerabilities. The Exception Request flow in Vulcan enables users to create exception requests for vulnerabilities received in remediation tickets. Once a request is submitted, the approval workflow is triggered, as detailed in this article.
The feature allows admins and permitted users to:
Define user permissions for the Exception request
Create custom exception request types with the organizational policy
Create/Edit Exception requests and trigger the approval flow
View vulnerabilities that have been approved (risk accepted / "acknowledged")
Set the number and identity of approvers, request expiration date, and email notification frequency.
View and manage exception requests through the Exceptions new page
Access the content and history of approval flows for auditing
How Exception Requests Work
To learn all about how Exception Requests work, let's take a look at the components of this feature in the following particular order:
Define the roles, permissions, and users of Exception Requests
User scenarios to consider
As an Admin user of the Vulcan Platform, you would be able to:
Set which users can approve exceptions so you can limit this action to users with the proper knowledge and clearance.
Set the number of users that must approve an exception request and the default expiration date of an approved request.
Execute a workflow that complies with the policy of the organization
As an Approver (Role) you would be able to:
Review, re-assign (delegate), approve, or decline exception requests on vulnerabilities while basing your decision on your organization's policies, GRC rules, and regulations.
As an Exception Requests Creator (Role), you would be able to:
Receive email notifications when requests are pending approval, approved, or declined.
Manage the requests, ensure other stakeholders are notified, and complete their tasks.
As a manager with the relevant permissions (Role) you would be able to:
Change the status of "acknowledged" vulnerabilities back to "vulnerable" by deleting an exception request immediately, so you can manage any existing risk that needs attention.
Once you are set on what roles you need for your Exception flow, you can move forward to define the users and permissions of Exception Requests.
As an initial step and a prerequisite, you need to set the users and permission of the exception requests flow.
Go to Settings > Users and Roles
Create a Role (or edit an existing Role) as you would normally do—for example, an "Exception Approver" role. To better understand what kind of roles you might want to create, look at the "Users and scenarios to consider" section.
Ensure the relevant Exceptions permissions are enabled under the categories "Settings" and "Exceptions".
For example, for the "Approvers" role, you might consider granting only the "Approve or decline and exception request" permission. It all depends on the regulation of the organization.
Click Save Changes.
Consider creating the rest of the relevant roles. See "Users and scenarios to consider" for Roles ideas.
Create and add the relevant users to relevant roles:
Settings > Users and Roles > Edit Users / Add a user
Set the role for the user and click Save / Create.
Once you are done with the users and roles, you can proceed to "Creating an Exception Request type".
Create an Exception Request type
After defining your roles and users for the exception request flow, the next thing you would do is create an exception request type. This is where you get to define the details of a request type, such as the number of mandatory approvers, expiration time, notification time to expiration, and frequency of notifications.
By default, new environments come with two exception request types:
Risk Acknowledged (0 approvers needed)
False-positive (0 approvers needed)
Note: an Admin user can change the defaults.
To create a new Exception Request type:
Go to Settings > Exceptions > Click on Create new
Give the request type a name and set the details and properties of the exception approval flow.
Click Save.
Once you are done creating all your relevant requests type (even if it is just one), you can proceed to "Creating an Exception Request on a vulnerability and triggering the flow".
Note: Exception requests cannot be created for vulnerabilities that are already in ‘Ignored/acknowledged' status or in 'Fixed status
Create an Exception Request on a vulnerability and trigger the flow
Permitted users can create Exception Requests in two ways:
Trigger Exception Requests flow directly through the Vulnerabilities page:
Check the relevant vulnerability or more > Click Take Action > Select Exception Request
Fill in the required details and review the linked Vulnerabilities and affected Assets:
Select request type
Insert exception name and Business Justification to make it more informative for the approvers.
Select the approvers
Select expiration date (once set, only admins/users with the right permission can override the Exception Expiration)
Attach files to justify or enrich the request:
Maximum Size of a Single File: 200MB
Maximum Total File Size: 100GB
Number of Files per Request: Unlimited (subject to the total file size limit)
Supported File Types: csv, doc, docx, pdf, txt, json, eml, jpg, jpeg, png, gif, xls, xlsx
You can click on Assets / Vulnerabilities to review the assets and Vulnerabilities linked to this request. You can also check/uncheck linked assets. When you uncheck an asset, it means that the vulnerability on that asset is not part of the exception request. This also means that you want to keep the SLA valid for the vulnerability on that asset. This is relevant if you have more than one asset linked to the vulnerability.
Click Save to trigger the flow
Trigger Exception Request flow directly through the Remediation Work Form URL in tickets
The Remediation Work Form allows security cross-team users to view vulnerability instances and their details through the remediation ticket, and to submit an exception request for part or all of the instances.
Change the Header and Footer of Exception Request emails
You change the default header and footer of the Exception Request email. To change the defaults, contact your Customer Success Manager or Vulcan support.
The Approval Flow
Once a flow is triggered, the approver will receive an email with the details of the request, including:
The email of the requester
The number of vulnerabilities and linked assets
Maximum risk
SLA status
link to review the request
Once the approver opens the request they get to modify the expiration date, add a comment, and check/uncheck related assets (depends on the permissions granted).
Then, the approver can click to Approve or Decline the request.
>>>
Once the request is approved/declined, the requester receives a confirmation email with the following information:
The email of the approver/decliner
Confirmation that the SLA on the vulnerability is now on Hold (in case of approval)
Request Expiration date
A note on what happens once the request expires (the SLA of the vulnerability resumes counting)
Managing existing Exception Requests
FAQ
When a particular exception is approved, what should we expect to see regarding SPR, risk mass, and asset prioritization?
Once an exception is approved, the respected vulnerability receives the "acknowledged" status. Acknowledged vulnerabilities appear under the Acknowledged tab (Vulnerabilities > Acknowledged) and don't affect SPR, Risk Mass, or any other risk-related stats. In other words, as long as a Vulnerability is in "Acknowledged" status, it is out of the risk-related analytics of the Vulcan Platform.
Does the respective vulnerability affect the risk-related analytics if the exception request is still in process (neither approved nor declined)?
Yes. As long as the vulnerability exception request is in-process, it's considered "Vulnerable."
What happens to approved Vulnerabilities?
Once a vulnerability is approved as an exception, it no longer exists in the Vulnerabilities > Vulnerable page view. The vulnerability moves to the "Acknowledged" page and no longer affects the Security Posture Rating.
When vulnerabilities are in Pending status, are they considered "vulnerable" or "Acknowledged"?
Vulnerability instances included in a pending request are still vulnerable and will only be acknowledged once approved.
How does the system handle vulnerabilities flagged as Ignored or Risk Acknowledged by the scanner?
When a scanner identifies vulnerabilities and flags them as Ignored or Risk Acknowledged, the system defers to the scanner's judgment. The scanner's designation takes precedence in these instances.
What happens when a user manually changes a vulnerability's status to Ignored or Risk Acknowledged within the Vulcan system?
Any changes made manually within the Vulcan system, such as setting a vulnerability's status to Ignored or Risk Acknowledged, are treated distinctly as Risk Acknowledged. This manual acknowledgement is prioritized by the system.
Will manually ignored or risk-acknowledged vulnerabilities be updated with new data from connectors?
Vulnerabilities that have been manually set to Ignored or Risk Acknowledged will not receive updates from data ingested via connectors. To allow updates, the vulnerability status must be manually changed back to a state other than Ignored or Risk Accepted.