Identity and Access Management (IAM)

In the second article on coding securely, IAM is another critical part of every cybersecurity program; as without having a plan to provide employees with the appropriate access levels, the rest of the program is almost meaningless. IAM sounds easy on the surface, but it is very complex to implement and takes attention to the details and maintenance for these privileges can be someone’s full time job. IAM is not just about password management, it is a comprehensive lifecycle management program regarding the:

• ?Creation/changes/deletion of privileges and authorizations to access data, systems, and applications
• Access privileges and authorizations for on-premise environments or within federated domains in the cloud
• Set up of single sign-on, multifactor authentication
• Access controls and privileged access management (PAM) when elevated rights for service accounts and integrations are needed
• Oversight and governance for compliance audits?

IAM starts in the human resources department, where a structure is created to look at positions, job levels, titles and departments that fall into several salary bands or ranges. Once the structure for HR is prepared, the next part of the IAM complexity starts – and that is breaking down by title, job level, department, and environment to determine the access needed by data set. This is further broken down by read or write access and for write access – includes a set of checkpoints and approvals to ensure that fraudulent activity does not occur. The following is not meant to be an exhaustive list, as there are many use cases that need these access checkpoints: HR systems (promotions, compensation, investment, benefits), financial (accounts payable, bank information), product information, supply chain transfers, engineering code and releases.

There is a chapter in my new book (link below) on Zero Trust and the approaches to IAM. This article starts to show where the process becomes more difficult, as the next step is to determine if the data has been mapped and then decisions need to be made as to who should have access to the data, how much access should be granted and the duration of the access. The data mapping includes where information is stored, how it’s used, how data is governed and the oversight for granting privileges. Multiple this exercise by the number of applications that your company has and IAM becomes complex.

Mapping the data is only one part of the exercise. The other is to create RACI charts (in my opinion) that determine the access levels for each position, and the subsequent approvals needed to make specific changes. Having this level of detail makes the IAM program much easier to build.

For engineering teams, the process isn’t any different, but there is another component and that is who has access to production environments, root environments, password vaults, source code libraries, service account keys and API tokens – otherwise referred to as admin rights and privilege access management or PAM. PAM is a topic for another article, though it is safe to mention here that having admin and PAM access to environments is literally having the keys to the kingdom and these keys should be well managed and protected. Take the example of LastPass, where a lead engineer’s home computer was comprised by a cybercriminal who installed a keylogger and when the engineer logged into his work environments with a non-company device, the hacker gained access to the master password vault and the access privileges to source code libraries and customer passwords in a massive breach that shook customer confidence. Having a higher level of privilege should be taken seriously and not passed out generously.

Lastly, a consideration of the audit process and external reviews for certification or regulatory requirements is one more stage in managing identities. Not to be taken lightly, as a CISO, I’ve had the opportunity to sit in front of auditors and in my program, I know the answers to their questions on how far up the chain of command does privilege go. Better said – not all executives need to have full access to every system or functionality in the organization – and this includes the CISO. This is one area where many companies get wrong and give away privileges to those that don’t need them. The rule of thumb is – if the amount of privilege is needed to complete one’s area of responsibility, then the access should be granted. If it isn’t needed, then access should not be given.

Think about it this way – if the company grants application access to every employee in every department – who’s left to watch over the data when it’s downloaded, changed, or deleted by an employee or cyber attacker?

For more information, read my new book: https://a.co/d/cEbRLlI

?