Feature Request Security Incident Tab for ServiceDesk Plus (Both On-Demand and On Premise versions)
We are having to log more incidents and do investigations for Security Incidents. This can be anything from a Breach, Malware or Virus. Which can also come from internal (USB, CD, etc..) or external such as an email. Each incident needs to have a log and a timeline that can be assessed. A report has to be done and lessons learned also. What I am proposing is a way for users to report in a normal fasion to the ServiceDesk as a request then we as the Technicians can turn that request into a Security Incident which would allow for a Unique number to be assigned to the Incident that is different than the Request number. Here is what I am thinking needs to be added to make this work effectively:
Identify Security Risk
1. User Name
2. Asset Information (Asset(s) that this is happening on)
3. Date of Incident (This may need to be back dated if the user did not report immediately. And a mandatory note should be added to justify the change)
4. Unique Security Incident Number. I would start with the identification of SI or SIN for Security Incident Number.
5. Mode Reported
6. Check boxes for different types of incidents. (E-mail, Shared Drive, USB, CD, etc...)
7. Tasks involved for the process.
8. Initial Analysis Start Date/Time.
9. Drop downs that can be created for each organization uniquely that also have the ability to add a new row as the analysis is done.
Analysis 1 Interview user for details Notes + or delete
Analysis 2 Did a Breach occur? Notes + or delete
Analysis 3 Was information Disclosed? Notes + or delete
Analysis 4 Create repository for Evidence Notes + or delete
10. A field to contact the appropriate people (internal) that an incident is in progress
11. A field to contact the appropriate people (external) that an incident is in progress
12. Drop downs that can be created for each organization uniquely that also have the ability to add a new row as the analysis is done. This can be URLs that need to be used or Logs that need to be pulled etc...
Analysis 1 Antivirus Scan Notes + or delete
Analysis 2 https://www.virustotal.com/ Notes + or delete
Analysis 3 https://www.fortiguard.com/ Notes + or delete
Analysis 4 https://www.hybrid-analysis.com/ Notes + or delete
Analysis 5 SIEM Logs Notes + or delete
Containment Area
This area should allow for what is being done to contain the security risk
1. Do we need to block Emails, URLs or take other appropriate mitigation steps to protect the environment?
2. Short term containment - This should forcus on limiting damage as soon as possible. i.e. unplugging the network line from the computer, turning off wireless connections, etc...
3. Long term containment -
3a. Re-install or rebuild the affected device.
3b. Apply security patches
3c. Restore any data and configuration information to the device.
3d. Take steps to ensure the device and other affected devices are “clean.”
Recovery
1. Time to recover from the incident.
2. Tests completed to ensure that the systems are clean and fully functional. (This could be running AV, Windows updates on the system to doing other appropriate tasks to insure the system is clean).
3. Duration of continued monitoring needed to observe for abnormal behavior. This would be the time alloted to monitor the recovery of the system.
4. Was the Hard Drive replaced? If so, when can the Hard Drive be placed back into production?
Lessons Learned
1. Identify changes in policy or security controls to prevent similar events from occurring in the future.
2.Create “Action Items” for any process improvement tasks identified.
3. Report back to management/stake holders and the response team.
Include:
- When the problem was first detected and by whom
- The scope of the incident
- How it was contained and eradicated.
- Work performed during recovery.
- Areas where the response team was effective.
- Areas that need improvement
Closure of Security Incident
1. Create an incident response report. Summarize details of the incident.
1a. Timeline of events.
1b. Executive Summary of details.
1c. Evidence collected
1d. Where evidence was stored
1e. Training needed
2. Security Incident should not be closed till all the Action Items from Lessons learned have been completed.
To make the process more simple I would recommend doing this like the Change process where you start with one tab then once the items are complete then move onto the next section.
Dennis Seyersdahl
Identify Security Risk
1. User Name
2. Asset Information (Asset(s) that this is happening on)
3. Date of Incident (This may need to be back dated if the user did not report immediately. And a mandatory note should be added to justify the change)
4. Unique Security Incident Number. I would start with the identification of SI or SIN for Security Incident Number.
5. Mode Reported
6. Check boxes for different types of incidents. (E-mail, Shared Drive, USB, CD, etc...)
7. Tasks involved for the process.
8. Initial Analysis Start Date/Time.
9. Drop downs that can be created for each organization uniquely that also have the ability to add a new row as the analysis is done.
Analysis 1 Interview user for details Notes + or delete
Analysis 2 Did a Breach occur? Notes + or delete
Analysis 3 Was information Disclosed? Notes + or delete
Analysis 4 Create repository for Evidence Notes + or delete
10. A field to contact the appropriate people (internal) that an incident is in progress
11. A field to contact the appropriate people (external) that an incident is in progress
12. Drop downs that can be created for each organization uniquely that also have the ability to add a new row as the analysis is done. This can be URLs that need to be used or Logs that need to be pulled etc...
Analysis 1 Antivirus Scan Notes + or delete
Analysis 2 https://www.virustotal.com/ Notes + or delete
Analysis 3 https://www.fortiguard.com/ Notes + or delete
Analysis 4 https://www.hybrid-analysis.com/ Notes + or delete
Analysis 5 SIEM Logs Notes + or delete
Containment Area
This area should allow for what is being done to contain the security risk
1. Do we need to block Emails, URLs or take other appropriate mitigation steps to protect the environment?
2. Short term containment - This should forcus on limiting damage as soon as possible. i.e. unplugging the network line from the computer, turning off wireless connections, etc...
3. Long term containment -
3a. Re-install or rebuild the affected device.
3b. Apply security patches
3c. Restore any data and configuration information to the device.
3d. Take steps to ensure the device and other affected devices are “clean.”
Recovery
1. Time to recover from the incident.
2. Tests completed to ensure that the systems are clean and fully functional. (This could be running AV, Windows updates on the system to doing other appropriate tasks to insure the system is clean).
3. Duration of continued monitoring needed to observe for abnormal behavior. This would be the time alloted to monitor the recovery of the system.
4. Was the Hard Drive replaced? If so, when can the Hard Drive be placed back into production?
Lessons Learned
1. Identify changes in policy or security controls to prevent similar events from occurring in the future.
2.Create “Action Items” for any process improvement tasks identified.
3. Report back to management/stake holders and the response team.
Include:
- When the problem was first detected and by whom
- The scope of the incident
- How it was contained and eradicated.
- Work performed during recovery.
- Areas where the response team was effective.
- Areas that need improvement
Closure of Security Incident
1. Create an incident response report. Summarize details of the incident.
1a. Timeline of events.
1b. Executive Summary of details.
1c. Evidence collected
1d. Where evidence was stored
1e. Training needed
2. Security Incident should not be closed till all the Action Items from Lessons learned have been completed.
To make the process more simple I would recommend doing this like the Change process where you start with one tab then once the items are complete then move onto the next section.
Dennis Seyersdahl