AMI3A: Am I Under Attack?
Under Attack — Money Time
Software contains vulnerabilities. Some are already known and waiting to be patched. Others have not yet been discovered by the software publisher or the organization using the software.
An attacker does not need to wait for us to find the vulnerability first. Attackers may discover a weakness, develop a way to exploit it, and begin using it before a patch, signature, or mitigation exists.
This is the Am I Under Attack? state: the point where vulnerability potential becomes active exploitation.
From Vulnerability to Attack
User-input vulnerabilities commonly exist because of three conditions:
- No input sanitation.
- Incorrect or incomplete input sanitation.
- Unsafe handovers between software components or systems.
In each case, a software component receives input that is unexpected, improperly handled, or not permitted. That input may change the intended behavior of the software.
Once the vulnerability is discovered, vulnerability management begins:
- The publisher investigates and fixes vulnerabilities in its own software.
- The consumer identifies, prioritizes, patches, or mitigates vulnerabilities in software supplied by others.
However, until the problem is fixed, the vulnerability remains a potential route to impact.
When Likelihood Becomes Real
Risk exists while impact is still only possible. An attack begins when the likelihood component of that risk starts to become true.
Attackers are now actively attempting to trigger a vulnerability, bypass a restriction, exhaust a resource, misuse legitimate functionality, or otherwise affect the asset.
Therefore:
Under Attack is any situation in which a potential impact is about to become real damage.
This is the point where technical risk may begin translating into actual damage to the security pillars:
- Secrecy
- Dependability
- Correctness
The result may then become measurable in lost money, operational disruption, recovery effort, reputational harm, or business impact.
This is serious, but it is also good news: the organization still has another opportunity to act before the attack becomes a compromise.
Anything Can Be Under Attack
Any software component, protocol, service, interface, identity, resource, or business process can become a target. Each requires protection that understands what it is observing.
A defense that understands HTTP is ineffective against a protocol it cannot inspect. A control designed to detect malicious input may not recognize a resource-exhaustion attack. A rate limit may reduce volume without detecting a successful exploit.
Security controls must therefore be classified by what they can see, understand, detect, and prevent. They cannot be treated as one undifferentiated defensive wall.
Attacks Do Not Always Look the Same
An attack may be immediate and obvious:
- A critical vulnerability is published and exploitation begins within hours.
- A zero-day exploit is used against a vulnerability the organization does not yet know exists.
- A known exploit is sent directly toward a vulnerable application.
An attack may also be slow, distributed, or difficult to recognize:
- A brute-force campaign runs at a low rate for months.
- Automated scanning quietly maps the organization’s exposed assets.
- A person manually investigates the site, looking for a route into the environment.
- A DDoS or cost-amplification attack consumes resources and generates financial loss without causing a complete outage.
The absence of a dramatic alert does not mean the absence of an attack.
Attack Search Patterns
Attackers may search in several ways:
- A specific vulnerability across any application.
- Any vulnerability in a specific application.
- Any vulnerability across any available application.
- A specific vulnerability in a specific application.
These patterns describe the difference between broad scanning, targeted reconnaissance, opportunistic exploitation, and focused attacks against a known asset.
The Attack Elements
From a technical perspective, an attack can be described using its essential elements:
An attack occurs when an attack agent sends an exploit toward an attack surface in an attempt to execute or trigger a vulnerability.
The main Attack Elements are:
- Attack Agent — the person, system, bot, tool, or infrastructure performing the activity.
- Exploit — the input, request, sequence, technique, or behavior used to trigger the condition.
- Attack Surface — the exposed interface, protocol, service, function, or resource receiving the activity.
- Vulnerability — the condition that allows the exploit to change behavior or cause impact.
This definition gives us a practical way to examine an attack. Security controls can detect one or more of these elements, prevent them from meeting, or stop the activity after it begins.
Preventing and Stopping Attacks
Not every attack is handled in the same way.
Prevent the Attack
For vulnerabilities that may produce immediate impact once successfully triggered, the objective is to prevent the exploit from reaching the vulnerable attack surface.
The attacker, exploit, attack surface, and vulnerability must not be allowed to meet.
Examples include injection, unsafe deserialization, authentication bypass, and remote code execution. Once the exploit succeeds, prevention has failed and the situation may already have moved toward compromise.
Stop the Attack
Other attacks create impact through continued activity rather than one successful exploit.
Examples include:
- Brute force
- Application-layer denial of service
- Resource exhaustion
- Abuse of legitimate functionality
- Cost-amplification attacks
- Low-and-slow automation
These attacks may continue for minutes, days, or months. The objective is to identify the activity, understand its pattern, and stop or reduce it before unacceptable damage occurs.
The Value of the Under Attack State
The Am I Vulnerable? state identifies what could happen.
The Am I Under Attack? state determines whether someone is actively trying to make it happen.
The Am I Compromised? state determines whether the attacker succeeded.
Under Attack is therefore the active defensive window between potential and realized damage. It is where security controls, investigation, and operator judgment work together to:
- Detect suspicious activity.
- Determine whether the activity is a real attack.
- Understand the target and attack method.
- Prevent a successful exploit.
- Stop continuing abuse.
- Verify that the defensive action worked.
This is where security controls demonstrate their operational value: not simply by generating alerts, but by helping the operator recognize, investigate, prevent, and stop attacks before impact becomes compromise.