Accountability in Security Policy
Another great question: “You really stressed individual accountability through the use of named user accounts, and the eradication of the use of privileged group accounts like ‘Admin’ and ‘root’—even to the point that such practice be reflected in Security Policy. Does anybody really do that? Why should we?”
Who, What, When, Where, and Why—that's what Security Policy *is*. (The How, of course, is properly described separately by Procedures.) It's the way any enterprise must document, justify, and codify its approach to, and decisions regarding, the management of risks to assets.
No matter how well specified the What, When, Where, and Why might be, without the Who—the details as to each actor's responsibilities for action or oversight—a Security Policy can't possibly be effectively implemented. Individual accountability (by documented position or role) is key.
Without this 1st plank, every responsibility will be "someone else's," and so ultimately no one's.
So yes, many of my clients manage to do this, and very well. It takes work and discipline, but it pays off.
Weblog Entry
Thursday, June 21, 2007
Entry Notes
Category: Stuff you gotta just do
Event: Typical student request.
Weather: Ahh... summer in MT!
Other Details:
I get questions like this all the time. No, ‘su’ isn’t OK. C’mon people: knowing who did what, and when, is about as critical as it gets, right? Right??
