Incident Management Policy

1. Purpose

The purpose of Incident Management within LEADx’s hosted platform is to properly handle security incidents and security incident management.

2. Scope

The scope is limited to LEADx’s hosted platform’s customer-facing infrastructure and includes:

• Preparation
• Implementation
• Reporting
• Detection and Analysis
• Communication
• Containment and Lockdown
• Eradication
• Recovery
• Review

3. Policy

Preparation

• Pre-emptive activities include and are not limited to:
• Processes that delineate between the various incident types, their severity, and potential impacts.
• Processes for when customer calls are handled via Customer Success.
• Processes directing customer incidents are forwarded to DevOps.
• Processes directing how incidents are handled by DevOps and logged in the company documentation repository.
• Security incidents, potential breaches, and management are funneled to DevOps for analysis & investigation.
• Monthly vulnerability assessments are conducted, assessed and the appropriate actions taken against LEADx’s hosted platform.

Implementation

All departments that maintain or handle Confidential Information – either Customer Information or Internal LEADx Confidential Information including LEADx’s Intellectual Property, have implemented the following processes:

• All employees are to immediately notify their supervisor, the Manager of DevOps and the CISO of any actual or suspected incident and/or security breach.
• Employees, including all full time, temporary, or contract are included in policies that enforce:
  • Using unique combination passwords.
  • Quarterly password changes.
  • Instructed to never share passwords with others.
  • Encrypting information when it is transmitted electronically.
  • Referring calls or other requests for personal information to management.

Reporting

If a data breach has occurred or is suspected employees are instructed to notify their supervisor, the Manager of DevOps and CTO.  In the event, neither the Manager of DevOps or CTO are reachable the CEO is to be immediately notified.

Detection and Analysis

Security events that will be monitored include:

• Anomalous network events (including login attempts, privilege escalation, port scans, and more)
• Anomalous files on disk
• Anomalous changes in program binaries

Mechanisms in place include:

• Automated detection tools.
• Regular Log Reviews.
• Security awareness training of staff.
• Risk assessment in accordance with LEADx’s Policies.

Suspected security incidents have unique tickets created in LEADx’s ticketing system and are analyzed to verify/validate that a security incident has occurred, is occurring, or will occur.  Ticket ownership remains in the DevOps team and includes classification, location, and likelihood.

Communication

The Incident Commander is responsible for internal communications.  External customer communication is the responsibility of the Director of Customer Service.

Containment and Lockdown

Once a security incident has been validated, DevOps is responsible for coordinating the containment of the incident using whatever means is necessary to limit and contain customer impact.

Eradication

Once a security incident has been contained, eradication is necessary to eliminate components of the incident, such as removing malicious code or disabling compromised user accounts.  Changes to the environment follow the urgent change control process.

Recovery

Recovery involves restoring information as closely as possible back to the point just before the incident occurred.  Adjusting monitoring and reviewed/adjusted security measures.

Review and Damage Assessment

The DevOps team and all involved will meet and review what went well, and what can be improved in the handling of the security incident.

Questions to be addressed during the meeting will include:

• The current status of the incident.
• A summary of the incident.
• Actions taken by all incident handlers on this incident.
• Contact information for other involved parties.
• A list of evidence gathered during the incident investigation.
• Comments from incident handlers.
• Exactly what happened, and at what times.
• How well did the DevOps team and management perform in dealing with the incident.
• Were the documented procedures followed and were they adequate.
• What information was needed sooner?
• Were any steps or actions taken that might have inhibited the recovery.
• What would the staff and management do differently the next time a similar incident occurs?
• What corrective actions can prevent similar incidents in the future?
• What additional tools or resources are needed to detect, analyze, and mitigate future incidents?