AMI3A Incident Response Framework (IRF)

This index outlines the AMI3A Incident Response Framework (IRF), developed by Lior Rotkovitch and promoted at SIRT.org. This methodology provides a structured reasoning and execution model for modern security operations.

1. Defining Incident Response (IR)

• The Business Perspective: Security exists to protect business value, specifically Revenue, Cost control, and Brand.
• The Technical Goal: IR is the set of urgent operational actions taken to prevent, contain, or recover from technical impact on SDC: Service, Data, and Compute.
• A Wider Scope: Unlike legacy definitions that only start after damage occurs, IR in this framework is the entire operational lifecycle of business-threatening technical risk. An incident begins the moment a risk becomes actionable.

2. The Evolution of Risk: The Three States

Risk is a lifecycle that moves through three specific operational states:

• Am I Vulnerable? (AMI Vul): Risk as potential. This is a condition that could cause impact. Managing vulnerabilities is “pre-incident response” — acting before exploitation occurs.
• Am I Under Attack? (AMI UA): Risk as active. Someone is attempting to realize the risk right now. This is where security controls are actively used to stop or prevent impact.
• Am I Compromised? (AMI Comp): Risk as realized. The damage has happened, and the goal is recovery, containment, and restoring business continuity.

3. State Flexibility and Transitions

• Non-Linearity: While risk often moves from potential (Vul) to attempt (UA) to success (Comp), any state can happen first.
• Interconnectedness: A compromise can reveal a new vulnerability, or an attack can lead directly to a compromise.
• Uniform Result: Regardless of which state you enter first, the objective is always identical: to act with urgency to eliminate, reduce, or accept risk to protect the business.

4. The AAA (3A) Execution Engine

• Separation of Concerns: AMI3 identifies the state, while AAA is the execution engine that runs within that state.
• Operational Power Process: AAA is designed to overcome “analysis paralysis” by providing a structured, repeatable engine for rapid mitigation.
• Core Requirements: The engine is built to be fast, repeatable, and measurable to handle the pressure of modern threats.

5. The AAA Steps in General

The engine follows a three-phase process (A1, A2, A3) to drive an incident to resolution:

• A1: Analyze (Understand the Situation):
• Risk (A1.1): Determining how bad the situation is (Severity, Scope, SDC impact).
• Priority (A1.2): Deciding how soon to act (Now, Soon, Later).
• A2: Actions (The Engine Room):
• Seek/Classify (A2.1): Turning raw signals into labeled evidence through investigation.
• Destroy/Construct (A2.2): Building a mitigation plan based on that evidence.
• A3: Acknowledge (The Contract with Reality):
• Apply (A3.1): Executing the mitigation plan to force a decision and stop the risk.
• Verify (A3.2): Proving the plan worked through monitoring. Success allows the team to go Back to Routine (BTR).