Incident Handling Policy

The Alert Logic TSX service is designed to monitor, detect, and respond to adverse security issues on behalf of our customers. Within this process, there are both automated and manual processes supported by our Analytics Engine, as well as our security operations center (SOC) personnel. This document outlines how the overall system and service work and what our standard policy is when handling security incidents, escalations, and response operations. 

In This Article

• Definitions
• Analytics Engine
• Incident Classification & Escalation Handling
• Required Security Contact Information

Definitions

An Event is an observable occurrence that may imply risk, harm, or a potential compliance violation as detected by our network traffic sensors or log messages received from within the customer's environment.

An Incident is a correlation of event(s) that imply harm to an information system, potentially violate acceptable use policies, or circumvent standard security practices. Alert Logic classifies these incidents into four risk severities; Low, Medium, High, and Critical, as determined by the Analytics Engine and/or the SOC analyst. Note: Learn more about how best to manage your incidents with our Managing Incidents in the Alert Logic Console knowledge base article.

An Escalation is a notification to a customer that there is increased activity that warrants closer monitoring and/or response.  In some cases, the Analytics Engine will automatically escalate to customers via email simply for awareness, but in the case of more serious activity, the SOC analysts will email and/or call the customer directly.

Response Operation(s) can be automated responses, such as the generation of blocking rules by the sensor to an associated firewall. Note: Learn more about Alert Logic’s response capabilities with our Intelligent Response for Managed Detection and Response knowledge base article and Get Started with Automated Response documentation.

Analytics Engine

The Analytics Engine collects security data from numerous sources across your organization’s environment and uses a frequently updated library of correlation rules to identify behavior for security incidents. This saves you the large investment of a standalone SIEM solution and your own security research team. To make sense of the massive data Alert Logic collects, the Analytics Engine processes and normalizes it to uncover security incidents. Valid security threats are vetted and escalated for remediation, which prevents an overflow of false positives and keeps our analysts focused on real, actionable incidents.

Once the Analytics Engine has correlated a series of events as an actual incident, it classifies the incident in accordance with the priorities described below. Any incident initially classified with a threat rating of High or Critical is immediately forwarded to a security analyst in the SOC for investigation.

Incident Classification & Escalation Handling

Low Severity and Info Severity incidents are often considered “informational” or for compliance purposes, and as a result are not usually escalated by default. These are available in the console and should be reviewed periodically but may not require any specific remediation actions. SOC analysts can also categorize false positive alerts as a low threat during their incident review. Common examples of Low incidents are:

• Potential Acceptable Use Policy violations by the customer's employees
• Vendor Scans, or authorized internal scans which trigger IDS events
• Untargeted up-host or port scans
• False positive alerts which have been downgraded
  Note: If you have frequent false positive alerts, please open a ticket with our SOC and we will work with you to tune the logic for your deployment.

Medium Severity incidents consist primarily of failed exploitation attempts observed in your environment. Because these incidents do not carry any evidence of successful compromise there is usually no significant real-time response required, but additional mitigating steps may be recommended. Medium incidents are typically escalated by default to all configured security contacts via email notification. Common examples of Medium incidents include:

• Brute force or dictionary attacks
• Automated or drive-by malware infection attempts
• Reconnaissance behavior (simple exploit scanning attempts)

High Severity incidents display evidence of compromise, confirmed vulnerability, or an extended duration attack within your environment. Our analysts' recommendations will contain next steps to help you begin your incident response triage and react as soon as possible. High Severity incidents will be escalated by email to all the contacts configured, and the SOC analyst will also call a list of pre-configured contacts. Common examples include:

• Brute force attacks that continue for long periods of time
• Verbose errors (stack trace, SQLi syntax errors confirming vulnerability, PHPInfo pages etc.)

Critical Severity incidents follow the same escalation guidelines as High Severity incidents, except that they typically are the result of malicious activity which requires immediate, time-sensitive response to contain and prevent further impact. Examples of this type of alert include:

• Active breach (lateral movement, suspicious service installs, etc.)
• Ransomware IOCs/propagation
• Data exposure (successful SQL injection returning data, publicly accessible login credentials, etc.)
• Successful exploitation of an unpatched, high-risk vulnerability

Required Security Contact Information

When customers are enrolled into an Alert Logic service, they must provide their Provisioning Coordinator with a prioritized list of three security contacts. These contacts will be called in order or priority in the case of a high or critical escalation.

The SOC may also accommodate specific escalation preferences for partners and customers to assist with service integration to existing processes defined by the client.  These customized escalation preferences must be submitted in writing to the SOC for approval and clarification before they can be implemented in the escalation process.  Otherwise, the processes and procedures outlined within this document apply.