Security Incident Response

The ErgoPlus Security Team provides 24x7x365 coverage to respond quickly to all security and privacy events. In responding to any incident, we first determine the exposure of the information and determine the source of the security problem, if possible.

Our Security Team reviews all security-related incidents, either suspected or proven, and we coordinate with affected customers using the most appropriate means, depending on the nature of the incident.

The following is our detailed incident response plan:

1. If the person discovering the incident is not a member of the Security Team, they will contact the Security Team using the #security channel in the company communications application (Slack), emailing security@ergo-plus.com, or using the company contact list to reach a Security Team member by phone. The following are possible sources who may discover an incident, and have been provided with the appropriate contact information and procedures to follow.

1. Customer support representatives
2. Sales representatives
3. ErgoPlus Injury Prevention Specialists
4. Leadership team
5. IT staff

2. The Security Team member who receives the communication (or discovered the incident) will refer to their contact list for both management personnel to be contacted and incident response members to be contacted. The ErgoPlus Security team member will contact those designated on the list. The ErgoPlus Security team member will contact the incident response manager using email, phone, and Slack messages while being sure other appropriate and backup personnel and designated managers are contacted. The ErgoPlus Security team member will log the following information:

1. The name of the person who discovered the incident.
2. Time of the report.
3. Contact information of the person who discovered the incident.
4. The nature of the incident
5. What systems or persons were involved?
6. How the incident was detected.
7. When the event was first noticed that supported the idea that the incident occurred.
8. Is the system affected business critical?
9. What is the severity of the potential impact?
10. Any information about the origin of the attack.

3. Contacted members of the response team will meet and determine a response strategy.

1. Is the incident real or perceived?
2. Is the incident still in progress?
3. What data or property is threatened and how critical is it?
4. What is the impact on the business should the attack succeed? Minimal, serious, or critical?
5. What system or systems are targeted?
6. Is the response urgent?
7. Can the incident be quickly contained?
8. Will the response alert the attacker and do we care?
9. What type of incident is this, eg virus, worm, intrusion, abuse, damage?

4. An incident ticket will be created. The incident will be categorized into the highest applicable level of one of the following categories:

1. Category one – A threat to public safety or life.
2. Category two – A threat to sensitive data
3. Category three – A threat to computer systems
4. Category four – A disruption of services

5. Team members will establish and follow one of the following procedures basing their response on the incident assessment:

1. Worm response procedure
2. Virus response procedure
3. System failure procedure
4. Active intrusion response procedure – Is critical data at risk?
5. Inactive Intrusion response procedure
6. System abuse procedure
7. Property theft response procedure
8. Website denial of service response procedure
9. Database or file denial of service response procedure
10. Spyware response procedure.
11. The team may create additional procedures which are not foreseen in this document. If there is no applicable procedure in place, the team must document what was done and later establish a procedure for the incident.

6. Team members will use forensic techniques, including reviewing system logs, looking for gaps in logs, reviewing intrusion detection logs, and interviewing witnesses and the incident victim to determine how the incident was caused. Only authorized personnel should be performing interviews or examining evidence.

7. Team members will restore the affected system(s) to the uninfected state.

8. Team members will recommend changes to prevent the occurrence from happening again or infecting other systems.

9. Upon management approval, the changes will be implemented

10. Documentation: the following shall be documented:

1. How the incident was discovered.
2. The category of the incident.
3. How the incident occurred, whether through email, firewall, etc.
4. Where the attack came from, such as IP addresses and other related information about the attacker.
5. What the response plan was.
6. What was done in response?
7. Whether the response was effective.

11. Evidence Preservation: make copies of logs, email, and other communication. Keep lists of witnesses. Keep evidence as long as necessary to complete prosecution and beyond in case of an appeal.

12. Notify proper external agencies: notify the police and other appropriate agencies if prosecution of the intruder is possible.

13. Assess damage and cost: assess the damage to the organization and estimate both the damage cost and the cost of the containment efforts.

14. Review response and update policies: plan and take preventative steps so the intrusion can’t happen again.

1. Consider whether an additional policy could have prevented the intrusion.
2. Consider whether a procedure or policy was not followed which allowed the intrusion, and then consider what could be changed to ensure that the procedure or policy is followed in the future.
3. Was the incident response appropriate? How could it be improved?
4. Was every appropriate party informed in a timely manner?
5. Were the incident-response procedures detailed and did they cover the entire situation? How can they be improved?
6. Have changes been made to prevent a re-infection? Have all systems been patched, systems locked down, passwords changed, antivirus updated, email policies set, etc.?
7. Have changes been made to prevent a new and similar incident?
8. Should any security policies be updated?
9. What lessons have been learned from this experience?