Hey bartender, I'll have another (access permission)

Recently I was in Columbus for some meetings, and walked across the street from my hotel to a better hotel which was better because they have a bar. I sat down and ordered the local soda pop. The lovely bartender bartender tapped her touchscreen eight or nine times, then swiped her card through the reader, then tapped twice more. And only then could she pour me some pop.

This is a great example of poor usability. It shouldn’t be that hard to serve, uh, pop. Too many touches, taking too much time, and the more touches you need, the more likely you are to make mistakes.

Oracle Identity Manager 9.x was very good, very stable, very popular. When it was time to build the next version, Oracle brought in third parties, partners, field people (like me!), and others to beat the thing up for usability. One of the early reviews of the alpha was, “too many clicks.” It took too many touches to perform simple provisioning tasks. So the remedy for that was improvements to the UI as well as the logical flow.

Historically, various identity startups have had some very flashy GUI’s, but not a lot of muscle on the back end. Oracle has had less flashy, possibly clunkier front ends. But last year they released an excellent new interface, and have continued to upgrade it. Not only is there a powerful back end to handle a broad range of use cases, in large volumes, there’s also an interface that allows administrators to easily manage users, resources, roles, and the rules that match them all up. It also makes it far easier for end users to request and track new resources.

So the moral is, I want to get there from here, and I want it to be as easy as possible. And that includes getting access.

NO MORE MR. NICE POLICY

I’ve stopped being patient with people while boarding planes. Recently, while stumbling onto a puddle-jumper to Columbus, the guy ahead of me stopped to get something out of his backpack, and seemingly fiddled with it for minutes. He finally put the thing in the overhead, before opening it up again and to dig some more. Then he pulled it back down OUT of the overhead to once again search. I finally said, “Pal, why don’t you do that out of the aisle, so everybody else can get by?” He gave me a nasty look, but screw it. “There’s a crowd back here,” I told him, and essentially shoved past him.

               There’s a reason for rules, and for enforcement. It keeps everybody moving forward. If we allow anomalies to hold things up, none of us gets anywhere. This is why I’m a huge believer in AUTOMATION. If you have policies and procedures that must be satisfied, in order to keep things moving, in order to keep people in the box, in order to keep you and everybody around you out of trouble, then you should follow those policies, and even st up a little robot guy to guarantee compliance. In the identity governance world, that means workflow.

               You create policies that say, “Once the warm body hits the HR system with a status of EMPLOYED, give the guy an email address, look up the other stuff he should get, and give it to him. Make sure that’s ALL he gets, but make sure he GETS it.” This means that warm body is enabled, with least privilege, so he’s productive, but not dangerous.

               When something changes, like that warm body gets transferred, or terminated (thus becoming a cold body), your workflow should make sure those privileges change or just plain go away.

               When you first put this stuff in place, you might arrange for workflow to simply NOTIFY, that is to send out emails to the people who must make stuff happen. “Hey you, give that guy an email address.” This way you can test out your logic, instead of finding out the hard way that your automation hasn’t been misconfigured to give a guy nineteen email addresses.

               Then to make sure you’re keeping an accurate inventory of that guy’s stuff, you ask for feedback. “Hey, did you give that guy an email? Didja? Didja? Didja, huh?” And you keep bugging until you get that feedback.

               And when you’ve gotten your logic sorted out, you complete the automation by installing CONNECTORS, sometimes called ADAPTERS, sometimes called MAGIC LITTLE GUYS THAT DO MORE STUFF.   If the email request is approved, then the workflow asks the connector to automatically create an email account. Then later the Unix account, the LDAP account, and so on.

               I can’t believe the customers I run into who OWN these kinds of systems, and don’t use them. They might as well put in a help desk app for provisioning. That would reek, yes, but using your provisioning system for notifications only, forever, is like putting your kids in the car and then PUSHING the damn thing to soccer practice. Recently I advised a client with an identity product that competed with mine to USE the thing. All they do is notify. What’s the point? You’ve got an elephant gun, but you use it to hunt flies (not that I’m advocating shooting elephants, so spare me the angry emails).

               Automation enforces your rules, keeps things accurate, keeps an audit trail, and saves you work. This isn’t like the collection of useless apps on your smart phone that you downloaded and used exactly once. This is good stuff, necessary stuff. Make it work FOR you.

Encore for OOW: how to pass a security audit

This is a reprint of an earlier post, for the sake of the nice people who sat through my session at Oracle Open World.

As promised, here’s my quick and dirty guide to the inventory of digital and physical assets you need to have handy whenever compliance or security auditors come calling. I have some lovely and grotesque true stories behind some of these, but we’ll tackle those another time. This is indeed the Cliff’s Notes version.

These are the things that auditors will ask for directly, or in some cases I’ve included items which, if you have them, you will indirectly provide something else they’ll bug you for.

Inventory of assets: servers, app servers, APPS, databases, directories (LDAP), load balancers, firewalls, web servers (including plug-ins), identity-authentication-authorization mechanisms, and so on. In other words, the systems that run your business as well as the systemsthat PROTECT those systems.

Authoritative sources: the things that say what you can have. For example, “If a user is in the HR system with a status of employed=Y, then they automatically get email and a phone.” HR and payroll systems are common authoritative sources. It’s common to have more than one, but bad practice to have MANY. By the way, a person cannot be an authoritative source.

Policies, processes: how things happen. A policy is, we make users change passwords every sixty days. The process is, our IAM system is configured to enforce this policy. How do you enable and disable users. How and when are reports generated. And CHANGE MANAGEMENT. Promotions, demotions, transfers, and the really big one, terminations, whether nice or for cause.

Legacy systems: they’re often left out because the cranky old guys who run them don’t like it when you include them in IAM architectures. “You’re not installing that %#^$ on MY box, Junior,” a guy told me in Indy once.

Dev and test procedures: how do you launch new apps or systems, whether homegrown or store-bought? Do you test code? Penetration testing, for example. If you use production data for testing, do you MASK that data to conceal PII for dev and test teams?

Data security: are you encrypting sensitive data? I can’t believe the goobers who end up in the news when they allow the escape of data that was in the clear. It needs to be scrambled in production, over the wire, and in backup. And how are you auditing? Do you watch who does what with the data? This includes DBAs and other privileged users. Do we not trust DBAs? No, we love them to death. But we worry about their accounts being compromised. And yeah, once in a while one of them DOES do something naughty.

Segregation of Duties: how do you develop those policies, how do you review them, how do you enforce them.

Privileged users: do temporary duties get an end-of-life? Do you audit what privileged users do? Do you watch service accounts to make sure they ONLY do what they’re supposed to do?

Reporting: is anybody tasked with reading exception and other reports and looking for anything actionable? Do you review alerts, even the non-critical ones? They often point to potentially bad behavior early on.

Exceptions: are they documented? Most of them are acceptable, if you are aware of them AND you’ve documented them. “It’s in my head” is not documentation.

Certifications: access reviews, in other words. How often do you conduct them, and do you take action against them. And make sure you’re not just rubber-stamping people to keep existing access without an actual review.

Disaster recovery plan: in chaos comes opportunity, often for bad guys. A customer of mine copied live data to an unsecured machine, and bad stuff nearly happened, while they were attempting to get back online after a meltdown.

Threats: do you know yours? Are people trying to hack your grid, steal your credit card info, muck with your servers? Have you identified your most likely enemies? Because all this leads to …

Risk assessment: How do you determine risk? Do you grade it (here’s a yellow alert, here’s a red alert, etc.)? Risk must be calculated, and re-calculated, dynamically. Also transactionally. You might assign a risk score to a privileged user, and also to a privileged app account. But don’t forget the other factors. The trusted CFO looking at financial data is a little riskier if he’s doing it at 2 am on the weekend from a mobile device. Is that really him?

DOCUMENTATION: everything needs to be captured. Everything I just talked about needs to be in a doc, or set of docs. Don’t EVER let an auditor tell you something about your environment you didn’t already know. It’s what auditors call “proof of compliance.” All the security and compliance in the world are meaningless if you can’t prove it, at least in terms of an audit.

There is WAY more to this subject, of course, but these are the high level must-haves. If you’re really sweating your audit and/or the aftermath, then it’s probably well worth your while to bring in help to take a pre-inventory and get you on the rails. Failing an audit is costly and embarrassing. It brings me a lot of business, but at the expense of my customers. Don’t be one of those guys.

Future-proofing your apps

Remember the Ziff socket? It was this nifty idea that when you bought a desktop computer containing such a socket, you could upgrade your CPU later by plugging in, uh, something to this socket, and you would be another few MHz more powerful. You wouldn’t have to keep buying new desktop boxes for years. Turns out, well, that didn’t work so well.

And do you remember the original promise of C? Write it once, and it’ll run on anything. You might have to recompile it on different platforms, but you wouldn’t have to rewrite it. And yeah, that didn’t work so well either.

Well, I think I’ve finally found my solution to keeping my apps usable, through myriad changes in my environment.

I deal a lot now with the Oracle API Gateway (OAG), an unfortunately-named thing (formerly called the Oracle Enterprise Gateway). It does a lot more than protect enterprise APIs. It’s sort of like calling your Lincoln Towncar an Adequate Trunk Space. But I digress.

Starting out as an XML gateway, OAG does very much more. Sure, it still inspects XML for bad payloads, but it can also handle many other protocols, checking for poisoned packages, evil documents, and other kinds of attacks. It can redact data in both directions. It can also enrich that data, adding values en route. It can perform intelligent routing.

OAG can be registered as a web agent for Siteminder, or an AccessGate for Oracle Access Manager, thus enforcing authentication and authorization policies that have already been created. Why reinvent the wheel?

OAG can also throttle traffic, to prevent DOS attacks as well as enforce SLAs for subscribers.

Here’s where I think the real value in this thing will be in the coming years: serving up and protecting enterprise APIs. So do the product managers at Oracle, which is why they slapped that name on it. If you want to make your web services available, but in the securest possible way, you can publish them through OAG in virtual form. Much like Oracle Virtual Directory lets you show to the world only the LDAP schema you wish, rather than the actual schema or database or web service (or combination of same) the data actually resides in on the back end., OAG provides the ability to expose only the plumbing you wish.

So again, just as you can map changes on the back end within OVD, you can map changes on the back end within OAG. If your web services now require an additional parameters specifying origin of request, you might have OAG fill in that parameter, provided it can identify that origin. Now those requesting clients don’t need to make any changes to how they make calls.

And here’s perhaps the biggest way OAG can protect you from having to change how you do things on the other side of the app server. It can modify protocols on the wire as well. A few very short years ago, we were all talking in SOAP as a common protocol. But with the explosion of mobile devices, the heavier SOAP has given way to the skinnier REST and JSON interfaces.  But wait, all my back end stuff still expects SOAP. Fine, so have OAG transform those REST or JSON calls to SOAP on the fly (after it’s checked for any possible badness, that is). Your web services get the same old request types, without the need to retrofit them to new models. In fact, because of the ability to transform messages, multiple clients might still come to you with multiple protocols, and you can translate all of them.

When somebody invents a new protocol that actually gets adopted (I’m currently working on JAML, or Jeff’s Asinine Markup Language), you simply have to fit OAG with a new filter that understands that protocol, so it can receive those calls, then return responses in that same language. The logic, the policies, the security, all remain in place.

Whether it comes by plane, by truck, by wife, by visiting relatives, beer still gets cold in my fridge. The protocol changes, but the back end remains the same. That’s my metaphor, and I’m sticking to it.

Stay kept up, or get swept up

I might have written about this before, but in case I haven't ...

I was with a salesguy a while back, a very, very smart man, which is hard to say when you hang around salesguys as much as I do. They're all kind of shifty looking, don't make a lot of eye contact, and they make you eat Panera Bread a lot. That's because Panera makes very handy boxed lunches that are easily packed into big bags, and it's all very easy to carry. I like Panera, don't get me wrong. My wife loves the soup they make in the loaf of bread. But man, I eat a lot of Panera. Every single meeting, there it is. 

Anyway, I digress. We were at this meeting, discussing database security, and the deputy CISO introduced us to his consultant, who was in charge of their DB sec initiatives. We talked about encryption, and then data masking, and then I asked about their strategy for battling SQL injection. Oracle has a killer DB Firewall for that. The consultant looked at us rather strangely, and asked, "SQl what?"

A guy who's in charge of db sec, and he didn't know what SQL injection was. I very politely, and without getting violent, explained to him what SQL injection is, how it's the hack du jour, how all the possible ways a bad guy might chop his way into your system are only the precursors to SQL injection, which is how the data, once uncovered, is finally harvested. 

Back in the rental car, the salesguy and I had a conversation that basically went like this: how do I get one of those jobs, where I can chage maybe $200 an hour to not know my subject? Being in charge of DB sec without knowing SQL injection is like saying you're in home security but don't know what a lock pick is. 

"Security" is a very broad subject, which is why there are so many specialities. I'll admit, I am a bit of a generalist, although I can get pretty darn deep on a lot of security subjects. Identity governance, compliance, audit support, authentication, authorization, fraud detection and prevention, single sign-on, social and mobile security, certifications, and THEN we get to database security. 

Encryption, data masking, data labels, SQL injection, segregation of duties, audit trails, etc.

It's a lot to know. So how do I know it? Well, for one thing, I'm old, so I've had the time. I also retain a lot of facts, which is why I'm a whiz at crosword puzzles. But my version of SQL injection, the way I harvest the data, is that I READ. I take the time to educate myself.

Is this stuff utterly fascinating? is it white knuckle reading? HELL no. But it's what I do for a living. And security is definitely a lot more interesting than a whole LOT of "security" subjects out there.

If you don't know your subject, if you're in charge of any aspect of security at your organization and you don't understand the threats and the possible solutions, then you are WORSE than not helpful. You yourself represent a risk. Because somebody in the chain of command is depending on you.  

I'll be speaking at Oracle Openworld next month, and looking forward to it. I don't drink much on the road, but I always EAT too much. One night at last year's OOW, I did three dinners in one night, because of the customers who wanted to meet up. One of my customers is presenting this year.

WHY do people come to OOW? Because it's a chance to LEARN. And there's a lot to learn. When you can attend an event like that, take the opportunity. But sure, it's not cheap, and you have to get the time off to do it, unless it's part of your job. Alternatively, take the time to READ, to LISTEN, to LEARN. 

Every time something new gets invented, some jerk figures out how to corrupt it. The internet is a wonderful thing for personal and business and social interests. It's also a super highway for creeps and crooks. I always say, if some smart geneticist bred a goose that laid golden eggs, the following week somebody would weaponize it. We have to at least try to stay one step ahead of such people.

Read, listen, learn. Your organization's well-being, and your job, may very well depend on it.