Navigation
The Black Book of Identity Access Mgmt
This form does not yet contain any fields.
    « The online waters can be rough | Main | Airline sec is like IdM sec … and NOT »
    Sunday
    Oct232011

    RISK-based sec isn’t perfect … that’s why it’s called RISK

    Being a parent means worrying a lot. Early on, you can control all the risks. This means keeping the basement door closed so the toddlers don’t crawl down the stairs headfirst, and not leaving your beer on the coffee table. The older they get, of course, the more risk is out of your hands.

    I let my kid drive places, increasingly far from home, and at odder hours. For work, to hang with friends, stuff with school. It scares the hell out of me every single time. I trust my very intelligent, resourceful offspring. I just don’t trust the rest of the universe, which is full of devious, stupid, drunken, boneheaded, and otherwise mouth-breathing hillbillies.

    But this is how your children learn, and grow. You assign a certain amount of trust, and you learn from what goes right and what goes wrong. And even after you learn everything you need to learn, bad stuff can still happen.

    You can’t just say, this activity is assigned this risk score. There are SO many variables. Driving to school is one thing. But if it’s foggy, or icy, or dark out, or a special occasion when more drunks are on the road, these add to the calculation. The absolute safest thing is to say, “No. Just stay home.” But obviously this kills the interaction, and earns me the death stare and the question, “Am I in your will?”

    It’s the same thing with IT security. Put all your data on a single server, don’t plug it into anything, and nobody can hack it without a thumb drive. But then your customers, partners, vendors, employees and other interested parties can’t interact with you to generate revenue.

    You can turn on absolutely every single security protocol there is, but it would slow things up considerably. El Al, the airline for a country literally surrounded by enemies, has a great security history. The price is lots of searching and lots of questions.

    I’ve been dealing a lot with adaptive authentication lately, including Oracle’s version, OAAM, and one of its competitors. These are great tools for calculating risk based on multiple factors, not just a flat score assigned to particular resources. Sure, the resource itself may have a risk score, but that’s just one of the items to consider when calculating the risk of a TRANSACTION, and deciding how to respond.

    “You want to look at employee salaries, and you’re the HR person, and it’s 9 am on a Monday and you’re inside the firewall? Okay.”

    “You want to look at employee salaries, and you’re the HR person, but it’s 7 pm on Monday, and you’re at home? Well, okay, but maybe I’ll ask you your security questions.”

    “You want to look at employee salaries, and you’re the HR person, but it’s midnight on a Saturday, and you’re on a mobile device? Forget it. And by the way, I’m automatically opening up a case and sending out alerts, you scumbag.”

    That’s why it’s called Adaptive Authentication. It has to adapt to what’s being asked. Who you are, what you’re asking for, when you’re asking for it, and from where. It might also look at what you normally do. A great use case for AA is the guy working for an American electronics company, but out of an Asian unit. He normally downloads a handful of engineering specs a week. But on a weekend, he’s downloading THOUSANDS. AA shuts him down and sends out an alert. Turns out he’s changing jobs and taking some IP with him.

    Quite often, dedicated employees do lots of funky work at funky hours, even on vacation. I took my box to Niagara Falls. It happens. This is why you want your system to take into account ALL the possible factors, then employ the policies you’ve set up for every occasion to calculate the risk of the intended action and then do one of the following:

    1)      Allow

    2)      Allow after additional info is requested

    3)      Allow after additional info is requested but still send out an alert

    4)      Disallow

    5)      Disallow and alert because obviously somebody’s attempting something really bad

    By the way, OAAM can also operate off historical data. Do you normally make these kinds of requests? Do other people in your group or at your location do so? If not, is this a higher risk? If it’s going to be a regular thing, do we adjust what’s considered the norm, going forward?

    NOTHING is ever totally safe. It’s called risk for a reason. But you’re in charge of security for an even better reason, right?

    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>