Detection is inadequate, because detecting the open barn door after the horse left is not helpful.

> Sprinklers

That is "we can prevent the server room from being destroyed" thinking, rather than "how do we survive the server room being destroyed" I'm proposing.

It may be helpful if you have more then 1 horse.

And you are wrong in labeling it "prevention". It is a feedback mechanism. Fast feedback is essential in almost ANY scenario. Most of the things can be fixed if detected early on.

The first thing is knowing. If you don't know something, you can't act on it. To take your battleship analogy, if I remove all torpedo sensors from the ship, how long will it last given it is compartmentized and whatnot.

> Most

That's still focusing on making components that will not fail, rather than a system that can tolerate failure.

FWIW, I agree with the point you're making, vis-a-vis system resiliency. Ideally the system should be able to tolerate having a data center burn down. My comments above about the value of sprinklers are really addressing a separate issue, which is the immediate life hazard risk to the people working in the data center in the event of a fire. With my "firefighter hat" on so to speak, I don't really much care about the servers and the data in the short-term if there' a fire - I just care that everybody goes home safely.

Why do we have pain receptors then ? Nature sux as designer ?

For the same reason you don't have a backup heart

You actually do have organ backups.

If you have a second heart, please report to area 51 immediately

That would be Krogan, not me. There are animals with multiple hearts. People can be made to have 2 hearts too, but let me not go into that.

But we have bunch of non-heart redundancy.

Yeah, if you ignore the various single points of failure in our circulatory, digestive and nervous systems there are plenty of redundancies.

There is no intelligence behind our design. Your body takes its current form because no mutation which would change it has yet led to a statistically greater chance of you passing on your genes. That nature designed you to have pain receptors is no more an argument for their utility than it is for the peacock's feathers.

Youre suggesting detection is only possible much after the fact, when it is possible to also do before an adversary has been able to achieve anything significant on the target. But credit where credit is due, detection is not the answer but rather early detection.

Sprinklers comment was made in jest.

I bought a book some years back about how to defeat burglar alarm systems, as I wanted to make my home more resistant to burglars. The book described a sophisticated system that would detect burglar entry and then automatically phone the cops.

The defeat was to chop the phone line where it entered the house, because the telephone company puts their box on the exterior of the house. (The book was printed before cell phones.) The sophisticated $$$$ detection system, defeated by the simple swing of an axe.

Relying on detection requires a perfect detection system, which is impossible.

If we're looking at how to do detection right in IT systems, the physical world example you give doesn't really apply all that well. First the environment is different and second threat detection in IT infra is a multi-stage process involving probabilities on each stage. You can't cut the wire and disable them all from one spot. (or you can if you slice the cable, but then you cut your access too - and a bunch of other collateral...)

We deal with imperfect information all the time when building complex software systems.

Let's talk dead node detection, for example, and consensus. "Perfect detection" is impossible due to possible network partition, yet we can build reliable distributed systems on top of that imperfect reality, even in face of malicious nodes (B-F/T). We do this via redundancies; mutli-step 'actualization' of system changes (e.g. transactions); and the ability to revert to a known stable state.

Based on that analog, I think it reasonable to strive for security regime approaches that permit for security failures at component levels. The computational and bandwidth loads may be excessive (ATM) but ultimately there will be systems observing systems and a type of 'security consensus or quorum' theoretical work informing how to build such systems.

There is a thin layer of semantics that overlays the generalized and irreducible state transition due to input: one instance is preventing inconsistent action on data; the other is preventing insecure action on systems.

You can expect single detection system to fail, so you need to make it redundant. For example impossibly loud siren.

Like you said before, any solution is a mix of 2 paradigms.

Another method of defeating a sophisticated burglar alarm system is taking an axe to the power cable to the building.

How many people have a battery hooked up to the siren?

Pretty much every residential system and every commercial system has a battery backup.

but isn't focusing on detection the fundamental change in perspective required? I.E.: You're no longer assuming there is a set of steps you can do to ensure it will never happen to you because it _will_ happen to you.

Yes, but it is in the opposite to what the parent comment advocated (prevention of any incidents)

The company I've founded is very much about providing better detection capabilities, but I'd say this is an oversimplification.

First of all, detection is methodologically bankrupt. We have almost no one out there saying how detection should be done with consensus - only in the last 5 years have we even started to improve here.

In my opinion, detection of attackers, which is what the industry focuses on today, is a huge waste of time and resources - it's the last step in the process that I would recommend.

I would personally say that detection should be staged as:

1. System inventory (can you attribute an IP or Hostname to a device identitiy, a user, etc)

2. Policy enforcement (can you detect when policies change, or are violated?)

3. Unexpected behaviors - go to the people building systems - ask them what's expected, what isn't, and build rules for that, or even better, have them build and maintain the rules under your guidance.

4. Attacker behaviors - finally, spend some time building rules for attacker behaviors.

Most organizations skip straight to 4, and then you have a team of defenders who have no idea how the network they're supposed to detect is supposed to actually work. This is throwing away the greatest advantage defenders have - that they know where the attack will take place, and they know all of the stakeholders for those environments.

Here's the chief of the NSA Tailored Access Operations saying this at USENIX four years ago.

https://youtu.be/bDJb8WOJYdA?t=83

"If you really want to protect your network you really have to know your network"

None of this is as simple as "detection" - it means working with the policy teams, with your infrastructure teams, with your product teams, to better understand your environment.