Vulnerability Management Policy
Breakout Learning Inc
Purpose
The purpose of this policy is to outline the requirements for (1) all product systems to be scanned for vulnerabilities at least annually, and (2) all vulnerability findings to be reported, tagged, and tracked to resolution in accordance with the SLAs defined herein. Records of findings must be retained for at least 5 years.
Roles and Responsibilities
Chief Information Security Officer (CISO)
- Updating the Policy: Responsible for reviewing and updating the Vulnerability Management Policy at least annually or as needed to reflect changes in the threat landscape, technology, or business operations.
- Reviewing the Policy: Actively participates in periodic reviews to assess the effectiveness of the Vulnerability Management Policy, ensuring alignment with industry best practices and compliance requirements.
- Maintaining the Policy: Ensures that the policy is accessible to all relevant stakeholders, regularly communicated, and compliant with the organization's security objectives.
Policy
Information Systems Audit
- Audit requirements for access to systems and data should be agreed upon with appropriate management.
- Scope of technical audit tests should be controlled and agreed upon in advance.
- Audit tests should be limited to read-only access to software and data unless otherwise agreed.
- All audit activities should be logged and monitored for traceability.
Vulnerability Scanning and Infrastructure Security Testing
- Breakout Learning Inc utilizes Google Cloud Security Scanner for vulnerability detection.
- Detection tools, threat signatures, and compromise indicators will be updated weekly, or immediately as required by emerging threats or critical vulnerabilities.
Penetration Testing
- Penetration testing is performed regularly by either an internal certified penetration tester or an independent third party.
- The Chief Information Security Officer, along with IT and Engineering, reviews findings from vulnerability scans and penetration tests.
Security Findings Reporting, Tracking, and Remediation
Breakout Learning Inc uses Jira Service Management (JSM) to manage and track vulnerability findings. Records of findings are retained for 90 days.
Reporting a Finding
- Vulnerabilities can be reported through the Jira Service Management portal: Breakout Learning JSM Portal at https://breakoutlearning.atlassian.net/servicedesk/customer/portals.
- Use the form titled "Report a Security Vulnerability or Incident" to submit a vulnerability report.
- Upon identification of a vulnerability, a JSM ticket is created.
- The description should include details, excluding confidential information, and a link to the source of the finding.
- A priority level is assigned to the finding.
Priority/Severity Ratings and Service Level Agreements (SLAs)
Priority Level |
SLA |
Definition |
Examples |
Critical |
24 Hours |
Vulnerabilities that cause privilege escalation, remote code execution, or unauthorized access to sensitive data |
Remote Code Execution (RCE), SSRF, SQL Injection |
High |
24 Hours |
Vulnerabilities affecting platform security processes |
Lateral authentication bypass, stored XSS |
Medium |
Best Efforts |
Vulnerabilities requiring little user interaction to trigger |
Reflective XSS, direct object reference |
Low |
Best Efforts |
Issues requiring user interaction or significant prerequisites (MitM) |
Debug information, mixed content |
If the severity rating or priority level is changed after a finding is created, the SLA is adjusted accordingly.
Resolving a Finding
- The finding is assigned to the responsible system or software package owner.
- All findings must be addressed according to the assigned SLA. No software is deployed to production with unresolved Critical or High findings unless an Exception is in place.
Closing a Finding
- A valid resolution (fix, false positive, or approved exception) is provided.
- The finding is re-assigned to the Reporter or Security Team for validation.
- After validation, the finding can be closed. The fix must first be deployed in a development environment, with a targeted release date for production deployment noted on the JSM ticket.
Exceptions
- Exceptions are requested when a direct fix for a vulnerability is not available.
- An alternative compensating control must be in place to mitigate the risk.
- Exceptions are tracked as JSM tickets linked to the original finding and must be approved by the Chief Information Security Officer and the asset owner.
Revision History
Version |
Date |
Editor |
Approver |
Description of Changes |
1.1 |
2024/10/01 |
Nikita Rogatnev |
Joshua Oster-Morris |
Standardized role titles across all relevant policies, replacing previous variations |
1.0 |
2024/01/01 |
Joshua Oster-Morris |
Jake Shepherd |
Initial version |