Incident Response Plan

Purpose and Scope

The purpose of this incident response plan is to provide a framework for Ectaro to respond to security incidents in a timely and effective manner, minimize the impact of incidents on our systems, data, and operations, and protect our clients, employees, and partners from harm. The scope of this plan covers all areas of Ectaro’s operations, including our software development, cloud-based web applications, and related infrastructure.

This plan is designed to outline the procedures and guidelines for detecting, responding to, and recovering from security incidents. The plan includes measures for identification, containment, analysis, and mitigation of the incidents that may affect the confidentiality, integrity, and availability of our data and systems. The goal of this plan is to ensure a coordinated and consistent response to incidents by all members of our incident response team, both internal staff and external resources.

This incident response plan is a living document and will be reviewed and updated regularly to reflect changes in our operations, systems, and technology landscape. It is also subject to testing and revision to ensure its effectiveness in addressing security incidents. The plan will be communicated to all relevant stakeholders, including employees, partners, and clients, and will be incorporated into our overall security policies and procedures.

Incident Response Team

The incident response team is responsible for detecting, responding to, and recovering from security incidents. The team consists of the following members:

Burak Kılınç / CTO / b.kilinc@ectaro.com / +31 6 273 338 61

Seyfullah Sahin / IT Security Manager / s.sahin@ectaro.com /

Emirhan Durusoy / Sr. Software Developer / e.durusoy@ectaro.com

The incident response team will work together to respond to security incidents in a timely and coordinated manner. They will communicate regularly with each other and with stakeholders throughout the incident response process. If necessary, additional team members or external resources may be called upon to assist in the incident response process.

Response plan

1. The person who discovers the incident will contact one of the member of incident response team.
2. The incident response team will log:
   1. The name of the caller.
   1. Time of the call.
   1. Contact information about the caller.
   1. The nature of the incident.
   1. What equipment or persons were involved?
   1. Location of equipment or persons involved.
   1. How the incident was detected.
   1. When the event was first noticed that supported the idea that the incident occurred.
3. Contacted members of the response team will meet or discuss the situation over the telephone and determine a response strategy.
   1. Is the incident real or perceived?
   1. Is the incident still in progress?
   1. What data or property is threatened and how critical is it?
   1. What is the impact on the business should the attack succeed? Minimal, serious, or critical?
   1. What system or systems are targeted, where are they located physically and on the network?
   1. Is the incident inside the trusted network?
   1. Is the response urgent?
   1. Can the incident be quickly contained?
   1. Will the response alert the attacker and do we care?
   1. What type of incident is this? Example: 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.
   1. Category two – A threat to sensitive data
   1. Category three – A threat to computer systems
   1. 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
   1. Virus response procedure
   1. System failure procedure
   1. Active intrusion response procedure – Is critical data at risk?
   1. Inactive Intrusion response procedure
   1. System abuse procedure
   1. Property theft response procedure
   1. Website denial of service response procedure
   1. Database or file denial of service response procedure
   1. Spyware response procedure.

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, and the authorized personnel may vary by situation and the organization.

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

8. Upon management approval, the changes will be implemented.

9. Team members will restore the affected system(s) to the uninfected state. They may do any or more of the following:

• Re-install the affected system(s) from scratch and restore data from backups if necessary. Preserve evidence before doing this.Make users change passwords if passwords may have been sniffed.Be sure the system has been hardened by turning off or uninstalling unused services.Be sure the system is fully patched.Be sure real time virus protection and intrusion detection is running.

10. Documentation—the following shall be documented:

• How the incident was discovered.The category of the incident.How the incident occurred, whether through email, firewall, etc.Where the attack came from, such as IP addresses and other related information about the attacker.What the response plan was.What was done in response?

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.

Notifying Amazon—If any data breaches involving data obtained from Amazon APIs, one of the incident response team member will contact with Amazon via e-mail 3p-security@amazon.com in 24 hours.

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.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.Was the incident response appropriate? How could it be improved?Was every appropriate party informed in a timely manner?Were the incident-response procedures detailed and did they cover the entire situation? How can they be improved?Have changes been made to prevent a re-infection? Have all systems been patched, systems locked down, passwords changed, anti-virus updated, email policies set, etc.?Have changes been made to prevent a new and similar infection?Should any security policies be updated?