Showing posts with label iam projects. Show all posts
Showing posts with label iam projects. Show all posts

Wednesday, July 7, 2010

Kuppinger Cole Analyst names Engiweb Security a “Hidden Gem” in GRC

What a good surprise! We are very pleased to be included in the “Hidden Gems 2010” report from Kuppinger Cole in the “GRC market segment - “Governance, Risk Management, Compliance”.

According to the Kuppinger Cole report: Hidden Gems are vendors which are (still) relatively small, less known then "the big ones", and which definitively offer innovative solutions that are worth considering. These vendors are not (yet) stars in the worldwide IAM, GRC, and Cloud markets.
It is in the nature of grinding Hidden Gems that some will not become the sparkling diamonds we expect today. Some will become acquired. However, there are strong opportunities in selecting products and services of innovative, young vendors – of the Hidden Gems.
The selected vendors are distributed into four categories. Besides GRC, categories include IAM, IT Security and Cloud.

You may recall that a few months ago we were also named “Cool vendor” by Gartner. The inclusion of our solution in the Kuppinger report reinforces the fact that we have a solution that is sound, distinct, concrete and able to solve customer problems and ensure success of business objectives.

But… but… as I already stated in my previous post, this is not enough! I don’t want to start the usual rail about the few “Ugly, Dirty and Bad” big companies again. It’s very frustrating to notice, however, that we always have to demonstrate or prove something, while just a few words and a PowerPoint presentation is enough for the “ big brand”.

This is a recent example: the prospective customer wants to implement a complete role-based Identity & Access Governance project by the end of 2010.
Our foe say “No problem”!
….. but wait a minute: the foe has also just affirmed that the roadmap for a new module - that is mandatory for the project – will not be integrated before October 2010, and on top of that the official timeline is CY2011!
How will they comply this to the project deadline, since lots of custom developments are required and the tools are not yet available? A mystery!
Alternatively, we humbly proposed a pitfall free solution with technical features that are at least ‘on par’ with the competitor’s. A solution with almost all functionalities natively available from our IDEAS platform without the need for further coding or custom developments… and obviously with the possibility to implement a POC in weeks.

The (ex) prospective customer verdict was: sorry, but we trust them and feel comfortable joining their grand vision”. No further explanations given!!
Is this a healthy competition?

Going back to the report spirit: Hidden Gems should mean that there are some fascinating less-known solutions on the market worthy of evaluation - including ones you possibly never knew existed!
The complete report is available to Kuppinger Cole clients here.

Tuesday, May 11, 2010

Good news from Italy: Piaggio wins award at Kuppinger Cole’s 2010 European Identity Conference

The European Identity Award in the category ‘Best Cloud IAM project’ was conferred to Piaggio, the well known worldwide manufacturer of Vespa scooters, for their use of Engiweb Security’s Identity & Access governance IDEAS solution.

The award recognizes outstanding projects as well as innovations and additional developments of standards. Directly from the awards page:
In the category “Best IAM Project in Cloud Computing”, […] The award was received by Piaggio Group of Italy for a hosted IAM solution based on products by Engiweb and focusing on defined, enterprise-wide business processes […] Both the number of nominees for the European Identity Award 2010 and the quality of the project submitted far surpassed last year. This is seen by Kuppinger Cole as a general sign of increasing maturity in IAM and GRC solutions. Especially notable was the number of nominations in the category “Cloud Computing”, a trend that the analyst group feels will be sure to continue over the next few years.

During the event Piaggio’s representative, Lorenzo Mastropietro, presented the company’s customer case explaining that Piaggio’s aim when they started was that of having a classic Identity Management project and from the beginning they had a clear vision of their business needs. Thus, even if the main targets were Access governance and Compliance improvements, Lorenzo highlighted how even the “basic” password reset functionality was sufficient to justify project investments. As a matter of fact, he is now using these early successful results to support internal marketing activities, in order to more fully involve all stakeholders and gain more support for future development.

Furthermore, thanks to the IM outsourced project, Piaggio does not need internal staff to execute IM operations and does not spend time and resources for its maintenance. The implemented solution makes it possible to delegate a big part of the ICT activities to the Outsourcer, allowing Piaggio to concentrate on aspects linked to business. (policy definition, workflows, role engineering, etc. …).

Friday, April 30, 2010

Vaso di coccio tra vasi di ferro

Blow the trumpets and blow the horns: we’re extremely happy that Engiweb Security has been announced as one of Gartner’s “Cool Vendors” for 2010, in the Application Security category. This is all thanks to the IDEAS platform that, even if could be best positioned as part of the market segment of “Access Governance Platform”, among other things provides additional support for Entitlement Management.

Will this acknowledgment create business opportunities for us in the international market? Will being a Gartner-certified “Cool Vendor” attract potential customers like bees to honey?

How to tell? This market is so strange!

Perhaps I’m a bit too disenchanted, but as a matter of fact, we still have to face a market where more than 60% of the customers do not perform serious “vendor selection” when they need to decide how to implement an identity management project.

As stated in the KPMG/Everett “2009 European Identity and Access Management Survey”, that can be downloaded here:
“When organizations are selecting their required IAM solution, a large amount acquire the solution of their preferred supplier and only 18% perform a vendor selection in order to select a ‘best of breed’ solution”
It is easy to guess who these “very very large” preferred vendors are…. however this may result in a “hidden” failure for the customer: licenses acquired and at once abandoned with no project that was implemented at all! (Hard to believe, but not everybody realizes that the implementation of a project is the biggest cost for an IM initiative).

I’m definitely pessimistic these days…

Anyway we at Engiweb Security have no intention of resting on our laurels… and we have some really cool things planned for the next product releases: Risk metrics/management and XACML support.
------------
Vaso di coccio tra vasi di ferro
This typical Italian expression was probably coined by Alessandro Manzoni who, in the first chapter of his masterpiece “Promessi Sposi” (The Betrothed), writes:

Il nostro Abbondio, non nobile,non ricco, coraggioso ancor meno s’era accorto, prima quasi di toccare gli anni della discrezione, d’essere in quella società, come un vaso di terra cotta, costretto a viaggiare in compagnia di molti vasi di ferro.
(Translation: Our Abbondio, not noble, not rich, not courageous, was therefore accustomed from his very infancy to look upon himself as a vessel of fragile earthenware, obliged to journey in company with many vessels of iron.)

The metaphor is clear: the vessel of fragile earthenware (Vaso di coccio) surrounded by many iron vessels (vasi di ferro), during a journey along a dirt road can easily be broken at the first little impact. Nowadays this expression describes a tricky situation where a person finds himself as a minority among hardened opponents.

Wednesday, August 6, 2008

No man is prophet in his own country

An Italian crazy approach to Identity Management projects

Preliminary remarks
  1. An Organization is launching an Identity Management Project where almost 80% of the foreseen IM processes require an authorization workflow.
  2. The Organization has selected an IM technology platform
  3. However, the requirements are so complex that it isn’t possible to meet them just with a customization of the web application of the vendor’s IM product
  4. Furthermore it is the Organization itself that suggests custom developments for the web application.
  5. … thus almost 80% of the IM project requires ex-novo software developments
  6. What a crazy world!!

Actual Story
We just received an Identity Management (IM) RfP from a large Italian company.
It seems that they have already done an internal technical evaluation, as they are asking mainly a system integration effort based on Oracle Identity Manager product.

From the RfP, translated from Italian: “(the company) wants to equip itself with an Identity Management system for supporting: the digital identity management processes, the software applications and other platforms authorization processes. To this end (the company): has identified in the Oracle Identity Manager product the technology to be used for implementing the system, has carried out a feasibility analysis, and has defined constrains and requirements for the implementation”.

Thus, just a system integration effort. They have done a rigorous vendor selection, and verified the feasibility of the project using the selected product.

Ok, fine, … but uhmm… they also want to develop new custom clients for specific functionalities not available from Oracle Identity Manager Web Application.

As a matter of fact, they have expressly invited the bidder not to customize the web application interface of the Oracle Identity Manager Administrative and End-User Console, but to implement the web interfaces using a “custom client” approach, i.e. a SW development based on Oracle Identity Manager Software Developer Kit (API).

Again from the RfP:
  • “From the (Company) requirements analysis, we want to draw bidder's attention to the following set of remarks pertaining to the requests management:
  • Roles (User Manager, Authorization Steward, Operator) of all users involved in a request approval process, need to have different scopes (or views), based on resource object attributes that represent the requested resource. For instance the User Manager doesn’t need to access fields like account identifier; this field, on the contrary, must be set by the AM function that creates the account on the target system. The first access password should be set by AM, displayed for the end user, not available by any other, and so on…”
  • A fill-in request process must be guided by specific wizards aimed at effectively supporting the end user. For instance a User Manager that wants to grant the access to an Application for one of his collaborator, must first of all select the user from a predefined list of all his collaborators. Then he must be able to select the application and related profile. The system must be able to guide him, by offering the standard profile (or in case, a list of standard profiles) associated both to the selected application and to the end user belonging Organization Unit.
  • ……..........
  • A user must be able to submit a request for modifying his assigned profile for application authorization, but the present release of Oracle Identity Manager doesn’t allow out-of-the-box to implement workflow for approval of modify requests of resources attributes already assigned to users.”
The questions is:
  • Does exist a product out there able to manage, out-of-the-box the above listed features, or at least able to provide a rich, exhaustive support for these functionalities?
Disclaimer
Yes, Engiweb Security can help with most of the above described missing features. For instance, reading from Engiweb Security IDEAS brochure:
“Administrator scope dynamic association in workflow processes. It is often necessary that workflow figures (delegated or peripherals administrators) have a limited scope both for users (only certain OU users) and Applications (i.e. this administrator only approves profile requests that belong to a specific application).”
There is no reason for me not to talk about it! ...but in short: is there someone who is interested? (certainly nobody in Italy).

Postscript
As soon as I ended this post, I discovered that some bloggers are discussing on FACTs and FUDs here and here.
The above described example well fits into the discussion.
We are a vendor used to face behemoths like ORACLE and SUN. In this post the Oracle products were mentioned, but I can give examples on SUN too. As the saying goes “People who live in glass shouldn’t throw stones!”

Tuesday, April 22, 2008

IAM System - Targets inconsistency policies

I’m joining Matt Flynn discussion on “Extending the ROI on Provisioning”, where he highlights an intriguing problem: how to manage direct modifications on the targets, where a IAM solution is in charge of providing approval workflow, synchronization, compliance, etc..…

Yes. Most organizations we work with are quite concerned about managing direct access to target resources, getting around workflows and central management (e.g. a profile assignment to a user directly on a target).

They confirm that despite all the precautions, it is always possible for inconsistencies to be created in their IT systems, causing authorization misalignments between the target systems and the IAM system.
Moreover, it is not possible to automatically classify and correct in advance all types of inconsistencies that can occur. However, it is certainly possible to provide a tool to detect and manage misalignments.

In our solution (the IDEAS suite), this problem is referred to as "Inconsistency Management". Within IDEAS' internal multilayer model, such actions can lead to the modification of many relations with decisions depending on many factors that must be shaped into appropriate policies.
Thus, whenever an inconsistency occurs (an offset between the IDEAS core repository and a generic target system) the Inconsistency Role Engine goes to work to repair the offset.

But what is the meaning of repairing?

Often there are difficult decisions to be made.

For instance, an authorized administrator accesses target1 and removes Profile1 from user John. Unfortunately Profile1 was assigned to John via a higher level Role: "Role1", which is actually composed of many other profiles on several targets (including of course Target1). Thus how should the IAM solution react?

The simplest policy could be to state that the central system is authoritative and thus everything must be reset back to original settings.
Another alternative policy could state that if the administrator is trusted, the modification must be accepted. But in the central repository of reference, John is assigned Role1, NOT Profile1. So alignment could mean the following:
  • remove the entire Role1 from John, or
  • verify if there is another available Role composed of all Role1 profiles except Profile1 (e.g. name this Role 2). If so, remove Role1 from John and assign Role2. If Role1 is part of a hierarchy and a lower level Role without Profile1 is available, it could be possible to assign this Role to John instead of Role1. In this case, while there is no impact on compliance, there could be a possible limitation on user access rights
  • Notify the relevant people (e.g. IAM administrator, Role1 owner and all actors involved in Role1 authorization workflow, etc..) that there is an offset between the central DB and the target. The policy could state that if there will be no remediation activities within a defined time period, the original settings will be restored.
If the Administrator, again directly on a target, adds a profile to John, this would be even more difficult to manage as there could be a huge impact on Separation of Duty verification. I'll try to write a specific post on this item very soon.

P.S: IDEAS ( IDEntity and Access management Suite) is a solution addressing the full gamut of Enterprise Role Management needs in multiple IdM solutions.

Monday, April 21, 2008

“User lock/unlock” management scenario


In my previous post I was raising doubts about the fact that implementing lock/unlock account procedure might not be so easy. Here I’m trying to explain why.

Preliminary remarks: although this requirement is rarely present in IAM project RfP’s, it is obvious that any large organization already has a procedure disciplining the user lock/unlock processes. Let’s try to imagine it in detail.

A user can be locked for various reasons. For example:
  1. Technical lock (a user is locked because he or she has exceeded max wrong passwords or due to extended inactivity).
  2. Administrative lock (specific events coming from HR determine a temporary or definitive user lock i.e. maternity leave or grace period before expiration).
  3. Security lock (a user is locked by a security manager).
It is also obvious that unlock procedures must follow hierarchy rules, such as:
  1. A Technical lock on a user can be removed by any administrator (Head of Unit, Help desk etc..).
  2. A Security lock on a user can only be removed by a Security Officer.
  3. An Administrative lock on a user CANNOT be removed by any administrator. His or her unlock is determined only by an HR event (return after long leave or expiration interruption etc..).
  4. To complete complexity, if a user’s Security or Administrative lock is directly removed by the target (e.g. using AD console), then the IAM system must react in real time by resetting the unlock.
These processes must be managed by the IAM system since access systems (e.g. MS Active Directory) do not have the “intelligence” for this purpose and therefore cannot “assist” such management.
If this type of requirement, even though not particularly complex, is not directly supported by the tool’s data model, a custom development consisting of "data model” definition managing would be required.
The data model shall support data, relations between them and other already available data as well as necessary developments to implement policies.

In conclusion:
  • When the product data model itself already supports these processes, mapping of the said process is reduced to pure and simple configuration in no time. Maintenance and changes are made by high level administrators
  • In case native support is not available, the following should be expected: detailed technical specification definition, Data Model updating, policy writing (usually at low level) and tests, changes, complex management, etc….

Friday, April 18, 2008

RBIA: The Great Unknown

An Identity and Access Management project is not always an easy job. It is very difficult to describe in few words why, but one reason for sure is that in the IAM environment procedures are always more important than technology. In other environments, (e.g. Document Management), technology can drive procedures, thus the right technology choice is the most important aspect.

Conversely, in the IAM environment it is quite impossible to find customers willing to change procedures because technology is unable to map these procedures into the product (or achievable only with huge software customisation). Procedures are important and relevant processes have to be mapped into technology without compromises.

On the flip side of the coin, there is another aspect to consider.
AM technology is still evolving. Most “official” IAM technology vendors are coming from the User Provisioning environment; in essence, coming from the bottom. Pure technology. Of course vendors are adding features trying in attempts to raise the bar but they are still conditioned by original sin – They want to add intelligence to technology instead of adding technology to intelligence.

Intelligence, as in many other IT contexts, is represented mostly by the conceptual model standing behind the product and a data model representing the conceptual model.
The secret of product “intelligence” lies in the conceptual model and its relevant data model.
Technology features like a beautiful, rich graphical interface for workflow design or the huge standard support are all important aspects, …. but I suggest that customers intending to acquire an IAM solution verify how complex it could be to implement simple procedures (e.g. user lock/unlock levels or procedure). It turns out to be a mess with customized software development and the writing of many, many technical policies: even if within a nice graphical environment.

This situation has encouraged the founding of companies who start from RBAC and progressively enrich the model to reach complete RBIA (Role based Identity Administration).
The RBIA model intends to integrate all concepts of User Management (including Credential Management), Role Management, Role Engineering, SOD compliance, Audit and Reporting all the way up to Unified Identity Approach, in order to unify Logical and Physical Access Management views.

According to my understanding, customers’ important expectation of an IAM project that easily supports present and future Identity Management procedures and processes, indicates that a field proven RBIA product is a “must”.

Addition of RBIA functionalities could result in an increase in license costs with respect to the budget sum. However, in our experience, this is greatly offset by tremendous savings of time and cost of project implementation along with a heavy reduction of project risks.

BTW, in a following post I’ll try to justify why implementing a lock/unlock account procedure might not be so easy.

Monday, January 7, 2008

Power is nothing without control

As Italian tyre giant Pirelli's advertising reminds us, "Power is nothing without control." But managing identity, roles and access control is often worthless or at least can be a nightmare without the right tools and handling ability.

Last Monday (yes January the 2nd, during Christmas holidays which, in Italy, officially end on January 6th), one of our largest customers decided to activate a complex internal shake-up.
The reorganization consisted of selling-off one of their companies and merging several internal divisions to form new companies. To summarize, 700 new Business Units (out of 20000) were created, and more than 8500 users (out of 85000), mainly employees, were reassigned with modified business responsibilities and access rights.

Of course the IAM system is directly linked to the company HR system, and role management is integrally aligned with identity management. The solution is quite HR-oriented, incorporating business structure and responsibilities. The viable Role management solution addresses resource/responsibilities association and SoD, and is supported by 3 rule engine environments which implement administrative and security policies.
Since HR is directly connected to the IAM systems, each modification in the HR system usually activates an update in the Role management internal repository. The Resource-Provisioning functions then start synchronizing with the relevant target systems (SAP R/3, AD, etc).

Do they like the automatism advantage of such an IM implementation?
The answer is yes and no. In general, if the operation exceeds a certain complexity threshold, the customer wants full control over all the complete chain of input and output events. As this was the case, they wanted to verify, ahead of time, the impact of this complex reorganization.

Specifically, HR modifications instantly affected the model within the Role/IM infrastructure, but the customer deactivated resource provisioning. They wanted more time to evaluate the final reorganization results. Analyzing the new organization model within the IM repository was sufficient enough to evaluate these effects.

Since they were quite concerned about the number of users to be removed across the several targets, they blocked the massive HR-driven operations and then printed a specific report listing users to be removed along with the action type and justification (reason) codes.

This helped them determine whether or not the HR input was correct and if the policies implemented had any bugs. As it turned out, they discovered that a policy rule was, in fact, not well written.

Even though this all happened during Christmas holidays, they used the tools available inside the Role management infrastructure without any intervention from the System integrator.

Of course, while the HR operations were blocked during the analysis, all modification on roles and business responsibilities arriving from the authorization workflow carried on as normal, including the activation of modifications on the targets via Resource Provisioning modules.

Again, as Pirelli’s mantra goes: power is nothing without control…