Written by Jaiz Anuar

If a Security Scan Can Take Down Your System, What Will a Real Attacker Do?

Security testing should avoid reckless production impact, but a system that cannot tolerate controlled scanning may also be unable to withstand malicious or unexpected traffic. The trigger deserves investigation; so does the underlying fragility.

There is a familiar conversation between cybersecurity teams and system owners.

“We need to run a vulnerability scan against production.”

The response often comes quickly.

“Only after midnight.”

“Can you do it between 12AM and 6AM?”

“Please make sure it stops before business starts.”

The concern is understandable.

Nobody wants a vulnerability assessment, penetration test or red team exercise to interrupt customers, transactions or revenue.

But there is an uncomfortable question behind this arrangement.

Attackers do not have maintenance windows.

They do not submit change requests.

They do not check whether the business is busy.

They do not stop at 6AM because production traffic is about to increase.

So if our own controlled security testing can destabilise a system, perhaps the scanner is not the only thing we should be investigating.

The Scanner Gets Blamed

I have seen variations of this many times.

Security runs a scan.

The application slows down.

CPU utilisation increases.

A service becomes unresponsive.

Maybe the server crashes.

The immediate conclusion is usually:

“The security scan caused the outage.”

Technically, that may be true.

The scan may have triggered the failure.

But identifying the trigger is not the same as identifying the root cause.

The better question is:

Why could the system not tolerate it?

Was the server already close to capacity?

Was memory exhausted?

Were application connection limits too low?

Did the database hit its threshold?

Was there a network bottleneck?

Did a WAF, firewall or load balancer behave unexpectedly?

Was the application simply more fragile than everyone assumed?

These questions matter because an attacker can create unusual traffic too.

So can legitimate customers.

Fix The Weakness, Not Just The Testing Window

Moving a scan from 2PM to 2AM may solve the immediate operational problem.

But it does not necessarily solve the resilience problem.

Imagine an application becomes unstable when a scanner creates 500 concurrent requests.

The organisation responds by limiting the scanner to 50.

Problem solved?

Operationally, perhaps.

Architecturally, maybe not.

The application still has the same limitation.

The organisation has simply configured its own security tool not to expose it.

An attacker will not necessarily be as considerate.

Neither will a sudden spike in legitimate traffic.

This is why security testing that causes an outage should not automatically lead to tighter testing restrictions.

It should lead to investigation.

Sometimes the answer will be that the scanner was configured too aggressively.

That is a valid finding.

But sometimes the more important finding is this:

The system was less resilient than everyone believed.

Red Teaming Should Test The Organisation, Not Just The Technology

This becomes even more important when we move from vulnerability scanning to red teaming.

A red team exercise should not only answer:

“Can the attacker get in?”

A mature exercise should also help answer:

What happens when something actually goes wrong?

Does the SOC detect the activity?

How quickly does someone investigate?

Can monitoring explain what is happening?

Does the system owner know who to contact?

Can the incident response team contain the problem?

Can operations isolate one component without taking down the whole service?

Can the organisation recover within the expected time?

Do backups actually restore?

Can Business Continuity Management procedures maintain critical operations?

Does management know when a technical incident should become a business crisis?

These are difficult questions to answer if every security exercise happens under perfect conditions.

Everyone knows the exact testing window.

Engineers are standing by.

The SOC has already been informed.

The application owner knows when the activity starts.

And everyone knows it will stop at 6AM.

That may be suitable for some testing.

But it is not how a real incident happens.

The Business Needs To Feel Some Of The Exercise

Security teams are often told:

“Do not interrupt the business.”

That is reasonable.

Nobody should deliberately create an outage just to prove a cybersecurity point.

But there is another side to that statement.

If every exercise is designed so carefully that the business never experiences pressure, uncertainty or operational disruption, are we really testing resilience?

Or are we only testing inside a comfort zone?

Incident response is not just about detecting malware.

Business continuity is not just about having a document.

Disaster recovery is not just about passing an annual scheduled exercise.

Cyber resilience is about whether the organisation can continue operating, make decisions, communicate and recover when conditions are no longer normal.

That cannot always be learned from a perfectly controlled exercise.

This Is Not Permission To Test Production Recklessly

There needs to be an important boundary here.

Giving security teams more freedom does not mean allowing unrestricted destructive testing against production.

Some techniques genuinely carry significant operational risk.

Denial-of-service testing.

Aggressive fuzzing.

Database manipulation.

Destructive exploitation.

Testing that may affect data integrity.

These require specific approval and safeguards.

Critical infrastructure and high-value transaction platforms may need even stricter rules.

There should still be rules of engagement.

Emergency contacts.

Stop conditions.

Explicitly prohibited techniques.

The objective is not to remove governance.

The objective is to stop treating:

“Security testing caused operational impact”

as the end of the discussion.

Sometimes that is where the discussion should begin.

Move Towards Controlled Realism

Organisations do not need to jump from midnight vulnerability scanning to unrestricted daytime red teaming.

Testing maturity can evolve gradually.

Start with controlled production scanning.

Understand which systems are sensitive.

Measure how they behave.

Tune scanning appropriately.

Then investigate why some systems cannot tolerate particular activities.

Improve capacity.

Architecture.

Configuration.

Monitoring.

Recovery capability.

Over time, introduce more realistic exercises.

Run lower-impact security activities during normal operating hours.

Conduct controlled red team exercises where fewer operational teams know the exact timing.

Exercise incident response without telling everyone precisely when the scenario begins.

Test whether escalation paths actually work.

Measure recovery against the RTO and RPO that the business has approved.

Test whether BCM arrangements still work when people are under pressure rather than sitting around a table discussing a hypothetical incident.

The goal is not chaos.

The goal is controlled realism.

A Production Outage Can Be A Security Finding

This is perhaps the mindset that needs to change.

When security testing causes a system to fail, we normally think:

Security caused an outage.

Sometimes another interpretation is equally important:

Security testing discovered a resilience weakness.

That weakness may not have a CVE.

It may never appear as Critical or High in a vulnerability assessment report.

But if predictable activity can make an important business service unavailable, it deserves attention.

Availability is part of security too.

And resilience is ultimately about the ability of technology, people and processes to continue functioning when conditions are no longer normal.

The Wrong Lesson From A Failed Scan

Imagine a vulnerability scan causes an application to crash at 3PM.

There are two possible lessons.

The first:

“From now on, security can only scan this system between midnight and 6AM.”

The second:

“Why did this application fail, and could someone outside the organisation reproduce the same condition?”

The first protects tomorrow’s operations.

The second may protect the organisation during a real incident.

Sometimes both actions are necessary.

Restrict the scan temporarily.

Investigate the failure.

Fix the underlying weakness.

Retest.

What should be avoided is allowing the temporary restriction to become the permanent solution.

Because there is a fundamental difference between our security team and a real attacker.

Our security team will follow the rules.

They will respect the maintenance window.

They will reduce the scanning intensity.

They will stop when the system owner asks them to stop.

The attacker will not.

So perhaps the next time a security scan takes down a system, the first question should not be:

“Who approved this scan?”

It should be:

“If our own scanner can do this, what happens when someone who does not care about our uptime tries the same thing?”

Question assumptions. Share knowledge. Build trust.