The approval flow - an overview
Up until now, the Vulcan Platform allowed you to change the status of a vulnerability from "Vulnerable" to "Ignored" by simply selecting a vulnerability and changing its status to "Ignored" without user permissions or an approval process to comply. This is why we developed the Exception feature. From now on, organizations can apply their risk-acceptance policy on vulnerabilities through the Vulcan Platform.
The feature allows you to:
Define user permissions for the Exception request
Create custom exception request types with your policy
Create/Edit Exception requests and trigger the approval flow
View vulnerabilities that have been approved to be "Ignored" (risk-accepted)
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 right 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 the policies, GRC rules, and regulations of your organization.
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 and make sure 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 "Ignored" 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 kind of roles you need to have 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 get a better idea of what kind of roles you might want to create, take a look at the "Users and scenarios to consider" section.
Make sure 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/or 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
The next thing you would do after defining your roles and users for the exception request flow is to 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: the defaults can be changed by an Admin user.
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.
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".
Create an Exception Request on a vulnerability and trigger the flow
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
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
Manage existing Exception Requests
Manage Exception Requests through the newly added Exceptions page. This is where you get to review all the triggered exception request flows, their statuses, and their details. You can also select to show only requests "Assigned to me" and "Assigned by me".
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
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)
What should we expect to see in terms of SPR, risk mass, and asset prioritization when a particular exception is approved?
Once an exception is approved, the respected vulnerability receives the "Ignored" status. Ignored vulnerabilities appear on the Ignore page (Vulnerabilities > Ignored) and they don't affect SPR, Risk Mass, or any other risk-related stats. In other words, as long as a Vulnerability is in "Ignored" status, it is out of the risk-related analytics of the Vulcan Platform.
If the exception request is still in process (neither approved nor declined), does the respective vulnerability affect the risk-related analytics?
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 "Ignored" page and no longer affects the Security Posture Rating.
When vulnerabilities are in Pending status, are they considered "vulnerable" or "ignored"?
Vulnerability instances that are included in a pending request are still vulnerable and won't be ignored until the request is approved.