Vulnerability Management: SecOps On-call Duties (template)

Prevent system downtime or a reportable security incident

Objective

The primary goal of monitoring alerts and identifying vulnerabilities is to prevent system downtime or a reportable security incident. In cases where an event does lead to downtime or an incident, the following protocols should be followed:

• [add link to internally published SEV - site event] - Postmortem Template: For system downtime not involving compromise of information security.
• [add link to internally published SIRP - Security Incident Response Plan]: For events that could potentially lead to the undesired destruction, loss, alteration, disclosure of, or access to, confidential information.

On-Call Engineer Identification

Use [Incident Management and External Communication] to identify the on-call engineer responsible for monitoring and responding to security alerts.

Weekly Debrief

• During the "Weekly Debrief: Vulnerabilities & Security Alerts," the on-call engineer from the past week will review the tickets opened and the status of unresolved tickets.
• Notate any sudden changes or increases in alerts to determine the root cause and assess if additional security controls are needed.

Daily Critical Alerts to Watch and Triage

• Monitor Alerts: Use [Internal Security Event and Incident Management Communication] for real-time alerts from automated 24/7 monitoring (e.g., #security-alerts)
• Triaging Alerts: Assess each alert to determine if action is required. Consider the impact, such as potential system downtime or unauthorized access, and proceed to open a ticket for further action.

Steps to Open a Ticket/Case to Track the Action

• Labels/Tags: [system that generated the alert] 
• Title/Name: Format - "Slack Alert - [criticality level] - [system that generated alert] - [finding type]" (e.g., "Slack Alert - Critical - GuardDuty - Policy:S3/BucketAnonymousAccessGranted").
• Description: Detail the action to be taken (e.g., "Revised S3 bucket permissions to eliminate anonymous access and configured bucket encryption to secure data at rest.").

Weekly Vulnerability Scans

• Conduct scans that cover architecture and software packages using [AWS Inspector] for architecture vulnerability scans and [SecurityHub] for configuration monitoring. Reports should be produced weekly and sent to the security@[email].com group email.
• Grouping Vulnerabilities: Collaborate to group all identified vulnerabilities based on the action required for resolution. For example, updating Lambda to version X.X can resolve 8 critical vulnerabilities.

Vulnerability Remediation Timeframes

Refer to the [add link to internally published Threat and Vulnerability Management Policy]. Remediation timeframes are based on the severity level and are determined by the CVE (Common Vulnerabilities and Exposures) ratings:

Related links

• Managing Vulnerabilities Guide
• Another template: Vulnerability Management: Manage and Track Events
  [Link to other template]