Breaking your own rules.
Managing security comes naturally to parents.
“Mom, can I go just this once?”
“Well, it isn’t a school night ... okay.”
“But mooooommm ... everyone else uses GET instead of POST.”
“I don’t care how many of your friends are doing it wrong; YOU are going to do it right.”
“But you said last week that it was okay.”
“That was before I found out this new bit of news. Sorry.”
“That’s not FAIR!!!” (Exit developer, stamping feet and slamming doors.)
“Guess who forgot to lock his workstation—AGAIN?”
“Nobody likes a tattletale. Go back to your office.”
The point is, a good portion of security work is managing and documenting exceptions. Pretty much ALL of firewall management is about exceptions. (That is, if you’re doing it right and starting from a default deny stance.) All remote access is about exceptions. In fact, if you looked at all user management as being about exceptions, you wouldn’t be too far off the mark.
That’s why I wish that security vendors had much more support for user annotation in their products. Take any vulnerability scan. The first thing you’re going to do is weed out the false positives: the ones where the scanner mis-identifies the platform, the ones where you don’t consider it a problem, and the ones where you know you ought not to be doing it in an ideal world, but you have to because of some brain-dead six-year-old product (or antiquated business partner).
Now, how do you track those so that you don’t have to weed them out AGAIN for the next scan? How do you document those when the auditors come in and ask you for the output? How do you keep track of who approved them, and why?
Same thing with compliance tools. How do you mark something as “To be done next year when we have the budget, now get off my back”?
And how do you track these over time, over multiple sites? How do you mark that Antwerp has taken care of this issue because they only have 20 hosts in their one office, but New York will probably NEVER get it done until they upgrade to Vista?
How do you document the decision to let J. Random Developer create 200 of his own testing accounts because he just can’t test his application any other way? How do you post a flag to follow up later and make him delete them all when he’s done? (“I want you home by ten, young man—and that’s final!”)
Right now, too much of security rests on institutional knowledge that may or may not be documented, but certainly isn’t documented anywhere near the scene of the crime. And none of it’s centralized to make it easy for me to print out and hand to a security analyst who’s trying to figure out why we have port 31337 open to an IP range in Qbekistan, accessing a workstation that’s running NeXTstep. Short of a big-ass Excel spreadsheet, I don’t know how to keep track of what I approved for whom, for what reasons, and for how long, in every area where I make decisions on a daily basis.
Do you treat every login and every network connection as an exception? If so, how do you document them so that someone else can find and read them?
Posted by shrdlu on Monday, August 28, 2006
(3) Comments • Permalink •
