Vulnerability management at a high level focuses on:
- Governance: Provides governance of security risks through classification, prioritization, and the establishment of remediation requirements.
- Reporting: Leverages automation to report risk findings and status updates to risk owners and stakeholders.
- Management: Utilizes automation to detect and manage ticketing and workflow issues, as well as handle escalations involving remediation extensions.
This runbook primarily focuses on automation usage and follow-up, and also provides a bare minimium process for remediation extensions for when a security exception or risk acceptance process is lacking. This runbook should be used once a vulnerability management program has been established. Please see the README.md file for guidance on where to start first.
This section outlines the steps to follow when an engineering team requests additional time to fix an issue or decides to accept the risk of the issue without remediation.
Request for extension: There may be times when the product and engineering teams are unable to resolve an issue within the remediation SLA and will request additional time. Reasons for requesting extensions include difficult fixes, such as those of an architectural nature, competing priorities, or a lack of resources.
The risk level of the vulnerability should determine who needs to be involved in accepting the risk and approving the extension. The table below provides guidelines on who can grant extensions and accept risks, but these guidelines should be adjusted according to your company's risk tolerance.
Vulnerability extension table
| Vulnerability severity | Default time to remediate | Product/Engineering risk approver | Security team risk approval for extension | Guidance for extension without escalation |
|---|---|---|---|---|
| Critical | 0-7 days | Product/Engineering VP/C-suite | Security VP/CISO | Criticals can only be extended for ~2 hours without escalation |
| High | ~30 days | Engineering/Product director | Security director | Highs can only be extended for 1-2 days without escalation |
| Medium | ~60 days | Engineering manager | Security manager | Mediums can only be extended for ~10 days without escalation |
| Low | ~90 days | None required | Sr/Staff security engineer/analyst | Lows can only be extended for ~20 days without escalation |
Steps for handling extension requests
- Receive extension request: Ensure that the person requesting the extension is authorized to do so. Generally, at minimium, this will be a product or engineering manager.
- Evaluate the requested timeline against the vulnerability extension table above:
- If the requested time is within the 'Guidance for extension without escalation' value, an appropriate security representative (as indicated above) must approve the issue and comment in the ticket that approval was granted. This is critical for audit purposes, legal considerations, and as a general best practice. The ticket update should also include the new fix date and update the 'due date' field.
- If the time requested is above the 'Guidance for extension without escalation' value follow step 3 onward.
- Loop in appropriate stakeholders for approval: At this stage, if an extension is requested beyond the 'Guidance for extension without escalation,' you will need to involve the appropriate levels of security leadership and engineering/product leadership to sign off on the extension.
- If all stakeholders agree to the extension ensure each stakeholder comments on the ticket with their approval and the number of days the extension is approved for. This must include both security leadership and engineering/product leadership.
- If stakeholders disagree on the extension, escalation is required. For example,
- Critical issues should be escalated to the CISO/BISO for security and the CTO/equivilent for engineering/product.
- A High issue should be escalated to Senior Directors in engineering/product/security
- A Medium issue should be escalated to the engineering/product/security director levels
- Verify ticketing contains required information: Ensure the ticket includes both the approvals as indicated above and a plan for future remediation. Without a specified plan, teams may indefinitely delay addressing the issue. Requiring a plan as part of the extension ensures that the engineering and product teams have a clear path to resolve the issue.
Steps for 'risk acceptance' instead of addressing risk
- Direct requests to existing processes: If your company has a security exception or risk acceptance process in place, direct these types of requests to that process. If no such process exists, proceed to step 2.
- Establish a security exception or risk acceptance process: If your company lacks a security exception or risk acceptance process, collaborate with leadership to establish one. The process should capture:
- Risk summary
- Advantages of acceptance
- Risks of acceptance
- Detailed description of issue with links to appropriate tickets/documentation
- Compensating controls in place to mitigate risk
- Signoff by the appropriate leadership level.
Note: Due to the complexity of this topic, a comprehensive risk acceptance or security exception process is not included here. Future releases from Sectemplates may provide dedicated resources for these processes.
This section outlines the steps to follow when handling the reports generated by the ticket health automation. This automation should run daily to flag issues early and often, enabling you to ensure issues are on track for proper remediation.
-
Health automation report is sent to the vulnerability management owner/security team once a day: Initially, it may be a good idea to send it out even if no findings are discovered to ensure its scheduled job is running correctly and accurately identifying issues.
-
Identify issues lacking a correct owner: An incorrectly assigned ticket won't be worked on, so you'll need to verify tickets with 'assignee' issues. This applies to tickets that are:
- Unassigned
- Assigned to employees who have left the company
- Assigned to unused or stale aliases
This may require contacting the engineering manager, product manager, or engineering team channel to find the right owner for an issue.
-
Identify issues with a blank or modified due date: Due date fields may become blank due to automation glitches, ticket movements, changes to the workflow during ticket creation, or manual removal or modification. Without a correct due date, automation will be unable to determine if an issue is being handled within SLA so it's critical to verify these are correct. Generally, the due date field should only be modifiable by the security team for vulnerabilities.
-
Identify priority changes: The priority of a vulnerability should only be changed or approved by the security team. Any deviation in priority should be manually reviewed by the vulnerability management program owner or delegate; otherwise, you risk high-risk issues slipping through the cracks.
- For tickets that have had their priority downgraded: Determine if this is the correct decision. If so, add a note on the ticket for audit trail purposes stating the approval of the downgrade. This is critical in case of a future breach, incident, or audit.
- For tickets that have had their priority increased: This may be a mistake, or the criticality of an issue may have increased since the initial discovery. The increase may require initiating an incident and should be evaluated quickly by the vulnerability management point of contact.
Tip: Consider scheduling a 15-minute meeting every day to allocate time to review these findings.
The goal of this section is to outline how you can utilize and support stakeholder vulnerability reporting.
- Verifying the report was correctly sent out: Verify that the reporting is working correctly, running at the expected time, and being sent to the expected stakeholders.
- Monitor for stakeholders requesting assistance: Review the email or Slack channel where the report was sent and monitor for stakeholders requesting assistance.
- Identify stakeholders requiring assistance, who haven't reached out: Chances are, your stakeholders may not review this report every time it's sent out. Determine which stakeholders have high-risk issues that are out of SLA, approaching out of SLA, or have a large quantity of issues, and offer your support.
- Schedule time with risk owners requiring help, or message them: Evaluate the current ticket health with each stakeholder and determine if you should message them or schedule time to meet to understand how you can help support their remediation efforts.
Tip: Consider scheduling a 15-minute meeting shortly after this report is sent out, to block off time to review these findings.
- Slack channel for help: Having a channel where engineers, engineering managers, and product managers can join and ask for security help is beneficial and keeps communication flowing. We recommend either using the main #security channel or, if the volume of requests becomes too high, creating a separate support channel for vulnerability remediation support.
- Office hours for help: In addition to running automation and overseeing filed issues, we recommend providing office hours where engineers or their leaders can join and ask for help on an issue. This will require having a security engineer or SME available to provide support for 30-60 minutes per week.
Runbook version 1.2 copied from Sectemplates.com 2024