Tag: saas

Down with federated provisioning

There’s been a bit of recent blogging activity about federated provisioning and SPML.  Having worked on both federated provisioning and SPML in a past life, it warms my heart to see this discussion.  Jackson, quoting the CIO of Education Testing Services, Daniel Wakeman, restates the observation that SaaS providers are providing when it comes to federated identity management.  This “major shortcoming” leaves service subscribers to fend for themselves in managing user lifecycle events like on-boarding and off-boarding.  Not acceptable.

That got me thinking – there really ought not to be a concept of federated provisioning.  Provisioning an application in the data center must be the same as provisioning an application in the cloud.  However, in the course of the conversation between James, Jackson, and Mark, it seemed SaaS applications and in-house applications were different from a provisioning perspective.

SaaS applications may be harder to provision and de-provision than non-SaaS application, but that doesn’t make them fundamentally different animals.  The point was made that SaaS apps lack a standards-based provisioning interface, an SPML interface.  The fact is the vast majority of applications, SaaS or not, lack a standards-based provisioning interface and this makes dealing with them very much the same.

Now there are two reasons that we don’t hear the same short of clamor about provisioning non-SaaS applications as we do with SaaS applications:

  • We’ve dealt with it so long that pain isn’t as acute
  • Provisioning vendors built an array of connectors, shifting the pain up a level, allowing companies to focus on the provisioning technology and not each and every application they want to provision

Provisioning vendors spent lots of time and money to build connectivity to traditional applications.  Lots.  And in doing so provided a bit of absolution for application vendors from their failing to provide a standards-based provisioning interface.  Having gone through all that pain and suffering, vendors are not eager to go through it again with SaaS applications, coding connectors to each one’s different web service.  Customers aren’t too keen on the idea either.

In providing SPML interfaces to their applications, SaaS vendors would do everyone a service.  Provisioning vendors could use their SPML connectors and not have to build to each SaaS application.  Customers wouldn’t have to write custom code to different service interfaces.

You don’t want that fired sales guy walking away with your customer list no more than you want him walking out the door with your pricing information.  To that end, there should be no reason why deprovsioning from an application like Salesforce.com is any harder than deprovisioning from LDAP.  Federated provisioning should not exist; there is only provisioning.

(Cross-posted from Burton Group’s Identityblog)

Compliance as a Service: Counter-counterpoint

Compliance as a Service – Counter-counterpoint

Matt and Mark have both responded to my response.  Matt writes:

Thanks for keeping us honest Ian! I would be pretty blind to claim that overall regulatory compliance can be solved with any IT solution (…or set of …or service of). But I didn’t make that distinction in my previous post. But, is that the basic point you’re making? …that IT compliance is a subset of overall Compliance? Or is there more to it?

Yes and no.  I do believe the IT compliance is a subset of overall Compliance, but that wasn’t my basic point.  My most basic point was, because Big C Compliance is so truly tied to people and process it cannot be delivered as a service.  The reason I responded to you and Mark about this was that I didn’t want the conversation to start off with a definition of Big C that was too limited and too IT-centric.

Understanding that big-C Compliance requires much more than IT controls, would it seem more realistic if we said IT-compliance-as-a-service? or IT-Audit-as-a-service?

IT audit/compliance can and should be delivered as a service.  And not just the tools and tooling for it, but ownership of the compliance state and risk as well.  To me this is a natural extension to Managed Security Services and companies like Counterpane and IBM offer this to an extent.

The main thing I’m wondering is if organizations would get value from an external party taking over the IT audit portion so that the org itself (who might be anticipating regulatory pressure) wouldn’t have to figure out which questions to ask, how to ask them, how to build controls to get the right answers, and how to prove that the answers are what they should be.

This is spot on and I believe this is valuable to companies of all sizes.

Why Compliance Cannot be Delivered as a Service

My friend Mark MacAuley can always be counted on to stir things up. He’s seen plenty of enterprise deployments and architectures and comes at problems with a combination of Yankee ingenuity and healthy cynicism. Over on Identitystuff, Mark writes about offering Compliance as a service:

The new frontier is CaaS – Compliance as a Service. Fixed cost, consistent automated reporting, a defensible model for implementing and showing transparency.

Although the intent of Compliance is good, in Mark’s estimation Compliance is 100% cost with no positive yield to the bottom line.

The trouble is that Mark refers to Compliance as if it is an IT service that can be delivered like outsourced help desk or security management. Compliance, the Big “C,” cannot be delivered as a service. The Big “C” is the interplay between people, processes, and IT systems to achieve the mission of the business in the context of regulatory and market pressures. It isn’t binary; it isn’t something you have one day and not the next. This dynamic interplay requires continuous measurement and feedback loops to ensure that deviations are corrected and, ideally, prevented.

Compliance is a matter of controls – instituting a variety of controls and then charting the business’ distance in relation to those controls at all times. Let’s take a simple common non-business example. When a cop pulls you over for speeding, you often get asked two questions:

  1. Did you see that speed limit sign?
  2. Do you know how fast you were going?

This is a simple example of controls in daily life. To track towards Compliance, first, you have to know about the control – awareness of the speed limit. Second, you have to be aware of your relationship to the control – how fast you are going. Finally, you, as a safe driver and responsible citizen, have to continually measure your relation to the control – keep your eye on the speedometer, unless you want a visit from auditors or enforcement agencies.

Expressing, understanding, monitoring, and enforcing controls CAN be delivered as a service. These services, including controls documentation and controls management, address automated and manual controls for IT and non-IT systems and processes. And it is the delivery of these capabilities as a service that can reduce the cost of compliance.

Matt Flynn get’s in on the action and provides a crucial point, if indirectly:

I think there are definitely organizations out there that would love to have a third party who is willing to be an expert and own compliance for them.

It’s people! Compliance is People! This is the other piece of the puzzle and as Matt says, it can be delivered by a third party. Service providers, with deep domain expertise, armed with controls documentation and management tools, can provide holistic compliance services, and with a little creative thinking, a bit of indemnity insurance, they can truly own compliance for an enterprise.

The Big “C” Compliance cannot be delivered as a service, nor by Santa Claus, not for all the tea in China. But that being said, compliance experts and expertise bolstered by controls management and documentation services can help organizations track towards Compliance and be able to adapt as any of the variables in the Compliance equation shift.

(Originally posted over on Audit Trail.)