We have met the enemy, and he is ...

In the last few months, Oracle’s been doing some joint presentations with a counter-terrorism guy. Everybody raves about his stories and background in figuring out who the bad guys are and where they’ll strike next. The idea is to anticipate their actions and nip them in the bud. He and I had a great chat about it. You can’t decide how to fix something until you figure out the exact problem, and he does it on a large scale. We discussed how it’s very similar to what we’re trying to do in IAM.

In the utilities arena, the big compliance beast is NERC, which mandates the protection and continuity of the electric grid. Identify your most important assets, then determine the type and scope of perimeter you will erect around those assets. Now, you might say that this is walling yourself up, and not proactively going after the bad guys who might assail that wall. But here’s where you do just that.

The Oracle Adaptive Access Manager (OAAM), a great product with a pain in the ass name, is access management on steroids. It’s not just policies; it can actually learn from user activity and help you build those policies. So in a standard AM environment, you set policies that say “people in this LDAP group can access pages in this directory.” You might look at time of day, and even origin IP address. This is what Oracle Access Manager does, and similar products like SiteMinder.

But what OAAM does beyond that is look for types of behavior. Volume. Transaction type. Movement. It will look at your IP now, and which IP you’re using ten minutes from now. Did you move? How far did you move? Did you start in New York, and end up in San Fran? Nobody moves that fast. You’re an impostor.

Are you the CEO? C’mon in. Are you the CEO but you’re logging in from home, and on a Sunday night? Hmm, you never do that. Give me a token first. I’ll even send one to your cel phone. Wait, you’re not using your normal device to log in. It’s a different laptop or smart phone. Here’s some security questions for you.

Wait, I don’t care WHO your credentials say you are, nobody has a legit reason to examine salary data on a mobile device. Denied.

Historically, do you download five files at a time? What about the other users at your location, or in your work group? If you’re suddenly doing something out of character for you or your group, such as downloading a thousand engineering specs at once, is it really you? Or maybe it IS you, but you’re quitting, and taking as much stuff as you can on the way out the door. So this activity needs to be shut down, and alerts generated.

These types of behavior can be put into buckets or patterns, which OAAM can examine when deciding if you’re good to go in a given session. In a lot of cases, OAAM customers don’t even set allow/deny policies. They’ll just turn the thing on for a couple of weeks to monitor behavior, and figure out what the policies should be. Maybe their users don’t access the system the way they anticipated.

OAAM can also learn changes in behavior. Maybe your workforce becomes more mobile. Maybe you’ve moved people around to different offices. They do more from home. It might automatically move somebody to a different bucket. And so on.

There’s so much to OAAM, it’s hard to cover it all here (there's lots more detail in MY BOOK). You might say, wow, what’s the downside to this wonderful piece of software? And here it is. It does so much, you may not want to do all of it. I don’t use 90 percent of the options on my phone. Novell used to beat Sun in a lot of LDAP deals way, way back when, with an inferior product, because most people didn’t use all the options in the more expensive Sun directory.

But OAAM is fairly unique in all the things it can do. It doesn’t just keep out the bad guys, it points them out to you. You want to fine-tune those policies, so that while you’re keeping the bad guys out, you’re not also punishing the good guys who have every legit reason to come in.

You can't spell "grid" without "id"

Even countries that get along with Iran aren't happy about tha country getting nukes. Well, maybe North Korea, since maybe they're getting tired of always being the worst trouble-maker on the block. Anyway, there are a lot of suspects in the recent Stuxnet worm, which seems to pop up in the systems of a lot of organizations, especially power companies, but seems to be primarily targeting Iranian facilities. The speculation is that is was spawned by some party who's unhappy with the prospect of the Iranians converting spent fuel into weapons-grade uranium.

There have been all sorts of hacking attempts targeting US facilities. Many of them appear to have originated in China, which is known to recruit, train, and support professional hackers. Luckily, the same set of security standards that are meant to help protect the grid from malfeasance, stupidity, and domestic hackers also serve as tripwires against foreign threats. These standards, of course, are incorporated into NERC CIP. The first part of that is the North American Reliability Council. The second part is the brilliant stuff they cooked up to secure the electrical grid. But everybody just refers to it as NERC.

I cover NERC CIP in detail in my book, so I won't go into that here. But in a nutshell, it requires that an electric provider create an inventory of their assets, both physical and virtual, then build a perimeter around them. The perimeter includes all manner of security protocols.

In the past year I dealt with one provider that says NERC is the concern for the plants themselves, and not the main holding company, because in theory NERC only covers actual electricity generating parties. But this is incredibly short-sighted, since the main honchos will be on the hook in the event of a disaster.

My two biggest engagements in the past year were with utilities, and that's for a very good reason.

NERC penatlies are butt-ugly, worse even than financial boo-boos, such as violations of FACTA. Why? Because if somebody steals a bunch of credit card numbers, you don't find out unless you're one of the victims, or it gets on the news. But if the power goes out, EVERYBODY knows.

Here's another grid acronym: SCADA. It's essentially the interface for managing the components of the grid. According to NERC, it's one of those things that shouldn't be web-enabled. But everybody does that very thing, because everybody is web-enabling EVERYTHING. I'm in charge of the plant, so I wanna be able to check on things from home on a Sunday night. Therefore, if you're going to publish it, for all practical purposes, then you darn well better secure it.

Identity management doesn't cover all aspects of NERC, but it covers an awful lot of it. Of course, IdM encapsulates a lot of different kinds of security, not ust logins and passwords. Authentication, authorization, behavioral analysis, and so on are all in the mix. You shouldn't be able to access or modify any security assets if your IP address isn't within an acceptable geographic range.

Think about it. Screwing with the financial grid can really louse up how things work. But crewing with the power grid can do the same thing, on top of causing civil unrest. Blackouts can shut down markets, retail, healthcare facilities, travel, and can even cause morons to loot and pillage, as we've seen several times.

It's being repeated all the time: the new frontier in war is in cyber-space. A lack of power tells the general public that the guys in charge aren't necessarily going to keep them safe. A solid IdM strategy is a good place to start.

A great way to worm your way into a NERC engagement? Ask them how their last audit went. Even the successful ones really, really suck.

What is your name? What is your quest?

I was recently helping an acquaintance re-enter their email service after she'd forgotten her password. Being that I'm one of the more computer-literate people in her circle, she figured I was the logical choice to call. She even suggested that, if she could not recreate her password, I could break into the service for her so she could retrieve her mail. I explained, if it was that easy, a whole lot of people a whole lot smarter than me would be doing it all the time.

"Did you click on forgotten password?" I asked.

"Oh, no, I didn't. What happens if I do that?"

"It will ask you your security questions. You must have set those up when you created the account."

In fact, she couldn't remember, but she thought that maybe somebody else had helped her set it up.

I had her click on "Forgot my password," and it indeed asked her some basics.

1) First pet's name

2) City of birth

3) Mother's maiden name

Sure enough, this got us in. And this is one of the things I cover in my book. The most basic requirement for a security question should be something that is easy for you to remember, but hard for somebody else to guess. It's that simple. Now, that's if you are serious about your own personal security. But now put on your admin's hat. Most people are freaking lazy. Even in corporate environments, where their email and other types of folders contain sensitive material, they don't like to put much effort into these questions. And that's when you get situations like this:

1) First pet's name?   fido

2) City of birth?  fido

3) Mother's maiden name?  fido

First off, you should NEVER let people create their own questions. You sould create a body of questions and let them choose from those. And those questions should be a little more challenging. Next, you should make sure the answers aren't ridiculous. Now, you cannot seriously validate the answers for an individual. One of your users might actually have been born in the town of Fido.

But what you CAN do, with the right technology, is ensure that those answers aren't too, too easy to decipher.

This is one of the things I've liked about Oracle Adaptive Access Manager (OAAM), a great product with a crappy name. It can enforce logic on the security questions' answers. For example,

- the answers can't all be the same

- the answers can't contain parts of the questions (my fave color is "color")

- the answers can't be part of the user's name

Sarah Palin's email got hacked during the 2008 campaign season because she (foolishly) made her security questions things that were easily Googled. She's a well-known public figure, whose personal info is all over the Net, and this is what she used for her security info. I find this completely mind-boggling. Or maybe not.

ID thieves don't take holidays

I recently tore up my knee and had to get a procedure done. I’m getting around a little, but mostly sitting and icing the spot where my meniscus used to be. My wife threw on a normally decent radio station which, for the Labor Day holiday, is playing working man’s tunes. This translates into utter crap. Gary U.S. Bonds. A really bad Springsteen tune. Rush. And that laxative of all pop singers, Huey Lewis. I finally crawled over to the radio and put on WXRT, and they’re currently playing “Comfortably Numb,” which is what I need right now.

I hope everyone who’s been busting their cans is having a decent Labor Day holiday. And I hope those of you who have been struggling to find a slot are keeping it together. When I first entered the job market after college, we were in the middle of an economic mess, but nothing like this. I built one house and sold another in this disaster, and I’ve been relatively lucky, although it was still difficult.

In our current train wreck, we have to be more vigilant than ever regarding identities. The occurrence of successful id theft, and the amount of money lost to id theft, had been declining drastically. But with the downturn, it’s kicking in again in a big way. And it’s not just traditional bad guys. Plenty of desperate people are trading on sordid opportunities with others’ identities, taking advantage of security holes. I hate to say it, but stats show that lots of identity crimes involving credit histories, names and other personal data originate with friends, relatives, and acquaintances.

There are tons of tips on how to avoid it, and still there are no guarantees. When you hear about municipal officials posting people’s SSNs and other data on public sites, you shake your head and wonder where their brains are. But there are some basics that I’d like to remind you of, based on things that have happened to acquaintances in the recent past.

Limit your use of debit cards versus credit cards. Less liability.

Phishing. Holy crap, there are still people who fall for this garbage. Your bank will NEVER send you an email asking for personal info. If they do, and it’s really them, then it’s time to get a new bank.

Update your passwords. Rotate the things. Regularly. Even if the organization you’re dealing with doesn’t make you do it, take it upon yourself to change that password. You never know when a keystroke logger has grabbed your tapping. Stay ahead of them.

Guard your Social Security number. I’ve been asking people for a while now, “Do you really need that?” And I’ve been surprised when I’ve been told, “Nah, not really.” But they ask for it anyway. Sometimes you can just give people your last four digits. It doesn’t hurt to ask.

Monitor. Periodically check your credit. And look at your card statements every single month. This is why I got married. Well, it’s one of the reasons, anyway.

If at all possible, enjoy the holiday, do something for somebody who isn’t able to, and be good to each other.



And nothing BUT the truth

When I published my last novel (www.houseofhush.com), even people who liked the damn thing commented, “You’ve got all these strange characters gathered in one place. Is that realistic?” To which I replied, “It’s based on a real place, where the people were even stranger than my characters. If anything, I downplayed the strangeness.” Which was absolutely true. Reality is often stranger than fiction. An Olympic skater’s boyfriend hires goons to hit another skater in the knee, then the first skater ends up on a celebrity boxing show where she kicks the snot out of a woman who got famous for accusing the US president of sexual harassment. Who can make that crap up?

In my recent masterpiece about identity and access (available from McGraw-Hill) , I have a whole lot of little grey boxes that pop up here and there, with stories from my experiences in the identity and access world. These are labeled as “true stories.”  I’ve had a few people ask me, “Are these really all true?” And in fact they are. I mixed up a couple of things, to save some folks some embarrassment, and in one case, I changed one tiny fact because the truth was more disgusting than what I printed.

One of the sadder ones was about the guys who got fired for being too-early adopters of a product that turned out to be a good one, but which at the time was not. I remember the day I was pumping gas into my Nova, and receiving a call from one of those guys, who was literally crying, thinking he would be canned any day. I had told this particular customer “don’t be the first kids on your block” to own this thing. But they were. In fact, they did just about everything you can possibly do wrong in running their project, and buying a 1.0 of a new directory was the final nail.

(There are actually LOTS of ways to muck up an IAM project, and here are my top ten.)

But one of my favorite true stories in the book is about an old employer of mine, where, because of badly written software and terrible QA processes, they sent out a bunch of letters to people who were too dead to read them, and all the letters were essentially addressed to

Mr. John Q. PublicDeceased

The old saying goes, comedy equals tragedy plus time. It’s only funny now, two decades later.

So here’s my point for today: whatever you build, TEST IT. Run it through a few paces first. Beat it up, before it beats YOU up. These aren't just simple use cases, where you want to make sure two numbers add up properly to a third. These are identities, and they're not just data to hold and process, they are precious to their owners. You're just the caretaker. TEST, then test again.