5

Almost all agree that during a pentest it is impossible to guarantee the integrity of the target (Is it acceptable that a skilled professional pentester deletes or modifies sensitive data in production unintentionally during a pentest?) because you are going to use unexpected input and automatic tools to see its response.

In this scenario, is it reasonable to perform a pentest over a critical infrastructure? The integrity of a critical infrastructura may be needed to protect human lifes and its malfunction put human lifes at risk.

How can we perform a security test over a critical infrastructure knowning its criticality?

Possible solutions to this problem are:

1) Perform a theoric audit

Theoric audits are ok but will have theoric results not real results.

2) Perform a pentest over an identical environment

When we talk about critical infrastructures (and for other environments as well) may be impossible to have two identical environments because the cost and the complexity of the environment.

When we talk about critical infrastructures we talk about things like:

  • electricity generation, transmission and distribution;
  • gas production, transport and distribution;
  • oil and oil products production, transport and distribution;
  • telecommunication;
  • water supply (drinking water, waste water/sewage, stemming of surface water (e.g. dikes and sluices));
  • agriculture, food production and distribution;
  • heating (e.g. natural gas, fuel oil, district heating);
  • public health (hospitals, ambulances);
  • transportation systems (fuel supply, railway network, airports, harbours, inland shipping);
  • financial services (banking, clearing); security services (police, military).
Community
  • 1
kinunt
  • 2,769
  • 2
  • 24
  • 30
  • "When we talk about critical infrastructures (and for other environments as well) it is nearly impossible to have two identical environments." Why? –  Sep 04 '13 at 15:43
  • @TerryChia because the cost and the complexity of the installation. But with this question I want to know if you think that having two identical environments is the way to go. – kinunt Sep 04 '13 at 15:46
  • Anything that critical, I would expect there to be at least a second system for fail-over. And if a second one can be built for that, it can be built temporarily for pen testing. Also it may be possible to rebuild on a much smaller scale as the requirements for performance/load etc are not the same – razethestray Sep 04 '13 at 16:02
  • @razethestray I completely agree but doing the paper of the devil's advocate I can say that critical components will have a second system fail-over but not the entire infrastructure so the fail-over systems will not be enough to mount and identical environment and pentest it. For example, if we have 3 critical routers, we can have 2 more just in case 2 of the 3 fail but not 3 redundant routers. – kinunt Sep 04 '13 at 16:22

3 Answers3

5

In any test that deals with critical systems, one would usually limit the test to low-risk operations, and avoid automated tools (e.g. Nessus) that might potentially harm the system.

Specific to critical infrastructure, I would say the following:

  • Schedule the test at a low demand point where applicable.
  • Make engineers and other support staff aware of the test, and have them standing by to fix any issues quickly.
  • Ensure that extra capacity / redundancy is planned during the test, where possible.
  • Ensure that the testers are given an appropriate action plan that details how to deal with serious faults, or unresponsive systems. This should include emergency contacts.

Despite this, there will always be a risk. It's something you have to deal with, and in a way it's a good thing. If the testers knock something offline by performing only low-risk actions, then you know that an attacker could do much worse. An accidental system crash during a planned test would suck, but not as much as widespread crashes due to malice when nobody is expecting it. Having it go down in the test scenario allows you to plan accordingly and make appropriate fixes.

Polynomial
  • 133,763
  • 43
  • 302
  • 380
4

Well, no, it is not "reasonable" to do possibly destructive tests over a critical infrastructure. That's by definition: the critical infrastructure is critical.

Let's do maths (maths are cool). A penetration test has some (hopefully small) probability p1 to disrupt the service on which it is applied. It also has probability p2 to allow the detection and fix of an issue which would have had probability p3 to be exploited, leading to a disruption of the service. Then the probability of disruption when applying the penetration test is p1 + (1 - p2)·p3 (either the pentest breaks things right away, or it "misses" the hole and the attacker succeeds anyway). If that value is bigger than p3, then the pentest on the live, critical system does more harm than good and must not be performed.

In all generality, this is all risk analysis: you have to balance the risks involved with doing the pentest, with the risks involved with not doing the pentest. Contrary to what my few mathematical notations above seem to imply, the relevant probabilities cannot be known with any decent precision, so it is all guesswork in the end. What really must be remembered is that there is a relatively large set of possible strategies:

  • You can do the pentest on the live critical system.
  • You can pay for the setup of a clone of the live system, which will be as identical to the live system as can be physically achieved, and do the pentest on that system.
  • You can do most of the pentest on a crude emulation of the live system, and work with the pentester to categorize the pentest actions: for some, the live system is likely to behave like the emulation, for others it is not. This may already reveal interesting things.
  • You can also do nothing at all. The risk might nonetheless be transferable with an insurance mechanism (depending on the context; business is easily transferred, human lives are harder).

An extra point to consider is that attacks are just one type of risk. You have other types, e.g. floods, earthquakes and fires, which can destroy much of the "critical infrastructure" anyway, and you have to account for those as well. A typical way to deal with floods is to have a backup infrastructure somewhere (a "cold site", "warm site" or "hot site", depending on how far the installation of that site was completed in advance). In some cases, this backup site can be used for risk-free pentests.

Tom Leek
  • 170,038
  • 29
  • 342
  • 480
0

Convert hosts to VM guests then take them offsite to pen test them elsewhere. Gather firmware samples and run them with Qemu. Ask for a few DCS, PLC, RTU, or smart meter devices that can be forced into early retirement for lab purposes.

atdre
  • 18,945
  • 6
  • 59
  • 108