Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Armor is a global leader in cloud-native managed detection and response. Armor solutions are designed to support your digital transformation and innovation while maintaining a consistent level of enterprise-grade security for your modern and legacy workloads alike. To deliver these critical security outcomes, Armor combines cloud-native, integrated managed detection and response capabilities along with stringent processes, a world-class team and purpose-built information and privacy infrastructure.

Armor takes steps to address foreseeable threats to your data and systems. Any issues that arise affecting your protected environment, applications, or data are our highest priority. Armor incident response is a key aspect of Armor’s overall security and privacy program. Armor has established an incident response capability that can be relied upon during such issues with a goal of reducing impact and restoring normal status while maintaining service quality and compliance. Once the solution is fully deployed and alerts begin to be emitted that require investigation, it is Armor’s responsibility to triage and investigate those alerts and to provide you a guided response.

This document provides an overview of Armor incident response plan that has been established to swiftly respond to any information security issues, eliminate threats, evaluate risks, assist in remediation efforts and for continual process improvement. Armor will follow this Incident Response Plan (IRP) and do so within the Service Level Agreement (SLA) The target audience for this document is Armor’s customer members, responsible for responding and managing incidents impacting your environment.

PROCESS OUTLINE - How Armor Protects You

How Armor Protects You

Armor enables you to own your valuable data and configurations while leaving the management to us. Armor provides a managed, cloud-native, and DevOps-centric solution that provides detection and correlation capabilities across all aspects of your operation. Armor works with you to ensure your environment is secure and compliant using a shared responsibility model. This model allows you to focus on the aspects of the stack that you are uniquely qualified or positioned to maintain and rely on Armor to provide the reference architecture and guidance stemming from its expertise. \ \ To learn more about MDR Shared Responsibilities, see Managed Detection and Response(MDR) Shared Responsibility Model

Integration

Integrations can include ingesting the logs and telemetry data from a system as well as integrating with a system’s API to perform automated tasks. Below is a list of example system archetypes that can be integrated into the Armor managed detection and response solution. We can integrate with your existing tools or recommend new solutions to fill detection and protection gaps. \ \ To learn more about integrations, see Extended Detection and Response + SOC (XDR+SOC)

Armor Service Levels

Armor ensures fully transparent communication to any affected customers that will take place according to the Service Level Agreement (“SLA”) established for each phase of the incident response. There may be scenarios which arise which impact the SLA. Armor has documented and communicated the service levels. Where applicable, Armor has established service level agreements with you as a part of the contractual agreements. The measure of Armor service against these service level metrics helps you to qualify that the incident response plan is meeting its objectives and goals. \ \ For further information, you may refer the Armor Service Level Agreement .

Armor Incident Response

Upon declaration of an incident, escalation to incident response team members with scheduled availability will be initiated. Every effort must be made to ensure all team members can demonstrate proficiency in each role. The figure below depicts the IRT organizational relationship during an incident, denoting process, and information flow along with management hierarchy.

Incident Response Team (IRT) StructureImage Added
Incident Response Team (IRT) Structure

Depending on the incident, the relevant roles will be assigned according to skill requirement and availability of Triage Analysts and Incident Handlers. As the incident response team checks in, roles will be assigned according to procedure outlined in the Incident Response Team Escalation Procedure. The Information Security Management team will ensure the incident response plan and procedures are maintained and followed. For every incident there must be assigned an Incident Commander. In addition, depending on the type of incident and escalation, the senior leadership from Armor and your organization may be activated, to provide support for maintaining the staffing capacity to effectively and guidance for handling incident response scenarios, and to evangelize and support the incident response plan. Armor requests at least one member of senior leadership should be available for making hard decisions during incident response should the need arise. All aspects of the incident are documented by scribe and custody of all evidence are captured and retained as per Armor policies and procedures.

Armor Incident Severities

The following table identifies the severity levels that Armor may assign to an incident:

SEVERITYIMPACT
CriticalExtraordinary and potentially catastrophic 1. Threat to life or physical safety of the public or personnel. 2. Significant destruction of systems, applications, or capabilities. 3. Massive loss of PII.
HighSignificant impact to business function 1. Sophisticated and sustained compromise involving a large number of systems compromised. 2. Malware that is spreading and difficult to control or counteract.
MediumSuspicious activity, moderate impact to productivity 1. Compromise of limited non-critical users/systems. 2. Isolated malware infections.
LowImpacts are limited or negligible in their disruption to operations 1. Significant level of network probes, scans, and similar activities detected, indicating a pattern of concentrated reconnaissance. 2. Penetration or denial of service attack(s) attempted with some impact to corporate or client operations. 3. Limited number of instances of a known computer virus or worm normally easily handled by deployed anti-virus software.

Incident Response Process

Armor provided SOC services include investigating and responding to incidents as they arise. Armor continuously monitors your SIEM and analytics planes for:

  • alerts
  • indicators of compromise
  • indicators of attack

Our team of cybersecurity experts will then analyze the incoming alerts and indicators to determine the validity of the alerts (checking for false positives, etc.) and then create a customized plan for:

  • mitigation
  • containment
  • remediation
  • recovery

Our team of experts helps prioritize actions and provides strategic and tactical guidance for implementing such action plans. Every incident is unique, and the goal of incident response process is to protect your environment, restore normal services as quickly as possible, and meet all contractual and compliance requirements.

Armor Incident Response Process

Incident Response ProcessImage Added
Incident Response Process
  1. Detection and Identification

    • During this phase, Armor’s systems and human analysts are monitoring for alerts and anomalies generated from the SIEM and analytics planes that have been deployed as part of the solution stack.
    • When malicious activity is detected, Armor will review the context and enrichment data to identify the attack vector and other associated indicators.
    • At this point an incident is created and assigned a priority automatically based on the rule triggered. As analysts investigate and validate, the severity may be re-assigned to the appropriate level based on impacts defined above.
  2. Investigation

    • The incident is assigned to one or more incident responders who will conduct this phase of incident response.
    • An incident may consist of a single critical event, or a series of correlated events that must be investigated.
    • In coordinated efforts between your incident response team and the Armor incident response team, the investigation and detection process may have an iterative approach where both teams are working collaboratively to assist, guide, provide feedback, and support each other until the threat is terminated.
    • The goal of the investigation phase is to determine the scope and potential cause of the incident.
  3. Containment and Mitigation

    • Upon determination of the attack vector(s) and probable cause(s) in the preceding steps, Armor will work with your teams to provide steps to you and your teams or vendors to implement containment and mitigation measures.
    • Containment measures may include isolation of a host, system, or application. Mitigation measures may include the blocking of specific traffic, IPs, or disabling of processes and functionality until remediation can take place to correct the behavior or activity.
  4. Remediation and Recovery

    • Remediation measures will be recommended by the SOC and implemented by the client or the client’s designated service provider.
    • Remediation measures may include repair, modification, patching, upgrading, restoration of backup, or any other requirements to bring the system or asset back into functional working parameters.
    • Recovery may include the running of playbooks or other procedures to ensure all traces of the incident are eradicated from the environment.

In instances where the remediation effort relies largely upon the customer’s team(s), Armor Security’s incident response team will be available to assist, guide, provide feedback, and support as needed. If it has been determined that a threat actor dwelled on the asset or system, and remediation has been completed, a full analysis report and timeline of the incident will be created providing the root cause and any suggestions that may help further secure the environment from such incidents moving forward.

Once an incident has been declared, priority will be assigned (as described in our Armor Incident Severities), and a ticket will be opened with information relevant to the incident for tracking and communication with your team. These tickets will provide historical context and review as needed. The method used for escalation may be automated or manual, depending on the capabilities present at the time of declaration. A wide range of incident types that may affect your systems or information. When considering the determination of severity, the type of incident and its ability to impact the client or underlying infrastructure is considered. In order to appropriately allocate IRT resources and facilitate follow-up incident analysis, Armor has created internal guidelines for categorizing the severity of incidents based on the known facts of the incident. This prioritization on how to resource the response to the incident is a most critical decision point in the incident response process. Incidents should be handled based upon the risk they pose to your environment, their information, legal and regulatory obligations concerning the information, and computing environment.

In the event of a critical incident being raised, a war room and conference bridge will be created where assignment of roles and initial briefing will take place. The bridge details will be shared via a ticket or an agreed secured method. Prior to any investigation, a storage location will be created to hold any evidence or supporting data, and all data obtained for the purpose of the investigation will be encrypted, and where possible signed to ensure forensic integrity. Your environment specific custom procedures provided by you will be referred to when an incident is declared. This can include asset documentation, escalation procedures, incident declaration requirements, and remediation procedures. If no evidence is obtained, the storage location may be terminated.

Retrospective

Upon conclusion of the incident, the incident will be set to a “Resolved” state. If it was been determined that a threat actor dwelled on the asset or system from the incident resolution, a meeting of all those who participated in and/or were affected by the incident shall agree upon a date to analyze and review the incident for procedural and plan implications, provide metrics, and identify lessons learned which will be incorporated into action items for future incident response training and goals.

Collaboration Scenario

The collaboration with your team is necessary to ensure security of your data and to achieve the security outcome. There are two types of incident response: managed and coordinated, with the primary difference between the two being that coordinated incident response often requires input, approval, or other interactions from you and/or your team, whereas managed incident response is fully managed by Armor (as described in our Shared Responsibility Model).

Managed Incident ResponseCoordinated Incident Response
Managed incident response refers to a response that is fully managed end-to-end without involving anyone from your organization. You will be notified within the ticket and in accordance with your preferences and legal or compliance requirements.Coordinated incident response refers to a response that is unable to be fully managed end-to-end without closely collaborating with your teams. In certain instances, you may have your own incident response team with whom Armor’s incident response team will coordinate to help resolve an incident.

These incident collaboration scenarios supported by automation and/or joint efforts between Armor’s incident response team and you where Armor will maintain availability and provide guidance until the incident is resolved.

Collaboration Channels

For both managed and coordinated incident response methods, clear and effective communication is essential to delivering security outcomes. Armor recommends real-time collaboration tools such as Slack or Microsoft Teams. Using these tools allows for real-time, historically tracked, and open chat communications with voice and video collaboration available as well. Armor also supports integration and ChatOps automation within these platforms to allow for a single collaboration channel for all incident response activities.

All incidents are also tracked centrally within the Armor Support Center and non-incident support inquiries can be managed here as well. The Armor Support Center is the official channel for support and new support inquiries should be raised here https://support.Armor.com. Issues raised outside of the official channel may not be subject to the Service Level Agreement (SLA) or a specific project deliverable agreement.

Incident Response Preparedness

As detailed in the sections above, effective response to incidents requires coordination and collaboration from all parties involved. There are a few steps that you can take to ensure that you’re prepared to satisfy the portions of incident response for which you’re responsible (as described in our Shared Responsibility Model):

  1. Public Verification of GPG Keys

    • Throughout the incident response process, sensitive information is often required to be exchanged between collaborative teams.
    • Because of the elevated alert levels during incident response, identity verification of those participating in the response to the incident is critical.
    • Using tools like Keybase, sharing your public key with Armor via the management console, or other forms of key exchange and verification are good ways of ensuring that the response phase isn’t delayed by identification verification processes that are sometimes significantly time consuming.
  2. Collaboration Channel Sharing

    • Armor collaborates with customer primarily via ticketing platform, for communication, responding to incident and for periodic updates. Depending on the type and severity of the incident, Armor may require collaborating with your team and SMEs via chat/video/voice platforms. Armor recommends real-time collaboration tools such as Slack or Microsoft Teams.
    • Ensure that the appropriate members of your team have the necessary permissions to accept invitations to join collaborative channels. Frequently other users (such as SMEs for a given set of affected devices) must be consulted to provide details about certain aspects of a system or reference architecture. Your team should have the necessary permissions to invite these additional people to the channel to participate in the response activities.
  3. Ensure Asset Inventory is Current

    • It is also very important that the asset inventory and classification is as current as possible.
    • This will aid in measuring the footprint and blast radius of a specific attack and will improve the overall response time and accuracy.
  4. Periodic Review

    • You must regularly review your incident response process to ensure that any weaknesses or gaps in the process are addressed.

Continual Improvement

At Armor, we strive to learn from every incident and implement preventative measures to avoid future incidents. The actionable insights from incident analysis enable us to enhance our tools, training and processes, overall security and privacy program, policies and procedures and response efforts.

Periodic Review

An incident response plan requires routine maintenance and periodic review. The contents of this document shall be managed by Armor Security Incident Management lead. Armor shall conduct a full review of the AIRP at least annually. The Security Incident Management Lead shall present an updated document to the Head of Security for re-approval once annually, even if there are no changes to the AIRP since the last approved revision. The AIRP shall have portions reviewed quarterly to update changes in management reporting structure, team responsibilities and personnel assigned to individual roles. Upon the conclusion of all critical incidents, a review of applicable lessons learned will be undertaken to provide improvement to the plan on an on-going basis.

Upon each revision, these essential factors shall be considered:

  • The efficacy of the previous version of the AIRP.
  • Recent changes in the types, volume, or source of Armor data that requires classification and special protection.
  • Changes to the regulatory definitions of protected data, such as Personally Identifiable
  • Information (PII), personal data (PD), sensitive personal information (SPI, payment card, information (PCI), or protected health information (PHI).

Rehearsal and Exercise of Plan

The Armor Incident Response Plan (AIRP) rehearsed annually through formal table-top sessions conducted either by an authorized third party or internally via direction from Armor senior security leadership. All key members of the Incident Response Team (IRT) will be present for testing focusing efforts on defined incidents within this plan. Results of the exercise will be provided to Armor Information Security upon completion. The exercise also provides input to continual learning and training paths that will be foundational to enabling Armor IRT. Exercise of the plan is conducted through daily operations as both client and Armor systems suffer attack.

Governance, Risk and Compliance (GRC)

Armor’s processes are tested on a regular basis as a part of our Governance, Risk and Compliance program to provide you with an independent verification of our security, privacy and compliance controls.

Armor is assessed annually:

  • Privacy Shield
  • PCI-DSS
  • ISO 27001
  • NIST
  • HIPAA
  • HITRUST
  • SOC 2 Type II

Summary

Armor provides Managed Detection and Response (MDR) services that include investigating and responding to incidents as they arise. Armor monitors, detects and responds to incidents and provides guided assistance to you for restoring normal status.

  • Armor’s 247 Security Operations Center (SOC) continuously monitors your environment for malicious behavior and responds to generated incidents. We follow Armor Incident Response Plan (IRP) and will deliver these services in accordance with our SLA.
  • Your overall security posture is a responsibility shared between you and Armor. Following Armor’s Shared Responsibility Model (SRM) there may be actions required of you and your team to ensure that incidents are properly remediated.
  • These vary on an incident-by-incident basis and your team should be prepared to collaboratively resolve incidents with the expert guidance provided by Armor.
  • Depending on the incident type and severity, Armor response will be fully managed end-to-end without involving your team.
  • Some incidents will require closer collaboration and coordination with your team to help resolve an incident. In such scenarios, a joint effort between Armor and your team will maintain availability and provide guidance until the incident is resolved.

Armor continuously monitors your SIEM and analytics planes for alerts, indicators of compromise, and indicators of attack. Our security operations centre has a team of experts providing around-the-clock monitoring, investigation, and remediation.