INCIDENT RESPONSE STRATEGY/PLAN
Our company (eVanik Networks Pvt Limited) is following the best methodology of Incident Response Plan. It includes the following basic methods to overcome with any incident occurred in our systems.
INCIDENT RESPONSE ROLE AND RESPONSIBILITIES
An incident is no time to have multiple people doing duplicate work. It’s also a terrible time to have important tasks ignored, all because everyone thought somebody else was working on it. Incidents are made worse when incident response team members can’t communicate, can’t cooperate, and don’t know what each other is working on. Work gets repeated, work gets ignored, customers and the business suffer.
That’s why effective incident response teams designate clear roles and responsibilities. Team members know what the different roles are, what they’re responsible for, and who is in which role during an incident.
Here are a few of the most common incident management roles that we have been using as keys to our own incident response strategy.
Role: Incident manager
Primary responsibility: The incident manager has the overall responsibility and authority during the incident. They coordinate and direct all facets of the incident response effort.
Secondary responsibilities: Everything someone else isn’t assigned to.
Role: Tech lead
Primary responsibility: The tech lead is typically a senior technical responder. They are responsible for developing theories about what’s broken and why, deciding on changes, and running the technical team during the incident. This role works closely with the incident manager.
Secondary responsibilities: Communicate updates to incident manager and other team members, document key theories and actions taken during the incident for later analysis, participate in incident postmortem, page additional responders and subject matter experts.
Role: Communications manager
Primary responsibility: The communications manager is the person familiar with public communications, possibly from the customer support or public relations teams. This position is responsible for writing and sending internal and external communication about the incident. This is usually also the person who updates the status page.
Secondary responsibilities: Collect customer responses, interface with executives and other high-level stakeholders.
Role: Subject matter expert
Primary responsibility: A technical responder familiar with the system or service experiencing an incident. Often responsible for suggesting and implementing fixes.
Secondary responsibilities: Providing context and updates to the incident team, paging additional subject matter experts.
COMMON SECURITY INCIDENT TYPES
There are many types of cyber security incidents that could result in intrusions on an organization’s network.
We have been responsive the following most common incident types.
- Unauthorized attempts to access systems or data
- Privilege escalation attack
- Insider threat
- Phishing attack
- Malware attack
- Denial-of-service (DoS) attack
- Man-in-the-middle (MitM) attack
- Password attack
- Web application attack
- Advanced persistent threat (APT)
INCIDENT RESPONSE AND ESCALATION PATH PROCEDURE
- Pre-assessments
At this stage, I review and dig-out the underlying security policy that invokes my incident response plan. Perform a risk assessment and prioritize security issues. Identify the most sensitive assets, and by extension, which are the critical security incidents my team will focus on. Create a communication plan, and prepare documentation that clearly, and briefly, states the roles, responsibilities and processes. At last but not least I ensure that my team has access to all relevant systems, and the tools and technologies they need to identify incidents and respond to them.
- Identification
My team effectively detect deviations from normal operations in organizational systems and identify if those deviations represent actual security incidents.
When a potential incident is discovered, the team immediately collect additional evidence, decide on the type and severity of the incident, and document everything they are doing.
- Containment
Once the team identifies a security incident, their immediate goal is to contain the incident and prevent further damage from occurring. This involves:
Short term containment—this can be as simple as isolating a network segment which is under attack or taking down production servers which have been hacked and are diverting traffic to backup servers.
Long term containment—applying temporary fixes to affected systems to allow them to be used in production, while rebuilding clean systems, preparing to bring them online in the recovery stage.
- Eradication
The team identify the root cause of the attack, removal of malware or threats, and preventing similar attacks in the future. For example, if an authentication mechanism was the entry point for the attack, it is replaced with strong authentication; if a vulnerability was exploited, it should be immediately patched. - Recovery
The team brings affected production systems back online carefully, to ensure another incident doesn’t take place. Important decisions at this stage are from which time and date to restore operations, how to test and verify that affected systems are back to normal, and how long to monitor the systems to ensure activity is back to normal. - Lessons Learned
At last stage the team complete documentation that could not be prepared during the response process and investigate the incident further to identify its full scope, how it was contained and eradicated, what was done to recover the attacked systems, areas where the response team was effective, and areas that require improvement. - Intimation to Amazon
- Eradication
I will inform Amazon via email to 3p-security@amazon.com within 24 hours of detecting any Security Incidents.
- Data Secrecy
I will not notify any regulatory authority, nor any customer, on behalf of Amazon unless Amazon specifically requests in writing that the Developer do so.
