This document outlines the steps required to prepare for and establish a security exceptions program. For simplicity, we assume Jira is the bug tracking system in use due to its popularity.
-
Determine security exception program owner: This individual will serve as a technical program manager to ensure smooth operations, handle escalations, and maintain follow-through.
-
Determine exception prioritization methodology: To understand which security exceptions are higher priority, you will need to utilize a consistent approach to determine the priority. A simple approach is to reuse the priority of the vulnerability as it should capture the impact, existing mitigating controls, and severity levels. See the vulnerability management program pack for details on vulnerability risk ranking methodologies.
-
Determine criteria and decision tree for approvals: To enable teams to move quickly, provide a decision tree that specifies who should approve an exception based on its priority. A sample table can be found here.
-
Determine required details within an exception: Please see 'Security Exception reporting requirements' for a list of specific fields to include in each exception request.
-
Determine how to document/track exceptions: You need to decide what type of artifact captures the exception details, such as a word document or Jira ticket.
- Option 1 - Utilizing a word document for individual exceptions, and a spreadsheet for tracking all exceptions: Some people prefer to stick with word documents and spreadsheets instead of integrating exceptions tracking into Jira. This pack provides a sample exception template, and exception tracker spreadsheet to get you started.
- Pros: You can get started quickly.
- Cons: Tracking the status of issues may be more manual, exception health automation/reporting automation may be limited.
- Option 2 - Utilizing Jira ticketing and dashboarding: Another option is to create new issuetype in jira using the exception requirements specified here.
- Pros: Once setup correctly, you can easily create Jira dashboards to visualize the metrics/status' of your exceptions. Jira provides APIs that will enable both health automation and reporting automation.
- Cons: Initial setup is more work, and may require maintence occassionally.
- Option 3 - Utilizing Jira ticketing with document attachment: A hybrid approach.
- Pros: You can automate exception reporting fairly easily.
- Cons: Automating ticket health reporting will be more challenging as it may require downloading and parsing the document template instead of jira fields.
- Option 1 - Utilizing a word document for individual exceptions, and a spreadsheet for tracking all exceptions: Some people prefer to stick with word documents and spreadsheets instead of integrating exceptions tracking into Jira. This pack provides a sample exception template, and exception tracker spreadsheet to get you started.
-
Develop a security exception runbook: When an exception is filed or responded to by a risk owner, a standardized set of steps must be followed to ensure consistency. Sample runbooks can be found here.
-
Test the workflow: After implementing your desired approach, test every basic workflow including
- Filling out the exception request to determine if additional/less fields are needed.
- Moving into a review state, then reverting back to the to-do/queue state.
- Denying an exception/ticket
- Approving an exception/ticket
- Sending a ticket back for more information
-
Pilot the process: Identify an appropriate risk item to test the process, and gather feedback from stakeholders. Incorporate this feedback to fix workflow issues, as well as to enhance the process.
-
Develop ticket health automation to identify issues: Automation is needed to verify that processes are running smoothly, tickets have the correct fields, and are not assigned to employees who have left the company. Please refer to the "Security exception health automation" section below for more details.
-
Determine reporting requirements and capabilities: After reviewing the reporting requirements and metrics sections, determine what metrics and reporting you want.
-
Develop reporting automation, and send out reports: A weekly or biweekly report sent to risk owners who have issues to address provides visibility into unaddressed risks. Please refer to the "Automating exception reporting" section below for more details.
-
Establish slack channel to discuss exceptions: Create an invite-only channel and include risk approvers and risk owners. This will enable faster communication, expedite responses, and support urgent escalations by bringing all relevant stakeholders together.
-
Establish a regular exceptions review meeting: Set up a biweekly or monthly meeting with approvers to address issues requiring their attention. Invite Risk Owners, Risk Approvers, and Subject Matter Experts to provide context during discussions. Please see the exception runbook section for more information.
This section will focus on two important aspects of a security exception program, reporting, and oversight of ticket health.
Please see security exception reporting requirements for this topic.
Verifying the quality of your tickets in an automated fashion is critical to ensure that risk is properly assigned to the correct owners, classified at the appropriate level, and not lost in the process. It is recommended to build automation that queries for these common quality issues and notifies the security DRI for your exceptions program daily:
- Tickets assigned to 'unassigned': Tickets may be accidentally or intentionally assigned to 'unassigned,' and it's important to ensure these tickets are not lost.
- Tickets assigned to employee who have left the company: At some point, employees will leave the company, and tickets may remain assigned to them. It's important to flag these tickets promptly and reach out to their former manager to determine who the new owner should be.
- Tickets lacking a due date: For various reasons, this field may become blank. Each ticket should have a clear expected fix-by date for the risk owner to evaluate.
- Tickets which have had their priority downgraded: These tickets should be reviewed by the security exception program owner or their delegate to determine if the decision to lower the severity/priority was appropriate.
- Due dates changed: People may attempt to change due dates to circumvent SLA oversight. It is recommended to mark this field as read-only; however, if you are unable to do so, you should monitor this field and notify the security team when the date is changed.
- Tickets which have had their priority increased: These tickets should be promptly reviewed to determine if an urgent matter, possibly requiring a security incident response, needs to be addressed. It also provides a signal on tickets which, during the transition to a higher priority, could be automatically considered out of SLA.
Note: If possible, tying a single report for both security exceptions and vulnerability oversight may be advantageous. Please see the 'Vulnerability Management Reporting Automation' section of the 'Vulnerability Management Program' pack.
Checklist version 1.0 copied from Sectemplates.com 2024