Nailed it.

With servers being generally virtual these days, and the underlying physical hardware a highly replaceable substrate, there's no reason for an enterprise to have serves which do more than one thing. If a server does only one thing, it ought to be named for that one thing.

mailserver-eastcoast.example.com

Where is that machine? Somewhere in the blade cage. If I yank the blade, it'll appear in a few seconds on another blade. Where is the data? On the giant fiber RAID, which is replicated in the west coast office, and two secret locations.

Compute is a cloud, storage is a cloud, services come from that cloud, the clouds made of physical devices in as many locations as make sense.

The old physical network topology is finally just the nerves and pumps, and no longer the focus.

The focus is the data. The data is what we produce to make value, to drive the business process. Servers aren't special anymore, they're like hammers. You don't name hammers, typically. But you might have more than w=one, and you definitely want to know two things: where is it, and what is it for.

If someone wants to steal something, and you are trying to prevent it, short of a body cavity search everyday, you've already lost the game. You can steal a code base and drawings for virtually any product by simply copying it onto a USB flash drive, and walking out. Often your cell phone will suffice.

If you are trying to prevent viruses and stuff, the same techniques apply for company owned laptops versus employee owned. If they can take it home, it can get infected. You might ameliorate things by having a forced virus checker installation, but a voluntary one will generally work just as well.

In the end, the only thing you are can't do is take the machine away, but this is such a rare event that it's almost not worth considering.

Process isn't a substitute for thinking, process is a substitute for forgetting. A well designed process is simply the thing you'd do if you could keep every *actually* important detail in your head at all times.

You should certainly file bugs against a process (in the same way you would against any work product) if you perceive that a step or steps is useless or wrong.

You *are* following a process, it's just ad hoc, and maybe made up on the spot. Formalizing that process is a way to make it repeatable, and debuggable.

That said, and to reiterate, you must fight against the bad process. Bad process isn't clear. It's a bad program. Debug it.

So, thinking like a would be cracker, the list of basic places to try first:

Persons front door.
One of their windows.
A bank near their house.
Their car, if visible.

Etc. Given the usual kind of passwords people choose for themselves, I expect this will be similar.

Of course, this assumes the cracker can figure out the person's address, but we know how easy that can be.

I have been teaching people to use a complicated random password, but to go ahead and write it down. Then the basic security problem is getting them to control that piece of paper (keep it in your wallet, please), and makes over-the-net cracking much harder. Most of my users never had a problem with this.

People are dumb. Millions of people would select something like the entrance for Fort Knox, or Norad, or a local bank. You have a training problem just as large as the one you have now.

Except that the space is never not filled. 0 is a valid address. The certificate means we haven't figure out how many apples you have yet.

1. Do not belittle or otherwise blow off the customer's fear. In fact, hear it, and agree that it's something to think about.

Them: "I'm worried about this Linux stuff. A guy was telling me that anyone could see the code, and just know how to hack it!"

You: "I can understand how that could be a concern. It is a little like having a map of the valuables in your house taped to your front door."

2. Explain why openness is helpful

Them: "Yeah, so what should we do?"

You: "To be honest, sir, the reason why we like that anyone can see the code is because that means anyone can fix those problems. And lots of people do, for the very same reason you are worried about it. They need something that's secure, and isn't going to surprise them."

3. Mention that serious people have a big stake in making this work.

You: "I should mention that a few companies have bet a lot of money on open source, and wouldn't be happy to see it easily broken. IBM, Novell, and Oracle, to name a few, have very large investments in Linux, and have donated many patches to make sure the code is secure. And for that matter, so has the NSA. They have actually extended the security quite a bit, with their Security Enhanced Linux."

4. Reassure them that people are thinking hard about this.

Them: "Yeah, but if anyone can see it..."

You: "...then you have to be extra careful. See, the strategy that Open Source follows, and everyone should, is to assume that everyone *can* see the code, so you better design it so that the real keys to the kingdom aren't in the code at all. You make sure the keys are completely in the hands of the owners of the system, so it doesn't matter if you can see how the lock works, you still don't have the keys."

5. Point out the obvious.

Them: "But what happens if someone tries to slip something in, and is really good at it?"

You: "Once in a while, someone tries. But when a thousand people might look at the files you are trying to sneak in, someone's going to notice. And then a hundred thousand geeks will make fun of you. In public, all over the internet."