Select any two versions of this STIG to compare the individual requirements
Select any old version/release of this STIG to view the previous requirements
From the Admin Console: 1. Select Security >> Global Session Policy. 2. In the Default Policy, verify a rule is configured at Priority 1 that is not named "Default Rule". 3. Click the edit icon next to the Priority 1 rule. 4. Verify the "Maximum Okta global session idle time" is set to 15 minutes. If "Maximum Okta global session idle time" is not set to 15 minutes, this is a finding.
From the Admin Console: 1. Go to Security >> Global Session Policy. 2. Select the Default Policy. 3. In the Rules table, make these updates: - Click "Add rule". - Set "Maximum Okta global session idle time" to 15 minutes.
From the Admin Console: 1. Select Applications >> Applications >> Okta Admin Console. 2. In the Sign On tab, under "Okta Admin Console session", verify the "Maximum app session idle time" is set to 15 minutes. If the "Maximum app session idle time" is not set to 15 minutes, this is a finding.
From the Admin Console: 1. Select Applications >> Applications >> Okta Admin Console. 2. In the Sign On tab, under "Okta Admin Console session", set the "Maximum app session idle time" to 15 minutes.
If Okta Services rely on external directory services for user sourcing, this is not applicable, and the connected directory services must perform this function. Go to Workflows >> Automations and verify that an Automation has been created to disable accounts after 35 days of inactivity. If the Okta configuration does not automatically disable accounts after a 35-day period of account inactivity, this is a finding.
From the Admin Console: 1. Go to Workflow >> Automations and select "Add Automation". 2. Create a name for the Automation (e.g., "User Inactivity"). 3. Click "Add Condition" and select "User Inactivity in Okta". 4. In the duration field, enter 35 days and click "Save". 5 Click the edit button next to "Select Schedule". 6. Configure the "Schedule" field for "Run Daily" and set the "Time" field to an organizationally defined time to run this automation. Click "Save". 7. Click the edit button next to "Select group membership". 8. In the "Applies to" field, select the group "Everyone" by typing it into the field. Click "Save". 9. Click "Add Action" and select "Change User lifecycle state in Okta". 10. In the "Change user state to" field, select "Suspended" and click "Save". 11. Click the "Inactive" button near the top of the section screen and select "Activate".
If Okta Services rely on external directory services for user sourcing, this check is not applicable, and the connected directory services must perform this function. From the Admin Console: 1. Go to Security >> Authenticators. 2. Click the "Actions" button next to "Password" and select "Edit". 3. For each Password Policy, verify the "Lock Out" section has the following values: - "Lock out after 3 unsuccessful attempts" is checked. - The value is set to "3". If Okta Services are not configured to automatically lock user accounts after three consecutive invalid login attempts, this is a finding.
From the Admin Console: 1. Go to Security >> Authenticators. 2. Click the "Actions" button next to "Password" and select "Edit". 3. For each Password Policy, ensure the "Lock Out" section has the following values: - "Lock out after 3 unsuccessful attempts" is checked. - The value is set to "3".
From the Admin Console: 1. Go to Security >> Authentication Policies. 2. Click the "Okta Dashboard" policy. 3. Click the "Actions" button next to the top rule and select "Edit". 4. In the "Possession factor constraints are" section, verify the "Phishing resistant" box is checked. This will ensure that only phishing-resistant factors are used to access the Okta Dashboard. If in the "Possession factor constraints are" section the "Phishing resistant" box is not checked, this is a finding.
From the Admin Console: 1. Go to Security >> Authentication Policies. 2. Click the "Okta Dashboard" policy. 3. Click the "Actions" button next to the top rule and select "Edit". 4. In the "Possession factor constraints are" section, ensure the "Phishing resistant" box is checked.
From the Admin Console: 1. Go to Security >> Authentication Policies. 2. Click the "Okta Admin Console" policy. 3. Click the "Actions" button next to the top rule and select "Edit". 4. In the "Possession factor constraints are" section, verify the "Phishing resistant" box is checked. This will ensure that only phishing-resistant factors are used to access the Okta Dashboard. If in the "Possession factor constraints are" section the "Phishing resistant" box is not checked, this is a finding.
From the Admin Console: 1. Go to Security >> Authentication Policies. 2. Click the "Okta Admin Console" policy. 3. Click the "Actions" button next to the top rule and select "Edit". 4. In the "Possession factor constraints are" section, ensure the "Phishing resistant" box is checked.
Attempt to log in to the Okta tenant and verify the DOD-approved warning banner is in place. If the required warning banner is not present and complete, this is a finding.
Follow the supplemental instructions in the "Okta DOD Warning Banner Configuration Guide" provided with this STIG package.
From the Admin Console: 1. Go to Security >> Authentication Policies. 2. Click the "Okta Admin Console" policy. 3. Click the "Actions" button next to the top rule and select "Edit". 4. In the "User must authenticate with" field, verify that either "Password/IdP + Another factor" or "Any 2 factor types" is selected. If either of these settings is incorrect, this is a finding.
From the Admin Console: 1. Go to Security >> Authentication Policies. 2. Click the "Okta Admin Console" policy. 3. Click the "Actions" button next to the top rule and select "Edit". 4. In the "User must authenticate with" field, select either "Password/IdP + Another factor" or "Any 2 factor types".
From the Admin Console: 1. Go to Security >> Authentication Policies. 2. Click the "Okta Dashboard" policy. 3. Click the "Actions" button next to the top rule and select "Edit". 4. In the "User must authenticate with" field, verify that either "Password/IdP + Another factor" or "Any 2 factor types" is selected. If either of these settings is incorrect, this is a finding.
From the Admin Console: 1. Go to Security >> Authentication Policies. 2. Click the "Okta Dashboard" policy. 3. Click the "Actions" button next to the top rule and select "Edit". 4. In the "User must authenticate with" field, select either "Password/IdP + Another factor" or "Any 2 factor types".
From the Admin Console: 1. Select Security >> Authenticators. 2. Click the "Actions" button next to the "Password" row and select "Edit". 3. For each listed policy, verify the "Minimum Length" field is set to at least "15" characters. If any policy is not set to at least "15", this is a finding.
From the Admin Console: 1. Select Security >> Authenticators. 2. Click the "Actions" button next to the "Password" row and select "Edit". 3. For each listed policy: - Click "Edit". - Set the "Minimum Length" field to at least "15" characters.
From the Admin Console: 1. Select Security >> Authenticators. 2. Click the "Actions" button next to the "Password" row and select "Edit". 3. For each listed policy, verify "Upper case letter" is checked. For each policy, if "Upper case letter" is not checked, this is a finding.
From the Admin Console: 1. Select Security >> Authenticators. 2. Click the "Actions" button next to the "Password" row and select "Edit". 3. For each listed policy: - Click "Edit". - Set "Upper case letter" to checked.
From the Admin Console: 1. Select Security >> Authenticators. 2. Click the "Actions" button next to the "Password" row and select "Edit". 3. For each listed policy, verify "Lower case letter" is checked. For each policy, if "Lower case letter" is not checked, this is a finding.
From the Admin Console: 1. Select Security >> Authenticators. 2. Click the "Actions" button next to the "Password" row and select "Edit". 3. For each listed policy: - Click "Edit". - Set "Lower case letter" to checked.
From the Admin Console: 1. Select Security >> Authenticators. 2. Click the "Actions" button next to the "Password" row and select "Edit". 3. For each listed policy, verify "Number (0-9)" is checked. For each policy, if "Number (0-9)" is not checked, this is a finding.
From the Admin Console: 1. Select Security >> Authenticators. 2. Click the "Actions" button next to the "Password" row and select "Edit". 3. For each listed policy: - Click "Edit". - Set "Number (0-9)" to checked.
From the Admin Console: 1. Select Security >> Authenticators. 2. Click the "Actions" button next to the "Password" row and select "Edit". 3. For each listed policy, verify "Symbol (e.g., !@#$%^&*)" is checked. For each policy, if "Symbol (e.g., !@#$%^&*)" is not checked, this is a finding.
From the Admin Console: 1. Select Security >> Authenticators. 2. Click the "Actions" button next to the "Password" row and select "Edit". 3. For each listed policy: - Click "Edit". - Set "Symbol (e.g., !@#$%^&*)" to checked.
From the Admin Console: 1. Select Security >> Authenticators. 2. Click the "Actions" button next to the "Password" row and select "Edit". 3. For each listed policy, verify "Minimum password age is XX hours" is set to at least "24". For each policy, if "Minimum password age is XX hours" is not set to at least "24", this is a finding.
From the Admin Console: 1. Select Security >> Authenticators. 2. Click the "Actions" button next to the "Password" row and select "Edit". 3. For each listed policy: - Click "Edit". - Set "Minimum password age is XX hours" to at least "24".
From the Admin Console: 1. Select Security >> Authenticators. 2. Click the "Actions" button next to the "Password" row and select "Edit". 3. For each listed policy, verify "Password expires after XX days" is set to "60". For each policy, if "Password expires after XX days" is not set to "60", this is a finding.
From the Admin Console: 1. Select Security >> Authenticators. 2. Click the "Actions" button next to the "Password" row and select "Edit". 3. For each listed policy: - Click "Edit". - Set "Password expires after XX days" to "60".
From the Admin Console: 1. Go to Reports >> Log Streaming. 2. Verify that a Log Stream connection is configured and active. Alternately, interview the information system security manager (ISSM) and verify that an external Security Information and Event Management (SIEM) system is pulling Okta logs via an Application Programming Interface (API). If either of these is not configured, this is a finding.
From the Admin Console: 1. Go to Reports >> Log Streaming. 2. Select either "AWS EventBridge" or "Splunk Cloud" and click "Next". 3. Complete the necessary fields and click "Save". If Log Streaming is not an option because the SIEM required is not an option, customers can use the Okta Log API to export system logs in real time.
From the Admin Console: 1. Select Security >> Global Session Policy. 2. In the Default Policy, verify a rule is configured at Priority 1 that is not named "Default Rule". 3. Click the "Edit" icon next to the Priority 1 rule. 4. Verify "Maximum Okta global session lifetime" is set to 18 hours. If the above is not set, this is a finding.
From the Admin Console: 1. Go to Security >> Global Session Policy. 2. Select the Default Policy. 3. In the Rules table, make these updates: - Click "Add rule". - Set "Maximum Okta global session lifetime" to 18 hours.
From the Admin Console: 1. Go to Security >> Authenticators. 2. Verify that "Smart Card Authenticator" is listed and has "Status" listed as "Active". If "Smart Card Authenticator" is not listed or is not listed as "Active", this is a finding.
From the Admin Console: 1. Go to Security >> Authenticators. 2. In the "Setup" tab, click "Add authenticator". 3. Select the configured Smart Card Identity Provider and finish configuration.
From the Admin Console: 1. Go to Security >> Authenticators. 2. From the "Setup" tab, select "Edit Okta Verify". 3. Review the "FIPS Compliance" field. If FIPS-compliant authentication is not enabled, this is a finding.
From the Admin Console: 1. Go to Security >> Authenticators. 2. From the "Setup" tab, select "Edit Okta Verify". 3. In the "FIPS Compliance" field, choose whether users enrolling in Okta Verify can use FIPS-compliant devices only or any device. 4. Click "Save" after making any changes.
From the Admin Console: 1. Select Security >> Global Session Policy. 2. In the Default Policy, verify a rule is configured at Priority 1 that is not named "Default Rule". 3. Click the "Edit" icon next to the Priority 1 rule. 4. Verify "Okta global session cookies persist across browser sessions" is set to "Disabled". If the above it not set, this is a finding.
From the Admin Console: 1. Go to Security >> Global Session Policy. 2. Select the Default Policy. 3. In the "Rules" table, make these updates: - Click "Add rule". - Set "Okta global session cookies persist across browser sessions" to Disable.
From the Admin Console: 1. Select Security >> Identity Providers (IdPs). 2. Review the list of IdPs with "Type" as "Smart Card". If the IdP is not listed as "Active", this is a finding. 3. Select Actions >> Configure. 4. Under "Certificate chain", verify the certificate is from a DOD-approved CA. If the certificate is not from a DOD-approved CA, this is a finding.
From the Admin Console: 1. Go to Security >> Identity Providers. 2. Click "Add identity provider." 3. Click "Smart Card IdP". Click "Next". 4. Enter the name of the identity provider. 5. Build a certificate chain: - Click "Browse" to open a file explorer. Select the certificate file to add and click "Open". - To add another certificate, click "Add Another" and repeat step 1. - Click "Build certificate chain". On success, the chain and its certificates are shown. If the build failed, correct any issues and try again. - Click "Reset certificate chain" if replacing the current chain with a new one. 6. In "IdP username", select the "idpuser.subjectAltNameUpn" attribute. This is the attribute that stores the Electronic Data Interchange Personnel Identifier (EDIPI) on the CAC. 7. In the "Match Against" field, select the Okta Profile Attribute in which the EDIPI is to be stored.
From the Admin Console: 1. Navigate to Security >> Authenticators. 2. Click the "Actions" button next to the Password authenticator and select "Edit". 3. Under the "Password Settings" section, verify the "Common Password Check" box is checked. If "Common Password Check" is not selected, this is a finding.
From the Admin Console: 1. Navigate to Security >> Authenticators. 2. Click the "Actions" button next to the Password authenticator and select "Edit". 3. Under the "Password Settings" section, check the "Common Password Check" box.
From the Admin Console: 1. Select Security >> Authenticators. 2. Click the "Actions" button next to the "Password row" and select "Edit". 3. For each listed policy, verify "Enforce password history for last XX passwords" is set to "5". If any policy is not set to at least "5", this is a finding.
From the Admin Console: 1. Select Security >> Authenticators. 2. Click the "Actions" button next to the "Password" row and select "Edit". 3. For each listed policy: - Click "Edit". - Set "Enforce password history for last XX passwords" to "5".