Stiennon talks about Rohati and their ‘new’ approach to NAC in the form of their NBEC, Network-based Entitlement Control. I, unlike some bloggers in our network, decided to check it out before formulating an opinion.

So, I checked it out and I’m a little disappointed… on several fronts. First, all the information I have with which to draw a conclusion is limited to the online ‘product demo’ available on their website. It’s not really a product demo, hence disappointment number 1.

Let down number 2 comes in the realization that the features they’re touting in the ‘product demo’ are actually things we can do today, with traditional hardware-based NAC solutions from those daily house-hold names… Symantec, StillSecure, Juniper, ProCurve, Enterasys and even Cisco. Rohati does (potentially) have a unique statement of being able to enforce policies without touching the client. But, again, we ‘can’ do that with several of the products I just mentioned. And I’m wondering how we could create the tunnel-like enforcement and security Rohati claims to offer without some type of agent on the client… after all, any encryption tunnel has to have endpoints, right?

I attempted what I usually do when I’m checking out security solutions, I went to the support section of the website to download product manuals or configuration and implementation guides. Even some white papers. I wanted to see how they’re really going about it all. But, disappointment number 3 jumped up and got me when I saw that the only resource on their support page was an email address. Hmm….

The company seems to be comprised mostly of long-term ex-Cisco employees. Out of the 8 members of the management team, there’s 1 President, 6 VPs and a director- 5 of which are co-founders. With just 2 years under their belt, I’m wondering what all they can have up their sleeve past a slight variation of current NAC solutions.

I may be completely wrong about the company and product(s). If I am, I’m sure someone will offer to send over some product manuals for me to read through…

The bottom line is… a rose by any other name would smell as sweet… or stink as bad.

# # #

Sir Lancelot or Guinevere? Hey don't laugh it could happen to you. In the meantime what has Richard so hot and bothered that he is subscribing mythical qualities to Rohati?  It seems they are using a layer 4 to 7 firewall to control access to applications. They call it network based entitlement control.  I wonder how they stack up to Palo Alto Networks and some of the other next gen application aware, access control firewall products.  From what I understand Nevis Networks and ConSentry can do similar things with the firewalls in their secure switches.

Nevertheless Rohati has gotten some good press, albeit with most coverage carping on the fact that they are founded by former Cisco employees (there are enough former Cisco employees to found many companies I would think). I do think that application aware access control is of tremendous value and this technology will find its way into many technologies. It is a logical extension of identity based access control. 

As usual though Richard can't resist taking a few cheap shots at NAC vendors.  In Richards idyllic view of Camelot, somehow performing pre-connect health or integrity tests is the devils own work.  Richard will just admit that these tests have value and people want them.  They do not preclude doing the rest of the job of access control that Richard seems to approve of though.  Alas, Richard and I have danced this dance before though and I am not going to get into the why it is important.  In fact, here is a new tact for you Richard, it is not important. If you are not going to be convinced, forget about them.  Look beyond admission control tests at what NAC vendors offer around access control and you may find similar type of technology to Rohati in the near future. 

Until than though Richard let me paraphrase Merlin from the movie Camelot "Never be too disturbed if you don't understand what a former analyst is thinking. They don't do it very often".

Sir Lancelot or Guinevere? Hey don't laugh it could happen to you. In the meantime what has Richard so hot and bothered that he is subscribing mythical qualities to Rohati?  It seems they are using a layer 4 to 7 firewall to control access to applications. They call it network based entitlement control.  I wonder how they stack up to Palo Alto Networks and some of the other next gen application aware, access control firewall products.  From what I understand Nevis Networks and ConSentry can do similar things with the firewalls in their secure switches.

Nevertheless Rohati has gotten some good press, albeit with most coverage carping on the fact that they are founded by former Cisco employees (there are enough former Cisco employees to found many companies I would think). I do think that application aware access control is of tremendous value and this technology will find its way into many technologies. It is a logical extension of identity based access control. 

As usual though Richard can't resist taking a few cheap shots at NAC vendors.  In Richards idyllic view of Camelot, somehow performing pre-connect health or integrity tests is the devils own work.  Richard will just admit that these tests have value and people want them.  They do not preclude doing the rest of the job of access control that Richard seems to approve of though.  Alas, Richard and I have danced this dance before though and I am not going to get into the why it is important.  In fact, here is a new tact for you Richard, it is not important. If you are not going to be convinced, forget about them.  Look beyond admission control tests at what NAC vendors offer around access control and you may find similar type of technology to Rohati in the near future. 

Until than though Richard let me paraphrase Merlin from the movie Camelot "Never be too disturbed if you don't understand what a former analyst is thinking. They don't do it very often".

While waiting for the pan-out of the Cisco System's acquisition of Securent, I can't help but wonder how Cisco is going to develop the Securent technology in its future products. Will the Securent policy engine (PDP) be used 1) as a main point for policy management and enforcement for network equipment, OR 2) will they continue using the product along the 'Securent-intended' path: enforcing fine grained application level policies by integrating policy enforcement points into applications, OR  3) managing fine grained authorizations on the network layer (without the need to open up applications), similarly to BayShore Networks, Autonomic Networks, and Rohati Systems? Without a comprehensive identity and access management offering (IAM), Cisco will probably be fit best to do 1) and 3) described above. This seems most consistent with Cisco's background and culture.

Several weeks on and I'm still digesting the massive amount of information and insight from the second European identity conference in Munich, organized by Kuppinger Cole. Five days chock-full of content (7 am to 7 pm every day!), 50 exhibitors, 130 speakers, four workshop tracks, five theme tracks, and 25 best-practice sessions. Hundreds of delegates showed up from all over, even though Infosecurity 2008 was raging in London the same week. EIC 2008 was a superbly run event, with the seemingly inexhaustible Martin Kuppinger at the center of the storm.

It's difficult to sum up the content: Internet-scale identity, identity-driven security, federation, single sign-on (SSO), provisioning, context-based authentication, mobile and user-centric identity, SOA, entitlement management, and information risk management all commanded their own tracks. But some unifying themes emerged, chief among them that well-planned and -implemented identity and access management (IAM) is increasingly a must-have if we want to have effective information security, information risk management, and even GRC in today's and tomorrow's enterprises. 2008 may not be the tipping point for IAM, but we're getting close. A few highlights:

• It seemed that every third presentation contained the words "Société Générale" or "Jérôme Kerviel". Nothing like an(other) egregious breach of policy, procedure, and trust to concentrate the mind! Suddenly everyone is rediscovering the Barings debacle of a decade ago and recalling the name "Nick Leeson" — and realizing that, while we have made great technological strides in the past decade, all too often the people and process elements get short shrift. (If the control framework breaks down, it matters little what tech was used to enact it...). So while there was plenty of forward-looking technology-centric discussion, the thread of policy and process ran through every conversation — there was even an entire track session devoted to avoiding internal fraud via rogue trading and the changing threat landscape.
• A lot of the Identity 2.0 discussion was still quite fuzzy. There was little agreement on what mobile identity really means and how companies offering consumer services can provide it to customers, and what the role of mobile operators (who at the moment look like the weak link in the security chain) might ultimately be. User-centric identity is a great idea, but needs to be implemented in a way that gives users meaningful control over their identities and associated credentials in a way that doesn't also shift all of the liability for financial fraud (identity abuse) from institutions to individuals. This has significant implications for things like mobile commerce.
• There was a great physical/logical convergence case study from City College Coventry (UK), which is providing converged smart-card credentials to more than 10,000 students and staff. The card will function as an ID badge across the College, parking pass, building pass, cashless payment card, library card, etc. It will also be required to use any computer, printer, or photocopier connected to the College's network, and will allow lecturers secure access to classroom resources. The College does have the luxury of setting up this system in the context of moving to brand-new facilities, but it shows that if the IT and physical security folks can agree to pull in the same direction, convergence is a wholly attainable goal.
• Results of an enterprise IAM study were presented; one of the most troubling findings was that half of the respondents reported that their biggest obstacle to implementing IAM was that the business was just not ready for it. User management is often in place, but downstream functions like auditing and monitoring are still far from mature in a holistic IAM context. Firms also report big gaps between expected and actual benefits from implementing IAM. That last bit is one reason we advise not trying to do it all at once; rather, break a planned IAM implementation into manageable project chunks, focusing on one set of short-term, tangible, demonstrable benefits at a time.

One panelist put it best: Technology maturity and integration are all well and good, but we need workflow integration and organizational maturity. The need to implement IAM provides an opportunity to share information, define new policies and processes, and streamline existing ones. The CEO and CIO/CSO/CISO need to sit at the same table, commit to eliminating organizational silos, and devise a cooperative approach.

Roles are indeed in the domain of the “identity weenie” — but alone, roles are nothing but a maintenance nightmare - they exist to be leveraged. Rules on the other hand, are the problem of the “authorization weenie” and are written (for example) as a WAM policy that says “All Production Accountant Level II resources can access the accounting SharePoint instance”. When you collect roles into a profile and collect rules into a policy and then evaluate for a given user, resource, and point in time, what you eventually get is an entitlement, ie “Jenny should get into the accounting SharePoint instance”. The goal is to have transitive logic between roles and rules, such that two different people can take on the two different statements being made. Jenny’s Manager can authoritatively state (through a workflow approval) that Jenny is indeed a production accountant. The owner of the Accounting Sharepoint instance can authoritatively state (through an authorization policy) that all production accountants should have access to their site. ... What happens when the system detects the static presence of two conflicting roles? What happens if one role is “truer” than another at some point in time?

The other silver bullet fallacy the RBAC introduces is the idea that objects, subjects, and sessions can be bundled so nicely enterprise wide. People look at their nice org charts and assume that you just plug that into your directory and go. Works great in a domain with hard edges like a call center where discreet groups of people execute the same tasks the same away across many sessions. Not so good once you step above the rote task level. Interestingly "God level" access works well with roles too, but we are not supposed to be building systems with that stuff any more, right?

All provisioning solutions provide some facilities for:

• Reduction of paper-based processes in favor of electronic requests and work flows
• Reduction of manual updates in favor of automated entitlement updates

All provisioning solution providers strive to have a compelling story for these items. Additionally, these were the focus of the first generation of solutions which emerged in the ’90s.

For the Identity Management programs with which I have been involved, automation and risk management have been equally important. This is somewhat reflected in the definition I use for provisioning:

Provisioning is the processes and systems which:

• Manage the entire Lifecycle of an Entitlement from request, through approval processes, onto issuance, and eventual revocation

• Provide transparent views of the status and history of each step in the Entitlement Lifecycle through the creation of durable and detailed records, which include all the information required to provide non-repudiation and event reconstruction for each step in an Entitlement Lifecycle

Note: Fulfilling these objectives always involves a mix of manual and automated activities, technical and procedural controls.

Based on my experiences, having prepared several product selection scorecards in this space, there are two major approaches (philosophies), that provisioning products take in this space:

The provisioning system “sees itself as”…

• Coordinating identity and entitlement activities among systems with the objective of providing automation

- - - OR - - -

• Maintaining a single centralized record of reference for identity and entitlement, as well as providing tools to automate approval, issuance, revocation, and reconciliation

The “Centralized Record of Reference” concept is the watershed between these two. The systems that are designed purely for automation tend to focus on “Coordination” of external events. These systems often do not contain an internal store of entitlements. The systems that maintain a “Centralized Record of Reference” approach have the ability, through reconciliation, to validate that the entitlements in the “wild” (e.g., in AD, LDAP, within local applications, etc.) match the “official” state (which they maintain). This enables these systems to detect changes and take action (e.g., drop the privilege, report the discrepancy, trigger a follow-up work flow, etc.)

Which system is right for you?

This really depends on what percentage of your systems require tight oversight. If you are in an industry with low-IT regulation, and the data of your core business is low risk, then it may make more sense to invest in routine manual audits of a few systems, rather than monitoring your entire IT world. On the other hand, if you are in an industry that is highly regulated, with high-risk data, then the automated oversight and reconciliation capabilities are likely a good fit for you.

FYI, last week I co-taught a one-day class on Identity and Access Management Architecture at RSA 2008. For the last 3rd of the class, Dan Houser and I had a list of advanced topics for the class to vote on. I prepared a module on Provisioning, but alas it was number 4 out of 7 options, and we only had time to cover 3… As a result, a Provisioning slidecast is “coming soon” to the Art of Information Security podcast.

Cheers, Erik

Art of Information Security would love your feedback !

Risk ROI for –Some– Provisioning Solutions…