Compliance - Incident Report Policy & Template
Incident overview
Postmortem owner | |
---|---|
Incident | |
Related incidents | |
Priority | status:P1 / status:P2 / status:P3+ |
Affected services | |
Incident date | |
Incident duration | |
Incident response teams | |
Incident responders |
Executive summary
Incident Evidence
. Application - cloudwatch
. Infarstructure - cloudtrail
. Network - WAF
Policy
The XStak pay team is responsible for responding to reports of incidents, compromises, and breaches computers, data, and network resources. The purpose of the Incident Response Plan is to establish procedures in accordance with applicable legal and regulatory requirements to address instances of unauthorized access.
The Incident Response Plan defines the policy, roles and responsibilities for the involved personnel when reacting to an information security threat. The primary emphasis of activities described within this plan is the return to a secure state as quickly as possible, while minimizing the adverse impact. Depending on the circumstances, the Information Technology Administrator (IT Administrator) may decide to modify or bypass one or more of the procedures outlined in this plan in response to a particular security incident, with the understanding that the IT Administrator will take all reasonable steps to investigate and resolve any security issues. The capture and preservation of incident relevant data (e.g., network flows, data on drives, access logs, etc.) is performed primarily for the purpose of problem determination and resolution, as well as classification of the incident. The team shall provide timely and appropriate notice to affected individuals and departments when there has been a security incident, a compromise, or a breach involving data, computers, or networks. The IT Administrator, Finance Department Director, and Administrator shall be responsible for reviewing breaches to determine whether notification is required, and directing responsible departments in complying with the notification obligation. All known or suspected security incidents must be reported to the IT Administrator.
Security Incident
Security Incident - A vulnerability which may compromise the security of resources has been discovered and is underway. Generally, this means a weakness in intrusion prevention has been found, an attempted exploit has taken place, or reconnaissance by a hacker has been thwarted. Examples include systematic unsuccessful attempts to gain entry, a PC or workstation infected with a virus, worm, Trojan, botnet, or other malware that has been discovered and removed.
Security Compromise – An escalation of a security incident where the attacker has gained control of a account, system, or device, and is leveraging that position to control and utilize compromised resources for the purpose of unauthorized acquisitions. At this point, it has been determined that data has not been compromised or stolen.
Security Breach – A confirmed, unauthorized acquisition, modification or destruction of private data has taken place. At this point, a breach has been forensically determined and evidence supports that data was compromised.
Private data - Data about individuals that is classified by law as private or confidential and is maintained in electronic format or medium. “Private data” means data classified as not public and available to the subject of the data, and "confidential data" means data classified as not public but not available to the subject of the data.
Unauthorized acquisition - For the purposes of this plan, this means that a person has obtained data without statutory authority or the consent of the individual who is the subject of the data, and with the intent to use the data for non-city purposes
Systematic unsuccessful attempts - continual probes, scans, or login attempts where the perpetrators obvious intent is to discover a vulnerability and inappropriately access and compromise that device.
Postmortem report
Instructions | Report |
---|---|
Leadup
| |
Fault
|
|
Impact
|
|
Detection
|
|
Response
|
|
Recovery
|
|
Five whys root cause identification
|
|
Related records
|
|
Lessons learned
|
|
Incident timeline
Follow-up tasks
Issue | Owner | Action items | Documentation |
---|---|---|---|
| |||
|
|
|
|
|
|
|
|