STIGViewer Support

For each application integrated with Okta, network zones must be defined in its authentication policy.

Overview

Finding IDVersionRule IDIA ControlsSeverity
V-279693OKTA-APP-003244SV-279693r1155078_ruleCCI-001414medium
Description
A mechanism to detect and prevent unauthorized communication flow must be configured or provided as part of the system design. If information flow is not enforced based on approved authorizations, the system may become compromised. Information flow control regulates where information is allowed to travel within a system and between interconnected systems. The flow of all application information must be monitored and controlled so it does not introduce any unacceptable risk to the systems or data. Application-specific examples of enforcement occurs in systems that employ rule sets or establish configuration settings that restrict information system services, or provide a message filtering capability based on message content (e.g., implementing key word searches or using document characteristics). Applications providing information flow control must be able to enforce approved authorizations for controlling the flow of information between interconnected systems in accordance with applicable policy. Each application in Okta should have a well defined access control policy that takes into account the end user network. This should be documented in the Access Control policy for each application. As an example, access to an application may be restricted to a specific location by policy. In this case, a network defining that specific location should be created.
STIGDate
Okta Identity as a Service (IDaaS) Security Technical Implementation Guide2025-11-19

Related Frameworks

1 mapping across 5 frameworks
SCF0 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (17) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

AST-04Network Diagrams & Data Flow Diagrams (DFDs)
1.00
AST-04.2Control Applicability Boundary Graphical Representation
1.00
CFG-02Secure Baseline Configurations
1.00
CRY-01Use of Cryptographic Controls
1.00
DCH-01Data Protection
1.00
DCH-19Geographic Location of Data
1.00
END-01Endpoint Device Management (EDM)
1.00
END-04Malicious Code Protection (Anti-Malware)
1.00
END-06Endpoint File Integrity Monitoring (FIM)
1.00
IAC-21Least Privilege
1.00

+7 more (top 10 by confidence shown)

NIST 800-530 mappings

No source states a mapping between these directly.

Also reachable in 2 hops (7) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

AC-3Access Enforcement
1.00
AC-4Information Flow Enforcement
1.00
AC-6(9)Log Use of Privileged Functions
1.00
AU-12Audit Record Generation
1.00
CM-7Least Functionality
1.00
SC-5Denial-of-service Protection
1.00
SC-7(5)Deny by Default — Allow by Exception
1.00
NIST 800-1710 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (1) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

3.1.3
1.00
CCI1 mapping
NIST CSF 2.00 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (4) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

Who does this work

18 NICE work roles and 10 EC-Council certifications.

This is an inference across published mappings, not a single claim by anyone. This check maps to a control, which maps to a Cybersecurity Framework outcome, which NIST assigns to the work roles below. EC-Council separately maps its certifications to those same roles.

A certification prepares someone for a role. It is not evidence that a holder is qualified, and neither NIST nor EC-Council has stated that any certification here addresses this check.

Work-role assignments published by NIST (NICE Framework Components 2.2.0 and the CSF 2.0 OLIR crosswalk). Certification mappings published by EC-Council.

Details

Check Text (C-279693r1155078_chk)

For each application integrated into Okta: 1. From the Admin console, open the "Security" menu, and then select "Networks". 2. Verify the list of networks includes all necessary allow or block lists. If any application is not configured with network zones, this is a finding.

Fix Text (F-84151r1155077_fix)

For each application, starting at the admin console: 1. Open the "Applications" group from the Menu, and then click the "Applications" menu item. 2. Click the application name. 3. Click the "Sign On" tab. 4. Scroll to the "User Authentication" section, and then click "Edit". 5. Select the appropriate Authentication policy from the pull down, and then click "Save". 6. Click "View Policy Details". 7. For each nondefault rule: a. Select "Edit" from the Actions menu. b. In the "IF" section, verify the "User is" setting has the appropriate allow or deny range has been selected based on the Access Control policy for the application. c. Scroll down to the bottom and click "Save". 8. For the Catch-All rule: a. Select "Edit" from the Actions menu. b. Scroll down to the "Then" section. c. For the "Access is" setting, select "Denied", and then click "Save".