In a previous blog article, we gave you a detailed explanation about why identities are right at the centre of digitalisation and security. In this article, we will show you how to make the paradigm shift to identity-centred security and what you need to keep in mind.
This identity-centred approach is easy to understand, clear and plausible. However, its effects are not known sufficiently well in all companies or are not welcomed. A frequent constellation is that critical IAM attributes are not kept in the HR system that manages staff, rather in the user directory (e.g. ADS). This situation has evolved over time. The identity-centred view enriched with business-related attributes creates a new perspective on security. Both personal identities and digital (silicon) identities are focused on. When dealing with identities, there are two core disciplines:
Unlike identity security, which is “only” concerned with establishing and protecting the identity itself, identity defined/centred security applies to anything that validates the trust of an identity. It is fundamental here to be able to maintain the identity context between the actor (identity) and the resource across different technology layers such as endpoints, applications, APIs and network infrastructure. This is because information like geographical location, device characteristics and login attempts are important elements of a transaction and are there to define the user when they make attempts to access information.
IA: Password management and security Secure password vaults store user names and passwords for a number of applications. |
IA: Integrations Connectors Integration of directories and corporate systems for information about users, applications and systems with information about access and authorisations. |
IA: Automated workflows for managing access requests Workflows for requesting access to systems and data. Including and excluding user administration, defining which roles need what level of access to applications and systems, and managing user access. |
IA: Provisioning Process of provisioning and revoking access authorisations at user and application level - for local and cloud-based resources. |
IA: Permissions management Security administrators can define and check what users are allowed to do in different applications and systems. |
IG: Segregation of Duties (SoD) Managing rules that prevent high-risk groups of access or transaction rights from being assigned to a single person. |
IG: Access verification Checking and verifying user access to applications and resources. |
IG: Role-based access management User access is authorised on the basis of their role which is required to perform their tasks. |
IG: Logging, analysis and reporting Logging user activity and identifying security problems or risks; raising alerts in high-risk situations; suggesting security improvements; taking remedial action; resolving policy breaches; producing compliance reports. |
Core capabilities of IGA
In identity security, the first step is to adopt an identity principle. This involves identifying the current “accessors”; both privileged and non-privileged as well as human and non-human identities. Along with defined responsibilities of the non-human identities, the architecture is defined based on the attributes and properties required, and it is enshrined as an identity principle. This is how you create IGA awareness and build bridges with stakeholders. This is because numerous attributes are required for identity and typically, these are determined and provided by specialist departments. For instance, HR ensures that people are identified and the identity makes use of the first and last name, location, etc.
The second step is to capture business processes so that identity as an actor can be put in context. As a rule, a hybrid approach is chosen here. On one hand, organisational characteristics of the company are identified and this is often referred to as a “top-down” approach. Then the real-world comparison, i.e. whether the business processes are also being correctly implemented on the system side, is then established by means of a “bottom-up” approach. This involves correlating and assessing the user and authorisation data, and drawing conclusions about the organisational conditions.
Due to far-reaching, generally cross-company IGA, there is significant support and commitment from the different stakeholder groups. If this commitment is not forthcoming, resistance can be expected. When talking about stakeholders here, they are very broadly defined in terms of IGA. Among others, stakeholders include management and corporate risk, as well as partner and supplier management, HR, customer representatives, customer stakeholders, etc.
The pre-condition for achieving a broad consensus is to map out the roles and bodies involved and to clarify their respective needs. You need to understand the stakeholders and their needs – irrespective of whether these are legal, organisational or convenience-related factors! You can achieve this through communication that is transparent and recipient-oriented (and wherever possible, personal) with auditors, risk managers, application owners and even end users. Some of you may be thinking to yourselves, “That’s only logical”. But believe me, especially with such extensive programmes, all too soon, well-practiced management principles are rapidly forgotten.
Establishing your Identity Governance & Administration (IGA) will be easier and more effective if it is built on best IAM practices. We recommend that you pay particular attention to the following three points:
1. Define all identity types
Identities are not just linked to people. When developing an IGA strategy, companies should consider all types of human and silicon-based identities – from end users to scripts to applications. These include, among others, clients, partners, suppliers, staff, services, devices or ‘things’. The list seems almost endless…
Reliable identity sources provide vital data for making informed decisions in the authorisation landscape. Therefore you should, define your leading systems of identities and ensure that each human and non-human identity is unique. This is the DNA of the IGA programme for each service and function, such as provisioning, certificates, privileged access or physical access, among others – both for on-premises (LDAP, ADS, etc.) and cloud applications (SaaS, etc.).
2. Proactively identify potential risks across all identity types
Determine the status of your access management, permissions, multi-factor authentication, directory services and identity lifecycle and governance. You need to address the following points:
By authorising audits and assessing the IAM organisation, you can provide information at any time about security-related points such as:
At the same time, systematic auditing provides you with detailed governance documentation.
3. Establish governance
Set up an appropriate authority, such as an IGA committee or an IGA competence centre, to oversee company-wide IGA. It must also have the authority to issue new policies. CISOs should take an IAM leadership role, resulting in improved alignment between identity and security functions. Also, ensure governance by putting in place appropriate control mechanisms and promote collaboration between teams, so that security and operational silos can be avoided and transversal measures can be implemented.
Along with stakeholder consensus, protecting identities and resources are the most fundamental prerequisites for initiating an effective IGA. We would be pleased to assist with progressing towards an identity-centred approach.