This document provides you a structured process and sample procedures to use when responding to intrusions on our Magento eCommerce stores. Many parts of it has been lifted liberally from the MSDN documentation on Incident Response and adapted to needs of eCommerce systems.
-
Create an Incident Response Team (IRT) to deal with security incidents for each aspect of the eCommerce solution defined in the table below. This may be a small team with some roles overlapped within your company. You can use the table below as a starting point.
-
Routinely monitor and analyze network traffic and system performance.
-
Routinely check all logs and logging mechanisms, including operating system event logs, application specific logs and intrusion detection system logs.
-
Verify your back-up and restore procedures. You should be aware of where backups are maintained, who can access them, and your procedures for data restoration and system recovery. Make sure that you regularly verify backups and media by selectively restoring data.
INCIDENT RESPONSE TEAM
| Role | Name | Phone | IM | Escalation Ladder | Notes | |
|---|---|---|---|---|---|---|
| Incident Leader | ||||||
| Management/Stakeholder | ||||||
| IT Contact | ||||||
| Communications | ||||||
| Legal Representative | ||||||
| National/Local Law Enforcement | ||||||
| Hosting SLA contact | ||||||
| Magento EE SLA contact | ||||||
| 3rd Party SaaS SLA contact |
| Role | Role Description |
|---|---|
| Incident Lead | In the event of an incident, you should designate one individual responsible for coordinating the response. The Incident Lead has ownership of the particular incident or set of related security incidents. All communication about the event is coordinated through the Incident Lead, and when speaking with those outside the IRT, he or she represents the entire IRT. The Incident Lead might vary depending on the nature of the incident, so feel free to have multiple versions of this document for each logical technical unit of your eCommerce system. |
| IT Contact | This member is primarily responsible for coordinating communication between the Incident Lead and the rest of the IT group. The IT Contact might not have the particular technical expertise to respond to the particular incident; however, he or she will be primarily responsible for finding people in the IT group to handle particular security events. In smaller teams this may be the same person as the Incident Lead. |
| Legal Representative | This member is a lawyer who is very familiar with established incident response policies. The Legal Representative determines how to proceed during an incident with minimal legal liability and maximum ability to prosecute offenders. Before an incident occurs, the Legal Representative should have input on monitoring and response policies to ensure that the organization is not being put at legal risk during a cleanup or containment operation. It is very important to consider the legal implications of shutting down a system and potentially violating service level agreements or membership agreements with your customers, or not shutting down a comprised system and being liable for damages caused by attacks launched from that system. Any communication to outside law enforcement or external investigative agencies should also be coordinated with the Legal Representative. |
| Communication/ Public Relations Officer | Generally, this member is part of the public relations department and is responsible for protecting and promoting the image of the organization. This individual might not be the actual face to the media and customers, but he or she is responsible for crafting the message (the content and objective of the message is generally the responsibility of management). All media inquiries should be directed to Public Relations. |
| Management/Stakeholders | Depending on the particular incident, you might involve only departmental managers, or you might involve managers across the entire organization. The appropriate management individual will vary according to the impact, location, severity, and type of incident. If you have a managerial point of contact, you can quickly identify the most appropriate individual for the specific circumstances. Management is responsible for approving and directing security policy. Management is also responsible for determining the total impact (both financial and otherwise) of the incident on the organization. Management directs the Communications Officer regarding which information should be disclosed to the media and determines the level of interaction between the Legal Representative and law enforcement agencies. |
| External resourses | Include in the table above a list of all the contact information for all the services that are critical to your Magento eCommerce store. If you have an EE Licence, include all the information required to get into with Magento Support or ECG here. Add rows for your hosting provider support line, internal contacts and also even terms of service. The goal here is that anything internal or external that affects the operation of your Magento eCommerce store should have a contact here. |
Responding to an Incident
The following table shows the responsibilities of these individuals during the incident response process.
| Activity | Incident Lead | IT Contact | Legal Representative | Communications Officer | Management |
|---|---|---|---|---|---|
| Initial Assessment | Owner | Advises | None | None | None |
| Initial Response | Owner | Implements | Updates | Updates | Updates |
| Collects Forensic Evidence | Implements | Advises | Owner | None | None |
| Implements Temporary Fix | Owner | Implements | Updates | Updates | Advises |
| Sends Communication | Advises | Advises | Advises | Implements | Owner |
| Check with Local Law Enforcement | Updates | Updates | Implements | Updates | Owner |
| Implements Permanent Fix | Owner | Implements | Updates | Updates | Updates |
| Determines Financial Impact on Business | Updates | Updates | Advises | Updates | Owner |
| Review the response and update the plan | Implements | Advises | Advises | Advises | Advises |
These steps should be conducted during an incident response. They are not numbered since they're not exclusively sequential. Rather, they happen throughout the incident. For example, documentation starts at the very beginning and continues throughout the entire life cycle of the incident; communication also happens throughout the entire incident. An overzealous response could even cause more damage than the initial attack. By working these steps alongside each other, you will get the best compromise between swift and effective action.
-
You should confirm whether you are dealing with an actual incident or a false positive.
-
Gain a general idea of the type and severity of attack. You should gather at least enough information to begin communicating it for further research and to begin containing the damage and minimizing the risk.
-
IMPORTANT: Record your actions thoroughly. These records will later be used for documenting the incident (whether actual or false).
Note: You should avoid false positives whenever possible; however, it is always better to act on a false positive than fail to act on a genuine incident. Your initial assessment should, therefore, be as brief as possible, yet still eliminate obvious false positives.
Be aware that damage can come in many forms, and that a headline in the popular sites exaggerating a security breach can be much more destructive than an actual intrusions. For this reason, and to prevent an attacker from being tipped off, only those playing a role in the incident response should be informed until the incident is properly controlled. Based on the unique situation, your team will later determine who needs to be informed of the incident. This could be anyone from specific individuals up to the entire company and external customers. Communication externally should be coordinated with the Legal Representative.
-
Protect classified and sensitive data. As part of your planning for incident response, you should already have a clear definition of which data is classified and which is sensitive. This will enable you to prioritize your responses in protecting all customer card data, and identifiable customer information. With Magento this is mostly stored in the MySQL database but also be aware of the possibility of Varnish, Apache or PHP logs being dumped to disk.
-
Minimize disruption of computing resources (including processes). Although uptime is very important in most Magento stores, keeping them up during an attack might result in greater problems later on. Compare the cost of taking the compromised and related systems offline against the risk of continuing operations. In the vast majority of cases, you should immediately take the system off the network. However, you might have service agreements in place that require keeping systems available even with the possibility of further damage occurring. Under these circumstances, you can choose to keep a system online with limited connectivity in order to gather additional evidence during an ongoing attack.
-
Determine the intent of the attack. Was the attack specifically directed at your store or was it random?
-
Identify the systems that have been compromised, only App servers? Was the database compromised?
- In some cases, the benefit of preserving data might not equal the cost of delaying the response and recovery of the system. The costs and benefits of preserving data should be compared to those of faster recovery for each event.
- For extremely large stores, comprehensive backups of all compromised systems and databases might not be feasible. Instead, you should back up all logs and selected, breached portions of the system.
- For higher profile companies and incidents, the media might be involved. Media attention to a security incident is rarely desirable, but it is often unavoidable. Media attention can enable your organization to take a proactive stance in communicating the incident. At a minimum, the incident response procedures should clearly define the individuals authorized to speak to media representatives.
- You should not attempt to deny to the media that an incident has occurred, because doing so is likely to damage your reputation more than proactive admission and visible responses ever will. This does not mean that you need to notify the media for each and every incident regardless of its nature or severity. You should assess the appropriate media response on a case-by-case basis.
- The CSIRT should thoroughly document all processes when dealing with any incident. This should include a description of the breach and details of each action taken (who took the action, when they took it, and the reasoning behind it). All people involved with access must be noted throughout the response process.
- Afterward, the documentation should be chronologically organized, checked for completeness, and signed and reviewed with management and legal representatives. You will also need to safeguard the evidence collected in the protect evidence phase. You should consider having two people present during all phases who can sign off on each step. This will help reduce the likelihood of evidence being inadmissible and the possibility of evidence being modified afterward.
- Remember that the offender might be an employee, contractor, temporary employee, or other insider within your organization. Without thorough, detailed documentation, identifying an inside offender will be very difficult. Proper documentation also gives you the best chance of prosecuting offenders.
After you have completed this document for your team, it is highly advised that you undergo drills to see how your team uses it and responds to issues. This way you can identify shortcomings or extra information you can add to it. It is very important that you thoroughly test your incident response process before an incident occurs. Without thorough testing, you cannot be confident that the measures that you have in place will be effective in responding to incidents.
For more information about creating an incidence response plan, see the following:
- Handbook for Computer Security Incident Response Teams
- Incident Response: Investigating Computer Crime by Chris Prosise and Kevin Mandia (McGraw-Hill Professional Publishing, ISBN: 00723829).