Advanced Security Management Response Time Policy
Advanced Security Management Response Time Policy
- All reported weaknesses, events and incidents must be assessed and results of such documented in the ticketing system by the Information Security Team.
- All Information Security Events (e.g. Alerts, Notifications) will be classified automatically during ingestion of alerts into the ticketing system, and will be analyzed/responded to according to the following table:
|
Alert Severity |
Alert Classification |
Initial Response Time |
|
Critical |
Alerts in this category are
indications of activity that are generally linked to successful intrusions
and are likely to cause big impact to organizations. These alerts. Common
examples of Critical priority alerts include: ·
Information leakage/data retrieval -
successful SQL injection that is returning data. ·
Successful worm propagation. ·
Problems requiring immediate defense
remediation to reduce exposure. ·
Post-compromise activity - outbound
remote shell cmds, attack tool downloads, etc. |
1 Hour |
|
High |
Alerts in this category are
indications of attempts to perform malicious activities or confirmed
malicious activity that could cause severe impacts to organizations. Even
though these may not necessarily indicate a compromise, these alerts need to
be responded to very quickly. Common examples of High priority alerts
include: ·
High severity, aggressive, penetration
tests ·
Larger scale/duration brute force
attacks ·
Malware Command Control Activity ·
Potential Server Compromise -
successful SQLi, Webshell activity, etc. |
4 Hours |
|
Medium |
Alerts in this category are
indications of attempts to break in the environment. Common examples of Medium priority alerts include: ·
Brute force or dictionary attacks. ·
Automated or drive-by malware
infection attempts. ·
More targeted reconnaissance behavior
- simple exploit attempts. |
24 Hours |
|
Low |
Alerts in this category are unlikely
to cause direct impact to organizations but should be paid attention to in
aggregation. Common examples of Low priority alerts include: ·
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. |
2 Business Days |
|
Informational |
Alerts in this category are generally
not related to malicious activity. Common examples are log review activities
that are documented in the form of alerts. |
5 Business Days |
3. The ticket will then be classified as either:
-
- True positives, actual Information Security Incidents,
- False positives, benign activity or unrelated to Information Security.
4. All alerts that impact customers or WatServ will be classified as Information Security Incidents.
5. Information Security Incidents will have an impact assessment to determine:
a. Endpoints compromised: number and scope, such as clients’, WatServ’s, critical/non-critical etc. b. Service degradation / impact to clients’ service delivery. c. Service degradation / impact to WatServ’s Shared Services environments. d. Accounts compromised: number and scope, such as privileged / non-privileged. e. Propagation status and extent.
6. Information Security Incidents will be classified, communicated, escalated, and dealt with according to this table:
|
Security Incident Severity
Levels |
Definitions |
Initial Response |
Action Plan Defined |
|
Security Incident - Severity 1 |
Confirmed security incident with severe
impact. Endpoints: Several mission-critical*
endpoints. Service degradation: WatServ service delivery completely compromised. Accounts: Several privileged accounts
were compromised. Propagation: Widespread propagation. |
30 minutes |
30 minutes |
|
Security Incident - Severity 2 |
Confirmed security incident with high
impact. Endpoints: One or two
mission-critical* endpoints. Service degradation: WatServ service delivery partially compromised. Accounts: One or more privileged
accounts were compromised, or several unprivileged accounts were compromised. Propagation: Confirmed successful
propagation attempts. Exploit exists. Attacker could gain user level access
privileges. Attacker could commit denial of service. |
2 hours |
3 hours |
|
Security Incident - Severity 3 |
Confirmed security incident with
medium impact. Endpoints: Several endpoints
(non-mission-critical*). Service degradation: Minor disruptions
to WatServ service delivery. Accounts: One privileged account was
compromised. Propagation: Confirmed unsuccessful
propagation attempts. |
Next Business Day |
1 Business Day |
|
Security Incident - Severity 4 |
Confirmed security incident with low
impact. Endpoints: Limited to one or two
servers or endpoints. Service degradation: Disruptions to WatServ service delivery that do not affect the customer. Accounts: One unprivileged user
account has been compromised. Propagation: Indicators (unconfirmed)
of broader propagation |
Next Business Day |
2 Business Days |
|
Security Incident - Severity 5 |
Unconfirmed security event or incident
with very low impact. Endpoints: One server or endpoint
affected. Service degradation: None. Accounts: One unprivileged user
account may have been compromised. Propagation: No indication of broader
propagation. |
2 |
3 Business Days |
Advanced Security Management Response Time Policy
All Information Security Events (i.e., alerts) will be classified automatically during ingestion of alerts into the ticketing system and will be analyzed/responded to in accordance with the following table.
| Severity | Definition | Response Target* |
| Critical | Alerts in this category are indications of activity that are generally linked to successful intrusions and are likely to cause big impact to organizations. Common examples are: · Information leakage/data retrieval – successful SQL injection that is returning data. · Successful worm propagation · Post-compromise activity – outbound remote shell commands and attack tool downloads | 2 Hours |
| High | Alerts in this category are indications of attempts to perform malicious activities or confirmed malicious activity that could cause severe impacts to organizations. Even though these may not necessarily indicate a compromise, these alerts need to be responded to very quickly. Common examples are: · High severity, aggressive, penetration tests · Larger scale/duration brute force attacks · Malware Command Control Activity · Potential Server Compromise – successful SQLi, Webshell activity | 4 Hours |
| Medium | Alerts in this category are indications of attempts to break in the environment. Common examples are: · Brute force or dictionary attacks · Automated or drive-by malware infection attempts · More targeted reconnaissance behavior – simple exploit attempts | 8 Business Hours |
| Low | Alerts in this category are unlikely to cause direct impact to organizations but should be paid attention to in aggregation. Common examples are: · 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 | 16 Business Hours |
Â
Business Hours: Mon-Fri, 8 a.m. to 5 p.m. (Eastern Time)
*Response Target – time required to perform initial alert triage and assessment. Response Target is measured as the elapsed time between alert detection and n initial customer response. That response will either be confirmation of an active security incident with proposed next steps (including required customer actions) or confirmation that the incident is a false positive.Â
Advanced Security Management Response Time Policy
- All reported weaknesses, events and incidents must be assessed and results of such documented in the ticketing system by the Information Security Team.
- All Information Security Events (e.g. Alerts, Notifications) will be classified automatically during ingestion of alerts into the ticketing system, and will be analyzed/responded to according to the following table:
Alert Severity | Alert Classification | Initial Response Time |
Critical | Alerts in this category are indications of activity that are generally linked to successful intrusions and are likely to cause big impact to organizations. These alerts. Common examples of Critical priority alerts include: · Information leakage/data retrieval – successful SQL injection that is returning data. · Successful worm propagation. · Problems requiring immediate defense remediation to reduce exposure. · Post-compromise activity – outbound remote shell cmds, attack tool downloads, etc. | 1 Hour |
High | Alerts in this category are indications of attempts to perform malicious activities or confirmed malicious activity that could cause severe impacts to organizations. Even though these may not necessarily indicate a compromise, these alerts need to be responded to very quickly. Common examples of High priority alerts include: · High severity, aggressive, penetration tests · Larger scale/duration brute force attacks · Malware Command Control Activity · Potential Server Compromise – successful SQLi, Webshell activity, etc. | 4 Hours |
Medium | Alerts in this category are indications of attempts to break in the environment. Common examples of Medium priority alerts include: · Brute force or dictionary attacks. · Automated or drive-by malware infection attempts. · More targeted reconnaissance behavior – simple exploit attempts. | 24 Hours |
Low | Alerts in this category are unlikely to cause direct impact to organizations but should be paid attention to in aggregation. Common examples of Low priority alerts include: · 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. | 2 Business Days |
Informational | Alerts in this category are generally not related to malicious activity. Common examples are log review activities that are documented in the form of alerts. | 5 Business Days |
Â
3. The ticket will then be classified as either:
- True positives, actual Information Security Incidents,
- False positives, benign activity or unrelated to Information Security.
4. All alerts that impact customers or WatServ will be classified as Information Security Incidents.
5. Information Security Incidents will have an impact assessment to determine:
a. Endpoints compromised: number and scope, such as clients’, WatServ’s, critical/non-critical etc.
b. Service degradation / impact to clients’ service delivery.
c. Service degradation / impact to WatServ’s Shared Services environments.
d. Accounts compromised: number and scope, such as privileged / non-privileged.
e. Propagation status and extent.
6. Information Security Incidents will be classified, communicated, escalated, and dealt with according to this table:
Security Incident Severity | Definitions | Initial Response | Action Plan Defined |
Security Incident – Severity 1 | Confirmed security incident with severe Endpoints: Several mission-critical* Service degradation: WatServ service delivery completely compromised. Accounts: Several privileged accounts Propagation: Widespread propagation. | 30 minutes | 30 minutes |
Security Incident – Severity 2 | Confirmed security incident with high Endpoints: One or two Service degradation: WatServ service delivery partially compromised. Accounts: One or more privileged Propagation: Confirmed successful | 2 hours | 3 hours |
Security Incident – Severity 3 | Confirmed security incident with Endpoints: Several endpoints Service degradation: Minor disruptions Accounts: One privileged account was Propagation: Confirmed unsuccessful | Next Business Day | 1 Business Day |
Security Incident – Severity 4 | Confirmed security incident with low Endpoints: Limited to one or two Service degradation: Disruptions to WatServ service delivery that do not affect the customer. Accounts: One unprivileged user Propagation: Indicators (unconfirmed) | Next Business Day | 2 Business Days |
Security Incident – Severity 5 | Unconfirmed security event or incident Endpoints: One server or endpoint Service degradation: None. Accounts: One unprivileged user Propagation: No indication of broader | 2 | 3 Business Days |
Â