Navigation
The Black Book of Identity Access Mgmt
This form does not yet contain any fields.
    « No shirt, no shoes, no session | Main | Shameless plug: the IAM book is out !!! »
    Thursday
    Aug052010

    Security ain't for dummies

    My wife’s a math teacher. So years ago, she got REALLY REALLY freaking upset when they put out a Barbie doll that, when her string was pulled, uttered the words, “Math is hard.” At the time, my woman said, “Only a MAN could have designed such a stupid thing.” I wanted to reply, “Only a man could have given you children, or bought you a pizza last night,” but I wisely kept my mouth shut.

    But, y’know, there are people who make that Barbie sound smart. In the not too recent past, I received an email from a customer who sent me a capture of a screen that my company’s product had generated, asking him to reset his password. He wanted to know why it was doing that. I explained to him, “This is what we in the security market call a security feature.” His password was ninety days old, and the system was asking him to change it.

    He asked why we only kept passwords around for three months. I explained, our product only enforces the policies that your administrators come up with. Our product could use the same passwords indefinitely, but that’s not a good idea. In the meantime, I said he should take the matter up with his own admins.

    He went on to complain that this was an inconvenience. Yes, yes, I wanted to tell him, you have to invent a new, strong password, with upper and lower case, digits and special characters, once every three months. In fact, now that you’ve done it, the next three-month clock is ticking, so you’d better start thinking of the next one. Do you have any kids? Maybe they can help you. Or wait, let me suggest one that incorporates all those strong password requirements. Try this one: B0nehe@d. That second character is a zero, so we’ve covered all the necessary bits.

    This same customer, by the way, had previously asked why approvals were necessary. If we were enforcing role-based provisioning, we should be able to automatically decide who could or couldn’t get access to a given system. Once again, I explained that these were his company’s policies, and that our tool was simply helping them enforce those policies. We’re the toolset, not the carpenter. I also gave him examples of where human eyeballs on an access requests were good things.

    Security dictates that you compile a number of ingredients: defined requirements, the policies to fulfill those requirements, the tools to execute and enforce those policies, and the willpower and the BRAINS to choose the tools and use them wisely.

    Math is hard.

     

    PrintView Printer Friendly Version

    EmailEmail Article to Friend

    Reader Comments

    There are no comments for this journal entry. To create a new comment, use the form below.

    PostPost a New Comment

    Enter your information below to add a new comment.

    My response is on my own website »
    Author Email (optional):
    Author URL (optional):
    Post:
     
    Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>