0
03

Identity and Access Management Fundamentals

In this topic, you’ll learn about the fundamentals of Identity and Access Management (IAM) that protect our information from unauthorised access, fraud and misdemeanor.

Scroll down
to learn more

The Sage story

Hackers aside, managing information security in a business with 50,000 staff raises the issue of internal breaches of security, whether that’s through malicious or careless behaviour.

We can minimise the risk of unauthorised access, fraud and misdemeanor by ensuring that employees have the access they need to do their job, and this access is justified, approved and used appropriately.

Therefore, it is essential that all CBA’s services comply with the Identity and Access Management (IAM) Standard, which outlines the specific requirements for:

  • Identity and Access Lifecycle Management
  • Role Management
  • Segregation of Duties (SoD) Management
  • Privileged Access Management
  • Authentication Management
  • User Access Reviews
    (explained further in Topic 4)

Let’s look at an example of why this is important. Click play to watch the video.

In 2016, UK firm Sage Group suffered a data breach after an employee accessed confidential client information without authorisation.

Sage provides cloud-based accounting and payroll software for businesses. The data breach affected almost 300 companies, potentially exposing their employees’ bank details and salary information.

The breach has come at a considerable cost to Sage Group - in January 2018 their stock price was at a high of GBP818. By the end of June 2018, it was trading at GBP626.

Access management

Implementing an effective role management strategy ensures that user access is controlled and managed in the context of job functions (e.g. Branch Manager) or specific access to a service (e.g. One.CBA Editor). Where roles provide privileged access (e.g. Administrator access to a database) or pose a higher risk, additional controls must be applied.

The Sage case study really challenges Doug’s thinking. He asks Jamie about his specific responsibilities when it comes to roles management. She describes the key aspects of:

Role profile

The data that provides context or additional information about the role (e.g. role name, role description, role ownership, role risk rating).

Role construct

The core substance of the role (e.g. role type, role classification, role composition, assignment rules, constraints, Segregation of Duties functions, approval workflow, identity lifecycle events, role utilisation).

Roles are living entities that undergo a number of changes over time and must be proactively managed through the role lifecycle (i.e. create, modify, review, retire).

Best practice

As part of his role, Doug is the Service Owner for a loan origination application that is going through an upgrade process.

One of his innovations has been to upgrade the functionality of the service, and he’s created some new roles in the process.

What next steps should he take?

As a Service Owner, Doug owns the role data for his service and ensures all the information about these roles and their entitlements is complete, accurate and remains fit for purpose.

A recent upgrade to the functionality of the service has meant that new roles need to be created. Doug needs to ensure that the requirements for the new roles are properly defined, documented and approved.

Doug’s service has been on-boarded to and is managed by the Group’s centralised Identity and Access Management (IAM) service – Identity Manager. This allows Doug to leverage automated and semi-automated IAM controls that protect his service.

Doug will definitely need to ensure the new roles he has created are updated in Identity Manager, but not just yet.

This becomes clear after he contacts Linda from DPG’s IAM Solution Delivery team. Linda points out that Doug hasn’t provided risk ratings for the roles yet and hasn’t considered any Segregation of Duties (SoD) requirements, which is a problem. Completing this information upfront will ensure that these roles are managed appropriately throughout their lifecycle.

Doug commits to getting back in touch after engaging the right teams to assist with his impact assessments.

Doug engages the right teams to complete his initial change, risk, and Segregation of Duties (SoD) impact assessments. He engages his Line 1 Risk team as he’s going to need some help to ensure the roles are appropriately risk-rated. He also engages the DPG’s Access Control Enablement team to discuss role management minimum standards and SoD in more detail.

Through this process, he identifies:

  • some roles that pose a higher risk (e.g. System Administrator) which will require additional approvals before access can be granted
  • some of the roles overlap in problematic ways, resulting in SoD violations

Doug updates his requirements and raises a service request to engage the DPG IAM Solution Delivery team to ensure the roles are updated in Identity Manager.

What’s Doug’s best way of ensuring these roles are properly assigned?

With the role creation requirements properly scoped for risk and SoD impact, Doug engages Linda to ensure that these roles will be reflected accurately in Identity Manager.

She also ensures they can only be requested and approved by the right people through Identity Manager.

Doug asks what is drift reporting?

Drift reporting shows the discrepancy between roles assigned through an application and what is noted in Identity Manager. It is essential that, where a service has been onboarded to Identity Manager, roles are always assigned and managed through that tool. Roles that are assigned outside of the tool present a risk to CBA, and will be reported.

Yes, that’s right.

Doug should ensure that users are directed to use Identity Manager to request or remove access. He also ensures that Linda and the DPG IAM Solution Delivery team are kept informed of future role modifications to minimise any drift reporting.

Doug asks what is drift reporting?

Drift reporting shows the discrepancy between roles assigned through an application and what is noted in Identity Manager. It is essential that, where a service has been onboarded to Identity Manager, roles are always assigned and managed through that tool. Roles that are assigned outside of the tool present a risk to CBA, and will be reported.

Not quite.

Doug should ensure that users are directed to use Identity Manager to request or remove access. He also ensures that Linda and the DPG IAM Solution Delivery team are kept informed of future role modifications to minimise any drift reporting.

But what should I do if…?

Doug still has some unanswered questions so he gives Jamie a call.

So, what should I do if the service is not required to be onboarded to Identity Manager? What is the process then?

The role management standards still apply – you would still need to conduct all your change, risk and impact assessments and engage Line 1 Risk for assistance as required to ensure roles are appropriately risk-rated and SoD is considered.

And what happens if any of the roles for my service are rated high to very high? Is it the same approval process when employees request access?

Great question. While all role requests require line manager approval, roles with a high or very high rating require additional approvals, usually by people that have the best understanding about the risks and the potential toxic combinations of access. This might be Line 1 Risk, Role Owners or Managers Once Removed.

Privileged access management

Privileged accounts – accounts that have elevated access or permissions – present a high risk to CBA. These accounts are high priority targets for malicious cyber actors, as they can access our most sensitive information and are able to perform special activities, such as installing and modifying software, changing network configurations or bypassing and modifying security controls.

It is essential that privileged access to Doug’s service is tightly managed to prevent unauthorised access to information held on our network. The IAM Standard explains a number of key privileged access management requirements such as:

  • role-based access control
  • registration and auditing of privileged accounts
  • provisions for emergency access and shared and general account management

Further guidance on how to implement these requirements is available in the Privileged Access Management Guideline.

Authentication management

As a Service Owner, Doug also needs to ensure that his service enforces authentication requirements as per the IAM Standard to correctly validate the users of his service as they log on, and protect the confidentiality of authentication credentials. This includes complying with requirements for:

  • strong and secure passwords that are unique to that service (i.e. long, containing a mix of letters, numbers and characters, and not re-used across other work-related or personal accounts)
  • password storage ie using a Group-provisioned solution for password vaulting, and
  • session management ie leveraging the Group’s session management capability through Identity Manager

Call to action

Let’s revisit the key focus areas when it comes to role management and SoD.

As you click each one, imagine how you might fulfil these obligations in practical terms, when managing your service.

Back at work

Browse to the module resources on One.CBA for more information about:

  • Identity and Access Management Standards
  • Role Management and Governance Framework
  • Role Management and Governance Service Domain
  • Segregation of Duties Service Domain
  • Privileged Access Management Guideline

Congratulations, you've finished Topic 3

Select the buttons below to continue.