Identity Management
Misconceptions about IDM and its components
1. “Any IT employee can lead an IDM project!”
The introduction of Secure Identity & Access Management systems (SIAM) is a highly complex project:
- IT and business departments jointly define new procedures to manage accounts and authorizations more easily.
- IT and Auditing define the audit procedures
- Various different applications are integrated into the IDM with their own user administration.
In order to be able to manage these processes, the customer’s project manager must have in-depth knowledge of the company and its organization. He must have an idea of how the individual applications are managed and should be able to break down language barriers between IT and business departments.
2. “Our vulnerabilities are plugged by the security software”
Without a doubt, virus scanners and firewalls are important elements of IT security. But they do not help when it comes to gaps in authorization management (access and access control). Practical experience shows that, especially in the AD, as a rule ¼ of all entries (accounts and authorizations) are faulty and form the ideal attack vector for data misuse, even by internal employees. If a security vulnerability then leads to damage, the company is liable.
3. “I find misuse by searching for unused accounts”
A dangerous fallacy that only reassures non-IT users, because: Accounts whose status is “unused” are not being misused at the moment (they should still be removed!). Accounts that are being misused are active!
4. ”Whoever uses LDAP already has IDM under control!”
A system that uses LDAP as a protocol can represent authentication (logon) or a central repository for identity data. A SIAM (Secure Identity & Access Management), on the other hand, offers the following additional features
- a workflow management system (applications, approval, etc.),
- a solid rules engine with extended business role management,
- an audit functionality with historical data (pure directory-based systems cannot do this).
In addition the LDAP lacks the highly integrative system connection for the provisioning of other systems.
5. “Exchanging the account information with directory is enough!”
The consolidation of the user control, for example with an Active Directory, is not enough. Thus the process control (workflow management) remains unconsidered and only partial parts (individual systems) of the authorization assignment are covered. The Active Directory lacks auditing, business role management and a highly integrative system connection for the provisioning of other systems.
6. “Centralizing system administration is a benefit!”
The centralization of services is certainly a benefit – if only to fulfill the ITIL functions incident, change and demand management. But a SPOC (single point of contract) only has a reactive function, i.e. it only reacts to orders. One of the biggest problems in IT security management, however, is the lack of cancellation of authorizations. An IDM (SIAM) system, on the other hand, is also able to support withdrawal of authorizations.
7. “IDM is SSO, and SSO is a low hanging fruit”
Single Sign-On is only one component of an IDM (SIAM) framework. It simplifies ONLY the authentication of the users and offers a rudimentary password management. Although the initial installation is manageable, the necessary management component (“Who can use SSO?”, “Which applications can which user use?”, etc.) is more complex. In addition, two-factor authentication, e.g. via smartcard, can hardly be circumvented, because a possible spying out of an SSO password would possibly make complete access possible. Then, however, the high license costs are usually out of proportion to the benefits. A true “Single Sign-On” is often difficult or impossible to achieve due to the technical complexity of the various systems (AD, LINUX, HOST, SAP, mobile devices, web applications, hosted systems) and the large number of systems.
8. “A Webshop delivers an IDM!”
This is what many think – but they forget that the webshop is not suitable for the denial of rights. Practical experience shows that even the best guidelines cannot guarantee that the responsible department will take care of the denial of rights. In contrast, IDM systems work preventively and reliably.
9. “Through IDM is the compliance assured automatically!”
Not necessarily, because: Identity products have many different building blocks and can be customized very differently. Those who integrate a history management tool into their IDM system (most products already contain one) have taken the first step towards compliance. Then the ACTUAL (what user authorizations are currently found in the systems) and TARGET states (what should be set according to the guideline) must be stored. Thus the audit tool can regularly display the difference between CURRENT and TARGET states allowing IT to find and close possible gaps. IT compliance is only guaranteed when the CURRENT state corresponds to the TARGET benchmark, not before.
10. “Reporting is the same as audit!”
Reporting shows the status of accounts and user authorizations in the systems. But the high-risk authorizations that deviate from the rule can only be found in comparison with the target status. This must be defined and continuously checked by the department. In addition, the comparison of the target and current state, including the marking of differences, is necessary for an audit. Only in this way can vulnerabilities be found and eliminated.
In order to relieve the business department (from audit work regarding authorizations) and to validate the authorization status promptly as well as to document it historically, one cannot avoid technical support to cope with the bulk.
11. “Re-attestations or audit trails replace an IDM!”
The superior cannot really handle a list of possible authorizations (e.g. 15 systems with 1000 authorization options each). This would result in a high training effort paired with low willingness (“I have better things to do!”). Such a procedure fails due to a lack of acceptance.
12. “Restricting yourself to the ‘internal employee is enough”
Whoever thinks along these lines forgets the external service providers, service personnel, suppliers or outsourcers. In addition, the question arises as to how the technical accounts or function accounts should be brought under control.
13. “To document the authorization assignments, the description of the new creation is sufficient.”
“Changes” are by far the most common form of authorization administration in the user life cycle. Practical experience shows: More than 90% of all authorization adjustments result from function changes, OU changes and project accesses – each with access and revocation. The new creation of a user, on the other hand, is usually simple from the point of view of IT security.
14. “Setup.exe’ and a few Blueprints’ – and my IDM is already up.”
Manufacturers advertise with this assertion. In doing so, they hide the necessary involvement of the business departments responsible for assigning authorizations. Management processes and workflows must be implemented. These have to be created individually, because they have to be oriented to different guidelines, if only because of the industry assignment – banks and insurance companies have different legal requirements than building material dealers. You can’t just impose processes, otherwise they won’t be accepted and will be bypassed.
A common process definition of IT and business departments is necessary. Exactly the same applies to the definition of business roles and rules.
15. “IDM is IT department’s job!”
The IT department operatively implements the authorization request of the department (purchase order, cancellation, etc.). For secure authorization management, however, the department needs support in formulating its authorization requests. Because the precise description of the necessary rights is not easy, because wrong requirements are not corrected anywhere and because the department has to justify its purchase orders. The use of specialist role modelling enables the business department to deal responsibly with its task. But the combination of bottom-up and top-down methods for role modeling alone shows that role modeling is not a gimmick, but the supreme discipline for business departments and IT.
16. “Change of OU is trivial!”
The withdrawal of authorizations from the old organizational unit cannot be changed at a deadline, since old tasks still have to be completed, although the employee is already working in the new organizational unit. The mere fact that the mail account must be continued (who would like to have their mailbox deleted because of a change of department?) shows how impractical the “delete everything” approach is. A flexible procedure that goes beyond this way of thinking must be found.
