Navigation
The Black Book of Identity Access Mgmt
This form does not yet contain any fields.

    Entries in compliance security policy (1)

    Sunday
    Oct242010

    I'm not opinionated, I'm just always right

    I belong to a writers’ group that meets at our local library, and each week we read our latest brilliance to each other. One young lady is writing a vampire story. In her latest installment, she wrote about how a nasty young vampire beat up an older vampire. One guy in the group said, “That makes no sense. The older vampire should be the most powerful one.”

    Instantly I asked, “Why?”

    The answer was, “Well, everybody knows that?”

    I countered, “Huh? I have a boxed set of all the Universal horror movies, including Bela Lugosi’s ‘Dracula,’ and I also have a beautiful copy of ‘Nosferatu,’ and the subject never comes up. Does there exist somewhere a vampire wiki  that says older bloodsuckers are stronger than younger ones?”

    It turns out that in one of the many, many, many vampire book series, this is the rule. Older is better. And this somehow has become the accepted dogma.

    I was recently in a meeting in which somebody who didn’t seem old enough to shave insisted to a co-worker that because their company was required to be compliant with PCI, there was a definitive way for them to create policies, and he knew this because he read it in a book.

    Is there a RIGHT way and a WRONG way to create security policies? Is there a magic blueprint for how you should configure a security perimeter and subsequently enforce it?
    Nope. Even if you’re subject to SOX, or NERC, or HIPAA, there’s still no “standard” set of policies. Now, you could say that PCI or NERC spell out policies very clearly. But what they really do is tell you at a fairly high level what the requirements are. HOW You get there is a different story.

    HERE is what is important: that you HAVE a policy, that it covers all the security and compliance basics to which you are subject, that this policy is documented, and that the policy is ENFORCED. The details have to be there, but as the security guru, YOU are the one to devise them, relative to your organization’s needs. In my book, I recommend that dreaded last resort of scoundrels, COMMITTEES. But peer review is always a good thing. "Hey, guys, let's all put on the table what we think should be in our policy." Then you beat it up, vote on it, whatever. Find out what every corner of the org absolutely needs, devise a policy that covers all the bases, and where you can, you fit in the nice-to-haves. Then you document, implement, and enforce.

    Even then, policies aren’t necessarily carved in stone. Things change, right? BUT … if  there are changes, they must be vetted, run through a review, documented and agreed upon, and then OFFICIALLY made part of the new policy. That’s what makes your changes part of the “right” policy.

    And you Do want to be right, don’t you?