Assessing Okta’s Protection of Customer’s AWS Credentials and User Directory
ACM.161 How does Okta protect our AWS credentials, configuration, system integration, and directory data?
Part of my series on Automating Cybersecurity Metrics. The Code.
Free Content on Jobs in Cybersecurity | Sign up for the Email List
In the last post we looked at how Okta works with AWS.
One concern I mentioned was that Okta is requesting long lived credentials instead of integrating via a role and an external ID to obtain a list of roles in our AWS account.
The other question is —more importantly — how does Okta store the usernames, passwords, and other information we store on their systems?
How would an attacker obtain our data stored at Okta?
To gain access to the AWS keys or user names and password stored at Okta, an attacker could try a number of different tactics.
Perhaps they could trick a user into giving them access to the information. I heard once in a class that Edward Snowden, who stole and exposed a lot of data belonging to the US government, simply asked a coworker if he could borrow their credentials. Apparently he was a “nice guy” and the coworker obliged.
Maybe the attacker could install malware on a user’s laptop like the attackers did in the Circle CI breach. Once the malware has access to the If Okta gives broad access to users that includes visibility into customer AWS credentials, that could be a problem.
In the case of the Twilio breach, attackers used phishing attacks (or smishing attacks involving SMS messages) to gain access to support professional credentials who had access to view MFA codes in transit. Could an attacker somehow obtain credentials of a support person at Okta and access customer data?
An attack similar to that did, if fact, happen at Okta. Attackers obtained access to potentially 366 customer accounts. This was a small percentage of customer accounts, but that fact doesn’t help if you were one of those customers. The incident occurred at a company named Sitel that provided customer support to Okta and one of their support engineer laptops got compromised.
Before you conclude that you should not use Okta due to this breach, consider the number of breaches and security incidents that have affected Microsoft and Azure customers, if you are using Microsoft Active Directory or Azure Active Directory. I provided some of them in this blog post. Security is hard. Who does a better job comes down to a lot of details I probably won’t have access to during a black-box assessment of a product.
Hopefully Okta has learned from it’s mistakes that led to this breach and has rectified the problem. That’s what we need to find out. In the end, Okta terminated their relationship with Sitel. We can glean from this article that they are taking additional steps to secure access and relationships with third-party vendors, but the article doesn’t say exactly what steps they are taking.
In addition, the scope of the breach turned out to be 2 customers according to the above article after a complete investigation. When performing incident response after a breach, companies investigate logs to determine how many systems, customers, and individuals may have been affected. That is why secure and comprehensive system logging is so important when a breach occurs.
The customer side of the responsibility model
On the AWS side, we have a challenge in that the user who creates the user and credentials and inputs them at Okta, that user has access to them. This appears to be a manual process. We’d like to have a secure way to automate that and prevent user access to those credentials if possible. Better yet, Okta could use a role that users in our AWS account cannot assume by way of zero-trust trust policy.
Since using long-lived credentials appears to be the only solution for now, we’ll probably want to limit who can perform this action. The people who generate these keys may be IAM administrators who already have these permissions, so the visibility provided by these credentials is of little additional value.
It would be great if Okta could provide the IP ranges that will trigger API requests using those credentials. In that case, we could write policies to restrict the use of these credentials to a given IP range at least.
We’ll look at Okta networking and other security controls available to us in an future post.
In addition, we need to train our users not to be fooled by phishing attacks such as those used by attackers in the Oktapus breaches. Additionally, we will need to ensure we limit access to administer Okta appropriately, using all available security controls that we can configure. More on that in upcoming posts.
Reviewing Okta’s CAIQ Assessment Answers
On the Okta side, this is where the cloud shared responsibility model comes into play again. It is up to Okta to make sure that the credentials, secrets, and data are never exposed — to attackers or insiders at Okta — once the credentials get entered into their system.
In regards to whether or not users can access the keys or data entered into the system, we could take a look at the CSA CAIQ Self-Assessment Questionnaire Okta created to try to determine how they prevent their own employees from accessing these keys or the customer role names. I wrote about the CSA CAIQ in this post on the AWS Shared Responsibility Model:
Let’s take a look at Okta’s answers to a few relevant questions.
IAM-04.1 Is the separation of duties principle employed when implementing information system access?
Okta’s production service leverages AWS Security Groups on all virtual hosts. Okta’s access control lists (ACLs) used on our Security Groups are proprietary and confidential. Okta technical operations personnel are the only people with access to production. The controls that Okta employs to restrict access, maintain segregated duties, and ensure least privilege access to production are attested to by multiple third-party assessments on an annual basis, including but not limited to: SOC 2 Type II, ISO 27001, and FedRAMP. AWS maintains control over physical and logical access to all of their computing facilities.
Analysis: AWS Security Groups are applicable to network segregation rather than separation of duties via IAM controls and architecture. I am not sure why networking controls are is part of this answer which is asking about human duties. Also, I have demonstrated how to separate duties in this blog series such that it would require a three-party collusion to access sensitive data. The fact that a group of people have full access to all production resources, if I am understanding this correctly, does not imply separation of duties between things like IAM, networking, and encryption the way I architected IAM permissions in this series. It does not sound like it would take a multi-party collusion to access the customer keys based on the data above. But perhaps the actual implementation is not fully documented here and such separation exists. On a security assessment I would ask more pointed questions. We can also look for additional documentation.
IAM-05.1 Is the least privilege principle employed when implementing information system access?
Okta enforces careful segmentation of duties and the principle of least privileges for access granted to our technical, development, and QA teams. This ensures no single person has the ability to change and deploy code in the production environment or view customer data without an audit trail. Our controls and processes are audited and attested to by an independent, third-party firm in multiple third-party assessments on an annual basis, including but not limited to: SOC 2 Type II, ISO 27001, and FedRAMP.
Analysis: It sounds like the principle of least privilege is applied to prevent any one person from moving code of their choosing to production which is very good. However this does not address our concerns about whether someone can access the AWS keys we’re entering into the system or view the roles that those keys have access to list, similar to how Okta support staff could view text messages with MFA codes in the Oktapus incident at Twilio. I would need to ask more questions on an actual assessment to determine the specific nature of the controls and what, exactly, people can access and what it takes to obtain that access, or find additional documentation.
CEK-11.1 Are private keys provisioned for a unique purpose managed, and is cryptography secret?
Okta services are expected to comply with the Information Security Policy. Okta mandates the management of cryptographic secret and private keys that are provisioned for a unique purpose considering information disclosure risks and legal and regulatory requirements.
Analysis: This answer is a bit vague. Once again, I would need to ask more questions and specific to our concerns to understand if an how the AWS keys and information they can retrieve is encrypted and who has access to the keys that can decrypt those secrets and data.
As I noted before, security architecture is not a checklist.
Although the CAIQ is helpful and I leverage it on security assessments and refer many people to it, it cannot help us answer a specific architectural questions about a key pieces of information in a system that we want to ensure are properly protected.
We are trying to figure out how a specific piece of data is handled within the Okta systems (the AWS credentials), the output when those credential get used, and specifics about the security of our user directory the data in it. The CAIQ answers do not go into enough detail about the overall architecture and how everything works together to understand if our data is really secure.
Vendor Security Architecture Documentation
While researching Okta, I came across another very useful document. This document is similar to the AWS document I wrote about in the post on the AWS Shared Responsibility Model that has now been archived.
In this document, Okta goes into much more detail about the security of its systems and architecture. I really appreciate this document and wish every vendor could offer a detailed document like this. As more customers as questions, the vendor can improve and refine their public facing security architecture document.
https://www.okta.com/sites/default/files/2021-10/technical-security-whitepaper.pdf
If you are considering using Okta it would be good to take a look at this document. If you are considering using an alternate vendor, such as Microsoft Azure Active Directory, AWS SSO, Google’s identity solution, or otherwise you might want to formulate questions for the other vendors based on this document. It has a lot of good points to consider.
One of the things I would be asking Okta, in light of the above breach, is that if third-party support staff at vendors get the same level of background checks and security training as their in-house staff.
I’d also want to know more about the type of access the third-party or any support engineers. It says in this document that it takes two people to access customer data. I wonder how that applied or didn’t apply in the Sitel incident above and what Okta has done about it.
Security Product Assessments
If I were performing an assessment on Okta, I would be asking more targeted questions about the way this data is handled by their systems and who can access it.
I would like to know more about how Okta assesses it’s vendors, like Sitel. It would also be good to understand the legal agreements in relation to security incidents and liability. I would refer to a lawyer for that analysis.
I would also try to verify the answers if I had access to the systems. For example, Okta could grant me the same permissions as the people who had production access at Okta and I could see if I could use those permissions to access sensitive customer data. I would need to see any communication platforms like Slack or Confluence or otherwise. Of course I would take a look at data in any support systems and development systems I could access as well.
I’d want to know what type of data can be shared on Zoom calls, for example. Some questions have arisen about a security researcher at Zoom accessing documents related to the Okta and Sitel incident. Personally, I don’t recommend customers share documents on Zoom. I ask them to send them to me encrypted in advance of a call when working with IANS clients. I can provide my public key to encrypt the documents as they traverse cloud systems. I delete them after the call.
Update 2/22/2022:
One other thing to ask Okta. Is your support staff going to ask my users to do screen shares? (Because Okta support just asked me to do that.) What software do you use for screen shares? Do you require my users at my organization to install that software to get support? Can I opt out as an organization of screen shares altogether?
As I mentioned, this is not a full product assessment as I can only view things from a black box perspective for the Okta side of the shared responsibility model.
In general, I find Okta’s security architecture document above to be much, much more helpful than a lot of the documentation other vendors provide when trying to assess their security. They also outline what your responsibilities are, as a customer, in more detail than some other vendors. The document is clear and well written. This document should be referenced in the above CAIQ questionnaire answers.
We could go into a lot more detail asking questions to Okta in a paid or potential customer assessment, but this is a pretty good starting point for understanding how they secure customer data. We’ll see what else we find as we continue to implement our AWS IAM SAML integration with Okta.
Follow for updates.
Teri Radichel | © 2nd Sight Lab 2023
About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight LabNeed Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for PresentationFollow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab
