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.
Successfully securing Layer 7 can be a challenge and it requires an investment. A cloud vendor’s commitment to Layer 7 security says a lot about how the company as a whole handles security. CIOs and other IT leaders who must vet and evaluate the security of current and prospective enterprise cloud vendors can use Layer 7 as a barometer. In my mind, there are three components they can use to evaluate how service providers manage the security of their applications:
This goes beyond simply running a vulnerability scanner. Vulnerability management is how a vendor identifies and manages fixes to security flaws. But how vendors assemble their vulnerability management program can be the stuff of ardent debates. After years of running a security research and penetration-testing firm, my approach is empirical and based on what I’ve seen that works well. Here are a few questions to help you ask about a vendor’s vulnerability management:
- How are vulnerabilities identified, validated, classified?
- Is there a formal fix process outside of just opening a ticket to the development team?
- Which assessment methods are used (i.e. code review, penetration testing, static analysis), if any? Are they accurate?
- Do you use third-party services, or do you rely on your own team to assess security? Or both?
- Can you prove the validity of the assessment?
Application layer security features secure development practices and safe code routines. This is not just about security features in the application but how security is built in broadly. The answers to the following questions say a lot about whether a vendor builds in security or bolts it on after the fact:
- Do you have a documented Security Development Lifecycle (SDL)?
- How is the SDL integrated into the broader Agile or Waterfall development process?
- Which tools do developers use to identify security flaws?
- Is there adequate separation of duties with the development team to ensure a release can be halted if security flaws are found?
So, you have found a bunch of vulnerabilities and your developers have quick fixes for them. Ensuring the same issues do not happen over and over again is critical. SaaS vendors, as much as possible, perform feature testing at scale. It’s important to test repeatedly as flaws such as cross-site scripting (XSS) tend to recur often. How your SaaS vendor leverages quality assurance testing to mitigate security issues says volumes about the Layer 7 security of the application. Questions I often ask include:
- How are the vulnerability management results fed back into the development process in real-time?
- Are the quality assurance and development teams separate? If so, what is the hierarchy?
- Which tools do the developers use to validate that flaws were fixed and won’t recur?
By no means do these question cover everything when it comes to Layer 7 security, and it’s necessary to flesh out a lot of information in the areas I listed above. In subsequent blogs, I will talk about vulnerability management, security development and fix testing in greater detail.