IAM Policies for Account Authentication
Setting an IAM Password Policy
Under the AWS Shared Responsibility Model, it is the customer’s responsibility to enforce appropriate IAM policies. PCI Requirement 8.1 stipulates several requirements for PCI-compliant IAM policies, including:
- Unique IDs for all users
- Control the addition, deletion, and modification of user IDs and credentials
- Immediately revoke access for terminated users
- Remove inactive user accounts within 90 days
- Manage third party IDs and remote access
- After six failed access attempts, lock the user out
- Set the lockout duration for at least 30 minutes
- When a session is idle for more than 15 minutes, require reauthentication to reactive the session
Configuring the appropriate settings in your AWS IAM Password Policy is how you will accomplish many of the sub-requirements under PCI Requirement 8.1, as well as using IAM Roles to further limit account access and enforce authentication.
Transcription
When it comes to complying with Requirement 8.1 in the PCI Data Security Standard, you have to put a lot of attention into your IAM hygiene within your AWS environment. The accounts that you’ve created, the accounts that you remove, the password parameters that you’ve implemented for the users within your IAM environment. This is what an auditor will really inspect as they’re trying to determine if you’re complying with PCI Requirement 8.1.
So, let’s talk about a few things that we’re going to walk through with this. First of all, only enabling specific user IDs. You can’t have generic IDs. You can’t have people who are sharing IDs and we do see this a lot. There tend to be a lot of administrative accounts that are shared by multiple people and you can’t do that. You have to have each ID assigned to an individual so there’s accountability for what is done when someone is using that ID. The second thing that we run into quite a bit, even in mature environments, is the inability of removing terminated users from the environment. Most people’s policies will state that they will immediately revoke access to a terminated user. But, having a very defined process so that you do get those accounts out of there or at least disabled when an employee is terminated or has left the company is a very, very important step for complying with Requirement 8.1 because these are the accounts that will be compared against your employee roles to determine if you have any accounts in there for people who are no longer with your organization. Finally, the password parameters are very important for complying with 8.1. You have to have a limit on the number of login attempts that can occur. It can’t be more than six login attempts before the account locks. Locking that account for at least 30 minutes is part of the requirement. Actually, for these capabilities, you’re going to have to look beyond the IAM parameters that are available to you. You’ll have to bring in some other capabilities from third-party resources in order to comply with these particular requirements. Also, when an account is idle for more than 15 minutes, you have to terminate the session and the user would have to log back in again.
Another part of this requirement relates to third-party accounts. We run into this quite frequently, as well, where you have IT providers, or managed services providers, or other vendors who require access to your environment. We’ll go in and we’ll see that they haven’t accessed the environment in a period of time. PCI Requirement 8.1 specifies that you only enable these accounts when it’s necessary for the vendor to do their job or perform their services. Having a process for you to manage that, if you had a vendor for example, who is doing that once a month for you, having a process where you go in and enable that account once a month and have rules around when it is enabled and available for them to utilize it. Finally, you have to have a process to evaluate any unused accounts. I was just looking in an AWS environment yesterday and there was an administrative account that had not been used in over 2,200 days. That’s an example of an account that, once it passes a 90-day threshold, you should disable or remove that account due to inactivity.
These are some of the requirements that you’ll find in 8.1. Please reach out to us and talk to us about any struggles that you’re having because some of these things can be tricky and we’d be happy to help you evaluate that and figure out the best way for your organization to comply with PCI Requirement 8.1.
Related Videos
5 Benchmarks of Role-Based Access Control Service Accounts
AWS Functions to Restrict Database Access
AWS Password Best Practices
AWS Password Expiration Policies
AWS Password Reuse Policy
Access Control Using IAM Instance Roles
Allow Azure Services Access to Storage Accounts
Assign Access Based on Business Need to Know
Assign Appropriate Contacts to Essential Roles
Attaching IAM Policies to Groups or Roles
Avoid Use of the Root Account
Basics of Role Assumption
Best Practices for Change Management in AWS
Best Practices for Password Parameters
Consider an Exclusionary Geographic Access Policy
Create a Review Process for Apps
Create a Review Process of Guest Users
Define Acceptable Use of Technology Part 1
Defining Resources in IAM Policies
Defining Resources in S3 Bucket Policies
Defining Roles and Responsibilities in AWS
Developing a Process for User Authentication
Disable Caching of Second Factor of Authentication Beyond One Day
Disable Public Access Level for Storage Accounts with Blob Containers
Disabling Unused Credentials
Disallow Other Apps to Access Company Data
Do Not Allow Users to Remember MFA on Devices They Trust
Do Not Use API Keys at the Project Level
Documenting a Systems Inventory in AWS
Enable Multi-Factor Authentication for Non-Service Accounts
Enable Multifactor Authentication for Administrators
Enable Multifactor Authentication for All Users
Enabling MFA for All IAM Users
Encrypt Dataproc Cluster Using Customer Managed Encryption Key
Enforce Multifactor Authentication for All Users
Enforce Separation of Duties When Assigning Service Account Roles
Enforce Separation with Access Controls
Enforcing Strong Encryption in AWS
Ensure Corporate Login Credentials are Used
Ensure Guest Accounts Are Restricted
Ensure HTTP(S) Access from the Internet Is Reviewed and Restricted
Ensure KMS Cryptokeys Are Not Publicly Accessible
Ensure Notifications are Enabled for Password Resets
Ensure Only Administrators Can Create Groups
Ensure Service Accounts Can't Access Admin Privileges
Evaluate and Restrict UDP Access from the Internet
Exclusively Use GCP-Managed Service Account Keys
GKE Authentication and Authorization Best Practices
How to Attach IAM Policies to Groups or Roles
How to Check MFA in a Credential Report
How to Check Use of the Root Account
How to Find Administrative Privileges in IAM Policies
How to House Multiple Accounts Within an AWS Organization
How to Modify Password Complexity in a Password Policy
How to Modify Permissions to EBS Snapshots
How to Prevent Password Reuse in a Password Policy
IAM Policies that Address Administrative Privileges
Identifying Unused Credentials in a Credential Report
Identity and Access Management Benchmarks in GKE
Introduction to Amazon S3 Access Points
Introduction to IAM Access Analyzer
MFA for API Calls
Notify Admins of Other Admin Password Resets
Only Allow Administrators to Delete Locked Resources
Only Allow Approved Employees to Invite Guests
Only Allow Trusted Apps to Access Company Data
PCI Requirement 7 – Restrict Access to Cardholder Data by Business Need to Know.mp4
PCI Requirement 7.1 – Limit Access to System Components and Cardholder Data
PCI Requirement 7.1.1 – Define Access Needs for Each Role
PCI Requirement 7.1.2 – Restrict Access to Privileged User IDs to Least Privileges Necessary
PCI Requirement 7.1.3 - Assign access based on individual personnel’s job classification & function
PCI Requirement 7.1.4 – Require Documented Approval by Authorized Parties
PCI Requirement 7.2 – Establish an Access Control System
PCI Requirement 7.2.1 – Coverage of all System Components
PCI Requirement 7.2.2 – Assignment of Privileges Based on Job Function
PCI Requirement 7.2.3 – Default “Deny-All” Setting
PCI Requirement 7.3 – Document Policies & Procedures for Restricting Access to Cardholder Data
PCI Requirement 8 - Identify and Authenticate Access to System Components
PCI Requirement 8.1 – Define and Implement Policies and Procedures to Ensure Proper User Management
PCI Requirement 8.1.2 – Control Addition, Deletion, and Modification of User IDs, Credentials
PCI Requirement 8.1.3 – Immediately Revoke Access for Terminated Users
PCI Requirement 8.1.4 – RemoveDisable Inactive User Accounts Within 90 Days
PCI Requirement 8.1.5 – Manage IDs Used by 3rd Parties to Access, Support, or Maintain System Comps
PCI Requirement 8.1.6 – Limit Repeated Access Attempts by Locking Out User ID After Six Attempts
PCI Requirement 8.1.7 – Set Lockout Duration to a Minimum of 30 Minutes
PCI Requirement 8.1.8 – Require Re-Authentication After 15 Minutes of Inactivity
PCI Requirement 8.2 – Ensure Proper User-Authentication Management by Something You Know
PCI Requirement 8.2.1 – Use Strong Cryptography to Render All Authentication Credentials Unreadable
PCI Requirement 8.2.2 – Verify User Identity Before Modifying Any Authentication Credential
PCI Requirement 8.2.3 – Passwords Require a Min. of Seven Characters and Contain Numbers & Letters
PCI Requirement 8.2.4 – Change User PasswordsPassphrases at Least Once Every 90 Days
PCI Requirement 8.2.5 – New Passwords Can’t Be the Same as Any of the Last Four Passwords Used
PCI Requirement 8.2.6 – Set Passwords for First-Time Use and Upon Reset to a Unique Value
PCI Requirement 8.3 – Secure All Individual Non-Console Administrative Access
PCI Requirement 8.3.1 – Incorporate Multi-Factor Authentication for All Non-Console Access
PCI Requirement 8.3.2 – Incorporate Multi-Factor Authentication for all Remote Network Access
PCI Requirement 8.4 – Document and Communicate Authentication Policies and Procedures to All Users
PCI Requirement 8.5 – Do Not Use Group, Shared, or Generic IDs, or Passwords
PCI Requirement 8.5.1 – Remote Access to Customer Premises Must Use Unique Authentication
PCI Requirement 8.6 – Authentication Mechanisms Must Not Be Shared Among Multiple Accounts
PCI Requirement 8.7 – Restrict All Access to Any Database Containing Cardholder Data
PCI Requirement 8.8 – Ensure Policies & Procedures for Authentication are Documented
Practice Regular Key Rotation for Service Accounts
Prevent Bad Passwords in Azure
Prevent Shared, Group, or Generic Accounts in AWS
Protect Admin Accounts with Security Key Enforcement
Protect Against Malicious Attacks with Azure AD MFA
Protect Resources from Unauthorized Access
Reconfirm User Information Regularly
Regularly Rotate API Keys
Require 2 Ways of Authentication for Resetting Passwords
Require Multifactor Authentication for Administrators
Restrict API Key Use to Specified Hosts and Apps
Restrict API Keys to Applications That Need Access
Restrict Access to Azure Active Directory (ADD)
Restrict Access to Azure Storage From All Networks
Restrict Access to Create Security Groups Only to Administrators
Restrict Access to the Administration Portal
Restrict User Authentication to Trusted Locations
Restrict Users from Adding Apps
Restrict and Review SSH Access from the Internet
Restrict and Secure Your Azure Environment
Restricting Access to EBS Snapshots
Review Internal and External Users Monthly
Review and Restrict RDP Access from the Internet
Risky Sign-Ins: What They Are and How to Prevent Them
Rotating Access Keys
SOC 2 Academy: Access Controls for Remote Employees
SOC 2 Academy: Additional Points of Focus for Logical Access
SOC 2 Academy: Assigning Roles and Responsibilities
SOC 2 Academy: Dealing with External Threats
SOC 2 Academy: How to Perform Thorough Inventory
SOC 2 Academy: Movement of Data
SOC 2 Academy: Preventing and Detecting Unauthorized Software
SOC 2 Academy: Protection Through Logical Access
SOC 2 Academy: Registering Internal and External Users
Securely Store and Access Secrets in Secrets Manager
Support MFA through IAM Policies
Understanding the "Deny All" Function
Use Least Privilege For Users at Project Level Roles
Using IAM Instance Roles for AWS Resource Access
Using IAM Policies
Utilize Private Endpoints to Access Storage Accounts
Utilize the Principle of Least Privilege
Verify Only Administrators Manage Group Membership Access
