I think every time I call one of my credit card customer service centers, I have the same befuddled response, probably because I only call once every 6 months, if that. “Can I have your password for this account?” Me: “…huh, what? I didn’t know there was a password..” Rep: “It is probably your mother’s maiden name.” Me: “…oh…ok well let’s try this.” And of course it works…it’s just so odd being asked a password on the phone…

I really don’t like having a gap between my use of an IDS/IPS and knowledge of the signatures. Today a new alert came across proclaiming “NETBIOS-SS: Bugbear Virus Worm.” I’m not sure what a “virus worm” is, but it certainly is something to look at right away. Turns out it was a false positive, but I really wish I could see what my vendor’s signatures actually are, rather than seeing the interpretation of them in the management console (which are almost always inconclusive and vague). Oh, since I’m complaining about the IDS/IPS, I’ll echo my old complaint that I really dislike capturing only one packet per alert, even though I have it set to log the stream…one packet certainly gives me a lot of context!

Annoying vendor salespeople #84: Insist on digital communication via email only. Actively reject any attempts at face-to-face or voice-to-voice communication. I think sales people have a handbook that says sales are guaranteed with face-to-face meetings and 80% guaranteed with voice-to-voice meetings. It’s almost like seeing a squirrel stuck inside a gallon milk jug.

What if we start convincing companies to roll out “secure by default” devices and software? Will we dumb down our workforce too much, with people who know how to roll something out but not know how to manage anything? IIS is easy to build now, but takes work to really understand it. Apache still scares IIS users because you need to make config changes early on… Just a thought, although I do believe “secure by default” should be the goal.

I was adjusting a script of mine the other day to account for the event of a configuration error in some file replication apps we run. A config error led to an issue with script execution, so I coded around it before I found the config error. This is effectively a little bit of “defense in depth” although this has nothing to do with security. But what if a config error occurs again? Because I’ve layered my script over the config, it might mask the problem with the config. Can defense in depth mask holes in the various layers because testing isn’t done on each piece? Possibly…