Skip to content

Commit

Permalink
⭐️ Okta security policies - ignore (#147)
Browse files Browse the repository at this point in the history 
This PR (mondoohq/cnquery#1048) should go
through in the next release for testing the new resources which has been
added!

---------

Signed-off-by: Hossein Rouhani <[email protected]>
Signed-off-by: Patrick Münch <[email protected]>
Co-authored-by: Patrick Münch <[email protected]>
  • Loading branch information
@HRouhani @atomic111
HRouhani and atomic111 authored Mar 14, 2023
1 parent 0c278c8 commit a861727
Show file tree
Hide file tree
Showing 2 changed files with 215 additions and 16 deletions.
1 change: 0 additions & 1 deletion .github/actions/spelling/expect.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -267,4 +267,3 @@ YWQ
auditevent
backchannel
superadmin
backchannel
230 changes: 215 additions & 15 deletions core/mondoo-okta-security.mql.yaml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -81,6 +81,10 @@ policies:
mondoo-okta-security-okta-users-unlock: null
mondoo-okta-security-okta-auth-swa-critical: null
mondoo-okta-security-okta-mfa-sign-in: null
mondoo-okta-security-okta-limit-superadmin: null
mondoo-okta-security-okta-mfa-strong-factor: null
mondoo-okta-security-okta-mfa-password-and-another-strong-factor: null
mondoo-okta-security-okta-mfa-password-reauthenticate: null
queries:
- uid: mondoo-okta-security-okta-mfa-access
title: Ensure MFA is active for everybody accessing Okta platform
Expand All @@ -95,7 +99,7 @@ queries:
Run the following query:
```mql
```bash
cnspec run okta -c "okta.policies.signOn.all(_.rules.all(status == "ACTIVE"))" --organization <org-name> --token <OKTA_TOKEN>
cnspec run okta -c "okta.policies.signOn.all(_.rules.all(actions["signon"]["requireFactor"] == true))" --organization <org-name> --token <OKTA_TOKEN>
```
Expand Down Expand Up @@ -137,7 +141,7 @@ queries:
desc: |
Session lifetime determines the maximum idle time of an end user's sign-on session to Okta. By enforcing a limited session lifetime for users, admins reduce the window of time wherein a malicious third party could attempt to access a user's applications from an active session.
This is especially important considering the workforce is no longer strictly confined to within the walls of an office. This functionality is a must for any organization with employees, contractors, and partners that work from home or other remote locations like coffee shops and airports.
This is especially important considering the workforce is no longer strictly confined to within the walls of an office. This functionality is a must for any organization with employees, contractors, and partners that work from home or other remote locations like coffee shops and airports.
The maximum session lifetime ensures that a session will expire after this maximum session time even if idle time never expires. Setting an upper bound minimizes the risk of session cookies misuse or hijacking.
User session will expire when the user has been inactive on Okta for the set time period, regardless of Max Okta session lifetime.
Expand All @@ -148,7 +152,7 @@ queries:
Run the following query:
```mql
```bash
cnspec run okta -c "okta.policies.signOn.all(_.rules.all(actions["signon"]["session"]["maxSessionIdleMinutes"] <= 120))" --organization <org-name> --token <OKTA_TOKEN>
cnspec run okta -c "okta.policies.signOn.all(_.rules.all(actions["signon"]["session"]["maxSessionLifetimeMinutes"] <= 1440))" --organization <org-name> --token <OKTA_TOKEN>
```
Expand Down Expand Up @@ -187,7 +191,6 @@ queries:
severity: 80
docs:
desc: |
Okta supports two protocols for handling federated SSO. OpenID Connect (OIDC) and Security Assertion Markup Language (SAML). The SSO protocol that you choose to implement your integration with is based on your app and use case. For new integrations, OIDC is recommended.
OpenID Connect is widely used not only in organizations but also in everyday scenarios like “Log in with Google”. The OAuth flow is quite different from the SAML flow. The main difference is that some actions happen in the user’s browser which is called the front channel and some actions directly between the Client Application and the Identity Provider (the backchannel).
Expand All @@ -196,15 +199,14 @@ queries:
SAML, in the most basic (and the most popular) setup, allows you to pass information about a user between an Identity Provider and a Service Provider (Client Application) via the user’s browser (User Agent). It does not require a direct connection between the Identity Provider and the Service Provider – everything happens via browser redirects. The user requests a signed document that confirms their identity from the Identity Provider, gets authenticated, and then sends the signed document to the Service Provider in order to log in. The signed document can also include information about the user’s privileges, groups, etc.
Useful comparison can be found here, https://developer.okta.com/docs/guides/oin-sso-overview/
audit: |
__cnspec run__
To audit Okta `cnspec run`:
Run the following query:
```mql
```bash
cnspec run okta -c "okta.applications.all(_.signOnMode == "OPENID_CONNECT" || _.signOnMode == "SAML_2_0")" --organization <org-name> --token <OKTA_TOKEN>
```
Expand Down Expand Up @@ -238,19 +240,17 @@ queries:
severity: 60
docs:
desc: |
User account that has been locked due to exceeding the password entry limitation, or other reasons, should only inform the administrator and he/she should not be able to unlock themselves.
In contrast the self-service password recovery might be considered for Okta Admins, https://support.okta.com/help/s/article/How-to-configure-selfservice-account-recovery?language=en_US
audit: |
__cnspec run__
To audit Okta `cnspec run`:
Run the following query:
```mql
```bash
cnspec run okta -c "okta.policies.password.all(_.rules.all(actions["selfServiceUnlock"]["access"] == "DENY"))" --organization <org-name> --token <OKTA_TOKEN>
```
Expand Down Expand Up @@ -286,7 +286,6 @@ queries:
severity: 60
docs:
desc: |
Secure Web Authentication (SWA) is an Okta technology that provides Single Sign-On (SSO) functionality to external web applications that don't support federated protocols.
Administrators can set the credentials for the application, or the end user can enter a specific username and password. Okta keeps the credentials for that application inside a secure store, encrypted with strong AES-256 encryption. After setting the credentials, end users only need to authenticate with Okta, and then they can SSO directly into the application.
Expand All @@ -301,7 +300,7 @@ queries:
Run the following query:
```mql
```bash
cnspec run okta -c "okta.applications.none(signOnMode == "AUTO_LOGIN" || signOnMode == "BROWSER_PLUGIN")" --organization <org-name> --token <OKTA_TOKEN>
```
Expand Down Expand Up @@ -344,7 +343,7 @@ queries:
Run the following query:
```mql
```bash
cnspec run okta -c "okta.policies.signOn.all(_.rules.all(actions["signon"]["factorPromptMode"] == "ALWAYS"))" --organization <org-name> --token <OKTA_TOKEN>
```
Expand Down Expand Up @@ -384,15 +383,14 @@ queries:
If enabled, when user reopens the same browser, they will not be asked to sign-in again if the session is still active.
Session Cookies (Non-Persistent cookies) are stored in memory and never written to the disk. Session cookies remain active as long as the browser remains active – once the browser is closed, the cookies vanish
audit: |
__cnspec run__
To audit Okta `cnspec run`:
Run the following query:
```mql
```bash
cnspec run okta -c "okta.policies.signOn.all(_.rules.all(actions["signon"]["session"]["usePersistentCookie"] == false))" --organization <org-name> --token <OKTA_TOKEN>
```
Expand Down Expand Up @@ -421,4 +419,206 @@ queries:
5. in "Persist session cookies across browser sessions " choose Disabled.
6. Update rule at the end.
query: |
okta.policies.signOn.all(_.rules.all(actions["signon"]["session"]["usePersistentCookie"] == false))
okta.policies.signOn.all(_.rules.all(actions["signon"]["session"]["usePersistentCookie"] == false))
- uid: mondoo-okta-security-okta-limit-superadmin
title: Ensure the users with Super Admin rights are limited to 3
severity: 80
docs:
desc: |
Super Admin role has the highest permissions of all the admins in Okta. Super Admins can create other admins, assign or remove permissions, and perform all other admin activities.
By limiting the number of administrators who have this level of permissions, we can reduce the odds of a bad actor gaining access to one of these highly privileged accounts.
audit: |
__cnspec run__
To audit Okta `cnspec run`:
Run the following query:
```bash
cnspec run okta -c "okta.users.where(roles.all(type == "SUPER_ADMIN")).length <= 3" --organization <org-name> --token <OKTA_TOKEN>
```
__cnspec shell__
To audit Okta with `cnspec shell`:
1. Launch `cnspec shell`:
```bash
cnspec shell okta ---organization <org-name> --token <OKTA_TOKEN>
```
2. Run the following query:
```mql
okta.users.where(roles.all(type == "SUPER_ADMIN")).length <= 3
```
remediation: |
### Okta Console
To update via the Okta portal:
1. Log in as Super Admin to the related Okta organization (Identity Engine)
2. Select from Security the "Administrators"
3. Select "Admins" column and remove the users with "Super Administrator" role if needed
query: |
okta.users.where(roles.all(type == "SUPER_ADMIN")).length <= 3
- uid: mondoo-okta-security-okta-mfa-strong-factor
title: Ensure the strong Factors is used for MFA
severity: 100
docs:
desc: |
While MFA is an ultimate way to add an additional layer of security and defend against credential-based attacks, not all factors in multi-factor authentication is safe and secure.
Traditionally popular factors like “security questions” and sms have proven to be problematic. Bad actors can easily find the answers to security questions online, and SMS can leave users vulnerable to phishing and SIM jacking attacks.
To increase the security. administrators should require users to authenticate via strong factors, like software-based "Authenticators", and make sure nobody is Phone and Email "Authenticators"
audit: |
__cnspec run__
To audit Okta `cnspec run`:
Run the following query:
```bash
cnspec run okta -c "okta.policies.accessPolicy.where(name == "MFA").all(rules.all(actions["appSignOn"]["verificationMethod"]["constraints"] { _["possession"]["deviceBound"] == "REQUIRED"} ))" --organization <org-name> --token <OKTA_TOKEN>
```
__cnspec shell__
To audit Okta with `cnspec shell`:
1. Launch `cnspec shell`:
```bash
cnspec shell okta ---organization <org-name> --token <OKTA_TOKEN>
```
2. Run the following query:
```mql
okta.policies.accessPolicy.where(name == "MFA").all(rules.all(actions["appSignOn"]["verificationMethod"]["constraints"] { _["possession"]["deviceBound"] == "REQUIRED"} ))
```
remediation: |
### Okta Console
To update via the Okta portal:
1. Log in as Super Admin to the related Okta organization (Identity Engine)
2. Select from Security the "Authentication Policies" and then select "MFA"
3. By Default there is a "Catch-all Rule" which can be edited or Add a new Rule.
4. Actions and then Edit
5. In the Section "Possession factor constraints are", the "Exclude phone and email authenticators" should be selected.
6. At the end Save
query: |
okta.policies.accessPolicy.where(name == "MFA").all(rules.all(actions["appSignOn"]["verificationMethod"]["constraints"] { _["possession"]["deviceBound"] == "REQUIRED"} ))
- uid: mondoo-okta-security-okta-mfa-password-and-another-strong-factor
title: Ensure the Password/IdP plus Another factor chosen for MFA
severity: 100
docs:
desc: |
A key goal for MFA is to add additional authentication factors to increase security.
There are three common types of authentication factors used to authenticate users:
* Knowledge - Something you know, such as a password.
* Possession - Something you have, such as a security key or Authenticator App
* Inherence - Something you are, such as a unique biometric or behavioral characteristic
Among the options that Okta currently offers in MFA configuration part, the combination of Password/IdP plus Another factor is the best practice.
audit: |
__cnspec run__
To audit Okta `cnspec run`:
Run the following query:
```bash
cnspec run okta -c "okta.policies.accessPolicy.where(name == "MFA").all(rules.all(actions["appSignOn"]["verificationMethod"]["constraints"] { _["possession"]["deviceBound"] == "REQUIRED" }))" --organization <org-name> --token <OKTA_TOKEN>
cnspec run okta -c "okta.policies.accessPolicy.where(name == "MFA").all(rules.all(actions["appSignOn"]["verificationMethod"]["factorMode"] == "2FA"))" --organization <org-name> --token <OKTA_TOKEN>
```
__cnspec shell__
To audit Okta with `cnspec shell`:
1. Launch `cnspec shell`:
```bash
cnspec shell okta ---organization <org-name> --token <OKTA_TOKEN>
```
2. Run the following query:
```mql
okta.policies.accessPolicy.where(name == "MFA").all(rules.all(actions["appSignOn"]["verificationMethod"]["constraints"] { _["possession"]["deviceBound"] == "REQUIRED" }))
okta.policies.accessPolicy.where(name == "MFA").all(rules.all(actions["appSignOn"]["verificationMethod"]["factorMode"] == "2FA"))
```
remediation: |
### Okta Console
To update via the Okta portal:
1. Log in as Super Admin to the related Okta organization (Identity Engine)
2. Select from Security the "Authentication Policies" and then select "MFA"
3. By Default there is a "Catch-all Rule" which can be edited or Add a new Rule.
4. Actions and then Edit
5. In the Section "Possession factor constraints are", the "Exclude phone and email authenticators" should be selected.
6. At the end Save
query: |
okta.policies.accessPolicy.where(name == "MFA").all(rules.all(actions["appSignOn"]["verificationMethod"]["constraints"] { _["possession"]["deviceBound"] == "REQUIRED" }))
okta.policies.accessPolicy.where(name == "MFA").all(rules.all(actions["appSignOn"]["verificationMethod"]["factorMode"] == "2FA"))
- uid: mondoo-okta-security-okta-mfa-password-reauthenticate
title: Ensure the re-authentication period for Password/IdP and MFA code is active and short
severity: 60
docs:
desc: |
The best practice is To prompt the user to re-enter the password and MFA code periodically. Like most topics in information security, the re-authentication interval has a tradeoff between security and convenience: a short amount has better security but is inconvenient, while a longer amount is more convenient but has lower security.
It should be tested that following two options never being configured for password and other factors:
* Every sign-in attempt
* Never re-authenticate if the session is active
Our recommendations is to configure the Password re-authentication after 4 hours and other factor every 8 hours.
audit: |
__cnspec run__
To audit Okta `cnspec run`:
Run the following query:
```bash
cnspec run okta -c "okta.policies.accessPolicy.where(name == "MFA").all(rules.all(actions["appSignOn"]["verificationMethod"]["constraints"] { _["knowledge"]["reauthenticateIn"] != "PT0S"} ))" --organization <org-name> --token <OKTA_TOKEN>
cnspec run okta -c "okta.policies.accessPolicy.where(name == "MFA").all(rules.all(actions["appSignOn"]["verificationMethod"]["constraints"] { _["knowledge"]["reauthenticateIn"] != "PT43800H"} ))" --organization <org-name> --token <OKTA_TOKEN>
cnspec run okta -c "okta.policies.accessPolicy.where(name == "MFA").all(rules.all(actions["appSignOn"]["verificationMethod"]["reauthenticateIn"] != "PT0S" ))" --organization <org-name> --token <OKTA_TOKEN>
cnspec run okta -c "okta.policies.accessPolicy.where(name == "MFA").all(rules.all(actions["appSignOn"]["verificationMethod"]["reauthenticateIn"] != "PT43800H" ))" --organization <org-name> --token <OKTA_TOKEN>
```
__cnspec shell__
To audit Okta with `cnspec shell`:
1. Launch `cnspec shell`:
```bash
cnspec shell okta ---organization <org-name> --token <OKTA_TOKEN>
```
2. Run the following query:
```mql
okta.policies.accessPolicy.where(name == "MFA").all(rules.all(actions["appSignOn"]["verificationMethod"]["constraints"] { _["knowledge"]["reauthenticateIn"] != "PT0S"}))
okta.policies.accessPolicy.where(name == "MFA").all(rules.all(actions["appSignOn"]["verificationMethod"]["constraints"] { _["knowledge"]["reauthenticateIn"] != "PT43800H"}))
okta.policies.accessPolicy.where(name == "MFA").all(rules.all(actions["appSignOn"]["verificationMethod"]["reauthenticateIn"] != "PT0S"))
okta.policies.accessPolicy.where(name == "MFA").all(rules.all(actions["appSignOn"]["verificationMethod"]["reauthenticateIn"] != "PT43800H"))
```
remediation: |
### Okta Console
To update via the Okta portal:
1. Log in as Super Admin to the related Okta organization (Identity Engine)
2. Select from Security the "Authentication Policies" and then select "MFA"
3. By Default there is a "Catch-all Rule" which can be edited or Add a new Rule.
4. Actions and then Edit
5. In the Section "Possession factor constraints are", the "Exclude phone and email authenticators" should be selected.
6. At the end Save
query: |
okta.policies.accessPolicy.where(name == "MFA").all(rules.all(actions["appSignOn"]["verificationMethod"]["constraints"] { _["knowledge"]["reauthenticateIn"] != "PT0S"}))
okta.policies.accessPolicy.where(name == "MFA").all(rules.all(actions["appSignOn"]["verificationMethod"]["constraints"] { _["knowledge"]["reauthenticateIn"] != "PT43800H"}))
okta.policies.accessPolicy.where(name == "MFA").all(rules.all(actions["appSignOn"]["verificationMethod"]["reauthenticateIn"] != "PT0S"))
okta.policies.accessPolicy.where(name == "MFA").all(rules.all(actions["appSignOn"]["verificationMethod"]["reauthenticateIn"] != "PT43800H"))

0 comments on commit a861727

Please sign in to comment.