Identities are one of the most important security layers in modern organizations. Identities, and the accounts they are connected to, allow those organizations to control who has access to their systems and services; to identify the actions that users, systems, and services are performing; and to control the rights that those accounts have and don't have.
All of that means that a well-designed identity and access management architecture and implementation is critical to how organizations work.
🪪What is Identity?
Identities are the sets of claims made about a subject. Subjects are typically people, applications, devices, or organizations, but the most common application of identity is to individuals.
Identities are typically linked to information about the subject, including details that are important to the use of their identity. This information includes attributes, or information about the subject.
🆔Identity Provider (IDP)
An Identity Provider (IdP) is a system that creates, maintains, and manages identity information for principals while providing authentication services to relying applications within a federation or distributed network.
In the context of online applications, an Identity Provider is a service that verifies the identity of users and sends data about those users to a service provider.
This process often involves the use of security tokens which contain assertions about the identity and authentication status of a user. Examples of Identity Providers include services like Google, Facebook, and Microsoft, which allow you to use your respective Google, Facebook, or Microsoft credentials to log into third-party applications.
This is possible because those applications trust the assertions made by these Identity Providers.
🗒️Attributes
In the context of Identity and Access Management (IAM), Attributes are specific pieces of data that define specific characteristics of an identity. They provide detailed information about a user that can be used to make decisions about their access rights.
Attributes can include a wide range of information, such as:
Any other information that might be relevant to determining a user's access rights These attributes can be used in attribute-based access control (ABAC) systems to make fine-grained access decisions.
For example, a rule might be set up to only allow users with the attribute "Department: Finance" and "Role: Manager" to access certain financial reports. This allows for more flexible and precise control than role-based access control (RBAC) systems, which only consider a user's role when making access decisions.
📜Certificates
Certificates, specifically digital certificates, are used in cybersecurity to assert or claim an identity by providing a means of proving the identity of a person, device, or website over the internet using these digitally signed certificates.
Here's a simplified explanation of how it works:
Issuance: A trusted third party, known as a Certificate Authority (CA), issues a digital certificate. The certificate includes the public key of the entity (person, device, or website), information about the identity of the entity, and a digital signature from the CA.
The CA verifies the identity of the entity before issuing the certificate. Distribution: The entity (now known as the certificate holder) can distribute its certificate to anyone who needs to verify its identity.
For example, a secure website will send its certificate to your web browser when you connect to it. Verification: When you receive a certificate, you can verify the identity of the certificate holder by checking the CA's digital signature on the certificate.
If the signature checks out, you can be confident that the certificate is legitimate and hasn't been tampered with. Usage: Once you've verified the certificate, you can use the public key it contains to set up a secure connection with the certificate holder.
For example, in SSL/TLS, the client uses the server's public key to encrypt a shared secret, which is then used to encrypt the rest of the communication. In this way, certificates provide a way to assert an identity in a way that's difficult to forge, because only the CA has the private key needed to create a valid digital signature. This makes them a crucial tool for establishing trust over the internet
🪙Tokens
Tokens are used to establish and convey trust between different components of a system. When a user or application authenticates with a system, they are often issued a token.
This token can then be presented as proof of authentication when making requests to other parts of the system. Hardware Tokens: These are physical devices that generate secure authentication credentials. They are often used in multi-factor authentication systems.
Hardware Tokens may plug in via USB, or connect via Bluetooth or other means to present a certificate or other information.
🔑SSH Keys
SSH keys are a pair of cryptographic keys that are used for authentication when logging into servers using the Secure Shell (SSH) protocol. They offer a more secure alternative to password-based authentication.
The pair of keys consists of a private key and a public key:
Private Key: This key is kept secret and secure by the user. It should never be exposed to the outside world. The private key is used to create a digital signature for the SSH session. Public Key: This key, as the name suggests, is public and can be freely shared. It is typically stored on the server in a special file (usually ~/.ssh/authorized_keys). The public key is used to verify the digital signature created by the corresponding private key. When a client attempts to connect to an SSH server, the server uses the public key to "challenge" the client. The client must respond correctly to the challenge by using its private key to generate a correct response.
If the response is correct, the server knows that the client possesses the correct private key and grants access. SSH keys provide a more secure method of authentication than passwords, as they are much more difficult to brute-force. They are also convenient for automated, passwordless logins for scripts and system tasks.
💳Smart Cards
Smart Cards are physical cards that have an embedded integrated circuit chip. They can be used to store data, but more importantly, they can process data.
This processing capability distinguishes smart cards from traditional cards that only store data, like a magnetic stripe card. There are two broad categories of smart cards:
Contact Smart Cards: These require insertion into a smart card reader. The reader makes contact with the card chip, allowing data to be read from and written to the card. Contactless Smart Cards: These use radio frequency identification (RFID) technology to communicate with a reader. They only need to be near the reader to operate. In the context of cybersecurity and Identity and Access Management (IAM), smart cards are often used for authentication purposes.
They can:
store cryptographic keys and certificates perform operations like encryption and digital signing This makes them a secure form of two-factor authentication.
For example:
A user might insert a smart card into a reader and then enter a PIN. The smart card verifies the PIN, performs a cryptographic operation using a stored private key, and sends the result to the system. The system can then verify this result using the corresponding public key, thus authenticating the user.
📚Account Types
In Identity and Access Management (IAM), there are several types of accounts that can be used to manage access to resources. Here are some of the most common types:
These are the most common type of account. They are associated with an individual user and typically have permissions that allow the user to perform their job functions. User accounts are often protected with a password and may also require additional forms of authentication. Service Accounts
These accounts are used by applications or services to interact with each other. For example, a service account might be used by a web server to access a database. Service accounts often have broad permissions and are typically protected with long, complex passwords or keys that are not known to users. Administrator Accounts
These accounts have elevated permissions that allow them to manage systems and applications. They can typically create, modify, and delete other accounts, change system configurations, and perform other high-level tasks. Because of their powerful capabilities, administrator accounts are a prime target for attackers and need to be carefully protected. Privileged User Accounts
These accounts are similar to administrator accounts but are typically associated with a specific individual and have permissions that are more narrowly scoped. For example, a privileged user account might have the ability to manage user accounts within a specific department. Shared Accounts
These accounts are used by multiple individuals. They are generally discouraged in most security frameworks due to the lack of individual accountability they provide. However, they may be used in certain situations, such as for a generic email account that is accessed by multiple people. Guest Accounts
These accounts have limited permissions and are typically used to provide temporary access to a system or service. For example, a guest account might be used to allow a contractor to access a system for a limited period of time.
📖Account Policies and Controls
Account Policies are set to provide controls about how and when accounts can be used, to control password complexity, lifespan, and other details.
Password Policies: These policies govern the creation and management of passwords. They typically include rules about:
Password complexity: Requirements for including numbers, symbols, uppercase and lowercase letters. Password length: Minimum and maximum password lengths. Password history: Preventing the reuse of previous passwords. Password expiration: How often users must change their passwords. Password storage: Ensuring passwords are stored securely, often hashed and salted. Account Lockout Policies: These policies protect against brute-force attacks by locking an account after a certain number of failed login attempts. They may specify:
Lockout threshold: The number of failed attempts before lockout. Lockout duration: How long the account is locked. Reset time: The period after which the count of failed attempts is reset. Time-based login in Identity and Access Management (IAM) refers to the practice of restricting user access to a system based on the time of day or week. This is also known as time-based access control or temporal access control.
By restricting access to certain times, organizations can reduce the window of opportunity for attackers, especially if those times align with normal working hours when monitoring and incident response capabilities are most active. In Identity and Access Management (IAM), the Network Location of a system can be a crucial factor in determining access controls. This concept is often referred to as location-based access control or geolocation-based access control.
It's important to note that location-based access control is not foolproof. IP addresses can be spoofed, and the geographic location associated with an IP address is not always accurate. Therefore, it should be used as part of a multi-layered security approach, in conjunction with other controls such as strong authentication methods, time-based access controls, and regular monitoring and auditing of access logs. Geofencing, geotagging, and geolocation are all techniques that use geographic information to enhance security in Identity and Access Management (IAM). Here's how each one is used:
Geolocation: This is the process of determining the geographic location of a device or user, often through the IP address, GPS data, or other location services. In IAM, geolocation can be used to enforce location-based access controls. For example, an organization might only allow access to certain systems from specific countries or regions. If a login attempt is made from an IP address outside of these areas, access could be denied. This can help protect against attacks from foreign sources or unauthorized remote access. Geographic information is also used to determine if an impossible travel time issue is occurring where a user logs in from one place and then another with enough distance between the two to ensure that the user cannot have traveled to the new location in the time given. Geofencing: This involves setting up virtual boundaries around a specific geographic area. When a device enters or leaves this area, a notification or action can be triggered. In terms of IAM, geofencing can be used to restrict access to systems based on the user's physical location. For instance, access to sensitive systems could be limited to devices within the company's physical offices. If a device attempts to access the system from outside this geofence, access could be denied or additional authentication could be required. Geotagging: This is the process of adding geographic information, such as latitude and longitude coordinates, to various types of media. In the context of IAM, geotagging can be used for auditing and monitoring purposes. For example, if a user performs an action on a system, the geographic location of the device could be recorded along with the action. This can provide valuable context for security audits and investigations. If suspicious activity is detected, the geotag can help determine if the action was performed from a known or expected location.
Disabling Accounts
In cases where accounts need to be terminated due to compromise or lifecycle changes like termination or retirement, or if other issues occur, disabling accounts is an important option.
Disabled accounts, rather than deleted accounts, can be a cause for concern, since they may still have privileges that could be used by an attacker if the account was restored on purpose or by accident. Thus, account audits often review disabled accounts to see if they are managed well and if the organization has a habit of reenabling them or validates why they were reenabled. Account Audits help to make sure that accounts are well managed, that accounts have the proper account permissions, and that appropriate controls are in place.
Account audits, which may be manual or automatic, focus on ensuring that accounts are configured as expected with appropriate permissions and rights based on the user's role or the organization's rules and standards for that type of account or user.
Access Policies
Systems also implement access control schemes to determine which users, services, and programs can access various files or other objects that they host.
Discretionary Access Control (DAC): In DAC, the owner of the resource decides who is allowed to access it. The owner can grant permissions to other users or groups. This is the least restrictive type of access control and is commonly used in file systems and databases. Mandatory Access Control (MAC): In MAC, access to resources is controlled by a central authority based on predefined policies. Users are given security labels (such as "confidential" or "top secret"), and resources are given security classifications. A user can only access a resource if their security label matches or exceeds the resource's security classification. This is a very strict form of access control often used in military or government settings. Role-Based Access Control (RBAC): In RBAC, access to resources is based on the user's role within the organization. Users are assigned roles (such as "employee", "manager", or "administrator"), and each role has a set of permissions associated with it. When a user is assigned a role, they automatically get the permissions associated with that role. This is a very flexible and scalable form of access control that is widely used in businesses and organizations. Attribute-Based Access Control (ABAC): In ABAC, access to resources is based on attributes associated with the user, the resource, the action, and the context. Attributes can include things like the user's department, the resource's classification, the current time, or the user's location. Policies can be very granular, such as "users in the finance department can view financial documents during business hours from the office". ABAC is a very flexible and powerful form of access control, but it can also be complex to manage. Rule-Based Access Control: In this model, access is granted or denied to resource objects based on a set of rules defined by a system administrator. For example, a rule might be set to deny access to a particular system between the hours of 8 PM and 6 AM. 
3.7 Given a scenario, implement identity and account management controls
