Death of the Service Account?

I love a good metaphor. In a previous post, I compared a provisioning system that does notifications only to a pickup truck that you push around instead of drive.

So what is a service account ? It's like your mom who does the laundry for everybody in the house, and all she expects is a bouquet on Mother's Day and a card, you ungrateful bastard. You log into your browser-based GUI, pull up a page, fill in some fields, and click submit to make an access request.

Then a web service takes over, and makes the appropriate entries in the database and directory on your behalf, with its own context. You have no account on the database necessarily, and if you did, you wouldn't have enough rights to do the job anyway,

There are benefits to this architecture. Fewer accounts to manage that access the database, and it's not a simple thing to propagate identity from the GUI all the way to the tail end.

BUT ... there are also drawbacks. If you want to truly examine the entirety of a transaction as it relates to a particular user, you need to correlate that user's activity against the portion of the service account's activity for that user's id. Messy, especially when you need to do it across all users and their transactions.  And the accounts that do the actual work are obviously created with more limited abilities than an omniscient service account that can affect ALL users.

So then the issue becomes, how do I get my id from the web page all the way through the service and ultimately to the database?

I've seen people do a handle swap, so that their id gets pasted on to the database transactions. But it's not always easy.

Well, now there's a way to do it within the Oracle stack.

Oracle now has as part of its security bag the Oracle Enterprise Gateway, or OEG. I can't wait for them to put OEG R1 on a piece of lit, and then we'll be calling it Ogre).

It has the ability to take that user session, re-authenticate it across services and even different protocols, and pass the proper context all the way through to the database and/or directory. If necessary, you don't even have to create ALL those accounts in the database, but actually use a separate directory, such as Active Directory, to authenticate against the DB. But now you've got straight-through auditability (f that's a word).

But wait … your DBAs have better things to do than manage user accounts. Icky. Creating and managing them. Resetting passwords. Handling the compliance aspects. So how to do it? Enterprise User Security, or EUS. The best part about this acronym is that it doesn’t have an O in front of it. It’s a way of provisioning to databases, handling policies, and managing passwords. You can map enterprise roles in it, and provide users with those roles simply by adding them to an AD group. The details are a post for another day.

OEG does a whole lot more than what I just said, of course, which I'll also discuss soon. But now instead of always bugging Mom, you can do your own damn laundry. And you'd still better remember the flowers.

USA! USA! We’re number … what?

Americans like to think we lead the free world in everything. And for many years, we did. “Made in Japan” used to mean cheap and crappy. “Made in China” really didn’t, until lead started showing up in the baby formula and the drywall. Those are the growing pains of capitalism, I suppose, and I presume they’ll get quality control under, uh, control. We invented the Internet, the browser (civilians don’t really understand that the Web isn’t all there is to the Internet), the assembly line, the atomic bomb (oops), Heather Locklear (in your face, Putin), and Lindsay Lohan (double oops).

But the USA has been dragging on several fronts for years. Manufacturing has been drying up like crazy, because it’s actually cheaper to import stuff by boat than it is to build it right here. A whole lotta innovation is coming from overseas. Other countries even take stuff invented by Americans and figure out how to launch it commercially, then sell it right back to the states. What the hell!

Another place the USA lags is in computer security. More than ten years ago, I had a HUGE customer that was bought by a German parent. The Germans had their own security standards that dwarfed those of their child companies. A big component of it was the use of tokens, plus digital signing. The Germans wanted non-repudiation of every transaction. Accountability. And this was pre-Enron, pre-Andersen, pre-shred-a-palooza.

Asians, Australians, Europeans, Indians, they all came up with security standards pre-dating Enron, and the stuff they came up with AFTER Enron were still better than those in the USA, even though Enron was a uniquely American economic disaster.

In India, they enacted a data protection law that was so stringent and so nasty that people went to jail, almost immediately, and in fact there were demands to back off a little. Those guys were not screwing around. In the USA, HIPAA was enacted in tiny little stages, with lots of warning, and even then the penalties amounted to a slap on the wrist. PCI can be ugly, but it’s not ugly enough, given the awful damage that can be done to people if their credit and other data escape. Contrast these to NERC, at least, and you get the equivalent of a sound beating with a stick.

Once again, the Germans are in the forefront. They build better cars, and they build better privacy laws. The European Privacy Directives are pretty good standards already, and in fact I use them as my privacy model in the compliance section of my book. I have a European client that is getting beaten up by their German contingent on privacy. No screwing around here. If I could summarize the model over there, it’s “collect only the data you’re supposed to, expose it only to the people who need it, use it only for what it’s meant for, then get rid of it.” No selling it to telemarketers, so analyzing it for other purposes, no keeping it around just in case you think you might want it later. Whatever you collect, put it in the right bucket for the right period of time, then it gets irretrievably dumped.

Maybe I admire the Germans’ attitude because I’m mostly German. But really, I deal with my clients’ audit requirements all the time, and the healthcare guys, where the data SHOULD be in a lockbox, seem to get away with murder. Other people skate by because even after a slap in the face audit, they only have to provide a letter indicating that they were at least semi-aware of their deficiencies, and they promise never to do it again.

Sorry, USA, but we’re way behind on green energy, making stuff, educating our children, and securing our data assets. Time to buckle down.

Happy Authoritative Source Day

My life runs on a very precise identity and access management system. All the components, definitions, and resources are there to get me enabled, schedule my activities, and provide feedback.

My authoritative source assigns my roles:

• ·         driver
• ·         payer
• ·         pancake maker
• ·         shoulder for reclining 

My authoritative source assigns my tasks:

• ·         make pancakes
• ·         take out garbage
• ·         pick up kid from track practice
• ·         listen to interminable story about somebody her mother knows

From my authoritative source I get analytics:

• ·         “How long has this been in the refrigerator?”

and alerts:

• ·         “You are not wearing THAT to the funeral, are you?”

and audit reports:

• ·         “I can’t believe you wore THAT to the wedding.”

My authoritative source approves my requests, while providing context to complete the transaction:

• ·         “Fine, but don’t you dare get drunk.”

Naturally, I am required to provide proper credentials for access:

• ·         Dinner
• ·         Movie
• ·         Take out the garbage

My authoritative source has spawned child processes, one of which paints and plays guitar and sings like an angel, and another one who is a genius whiz at crossword puzzles and starts college in the fall.

My authoritative source ensures that I am properly provisioned with everything I could possibly need to get through my morning, my day, my week. In this way I am not lacking food, beer, clean clothes, attention, affection, or advice that I didn’t even ask for but will get anyway.

My account was in fact transferred more than two decades ago from my original authoritative source, who now spends her winters in Florida and taught me to be a relatively good person. I have been lucky enough to have had, for my entire life, two fully secured, non-repudiable, certified authoritative sources with complete integrity, fallback capabilities, and unconditional love.

Happy Mother’s Day, Lena and Mary.

auto-pilot provisioning

I've been hanging out at a couple of clients where they have pretty decent identity products installed. They can open up user accounts, they can look up the status of those accounts. They can run a handful of reports.They even use workflow. And what does the workflow do? It sends emails that tell system admins to manually create, modify and delete accounts.

WAAAAAHHHHHH !!!!!  Holy crap, what good does that do? I see way too many of these. What is the point of having a workflow-driven, policy-based structure in place if all it does is NOTIFY? You could hire a monkey, stick his ass on roller skates, and save yourself the dough. It's the same as buying a pickup truck, loading it up with the furniture you need to move, then PUSHING it down the street. Ja forbid you turn the key and make the engine do the work.

So one client has recognized this shortcoming and specifically wants to automate. There's the key word: AUTOMATE. If the requesters have to tell the system who the approvers are, and the order they must approve, then again, you're wasting the electricity if takes to run IdM. Wait, there's another key word: POLICIES. The policies you create in your system, THOSE are the deciders. The policies decide who can and can't have something. They also decide who the deciders are. Rather, the approvers. 

Oracle has this thing called Database Vault. IT can create realms of security, like database firewalls. If you have this role, you can get at this section of data. Cool. Then Oracle went out and bought a thing called Secerno, which does the same thing, only at the perimeter. You can't send in this kind of query because I don't like you. Before the cycles even get wasted on the database engine, the outside db firewall stops the bad SQL statements. Okay, so your policies are like this. Before an approver even receives an obviously bad request, it's been stopped by the policies, so that the approvers only get the iffy ones. At the tail end of the policies that accept, route, and ultimately approve proper requests, the AUTOMATION also talks to the endpoints and says HERE, I've got a live one for you.

Automation and policy work hand in hand to make your IdM system worth it. If you're using a help desk system and its inherent ticketing, or a non-automated IdM thingy, then you have WASTED YOUR MONEY. I replaced a halfway decent Novell identity system once where I asked, "While I am happy to do this thing for you, I would like to know what you didn't like about it." And the answer was, "We never used the workflow." To which I replied, "Well, why the hell NOT?"

Automation. Policies. They are worth the time you put into defining and punching them in. That is to say, if your company's money and efficiency and user base are worth it. If they're not, well, then forget everything I just said.

That's not my job!

My rotten kids are forever pointing fingers at each other over whose turn it is to help with laundry, or load the dishwasher, or give the dog an enema when he’s having tummy trouble. Actually, we don’t do that to the dog anymore, we simply make him watch that show with the Kardashians, and it has the same effect.

And the reason I bring this up is, it JUST came up in a partner discussion over compliance. We were chatting about which type of product to use in a particular situation to protect data from prying eyes. This subject has arisen on several occasions, this time in relation to compliance. And what we debated was the best way to prevent unauthorized access to compliance-related data. So imagine these options:

I can control access at the identity perimeter, meaning the point at which users authenticate to the proper role to access the data in question. I can also apply policies for authorization, meaning putting rules in place to determine which roles contain the correct privileges for accessing that data. This is a classic case for RBAC. Of course, this presumes that these policies then grant access to the functions which themselves access the data FOR those users. If we’re talking about the Oracle stack, for example, I’m using OIM to provision roles that are maintained in OIA, and using OAM for basic auth and AZ. I might also use OAAM for stronger auth, and even OES for fine-grained access control.

The second option is doing this at the database level. I can create database level roles in EUS. I can create realms of protection in Database Vault. I can employ Data Masking, Data Labels, and the Advanced Security Option, for encrypting (and exposing) data down to the column level, to only those souls fortunate enough to have privileges.

Which is better? This is what I was asked. So here’s the answer. It’s really hard to do business-oriented access control at the database level. It’s not HR-friendly. And you really, really, really have to understand the database’s relation to the individual business functions. But if you ARE able to establish those relations, and you have that understanding, and you’re talking about very critical data, then database security is airtight. No matter what programs a hacker has compromised, he can’t get past that database level wall. It’s the last trench dug by the defenders.

Auth and AZ protection, naturally, relate directly to the business. RBAC allows business people to dictate business-logical security. It’s certainly easier and more natural to maintain than database security.

Ideally, you’d have both. But the expense is most likely prohibitive for most organizations to HAVE both, at least simultaneously on the same apps. You might apply database security in some areas, and access control in others.

So the correct answer is ….. it depends on who’s responsible for it. Who will have the job of maintaining that security? That’s how you decide which to buy and deploy.  With great power comes great responsibility, wisdom we were given decades ago by Stan Lee. If I’m in charge of security for a subsection of the assets, not only must I protect it, I must also ensure access to those who need it. If I’m doing db-level sec, I need to make sure that the users AND the processes that need access can get it, otherwise I’m in business-prevention mode. But if the guys building the web services have done their jobs right, I may only need to provide database-role-level access to those processes that are acting on behalf of the users, and those services are only providing user id’s as context. Meanwhile, business-oriented security staff can build access policies based on users and roles and business context. But again, who’s in charge of security? Who will own it? Who will maintain it?

There are many advantages AND disadvantages to working out of the house (when I’m not on a plane, that is). One of them is having a con call to jump on whenever it’s time to load the dishwasher. “Hey, kids, YOU load the dishwasher. I’ve got to go pay the bills.”