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

In this post, I’ll focus on the first component: vulnerability management. It may be a hot topic of debate for many security professionals, but vulnerability management is not simply compiling results from an automated scanner. Instead, it’s about identifying valid application vulnerabilities as quickly as possible and getting those issues into the developers’ queue to fix quickly. (Sure, “quickly” and “as fast as possible” are relative, but it should go without saying that you have to assess the risk of the validated vulnerabilities.)

But how should you go about identifying and validating vulnerabilities? And what’s the best approach to applying risk? These can be subjective in nature. Automated penetration testing, scanning and static code analysis tools will kick up a lot of false-positive vulnerabilities. I use “valid” and “validated” to describe vulnerabilities that need to be found and fixed, which is where an actual human is important to bypass the false-positives and identify issues that could conceivably occur.

Third-party consulting firms are a great source of validated vulnerabilities. Even if you have an on-staff penetration testing team (and odds are that you don’t), use and alternate between reputable independent third-party penetration testing firms, even if it’s only once per year. Good firms will have the latest attack methodologies and will be able to draw upon years of experience testing apps similar to your company’s app. This doesn’t mean you should discount your automated scanning tools, as I will go into further below. Here’s a pro tip: Have the third-party testing firm you select use the same automated tool that you use to enumerate all possible vulnerabilities before validation. This allows your team to have a baseline to focus on new issues that may appear.

What about internal means of identifying vulnerabilities? Just because automated tools will report many false-positives doesn’t mean they can’t be useful. If you make one or two tools part of your arsenal, use them to arm the folks who understand the most about the application. Personally, I like to employ static code analysis tools, but they are often deployed incorrectly. Here’s another pro tip: Get the static analysis tools into the hands of your developers as much as possible. If you have time, I highly recommend viewing a video, recorded at AppSec USA 2012, about how Twitter’s Dev-Ops security team did this for their development team. The take-away here is that you can leverage the development process to find and fix security issues before they even make it QA testing.

Public feeds are another method to consume potential vulnerabilities to your app and the infrastructure that runs it. It can be difficult to keep track of the latest advisories or recently released zero-days, but as security employees, we have to do it and then dig into which ones actually impact our applications and services. While subscribing to support newsletters and frequently checking vendor support sites are a must, Twitter and Google Alerts are great tools to dial into security industry folks, so you can keep up-to-date on the biggest vulnerabilities that could affect your service.

Lastly, the most important component of vulnerability management is how transparent the provider is to its customers. I get to say quite a bit in this blog about what works for Okta, but how do I demonstrate it? All Okta customers have access to our quarterly pen-test results, and I sit down with customers and discuss Layer 7 security — and vulnerability management — all the time.

Last pro tip: Penetration test reports are not dirty laundry! If you are cloud service provider, share them with your customers, even if they show weaknesses. Your customers will have a tremendous amount of respect if they see that you’re not only hunting for vulnerabilities, but in how you’re fixing them, too.

In the next installment, I will get into assigning risk as well as increasing Layer 7 security through security development. I will also draw upon Security Development Lifecycle (SDL) fundamentals that drive better Layer 7 security in the development process.