Security convergence

There's a convergence about to occur in the enterprise security and business space; Physical Access Control (PAC) and Logical Access Control (LAC) have been separate islands within most organizations. The IT dept usually owning the LAC systems and the PAC side owned by some business person responsible for overall facilities. As new governance standards and regulatory compliance demands are emerging. and overall improved risk mitigation is required, I've noticed a pressure arising within most orgs to converge these two worlds.

It's actually quite amazing when you get a bunch of engineers from the PAC world in the same room as the solutions architects we have in the LAC "galaxy"...it's a like watching a kid who's lost his parents in a foreign country and finally finds them again. We did this a couple months ago with some local engineers from Honeywell and my software engineers...we started the meeting and most of the techs on their end were sitting there with that disgruntled look on the faces...clearly wanting out ASAP (the MD of Honeywell SA I know and he dragged some of them to the meeting).

Someone had to start the gig going so I did... Started talking about Identity Orchestration and non-intrusive logical integration of ICT systems. I opined about our ability to focus on lightweight identity and identity attribute info...having the ability to transversally reference an identity irrespective of location, data store type, event engine, and application stack...enterprise wide.

Even spoke about the "identity onion" (I know, I know...a pathetic attempt cause I was simply utilizing old analogies; the core of the onion = function/role/profile, layering around that = process(es) and interdependency of process, additionally layered around this (the outter most layer) = business policy(ies) and rules)...ok, ok...stop frowning already...it works for me...in fact...it worked in this meeting also!

Anyway, spoke about the ability this onion gives you once you take the next step; mapping the human political framework within the business to the onion + mapping the identity and attributes of the identity to agreed upon authoritative sources in the business (i.e. GroupWise owns the email id, SAP HR owns the employee ID) + mapping logical authority to the onion (i.e. SAP HR is the transversal authoritative source of employee existence in the business...so...if someone doesn't exist in SAP HR, they shouldn't exist anywhere in the business - aka Provisioning/Deprovisioning).

The Honeywell boys were nodding their heads now...starting to see the link...so were my guys ;)

I ended the description of our world by outlining that we provide a non-intrusive and transversal Identity orchestration framework. The framework is owned by the CFO/Risk Officer/Compliance Officer/Business Optimization folks...not by IT. It allows business to define regulatory and governance rules according to meta standards and best practice...and then translates this so the ICT infrastructure acts accordingly.

The most critical attribute of this "Meta Identity Spine" is that it HAS TO BE non-intrusive and employ orchestration via web services.

If it has these values and positioning...once essentially has introduced an proverbial SOA for Identity in the business...which means we have Service Oriented Identity and identity attributes in the business. I pushed my luck a little...spoke about this being the obvious first step towards a true end-to-end SOA. i.e. once you have identity service oriented you have a contextual mapping of your entire SOA strategy...my thoughts here are very simplistic; if any organization is truly its' data and its' people...kinda makes sense to get a mechanism to harness the referencing of these first...then again...who am I anyway ;)

I know...you're sitting there thinking...I've read this far and the guy still hasn't spoken about how LAC and PAC comes together... Here it is...

The Honeywell engineers sat there...now on the edge of their seats...having made several notes...and...THEY GOT IT BIG TIME! The started asking questions like; Do you mean you can reference any identity related data, irrespective of the architecture stack, throughout the enterprise...without changing anything or requiring massive connectors custom written for all the custom apps...? I said YES! Do you mean this "Common User/Profile/Policy Repository" any of our systems can also speak to non-intrusively...? I said YES! (Did prompt him on their standards adoptions and usage in their apps - which they nodded positively too)

Note: I made it clear to these guys that we're integrating/correlating/listening for events across the enterprise..FIRST! This framework isn't optimized for transactional data synchronization...you go use you EAI messaging bus for that stuff. Yes, we can tranform and federate/synchronize/virtualize identity information within the framework of provisioning...but our real purpose and value is orchestrating based upon events! This ensures minimal data touch which runs you right into corporate politics and empires...and creates quick tangible solutions that demonstrate real return!

Then it all became so clear...Why? Here's some use cases of the value of PAC being able to speak to LAC;

1. Simple business policy enabled: If you're not in the building - you should not be logged onto anything applications/services on your desktop! - all possible if the user leaves his floor, heads to ground floor, swipes his building access control card, the turnstile lets him out, the LAC system listens for "exit" event on the physical building access control unit, picks up the event and disables/disconnects/expires all authentication for that userid throughout the enterprise. (i.e. if you're not in the building you authentication credentials are rendered void...cause you're not there!) - the risk officers really like this one cause it enables broad and tangible risk mitigation associated with fraud minimization ;)

2. Another simple use case: (btw: the Honeywell boys came up with this one - we're currently deploying the solution for a minerals and energy org here in South Africa) A very large mine in the country utilizes on average 35,000 contractors per annum. Each one of these 35k contracts allow for expensing home internet access - this customer was paying their ISP for this remote access service (RAS) approximately $9,5m per annum...yip...$9.5 MILLION per annum. The customer knows this figure is exorbitant but has no way of really controlling this without affecting contractor performance...I know...when I heard the customer say this...I thought "YEAH RIGHT"...and do I have a bridge to sell you ;)

Guess what was happening here? - contractors were showing up for work and still expensing tons of home data downloads...cause their kids were streaming multimedia via the RAS solution whilst dad was contracting away at one of the mining locations.

Anyway...instead of getting all techie to solve this problem we're just linking the Honeywell building/gate/mine physical access control system (integrated and deployed throughout the country and at every remote mining location) with our LAC system. i.e. we were simply listening for the "entry" and "exit" events on the PAC systems - if the contractor is onsite (the event being an "entry") we personify the business rule that says disable RAS for that userid.

The result? We haven't deployed the system totally yet and already we've cut monthly RAS usage by 75%

So...we're running around talking to every Honeywell customer and we're yet to find one that doesn't think they need this! Yip...the meeting did end in a group hug...and I think I stopped it just in time when one of my engineers looked like he was about to shed a tear of joy.

Maybe it's just happening here in South Africa...but...we're definitely seeing a massive convergence of PAC and LAC...driven by regulatory compliance, risk mitigation and governance enablement.

It's fun seeing the application of technology having such real relevance and logical value!