The Power of FAIL.
Any time you’re evaluating or designing a system, you have to take into account the ability for things to go horribly wrong.
Now, this is pretty obvious when you’re building a bridge, but for some reason, nobody expects security analysts to be thinking this way. I guess it’s because people on the outside think we’re all about stopping 3v1L H4X0rz, and that security stops there. If they think any further than that, they expect that we’re all about stopping naive users from writing their passwords on Post-It notes (which is also a depressingly frequent part of the job, don’t get me wrong).
So developers get confused when I point out potential failure points in their applications. Either they say, “But who would DO that?” or, “Don’t worry, our users aren’t smart enough to try that.” My Clue Bricks are showing signs of heavy wear; I think they’ll FAIL before the need for them has dissipated.
For example, I’m just picturing my next conversation with a virtualization engineer, where I’m planning to tell him how I want my virtualized instances of a certain critical division handled:
“Oh, and you can’t use VMotion on these.”
“WHAT?? Why not? VMotion will allow us to provide fault tolerance by moving things around!”
“Take a look here. We’ll have eight instances, four primary and four backup, right?”
“Right.”
“Well, you’re going to put each primary and its associated backup on separate VM hosts, right? They’re never going to be on the same ones.”
[Blank look.]
“Because one of the great new things introduced by virtualization is grouping previously separate instances under a SINGLE POINT OF FAILURE.”
[Blank look.]
“If your hypervisor takes a dump, or if the VM host hardware fails, everything on that box is going down together. So I don’t ever want to see a primary and its backup on the same box. Since there are only eight servers, you’re not going to have more than two VM hosts, so there will be no need to migrate anything around except in an emergency. Now, for performance reasons, if the backups aren’t busy, you may want to have two backups on each box with two primaries, so that the primaries can suck up the resources. But you’re not going to do any fancy switching on the fly. So no VMotion.”
“But ... what if both of them go down?”
“In that case, you can move them manually. I want you to be thinking about it; I want you to be careful and deliberate. Besides, these servers are classified differently from all the others and I don’t want any of them to ACCIDENTALLY reappear on some other host with a different policy setting.”
“What’s wrong with that? We can isolate them from each other using policy rules; that’s what this nifty management software is for.”
“Rules can be fubared. Software can be hacked. There’s no substitute for a physical gap when you’re really serious about separation.”
Now, at this point, I expect the engineer to get this sullen look on his face as if I’m telling him that I expect him and his whole admin staff to be stupid. (From what I’ve seen, many of them are only barely IN the drawer with the sharp things.) But that’s not the point: I expect them to be HUMAN. When you have more moving parts, you have more opportunity for FAIL, and that’s why you disable any of them that you don’t absolutely need. Simplify, simplify, simplify. Just because something comes with a nifty new feature, it doesn’t mean you have to use it.
Actually, that’s why virtualization makes me nervous, in a nutshell. It allows you to shoot yourself in the foot faster, with more efficiency and automation. “Dammit, where did that VM go??” “Oh, I thought you wanted that one retired, so I took it offline.” “Well, where is it archived?” “Um, let me see ...” “Hey, who set up this instance called ‘ursopwn3d’?”
Take another example. People keep going on about how DLP is only really good for “stopping stupid.” Well, maybe that’s only as good as it’s ever going to get. And that’s okay; maybe anything that interferes with a business process by design can’t do much prevention when the only differences between malice and stupidity are, well, intent and cleverness.
Human error can and should be prevented wherever possible. Same with stupidity. But in the case of malice, you probably have to lean more on the side of detection instead.
STUPIDITY : MALICE :: FAIL : PWN. Remember this for your Security Aptitude Test, grassh0pper.
