OneLogin security chief delivers new security model

After the 2017 breach of OneLogin Inc.'s cloud identity and access management platform, the San Francisco company made some major changes. One involved new management.

Justin Calmus joined OneLogin as the chief security officer in April 2018 as the cloud IAM provider rolled out a new product strategy built around unified access management. As OneLogin security chief, Calmus is responsible for the company's risk management, security and compliance programs.

The company is trying to rebuild its security program -- and OneLogin security -- after a breach on May 31, 2017. OneLogin was alerted to the unauthorized access to its cloud-based, single sign-on services by unusual database activity that may have exposed customer data, application information and various keys in the U.S. operating region, according to initial reports by the company. At the time, OneLogin had roughly 2,000 customers in 44 countries, including SaaS providers and global enterprises.

In part two of this Q&A, Calmus discusses how the OneLogin security model has changed in the aftermath of the 2017 breach.

Editor's note: This interview has been edited for length and clarity.

When I spoke with OneLogin CEO Brad Brooks, I asked him how the OneLogin security model has changed since the 2017 breach. Is that something you can address?

Justin Calmus: Yes. We take transparency very seriously. I can talk a little bit about the breach of last year.

So here's the gist of it: We were using Amazon Web Services, and with Amazon Web Services, you are issued a key, and that key usually contains access to whatever environment you are spinning up. What happened was an actor got ahold of that key and the actor launched a new instance using that key and then attempted to copy data off that instance onto their new instance.

Justin Calmus

The minute that happened, actually, our tech ops and security team jumped in and they shut down the instance. And we immediately notified our customers. It was a proactive step to ensure that we were being very transparent with the operation and letting folks understand a little bit more.

Are there things about the 2017 breach that you think other CSOs would benefit from knowing, in terms of how it was handled?

Calmus: Be very transparent and make sure that you are actively engaging with your customers. I think that we did that pretty well.

One thing that CSOs should pay attention to is when you are launching an AWS [environment], make sure you do a thorough review of what your keys have access to. Make sure that you are using temporary session tokens and things like that, which are options in AWS now. I would [say] that if you are a CSO and you have an environment up and running, do a review of your keys, basically.

Did the company figure out who carried out the attack?

Calmus: I can't get into that detail. That's still an ongoing thing that we are working on, but I'm happy to talk a little bit more about the technical details.

The actor attempted to launch a new instance and then they attempted to copy data, and that data may have contained some customer data. We are still not 100% certain what was exposed, and I cannot talk too much about that because of the ongoing investigation.

But in terms of the infrastructure, the issue simply was that we were using a key that contained access to a lot more of our infrastructure than we should have. So, after that, what we did was we essentially took a look at all of our infrastructure, all of our policies, even took a look at our executive management.

We changed our infrastructure to be more secure. We implemented the temporary session tokens -- temporary credentials is how I think they refer to them in AWS. We implemented multifactor authentication. You have to actually use YubiKeys to even get a token, so you have to be physically present. Those are some of the small infrastructure changes.

That is one of the things that changed after the breach when it comes to modeling; we do everything through risk models now.

From a policies perspective, we looked at our policies internally and then had an external contractor come in and do a thorough audit of not only our infrastructure, but [also our] policies and procedures.

Finally, the last thing that we did, which is also why I am here, is we switched up the executive management chain. Now our executive management chain has over 100 years [of experience] in the security space, which is great in terms of moving forward as an organization.

You've talked about some of the steps that were taken at OneLogin. Can you explain how your current security model differs from the one used prior to the May 2017 breach?

After the 2017 breach, we took a thorough look at risk modeling -- what approach to take for doing risk modeling and moving that forward.

Everything that we do now from product to security in the access space comes with a risk model. That is one of the things that changed after the breach when it comes to modeling; we do everything through risk models now.

OK, so what does that mean? In other words, how do you define a risk model?

Calmus: It can change per category. A risk model for infrastructure might be [that] you have folks that are VPNing into a data center to access a batching host or middleman host to get into production, so where are the actual risks in your organization? Is there a VPN tied up? Is there two-factor authentication on your infrastructure and your host? Are those things changing? How often are they changing? How often are you changing the passwords in your environment?

All of these questions really graph out what your risk model is, so the best way to answer that question is that risk models are very different from the point of understanding your infrastructure. You understand the people. You understand the technologies. You understand the processes.

And then you take all of that and you can even come up with a calculation. Is this a risk to our environment or is it not? And things like implementing multifactor authentication would lower your risk, and things like, 'OK I can just SSH into any host' would greatly enhance your risk.

Are you in charge of that effort?

Calmus: Yes. Our risk management organization includes the CTO and the co-founder. Then, depending on the risk level to the organization, it can roll up the chain to include most of our executives, so it is an executive-sponsored risk management committee.

What else related to the changes in the OneLogin security model do you think is important?

Calmus: I think just in terms of the impact here -- the executives that we brought in and the staff overall, the infrastructure changes we made, the policy changes we made, and even having a person come in to ensure that yes, those are the steps we should take. I am pretty confident that we took the right steps.

And ensuring that we over-communicate to our customers and be transparent, right? I think there are really big companies that stuck with us through this. So I think, overall, we are making the right steps and companies can see that.