MegaplanIT Blog's & Informational Resources

Whether you’re looking to secure your business or stay PCI compliant, MegaplanIT has a certified team of experts that can help you every step of the way. Stay informed with up-to-date blog.

Incident Response – What does an Incident Response Plan look like? Pt3

MegaplanIT
Posted by MegaplanIT on 8/5/21 9:39 AM

Written By: 

Caleb Coggins: Director of Compliance Services LinkedIn_logo_initials 

Mark Repka: Security Consultant LinkedIn_logo_initials 

Michele Adelaar: Security Consultant LinkedIn_logo_initials


Part 3 Graphic

Incident Response is an essential cybersecurity component. It builds on an iterative foundation of preparation, detection, containment, eradication, and post-incident activity. An Incident Response Plan (IR Plan), policies, and procedures should be in place prior to responding to an incident. Organizations activate Incident Response Plans (IR Plans) and procedures in response to a variety of attacks ranging from malware outbreaks to data breaches and distributed internet-based attacks. The type of incident can vary in classification based on criteria such as severity and impact which in turn drive response time, resource allocations, and level of escalation. For those subject to PCI DSS compliance, for example, an IR function must be activated in response to specific situations such as the identification of one or more rogue wireless access points. Regardless of an incident’s magnitude or specific characteristics, the phased approach of the incident response process provides a consistent way for teams to manage incidents.

 

Preparation Phase

The preparation phase assembles the elements, information, and personnel necessary to execute an appropriate response to an incident. An often overlooked starting point is the effort to reduce the quantity and severity or impact of incidents. This is accomplished through controls implementation, based on your organization’s internal controls and risk management activities. As we mentioned in a previous blog, leveraging a documented risk assessment can provide insight into what residual risks remain after applying specific mitigations or other forms of risk treatment.

  • Have we put measures in place to reduce the number, severity, and impact of incidents?
  • Do we have sufficient documentation, communication channels, and leadership involvement?
  • Do we have the right tools and resources in place to respond to an incident?
  • Have we conducted sufficient security awareness and IR-specific training, prior to tasking individuals with IR responsibilities?

 

Detection & Analysis Phase

The second phase of the IR process involves identifying that an incident has occurred. Specific systems and tools may generate alerts via email or dashboards that require further triage and analysis. During this phase, responders begin to determine the extent of an incident and the impact on the organization. The extent may be limited to a specific system, application, or network zone. An attacker may have succeeded in compromising a service that may lead to an enterprise-wide compromise. Detailed investigation activities and procedures may determine if a reported security event is a valid incident or false positive. Given the volume of security event data and the importance of timely response to an actual incident, organizations increasingly rely on automation and context-based functionality to triage and validate suspicious event data. Analyzing the “what” and “where” characteristics of the incident will assist with incident classification and set the stage for the subsequent IR process phase.

  • Is the IR team well-versed in common or known attack vectors that apply to the organization?
  • Are procedures in place and understood, so that responders can respond to general and specific incidents, regardless of the type of attack vector?
  • Are the incident classification and escalation procedures clearly understood, to avoid delays in prioritization or resource allocation?
  • Are tools and operational systems in place, to collect security event data and alert on potential security events or incidents (centralized logging solutions, security programs)?
  •  Are our forensic tools and resources available to preserve digital forensics evidence, based on internal or external requirements?
  • Are personnel monitoring publicly available sources for newly identified vulnerabilities or exploits? Any additional vendor security feeds or internal methods?
  • Are personnel trained on how to report a potential security incident through available methods (email, phone call, web portal)? Does the organization provide a means for reporting by third parties?
  • Is the organization leveraging Security Orchestration, Automation and Response (SOAR) and the MITRE ATT&CK Framework to build increased automation and efficiency to the IR process? To learn more about SOAR capabilities, visit our blog or watch the following demonstration.

 

Containment, Eradication & Recovery Phase

The third phase of the incident response plan is defined in three parts which coalesce into a group of steps intended to limit damage, address threats and vulnerabilities, and restore systems and services to normal operations. Due to the variety of incidents and attack vectors, containment procedures can be very different for particular incidents. Self-propagating malware originating from third-party systems may involve isolating specific networks and systems, while systems actively targeted due to a software vulnerability might be disabled or modified at a service or configuration level.

  • Do we have sufficient evidence to establish a perimeter for containment?
  • Have we identified the relevant attack sources and targets?
  • Who has the authority to make decisions on containment actions?
  • Do we have documented containment procedures for known attack vectors?
  • What automated or manual methods are currently in place to implement and enforce containment?

 

Eradication

The eradication sub-phase can include a range of elements from systems and services, to user accounts and specific malware programs. Identifying and eliminating the target elements may require a coordinated effort with multiple technical teams and resources, in addition to the core members of the IR team. Eradication steps vary based on the specific incident’s characteristics. Procedures may entail the removal of identified malware or disable compromised accounts.

  • Have we successfully identified or confirmed all affected elements (systems, accounts, services, files, personnel, etc.)?
  • Do we need to collect any additional digital forensics evidence prior to eliminating the identified threats?
  • What methods do we have to confirm successful eradication?

 

Recovery

After eradication, it is time to recover. Steps include restoring systems and services to normal operations. As it relates to identified vulnerabilities, systems may be remediated (software patch installations, configuration changes). Depending on the remediation requirements, the recovery phase can occur over a prolonged period of time, with the intent of preventing or reducing the likelihood of a repeat incident. Keep in mind that the IR process phases include an inner loop that iterates between “Detection & Analysis” and “Containment, Eradication, and Recovery”. During incidents, there may be situations where an additional system is identified as compromised or infected, requiring further iterations of containment and eradication prior to full recovery.

 

Post-Incident Activity Phase

We have reached the least exciting and most misunderstood section of the IR process – post-incident activity. This is more than just closing a ticket or decompressing from weeks of late-night meetings and pizza deliveries. Post-incident activity or lessons learned includes the formal documentation of the event, a review of the results and metrics, and identification of areas for correction or continuous improvement. In some cases, post-incident actions may lead to updates in processes (change management, patch management, password resets) or documentation (configuration standards, procedures, and policies. This phase is essential to the regular maintenance of and improvement of the incident response process.

Malicious actors are agnostic to an organization’s policies. They will find ways to infiltrate an organization, compromise target systems, and achieve their goals and objectives. These incidents, these violations of policy and computer security practices, must be met with a solid Incident Response capability. NIST has published detailed guidance for organizations to adopt this phased incident management process and develop an incident response function in NIST SP 800-61. While the IR Plan and overall IR phases are important, associated policies and procedures should not be overlooked. Key components of an Incident Response policy, plan, and procedures are detailed below:

 

IR Policy

  • Policies should be customized and specific to the organization. Avoid blind adoption of policy templates.
  • Ensure the policy includes the scope, objectives, and relevant roles and responsibilities.
  • Lines of authority and leadership commitment should provide IR personnel with the necessary support to perform their job duties without pushback from management, personnel, or business units.
  • For those less familiar with IR processes and to avoid confusion during an actual incident, be sure to include a section with definitions for key terms.
  • Define incident types, based on severity and impact ratings. Map these types to prioritized response times, expected resource allocation, and level of escalation within the organization.
  • Identify how the IR process will be measured. Incident data from After Action Reports (including Lessons Learned) can be used to evaluate the performance of the IR capability. Consider metrics such as incident length, type, quantity, and effectiveness. A combination of objective and subjective measures is recommended, including an evaluation of IR performance (subjective).
  • Provide reference to mandatory forms and reporting expectations for security incidents. Specific forms and documents do not need to be included in the policy. They are often standalone and may also be more specifically referenced from within the IR Plan document itself.

 

IR Plan & Procedures

  • Similar to policies, IR Plans need to be customized and specific to the organization.
  • Define your goals and objectives.
  • Establish your process lifecycle and approach.
  • Align details of Incident Command, lines of communication, and performance metrics with the IR Policy
  • Describe incident classifications (types based on severity and impact), and reference associated escalation procedures and required response times (service levels). Provide connectivity or reference to Disaster Recovery/Business Continuity resources within the organization, to support the recovery sub-process for confirmed incidents. Consider flow charts or swim lanes to visually represent the overall process.
  • Document notification requirements and guidance, including internal and external points of contact.
  • Document the Lessons Learned feedback loop function, to ensure the IR process continues to improve and mature.
  • Maintain a contact list for key participants, including alternate contact methods. Consider using an IR Plan Appendix or separate document, based on your document management strategy.
  • Provide sufficiently detailed IR procedures, forms, templates, and checklists. These may be presented as separate documents, in a series of appendices, or maintain through an online workflow tool.
  • Include “playbooks” that provide procedural guidance for scenarios such as ransomware.

 

The best incident response plans are tailored to the organization, straightforward to follow, and provide a clear escalation path. Choose tools and automation resources wisely to manage your incidents, simplify reporting, and continuously grow and improve your organization’s capabilities.

 


 

Speak With A MegaplanIT Expert 

Here at MegaplanIT, we have decades of experience handling incident response plans, testing, and analysis of threats to production environments. Our SOCaaS can aid you in identifying and responding to security events and malicious activities within your environment. Our dedicated consultants advise on incident response plan scenarios, custom-tailored to your organization, minimizing impact to your team while maintaining the maximum return on investment. Reach out today, for assistance with creating a test or reviewing processes for compliance.

 

Schedule Meeting

 

Topics: Compliance Services

Leave Comment