Thoughts from the Sony Breach

Sony has made big headlines – for all the wrong reasons – for having sensitive company data stolen and posted online in late November. (For full details, I’d recommend WIRED’s “Sony Got Hacked Hard: What We Know and Don’t Know So Far.”)

The event has sparked a lot of debate as to the source of the attack and how it was achieved, with the conversation now expanding to legal concerns and calls to media to stop publishing hacked documents. I certainly don’t know all the facts (and probably never will), but I do know that this was a catastrophic attack for Sony Pictures. It reminds us that any infrastructure is vulnerable to a well-funded, determined attacker.

Whenever breaches get sensationalized and garner the attention of seemingly every publication imaginable, I tend to think about some basic security strategies companies could use to help avoid these incidents.

Here are a few of them:

Okta Strengthens Partnership with Box through Box Trust Security Ecosystem

Ensuring security has always been an omnipresent concern for businesses. But in today’s world of increased cloud adoption, more of a focus on mobility and the ubiquity of connected APIs, the number of malicious threats has amplified – driving enterprises to rethink traditional security postures. New security models must include both the context of the enterprises’ cloud service providers and, at the same time, that of the knowledge worker’s mobility experience.

tumblr_liwifqef5Q1qd9o7rOkta was built from the ground up in the cloud to address these concerns in a seamless, secure way. We create and support new technologies to enable CIOs to offer user-centric technology experiences – empowering new kinds of business value, as well as flexible, efficient and speedy user workflows. And it’s because of this deep focus on security that Box announced yesterday they’ve selected us as a certified partner for its newly announced Box Trust initiative.

Update from Okta - Heartbleed

You’ve likely read about the Heartbleed vulnerability that has affected much of the Internet. The short version: Heartbleed is a bug that affects the way online services encrypt connections between their service and their users, and if not corrected can lead to sensitive information being revealed. Most services and sites on the Internet use OpenSSL, the code that was affected, making Heartbleed a top story this week. We want to tell you about Okta’s response.


Security companies set themselves apart with their response times. Since the initial alert regarding Heartbleed, Okta quickly addressed the bug, updated its service, and eliminated any Heartbleed vulnerabilities going forward.

We have no evidence that any Okta customers have been maliciously impacted by this vulnerability, and we continue to actively monitor and investigate any and all potential issues.

We’ve been working with our customers to outline additional steps they can take going forward. An example is enabling Multi-factor Authentication for even more security. For our customers, all of those steps are outlined here.

Building Trust and Security Through Transparency of Service

Transparency is a great way for cloud providers to demonstrate and prove good security practices to their customers. Often times, however, the transparency stops when outages or service hiccups occur. During an incident, how a cloud provider communicates to its customers says a lot. In a guest post for the Cloud Security Alliance, I discuss why customers should expect clear, transparent SLAs from their service providers, what customers should expect during an incident and why transparency is so important from a security and trust perspective. Head over to the Cloud Security Alliance to read the full post.

With the growing movement of enterprises to the cloud, it’s more important than ever that service providers demonstrate and prove good security practices to their customers, in good times and in bad. During an incident, how a cloud provider communicates to its customers says a lot about its commitment to security. Sounds obvious, right? Well, three different times during the past seven months — and once while I was on a panel at the 2012 CSA Congress in Orlando — I’ve learned that it isn’t clear after all. As CSO at Okta, I work closely with our customers and they always ask, “What will you guys do if a breach occurs?”

Securing Layer 7 – Part 2: Application Vulnerability Management

I recently kicked off a blog series about the importance of securing Layer 7, otherwise known as the application layer in the OSI model. It’s a critical part of Okta’s security program because Layer 7 is closest to our users, and also because Okta’s cloud-based IDM solution integrates with on-premises and external SaaS identity stories, mobile devices — and more. Layer 7 security is top of mind for me.

While I don’t think there is any secret formula on how to address Layer 7 security, I have seen many approaches from my time helping run IOActive, a leading boutique security research and services firm. Since joining Okta as CSO last summer, I have introduced three components or focus areas of Layer 7 security that I know work well.

  • Vulnerability Management
  • Security Development
  • Fix Testing

Securing Layer 7: The Closest Point to the End User

Building and maintaining Okta’s security program is an interesting job, to say the least. The stakes are high: Not only is identity management core to IT, it is central to an enterprise’s security. Plus, Okta delivers IDM from the cloud, so between mobile devices, third-party partners and the inherent security concerns associated with user habits, my job as CSO is truly one-of-a-kind.

We take security seriously at Okta, and have adopted a holistic security program to back it up. Everything we do — whether it’s IT, engineering, product, etc. — directly supports the security posture of our service. As a cloud-based service, we have to be extremely vigilant when it comes to security; our customers depend on it. We pay particular focus on Layer 7 security, which is one of the most important aspects of enterprise-grade SaaS security. Layer 7 is an old-school (but useful) reference to the layers of the OSI model. All layers of the model have security implications that compound when moving up the stack.

Forget Disaster Recovery, Let’s Talk Disaster Avoidance

“What’s your disaster recovery plan?”

It’s a question I’ve been getting from customers quite a bit lately. And it caught me off guard the first time I heard it. Typically, inquiries on disaster recovery come from someone on an audit team who has the daunting task of creating a disaster recovery and business continuity plan across the entire company. To assemble such plans, they must robotically evaluate each of the company’s business partners and service providers. During these conversations, I’ve glimpsed the perfect disaster recovery service and wanted to share a few thoughts.

My first disaster recovery conversation went something like this:

“Hi, David, I am from such-and-such company. I work on the IT audit team. I am currently assembling and auditing the company’s disaster recovery and business continuity plan. Can you walk me through Okta’s DR and BC plans so I can include them with ours?”

Keeping it Simple to Keep it Secure

The New York Times recently ran an interesting profile of Peter Neumann, one of the preeminent computer scientists in the world. The story, “Killing the Computer to Save it,” details Neumann’s ideas for how to solve the inherent security vulnerabilities in computer systems that have been repeated again and again for the past 50+ years. Neumann’s thesis, essentially, is that simplicity is the key to security — advice that’s been mostly lost on the computer industry since its inception. John Markoff of the New York Times writes:

“’[Neumann’s] biggest contribution is to stress the ‘systems’ nature of the security and reliability problems,” said Steven M. Bellovin, chief technology officer of the Federal Trade Commission. “That is, trouble occurs not because of one failure, but because of the way many different pieces interact.” ... Dr. Bellovin said that it was Dr. Neumann who originally gave him the insight that “complex systems break in complex ways” — that the increasing complexity of modern hardware and software has made it virtually impossible to identify the flaws and vulnerabilities in computer systems and ensure that they are secure and trustworthy.”

Neumann is concerned with the security of computer systems as a whole, but his simplicity thesis holds true in identity management, too. One reason on-premise identity management has always failed is because it breeds complexity — complexity to your internal network, IT staff and certainly maintenance.

Encryption in the Spotlight due to Vulnerable Android Apps

Last week, Ars Technica’s Dan Goodin published a story detailing how downloaded Android applications have the potential to expose the sensitive personal data of more than 185 million users.  Vulnerabilities due to inadequate or incorrect use of SSL/TLS protocol libraries expose everything from online banking and social networking credentials to e-mail and instant-messaging contents.  A group of computer scientists identified 41 applications in Google's Play Market that could leak data from an Android phone connected to webservers for banks and other online services.

In addition to the research paper that sparked the article, there was another body of research out of Stanford University and the University of Texas, which exposed additional security issues with Android apps as well as a plethora of other popular web applications, services, electronic banking sites, and more. Again, the security issues stem from the incorrect or inadequate use of SSL/TLS libraries within the applications.

Defining the Enterprise Cloud Service – Part 6: Strong Encryption Throughout

During the past few weeks, I’ve written about what it takes to build a cloud service that’s ready for the enterprise. Essentially, there are three characteristics that set true enterprise cloud services apart from their consumer counterparts: Security. Reliability. Trust. When evaluating an enterprise cloud service for those characteristics, there are five traits to look at:

  • Development for the enterprise
  • Endless 9s reliability
  • Benchmarked and audited service
  • Strong encryption throughout
  • Singular focus on the customer

I saved the “strong encryption throughout” category for the finale because it’s the most important component — and it’s very easy to do incorrectly.