Using Okta to Protect IL4 (FedRAMP)
Okta is the industry leader in identity and access management, enabling organizations to accelerate the secure adoption of their web-based applications, both in the cloud and on premises. Okta delivers a complete solution that addresses the needs of IT, end users, business leaders, and developers; no customization is required. By adopting the Okta service, organizations dramatically improve the security and ease of managing their applications, including Software as a Service (SaaS), Platform as a Service (PaaS), and other on-prem and cloud-based applications. IT benefits by using one central place for policy-based management that governs which users get access to the mission-critical applications and data that power core business processes, regardless of their location. End users benefit by using their Okta single sign-on homepage to simplify their life and reduce the security risks caused by “password fatigue,” and developers benefit through the use of an easy-to-implement, hardened identity platform, enabling them to focus on delivering feature sets, not building user management. With Okta, there is no longer a need for users to resort to the typical tricks for memorizing passwords—obvious or reused passwords, writing passwords down on Post-it notes, or saving them in Excel files on their laptops.
Using industry-standard technologies such as SAML, OpenID, OAuth2, and WS-Fed, Okta is designed to provide the benefits of strong, centralized authentication without 3rd party exposure to downstream data. Customers regularly use Okta to protect Personally Identifiable Information (PII), Payment Card Industry (PCI), credit cardholder data environments (CDE), Healthcare and Life Science data such as electronic Protected Health Information (ePHI), Financial data, and more, while staying out of scope for the associated regulations. This reduces cost and increases technology organization to be more flexible, ultimately creating a better user experience.
In 2017, Okta obtained a FedRAMP Moderate Authorization, enabling Federal customers to use the Okta service for unclassified workloads which includes DoD Impact Level 2. Okta provides identity services for multiple agencies, including the Department of Justice, Center for Medicare and Medicaid Services (part of Health and Human Services), Surface Transportation Board, and the Federal Communications Commission. Okta is also integrated as part of other cloud services currently FedRAMP Authorized. As Department of Defense agencies continue to migrate workloads to the cloud, there is a greater need for centralized identity management. In this document, we will discuss methods that can be used to reduce the risk of using Okta to protect DoD workloads up to Impact Level 4.
Okta is implemented as the identity layer in your application, where it performs authentication and authorization, passing a token to the application with an identity assertion. It is the responsibility of the application to correctly assign and manage privilege to the user based on this token. With this model and approach, Okta does not have access to any sensitive data stored within the application, and can be separated from this data.
Authentication is typically performed using one of the SAML 2.0, OAuth, or OpenID Connect standards, where an authentication token is generated and signed using a pre-shared certificate configured by the system administrators. This token is passed over a TLS 1.2 connection through the end-user’s browser (UserAgent), which creates a separation between Okta and the data in the downstream application.
Okta may also be connected to a directory system such as Active Directory or LDAP in order to extend the organization’s identity into the cloud. Okta’s AD agent is designed with security in mind; in a typical deployment, no firewall changes are needed to integrate on-premises directories. The Okta agent may be installed on any domain member server, installation on a domain controller is not required. This allows the customer to maintain full control over the permissions the Okta Agent operates under, and can filter and control what attributes are shared with Okta. Data is always encrypted while at rest and in transit.
Because in both use cases, Okta passes only an authentication token back to the client, Okta is not exposed to sensitive data maintained in the protected application. Okta only handles authenticator information, and steps out of the way. Detailed Log information can be fed in near real-time to your SIEM tool for aggregation and reporting with a feed from your downstream application to identify and protect against internal threats.
IL4 and IL5 Control Mapping
The FedRAMP Moderate Authorization level contains 325 controls that align with Impact Level 2 requirements. In order to support Controlled Unclassified Information (IL4), the DoD has added 38 additional controls to the FedRAMP Moderate baseline, and 48 additional controls to achieve the IL5 baseline. Okta has reviewed these controls and provided responses in the Control Enhancement Workbook, in Appendix A.
Of the additional controls, 18 are the Customer’s responsibility, or are shared between Okta and the Customer, and 4 are Not Applicable. The remaining controls can be reduced in risk by implementing Okta as an Interconnected System and ensuring that log data is fed to an appropriate SIEM, managed by the customer. This ability to link and correlate log feeds provides detection and response capabilities to any anomalies in the authentication process.
Customers may also choose to implement Okta with FIPS-validated authentication credentials, further reducing the perceived risk associated with Okta. This includes using Okta Verify, PIV or CAC cards, or authentication tokens such as Symantec VIP. Okta’s Adaptive Multi-factor Authentication (Adaptive MFA) product enables the use of costly high-strength authenticators where they are required, while allowing organizations to use lower-cost authenticators where they can be supported. This helps to eliminate “authentication fatigue”, providing a better user experience without impacting security.
Protection of PII and PHI
The Okta service was built on the foundation of strong protections for user Personally Identifiable Information. This is evident in our security controls, our ISO 27018 certification, and our commitment to international privacy regulations such as the EU GDPR. With respect to US Government data, Okta provides the protections required for both Personally Identifiable Information (PII), and Protected Health Information (PHI). All data is encrypted both at rest and in transit. Additionally, Okta uses organization-level encryption to protect sensitive data, such as authentication credentials and certificates. This organization-level encryption uses Amazon KMS, a FIPS 140-2 L2 hardware encryption module to protect a key that is unique to each customer tenant. This protects against cross-tenant attacks, and provides a log of all accesses to customer authentication data. More details about Okta’s layered security approach can be found in Okta’s Security Technical Whitepaper.
Risk Scoring of PII
Okta performed a Privacy Impact Assessment as part of the FedRAMP authorization process. This risk assessment identified the following PII and components (From SSP Attachment 4 – Okta IDaaS PTA PIA v1.2):
At a minimum, Users must provide an Email address to use the Okta service. In many cases users may also provide a First Name and Last Name for personalization, and a cell phone number in order to receive multi-factor authentication tokens. The customer may choose to include other PII about the users as required for the usage of downstream systems. This additional information may impact the Privacy Impact of the application.
In reviewing the Confidentiality Impact Levels from NIST SP800-122, Okta has determined the application poses Moderate risk to PII:
Risk Scoring of PHI
There are a minimal number of use cases where Okta may store or process Protected Health Information. The most common case is where Okta is used to authenticate users into a health portal, where the assignment of a downstream application may indicate a medical condition or diagnosis. If Okta is used to authenticate users into an application that contains PHI, but where the existence of the application does not indicate a medical condition, then the Okta service is not subject to HIPAA regulation. The most common use case is when Okta is used as a hospital employee portal, and one of the assigned applications is an Electronic Health Records application such as Epic, or another application that contains PHI.
When Okta is used in a method that puts it in scope for PHI, the risk associated is Moderate, as determined in the PII risk assessment.
Okta has been designed from the ground up to safely store and process an individual’s most sensitive data – their identity, while being segmented as much as possible from the business’s most sensitive data. With the implementation of log aggregation and monitoring, appropriate multi-factor tokens, and configuration of authenticator strength controls such as session timeout, the additional risks of implementing Okta can be mitigated. In exchange, the ability to deploy a risk-based authentication strategy and enforce strong authenticators where they are required reduces the risk of identity-related breaches while providing users with a better experience.
Appendix A: Control Enhancement Workbook