Security by Design: An End-to-End View of Okta’s Cloud Service Safeguards

Carrie:  Hey, everybody. Thank you for joining us for the security track this afternoon. My name is Carrie. I'm the head of marketing for Asia Pacific at Okta. We're very excited that you can all join us today for our next session. 

I've actually had the luxury of spending the last week with this gentleman. Yassir, our CSO at Okta is actually going to take us through a view of end-to-end security within Okta's platform. I've just had Yassir down with us. 

They got the security risks summit in Sydney and he came. He was listed as one of the best speakers from the conference. So no pressure, Yassir. Come on up here. We look forward to hearing from you. 

I'll just remind you as well that we are actually recording this session, so if you stay in your seats, and turn off the mobile phone, that will be wonderful. 

Yassir:  All right. Thank you, Carrie. Hello, everyone. 

As Carrie mentioned, my name is Yassir Abousselham and I am the Chief Security Office here at Okta. I'm here to talk to you about how we secure our product and our platform. I'm glad to see that so many of you are here. I'm not the only one who's interested in security, so that's definitely something that I take comfort in. 

So first we're going to cover just a few words from our legal team. Hopefully you're going to read really, really fast. But it's actually what it says is we're going to make some statements, and we reserve the right to change course if needed. You see this type of disclaimer pretty much every session you're going to attend today. 

But the first thing I want to talk about before talking about investments is the type of attacks that we see on the Okta platform and the Okta product. So this is essentially your identity frontline. In terms of attacks, we see as you can imagine, the whole gamut of attacks. They range from brute force attacks to application level attacks, such as access hardware or access farce. 

In terms of complexity, primarily a lot of these attacks are very simple and very basic. The attackers are after credentials, and they'll take the shortest path to reach that goal. So what they do is they typically just run brute force attacks to be able to compromise accounts, and delivers last security and passwords policies and the lack of MFA. 

Then in terms of targets, what we are seeing is that there is a kind of a diversity in terms of the targets that these attackers are after. They could go after one single organization, as much as go after a cloud application provider such as Office 365 or JIRA. In some cases, they want to cast a white net and they'll go after pretty much the entire platform. 

Again, the objective is to harvest as many of the credentials as possible. How to do that? We see some sophistication, and also some really basic attacks, so we see things like just a single attacker coming in from a single IP, most likely using a single laptop, and we also see entire cloud infrastructure being spun up just to do an attack. 

After a few days that entire infrastructure get dismantled. In some other cases, also which we see is attackers come in from the TOR network in an attempt to hide their tracks. And also, to be able to optimize those attacks, some of these attackers get somewhat creative, so they will start an attach on a Friday evening, or just before a long weekend, so as you can imagine, they are very popular with our security team. 

They completely spoiled their weekends. Then the last thing I want to say here is the problems that we see. So we keep seeing the exact same problems over and over again. Essentially, password reuse would be one of the largest or highest impact problems that we see. Your users, our users, essentially this is across the entire ecosystem. They keep reusing the same password that they used for their corporate service as the personal services that they sign up on. 

So to the extent that those personal services or websites that they sign up for get compromised, those same credentials are being reused to attack your corporations. The second major problem that we see is the lack of MFA. I think we live in a world where it is absolutely accepted that passwords are no longer sufficient. So we have and you owe it to your organization and to users to adopt MFA. 

I think if we do ... Those of you guys who were in the keynote today, you know that you get MFA for free as part of your SSO product, so you really have no reason for not adopting MFA at this point. The last thing I'm going to say about that is if you're still using password exclusively to guard access to any kind of publicly exposed service, it's really just a matter of time before those user accounts get compromised. 

So use MFA and that's actually one of the essential things that you could take out of this session. So I'd like to give you a little bit of a breakdown in terms of all these types of attacks that we see. The breakdown is really, really simple. So 99 percent of the attacks, actually more than 99 percent of the attacks that we see in our platform are just targeting credentials. 

Again, the attackers are after credentials, and they'll take the shortest path to get to that goal. Which means that less than one percent of these attacks target application level vulnerabilities, and maybe this is due to the amount of investments that we made in security in our platform. But essentially at this point, the attackers know that there's not a lot of return they can get by attacking Okta. 

So instead, they will attack the Okta customer. They will hope that you don't use MFA and that you have lax password policy and so on to be able to compromise your credentials or user credentials. This is an example of an attack, so essentially it starts by an attacker, an adversary compiling a list of credentials. The way they do that is by either leveraging some of the credentials that were exposed as part of data breaches that took place in the past, so they will download all that for their list. 

Then what they also do is they use script to generate a list of credentials, and lastly, they leverage the professional network, so essentially what they would do is look it up on LinkedIn. They'll find the list of your employees. They determine that your email address is composed as first, last name @domain.com, and there you go. So now they have a full list that they can use to attack your infrastructure. 

From there, as I mentioned earlier, they could be attacking using a single machine, or they could rent a bot or hide behind TOR network or in some cases by services from a cloud provider to mount these attacks. The attacks are launched, and again, they're launched against either a cloud service provider, a cloud application, or an entire ... as I mentioned earlier, they cast a white net, and they'll go after domain name. 

One thing that's interesting that happens here because Okta is the gate between these attackers and the system that they target, we end up being on the receiving end of all of that traffic. Essentially, any time your organization gets attacked, we get the benefits of receiving all that nice malicious traffic. So we have to deal with this. The way we deal with it is obviously by identifying the IPs that are malicious and blocking those IPs, and I'll give you an example of a single campaign that we saw a few weeks ago.  

So this is an example. This is an example of a campaign that took place between July 15th and 30th of this year, so essentially the attack targeted over 700 of our customers. There was over 100,000 incorrect user names that were tried. Which typically means that the attacker is using some kind of script to generate this list. 

Over 1 million failed password attempts, and then the thing that's interesting here is that our team was able to block 1235 IP addresses in a span of a single week, without impacting any of our customers, meaning our team takes great care to making sure that every malicious traffic or VIP address that they block is actually a malicious IP, and not one that belongs to a legitimate user. 

So how do they do this? I want to talk about some of the investments that we made in creating and evolving our information security program. First, as a cloud security company, we obviously believe that security is our top, a top priority for us. It is embedded in our DNA, and it is embedded in pretty much every layer of our organization. It really starts at the top. Security is a board level topic. 

It is a C-level issues. As a matter of fact, the security team reports directly to the founder and CEO, Todd McKinnon, which grants us the visibility and the investments that we need to be able to improve our ... Continuously improve our program. We structure our security capabilities in two ways. One is that we have a core security team, and then we have satellite teams or in some cases just individuals that are embedded in engineering, product, and IT, and other functions. 

That way, each one of those functions get the right level of attention, the right level of focus with contacts and with knowledge of the areas that are important to that team to be able to drive security. We do use a number of principle to be able to prioritize and paint the vision for our security. Essentially they are three principle. The first one is we believe in something called operational discipline. 

For some of you who are parts of the security community, this is often gets referred to as security hygiene. This, we believe that is a fundamental principle for you to be able to run an effective security program. We also maintain agile, security program. And I'll talk about each one of these components. Lastly, we want to bring visibility into how we do security, to both our customers and the security community as a whole. 

So let's talk about operational discipline. To be able to run an effective security program, you have to start with a hardened and strong and secure infrastructure, so the way that's done in our case is that we invest in secure standards. So our entire infrastructure and system that we use at Okta, we define what the secure standards are going to be for each one of those components and we invest in making sure that they are applied consistently as a standard across the environment. 

The second thing that we do is we have a ... Made some investments in running an effective vulnerability management program. What that means is we are aware of our scope, of our assets, end-to-end, and we use a number of tools, a variety of tools to be able to scan what is application system, systems, code for vulnerabilities, all those vulnerabilities are getting triaged and they're getting prioritized, and fixed according to SLAs.

The next thing is we recognize the threat that our users are subjects to from things like ransomware, malware, all the phishing, spare phishing attacks that we see on a daily basis. To be able to mitigate that risk, we invested in hardening our end points. The last thing I want to talk about is network security. So obviously this is a critical area, where they could dedicate the entire slide for it. 

As some of you know, we are 100 percent deployed on AWS. Our entire infrastructure runs on the AWS cloud, so just I guess predictable to suspect that we are heavily invested in making sure that AWS infrastructure is secure. The way we do that is two part actually. Some of the things that we do are include investing in AWS security from the perspective of making sure that our standards are consistently deployed, and if there is any anomalies that are detected, automatically obviously those anomalies are sent as notifications to our team. 

Obviously the proper investigation is done, and any kind of remediation that's needed is taken care of. The second thing is that we limit the communication that is able to take place between the different components of our AWS infrastructure. Meaning if a system on the QA network does not need to talk to production, then we don't provide that ability to talk to production. So there's a great amount of work that is done to make sure that each one of the systems, each one of the components is segregated and segmented, to be able to have effective network security on our production network. 

That segmentation principle extent to our corporate network, so we have segmented our corporate network to make sure that if you are connected as one of our employees, for example, to our corporate network, you don't have any more privilege to access in our production network as if you were connecting from the internet. So essentially when it comes to interaction with our production systems, really the internal network is not necessarily that much trusted. That gives us another layer of security. 

We do recognize that a lot of the information that's being sent between ... Communicated between the client's agents, whether they are browsers, or mobile applications, from the customer side, and the Okta platform contain sensitive information. So for that, all communication between these components, so the agents and the Okta platform or the Okta products is encrypted using TLS. We take that same principle again, and we extend it to communication between Okta and all of the cloud vendors that we support. 

The last thing is DDoS mitigation, so we did learn some great lessons from the Dyn DNS attack that happened last year. We made a number of investments to strengthen our ability to mitigate the risk of DDoS. We are resilient to again, mitigate that kind of risk. Including having multiple DNS providers to be able to low the balance, if there is a need to for that kind of capability. 

So that said, we are an identity and access management company. Because we operate in the shield, we believe that identity and access management and access controls are one of the fundamental principles that need to be deployed and operated to be able to secure our environments. As you can suspect, you would suspect we deployed Okta products on our environments, so we use the entire Okta suite of products. We are 100 percent deployed on the Okta cloud. So we use EMM, MFA, adaptive MFA, SSO and so on. 

We believe in the principle of least access or least privilege. So a user or an employee that has access to our system obviously is onboarded. They're given access just to the types of resources that they need to do their job, and we changed that access as they move around the company and so on. On the tail end, we offer them when they no longer work for the company. But we take it kind of a step further. 

We have some principles that ... Or policies that we implemented to make it very simple, so for example, we have zero developer access to production. No developer within Okta has access to production. We have zero access or vendor access to any customer information. You as our customers there is absolutely no risk that a vendor would ever have access to your information. We don't outsource coding. We don't have contractors that do software development for us and so on. 

So that's some of the principles that you use to obviously maintain an effective access management program. Lastly, we recognize that even having an effective access management program in place, is not enough. So we use encryption to further those controls, and in that respect, we have created an entire hierarchy of encryption keys that roll up to a KMS, a Key Management System, and each one of the customer organization or we call them customer org, that's really ... 

Each of the organizations that we support has their data encrypted with separate keys. So that we believe provides an extra layer of protection, just in case ... Let's say for example one of the Amazon employees get access to a piece of hardware or hard drive that contains Okta information, there's absolutely no chance for that hard drive to contain customer information clear test. 

So this is the kind of controls that we use to cater that use case. So I mention that we run on AWS, but we really do not depend on AWS. What this means is that maybe compared to some of the other vendors, if you are involved in any of the compliance initiatives, you go to the vendor and you ask, "Hey, can you give me your SOC2 report and so on?" They'll ... A lot of times they'll give you the AWS SOC2 reports. 

In a case of Okta, we don't do that. We actually depend on one single category of controls, when it comes to AWS. We don't maintain or we don't have access to AWS data centers, so we rely on AWS for physical controls and that's it. Every other control that is part of our security program is designed, built, and maintained by our security team. Now let's talk about some of the principles that we use ... Actually it's not right. 

Let's talk about how our security program is composed. So I realize that agile means different things for different ... Really in our case, it means a structured program that has comprehensive coverage of our risks, and that is dynamic in nature to be able to counter any new attacks, any new threats that our platform or products are subjects to. So our security team is composed of three sub-functions. 

This is the core security team. This is not the satellite teams that we talked about. The first one is the defensive security team. We have an offensive security team. Then we have trust and compliance. So let's talk about the defensive security team. This team's mission is to harden the Okta infrastructure. They work with different functions, whether it's IT, engineering, our infrastructure team, to deploy ... 

Or I guess to do the risk assessment, to define the kind of controls that we need to deploy to secure our environment, and to design, deploy and operate those controls. They're also responsible for that margin that I was talking about earlier. So they are constantly monitoring in our environment. A lot of the traffic that we receive from our customers they detect and they respond to all those attacks, by either blocking and doing other things to be able to ... As far as the instant response program. 

The second team is the offensive team. This is team that is tasked with the mission of thinking like the attacker. Their mission or their goal is to break Okta. So if they're able to break Okta, they can bring those lessons to our engineering, to our IT and so on. To be able to continuously improve our infrastructure. This is a team that is composed primarily of security researchers. They have been in the consulting industry for a while.

They're very well published. As a matter of fact, they don't only focus on security and the Okta infrastructure, but they also look at the security of the third-party code that's deployed on the Okta product. They often worked with these vendors to be able or to allow them to improve their security defenses. They publish white papers. They present at conferences, such as Def Con, and they also release open-source tools as a way to contribute to the security community. 

They assess the security of the Okta environment, that could be the Okta platform. The Okta product and so on. So they do that by doing a number of things. It could be a threat model. They do threat modeling. They do design reviews, code reviews and pen testing. Pretty much they're continuously trying to break into Okta or to find weakness in our security to be able to improve it. 

They're also responsible for assessing the security of our third-party providers, third-party vendors. To make sure they are up to par. Their security is up to par with our expectations. I think I mentioned earlier that no vendor has access to customer information when it comes to Okta. They work with our developers to deploy ... To do a secure code training for our developers, and the last thing they did do is this thing called ... We refer to it as "industry breach post mortem".

Essentially they scan. On a weekly basis they scan the news and they ... To the extent that there is a high profile breach or a security event that happens, they come back and work with different stakeholders to make sure that we are resilient facing ... If we need to face the same type of attacks that caused those kind of breaches. 

Last but not least, this is our third team. It's the trust and compliance team, as the name implies. They are responsible for maintaining the trust with our customers. And obviously comply with all of the laws and regulations that we're subject to. So they're responsible for ... To be able to do that, they're responsible for governance, whether that's either defining the policies, maintaining the policies, assessing and evaluating our internal controls. 

They are responsible also for making sure that our editing access managements processes are up to par. They're involved in granting access and improving access to privileged users, and they do this thing called customer assurance. Essentially any time you need some kind of materials, white paper, you need a security questionnaire completed for let's say the purposes of your compliance program. This is the team that you interact with. 

Any time you want to coordinate someone to coordinate a pen test, this is also the team that you talk to. They're also involved in having those discussions around our MSA to make sure that we have the right level of guarantees that are given to our customers, as part of our contractual agreements. Also, they look at our vendors to make sure that any vendor that we deal with is up to par in terms of security. 

Lastly, this team is responsible for information security training for all of our new employees, vendors and interns. So with that, I want to talk about the last principle, which is transparent security. What this means is really that we want our customers, we want the security community to be part of our security program, want them to help us improve, and we want to grant visibility to give you the kind of assurances that you need to obviously trust your critical assets to Okta. 

To be able to do that, we do a number of things. So I think mentioned that we have a red team that does pen tests on a continuous basis. We don't stop there, but we also contracts with independent consulting firms to do pen test on our platform, on our product, and our ... essentially environment end-to-end, including corporate. Both pen tests are done on a yearly basis, and you as a customer, you can ask to be given access to the reports that come out of those pen tests. 

So you'll be able to actually see if there are any findings, anything that could be of interest to you. The second thing that we do is commit to running an effective security program, and we don't just say in our ... If you look at our MSAs, we just don't ... We don't just say, "Hey, our security program is effective." We actually go into granular details to commit to you on contracts about every aspect of our security program to give you again, more comforts. 

So not only we have the proper controls. We do our own test. We have independent test, but we also commit to you that those things would be effective as part of our contractual agreements. The last thing and this is something that differentiates us from the rest of the industry. You as a customer, if this whole thing is not enough for you, you are able to do your own pen test on our environments. 

If you have internal capabilities. If you have a red team, you can ... We can help you coordinate a pen test on our environment. Or you can hire a consultant firm to do a pen test one that we have. To the extent that you're able to find something, then obviously we'll have those discussions. We'll do a response, and if there's something for us to improve, we'll commit to you to make improvements within certain deadlines that are obviously acceptable to you. 

Now we're going to talk about the last aspect or components of our transparent security, which is the bug bounty program. So now we not only have our internal security team that's doing assessments. We commit as part of our contracts to you. We let you as our customer look at our security and evaluate it. We also want the entire security community to assess the effectiveness of our security program. 

We partner with Bug Crowd. We launched a bug bounty program back in June 2015. So initially it was a private program. We had 10 researchers out of the 100,000th researchers that exist. That participates in the Bug Crowd program. This is initially, and then at some point in 2016, we decided, okay. Well, we want to get more developers to ... I'm sorry, not developer, but security researchers to look at our security. 

So we opened our program. We made it public. Since then, we had over 10,000 researchers actually look and assess our security. This is different from the 100,000s that exist on the platform. These are actual assessments that took place of our platform and our products. These are some of the things that came out of those assessments. So over the last couple of years, we had 700 submissions that were made. 

We granted a little over 50k ... 50,000 dollars worth of payouts. Then we had, as I mentioned, over 1000 researchers. One thing that's interesting about this is that we didn't have any high or critical findings. The 5,000 dollars highest reward that you see there, was granted to researchers who showed a lot of commitments, creativity. As I mentioned, they were very creative in finding what looked like a security issue, and they spent a lot of time trying to develop an exploit to be able to show or to develop a POC. 

But even if they were not able to exploit what looked like a vulnerability, we decided to grant them that award. So that said, I want to talk also about customer assurance. For those of you again, who are involved with compliance, you would definitely appreciate the fact that went above and beyond to be able to certify against all of these industry standards. So for our government clients, we certified against FedRAMP. On healthcare it's HIPA, for the general customers we have ISO. 

We have CSA star level one, and star level two. As a matter of fact, I would definitely encourage you to go to the CSA star website. Download the questionnaire, and look at all of the details as provided about how we operate our controls. We do a SOC2 audit Type II. That reports if you get access to it ... You should actually ask to have access to it. It has a lot of details about our architecture and how we design our security controls. 

ISO again, EU model clauses for privacy, and then we are working to again, add more certifications and comply with more standards. Namely for FICAM, and we're helping our customers to comply with GDPR. So now we talked about everything that we do on the Okta side to secure our platform, our product, but for our customers to be secure, for your assets to be secure, it's really ... You have a bigger role. 

You have to contribute and really security is a shared responsibility between Okta and our customers. So in a way you have to take security in your own hand. Okta is just a platform. It is a product. So it's up to you to configure it to meet your standards, to meet your policy, and to be able to secure your assets. It really starts by you understanding your environment. Understanding your assets, understanding your risks. 

The risks that you're a subject to. And deploying the right mix of product that will allow you to achieve that goal. Those products could be Okta. It could be some other vendor. Really, it does not matter. The most important thing is that you have the right defenses to be able to secure your assets. We'd be happy if you're deployed on Okta end-to-end, but again, the most important thing si for you to mitigate ... to be aware of all of your risks and mitigate them. 

We also encourage you to have a standard security policy, that includes things like your policy around password composition. We want you to have MFA. Again, I'm going to stress the MFA right now is required. You can no longer rely on password alone to guard any kind of publicly exposed services, and we do encourage that you reduce your attack surface by reducing the number of accounts that each one of your users need to maintain. 

That's done through SSL. You need one single account that allow your customers to log in, to all of the assets in the services they need to consume to be able to do their job. The last thing is ... I mentioned all of these attacks and the fact that Okta monitors the entire platform. We're able to identify block attacks that target our platform, but really we are lacking context. You are the only one. As our customer, you are the only one who is aware of each of one of those brute force attacks against your Okta deployment. 

You're the one who's aware of the context of whether a service is just mis-configured and trying failed password on a continuous basis, whether one of your users is traveling to Australia or some other parts of the world. So you are the one who has that kind of context to be able to make a decision on whether a traffic is legitimate or malicious. To that extent, you must deploy the right level of controls when it comes to consuming logs, whether it's on the Okta admin UI. 

Consumer logs through the API or through one of the applications that is made available to you by one of our partners. Such as the Splunk Okta application. So again, security is a shared responsibility. Actually I wanted this slide backward, but in summary Okta has your back. We have made significant investments in securing our platform and our product. We see attacks every day. They're for the most part simple. They target credentials. 

We have deployed a comprehensive program to be able to secure our entire environment. Really lastly is you have to take security in your own hand. You have a critical responsibility and role to play in securing your Okta deployment. That is my talk. Thank you very much for attending. I'll be around for Q&A. Thank you.