Identity and Access Management

Identity and Access Management (IAM) is the framework of policies, processes, and technologies that manage digital identities and control access to resources. In the context of SY0-701, IAM is about ensuring that only authorized users, devices, or services can access specific data or systems. The core components are identification (claiming an identity), authentication (proving that identity), authorization (determining what that identity can do), and accounting (logging what was done). These four are often abbreviated as IAAA (Identification, Authentication, Authorization, Accounting).

Authentication is based on three factors: something you know (e.g., password, PIN), something you have (e.g., smart card, token, phone), and something you are (e.g., fingerprint, retina scan). SY0-701 emphasizes multi-factor authentication (MFA), which requires two or more factors from different categories. For example, a password (knowledge) plus a one-time code from an authenticator app (possession) is MFA. Two-step verification (e.g., password + email code) is not necessarily MFA if both steps are from the same factor (knowledge). The exam tests your ability to identify true MFA scenarios.

Once authenticated, a user needs authorization to access resources. Common models include: - Discretionary Access Control (DAC): The owner of the resource decides who can access it. Common in file systems (e.g., Linux file permissions). - Mandatory Access Control (MAC): Access is based on labels and clearances managed by a central authority. Used in military and high-security environments. - Role-Based Access Control (RBAC): Access is based on roles assigned to users. For example, "HR Manager" role has access to employee records. - Attribute-Based Access Control (ABAC): Access decisions are based on attributes (user, resource, environment). For example, "allow access if user is in finance department AND time is during business hours AND resource is the accounting system." ABAC is more flexible and is increasingly used in cloud environments.

An Identity Provider (IdP) is a system that creates, maintains, and manages identity information and provides authentication services. Examples include Microsoft Azure AD, Okta, and Google Workspace. Federation allows users from one organization to access resources in another organization using their home credentials. This is achieved through trust relationships and standards like Security Assertion Markup Language (SAML), OAuth 2.0, and OpenID Connect (OIDC). SAML is XML-based and commonly used for enterprise single sign-on (SSO). OAuth 2.0 is a delegation framework for token-based authorization, while OIDC is an authentication layer built on OAuth 2.0.

SSO allows a user to authenticate once and gain access to multiple applications without re-entering credentials. This reduces password fatigue but creates a single point of failure. If an attacker compromises the SSO session token, they can access all linked applications. Session management involves creating, maintaining, and destroying sessions. Session tokens should be random, use secure transmission (HTTPS), and have short lifetimes. The OWASP recommends using HttpOnly and Secure flags for cookies, and implementing session timeout after inactivity.

PAM focuses on controlling and monitoring access for privileged users (e.g., administrators, root accounts). These accounts have elevated permissions and are prime targets for attackers. PAM solutions enforce least privilege, rotate passwords periodically, and record sessions for audit. For example, a PAM tool like CyberArk or HashiCorp Vault can provide just-in-time (JIT) access, where a user requests temporary admin rights for a specific task. The exam covers concepts like password vaulting, session recording, and approval workflows.

ACLs are lists of permissions attached to an object (file, directory, network resource). They specify which subjects (users, groups) have what type of access (read, write, execute). In networking, ACLs filter traffic based on source/destination IP, port, and protocol. For example, a router ACL might allow inbound HTTP traffic (TCP 80) from any source to a web server. SY0-701 expects you to understand the difference between discretionary ACLs (where the owner controls permissions) and system ACLs (used by the OS for auditing).

Proper account management includes provisioning, review, and deprovisioning. Provisioning creates accounts with appropriate privileges. Review ensures accounts are still needed and permissions are correct. Deprovisioning disables or deletes accounts when users leave or change roles. Common mistakes include orphaned accounts (accounts for former employees still active) and privilege creep (users accumulating excessive permissions over time). The exam emphasizes the principle of least privilege and the need for regular audits.

Several protocols are used for authentication in networks: - Kerberos: A ticket-based authentication protocol used in Active Directory. It uses symmetric key cryptography and a trusted third party (Key Distribution Center). Common ports: UDP 88 (Kerberos), UDP 464 (Kerberos password change). - LDAP: Lightweight Directory Access Protocol (port 389 for unencrypted, 636 for LDAPS). Used to query and modify directory services like Active Directory. - RADIUS: Remote Authentication Dial-In User Service (ports 1812/1813 for authentication/accounting, or 1645/1646 legacy). Used for network access control (e.g., VPN, Wi-Fi). - TACACS+: Terminal Access Controller Access-Control System Plus (port 49). Cisco-proprietary, separates authentication, authorization, and accounting. - 802.1X: Port-based network access control. Uses EAP (Extensible Authentication Protocol) over LAN. Common in enterprise Wi-Fi and wired networks.

Common threats include: - Credential Stuffing: Using stolen username/password pairs from one breach to try on other sites. Mitigation: MFA, account lockout, rate limiting. - Password Spraying: Trying a few common passwords against many accounts. Mitigation: strong password policies, MFA, monitoring for multiple failed logins. - Pass-the-Hash: Attacker captures a hash and uses it to authenticate without knowing the plaintext password. Mitigation: use Kerberos instead of NTLM, restrict local admin privileges, enable Credential Guard. - Privilege Escalation: Attacker gains higher permissions than intended. Can be vertical (user to admin) or horizontal (user to another user). Mitigation: least privilege, PAM, regular permission audits. - Social Engineering: Phishing, vishing, or pretexting to obtain credentials. Mitigation: user training, MFA, email filtering.

Implement multiple layers: strong password policies, MFA, least privilege, regular audits, session timeouts, and monitoring. Use a SIEM to correlate logs from authentication servers, firewalls, and endpoints. For example, a SIEM alert might trigger on a user logging in from two different geographic locations within an impossible time frame, indicating a possible credential theft.

Scenario 1: SOC Analyst Responding to a Brute Force Attack

A SOC analyst sees a surge in failed logins (Event ID 4625) for multiple user accounts from a single IP address. The SIEM shows 1000 failed attempts in 5 minutes. The analyst checks the account lockout policy (e.g., 10 attempts in 15 minutes). The accounts are locked out, but the attacker continues trying other accounts. The analyst blocks the IP on the firewall and enables MFA for all external logins. The correct response is to identify the source IP, block it, and reset passwords for affected accounts. A common mistake is to assume lockout is sufficient; attackers often use password spraying, which avoids lockout by trying a few passwords on many accounts. The analyst should also check for successful logins from the same IP (Event ID 4624) to see if any accounts were compromised.

Scenario 2: Privilege Escalation via Service Account

An engineer notices that a service account (svc_backup) has been added to the Domain Admins group. The change log shows Event ID 4732 (a member was added to a security-enabled global group) from an admin workstation. The engineer reviews the change request—none exists. The incident response team investigates: the admin's credentials were phished, and the attacker used them to escalate privileges. The correct response is to remove the service account from Domain Admins, reset the admin's password, and audit all changes made by that admin. A common mistake is to only remove the service account without investigating the root cause. The team should also check for other unauthorized group memberships and potential persistence mechanisms.

Scenario 3: MFA Bypass via Session Token Theft

A user reports receiving MFA push notifications for logins they didn't attempt. The SIEM shows successful logins from an IP in a different country. The user's session token was stolen via a man-in-the-middle attack (e.g., using a rogue Wi-Fi). The analyst revokes all active sessions, resets the user's password, and forces MFA re-enrollment. The correct response also includes reviewing the user's recent activity for data exfiltration. A common mistake is to only change the password, leaving the session token valid. The analyst should also check for similar attacks on other users and implement token binding (e.g., using certificate-based authentication).