From a86172740ee8f8ce54e6a865cbbbd19e89826cd8 Mon Sep 17 00:00:00 2001 From: hrouhan <56231339+HRouhani@users.noreply.github.com> Date: Tue, 14 Mar 2023 23:39:29 +0100 Subject: [PATCH] =?UTF-8?q?=E2=AD=90=EF=B8=8F=20Okta=20security=20policies?= =?UTF-8?q?=20-=20ignore=20(#147)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This PR (https://github.com/mondoohq/cnquery/pull/1048) should go through in the next release for testing the new resources which has been added! --------- Signed-off-by: Hossein Rouhani Signed-off-by: Patrick Münch Co-authored-by: Patrick Münch --- .github/actions/spelling/expect.txt | 1 - core/mondoo-okta-security.mql.yaml | 230 ++++++++++++++++++++++++++-- 2 files changed, 215 insertions(+), 16 deletions(-) diff --git a/.github/actions/spelling/expect.txt b/.github/actions/spelling/expect.txt index de253f82..67143c54 100644 --- a/.github/actions/spelling/expect.txt +++ b/.github/actions/spelling/expect.txt @@ -267,4 +267,3 @@ YWQ auditevent backchannel superadmin -backchannel diff --git a/core/mondoo-okta-security.mql.yaml b/core/mondoo-okta-security.mql.yaml index 076f660a..e5fb6a2b 100644 --- a/core/mondoo-okta-security.mql.yaml +++ b/core/mondoo-okta-security.mql.yaml @@ -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 @@ -95,7 +99,7 @@ queries: Run the following query: - ```mql + ```bash cnspec run okta -c "okta.policies.signOn.all(_.rules.all(status == "ACTIVE"))" --organization --token cnspec run okta -c "okta.policies.signOn.all(_.rules.all(actions["signon"]["requireFactor"] == true))" --organization --token ``` @@ -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. @@ -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 --token cnspec run okta -c "okta.policies.signOn.all(_.rules.all(actions["signon"]["session"]["maxSessionLifetimeMinutes"] <= 1440))" --organization --token ``` @@ -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). @@ -196,7 +199,6 @@ 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__ @@ -204,7 +206,7 @@ queries: Run the following query: - ```mql + ```bash cnspec run okta -c "okta.applications.all(_.signOnMode == "OPENID_CONNECT" || _.signOnMode == "SAML_2_0")" --organization --token ``` @@ -238,11 +240,9 @@ 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__ @@ -250,7 +250,7 @@ queries: Run the following query: - ```mql + ```bash cnspec run okta -c "okta.policies.password.all(_.rules.all(actions["selfServiceUnlock"]["access"] == "DENY"))" --organization --token ``` @@ -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. @@ -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 --token ``` @@ -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 --token ``` @@ -384,7 +383,6 @@ 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__ @@ -392,7 +390,7 @@ queries: Run the following query: - ```mql + ```bash cnspec run okta -c "okta.policies.signOn.all(_.rules.all(actions["signon"]["session"]["usePersistentCookie"] == false))" --organization --token ``` @@ -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)) \ No newline at end of file + 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 --token + ``` + + __cnspec shell__ + + To audit Okta with `cnspec shell`: + + 1. Launch `cnspec shell`: + + ```bash + cnspec shell okta ---organization --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 --token + ``` + + __cnspec shell__ + + To audit Okta with `cnspec shell`: + + 1. Launch `cnspec shell`: + + ```bash + cnspec shell okta ---organization --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 --token + cnspec run okta -c "okta.policies.accessPolicy.where(name == "MFA").all(rules.all(actions["appSignOn"]["verificationMethod"]["factorMode"] == "2FA"))" --organization --token + ``` + + __cnspec shell__ + + To audit Okta with `cnspec shell`: + + 1. Launch `cnspec shell`: + + ```bash + cnspec shell okta ---organization --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 --token + cnspec run okta -c "okta.policies.accessPolicy.where(name == "MFA").all(rules.all(actions["appSignOn"]["verificationMethod"]["constraints"] { _["knowledge"]["reauthenticateIn"] != "PT43800H"} ))" --organization --token + cnspec run okta -c "okta.policies.accessPolicy.where(name == "MFA").all(rules.all(actions["appSignOn"]["verificationMethod"]["reauthenticateIn"] != "PT0S" ))" --organization --token + cnspec run okta -c "okta.policies.accessPolicy.where(name == "MFA").all(rules.all(actions["appSignOn"]["verificationMethod"]["reauthenticateIn"] != "PT43800H" ))" --organization --token + ``` + + __cnspec shell__ + + To audit Okta with `cnspec shell`: + + 1. Launch `cnspec shell`: + + ```bash + cnspec shell okta ---organization --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")) \ No newline at end of file