Our online world may consist of things like routers and firewalls and storage arrays, but the user interface through which we access that infrastructure is the application. It could be a CRM platform or it could be a random noise generator on your mobile device. No matter how you use it, each of these programs accesses resources and has security features that need to be considered.
CRM and other database platforms have much higher security standards. But any application that accesses or stores personal data needs to be safe. Not a day goes by in modern times without the notification that some application exposes sensitive data in some form or another. Often, the vectors through which these exposures happen aren’t readily apparent to researchers. It could be some form of cross-site scripting (XSS) or perhaps a latent vulnerability in the code base. No matter how the attackers get the data it’s too late to stop it once they have what they came for.
Perspectives on Protection
How do you stop all these exposures from happening? Well, one idea that I’ve heard floated around frequently in the is “moving security left” in the Software Development Lifecycle (SDLC). We often think of security as something that’s just attached to the project after it’s been developed and tested. That kind of thinking leads to massive exposure in the long run. Instead, we need to move the discussion about security further into the formative phases of the SDLC, which are typically illustrated on the left side of the chart in the Build and Plan phases.
Shifting security to the left means understanding how to find vulnerabilities in the program before it’s built and ready to ship. That means you need to be able to scan the application for these kinds of issues as it’s being put together. That means changing the way you look at security with regards to the build process.
During the RSA Conference earlier this year I had the chance to talk to two different companies taking a look at the problem from two different perspectives. Tinfoil Security and WhiteHat Security are both application security platforms that focus on catching vulnerabilities before they are released into the wild. Both companies also say they have a focus on the development side of the house. How they both choose to attack that perspective can help you understand the difference how to move security left in your SDLC.
Shiny Hats
Tinfoil Security was founded by Michael Borohovski. However, anyone that’s ever met him knows that he prefers the name “Borski”. He told me that he’s been started his turn in the security world by hacking video games when he was 13 years old. That kind of mentality lends itself well to looking at applications as targets. After he graduated from MIT he co-founded Tinfoil in 2011.
Tinfoil is focused on the developer side of the house and specializes in API security. Borski told me that Tinfoil grabs the APIs of the application and starts trying to attack it just like a real hacker would. They take fields and fuzz them to see what gets returned. They try to inject code to see if there are any escapes or sanitization issues with the API. Tinfoil tries to emulate the way that someone with nefarious intent would invade your systems.
Tinfoil doesn’t need access to your code in order to test your system. They want to see how it will work when someone tries to access it after it’s already published. That means you don’t have to focus on using it with pre-production apps. You can instead run Tinfoil against apps you’ve already built and ensure that they were built properly.
Tinfoil also helps you in the development cycle by allowing your teams to check their code as it’s completed. If you expose your APIs earlier in the cycle you can let Tinfoil push them to their limits and find the exploits before they ship. As Borski said, “vulnerabilities are bugs with consequences”. By looking at vulnerabilities as an inevitable part of the process, you can help catch them more quickly instead of treating them as something exceptional that should never happen.
Ivory Hats
The other company I spoke to during RSA was WhiteHat Security. They take a different approach by integrating into the early phases of the SDLC. WhiteHat Security can scan your source code to determine if you have vulnerabilities in out-of-date libraries or in methods that have been deprecated.
WhiteHat has been around for quite a while now. They were founded in 2001 and have been providing offensive security security servers for their customers for that time. Their perspective is that vulnerabilities don’t happen in a vacuum. Instead, most things are caused by a series of code decisions that layer on top of each other to create issues. By detecting those issues early you can get them patched out and fixed before they make it all the way to production.
The flip side of that integration is that you need to have WhiteHat installed and looking at the process early on. It’s not something that really works well after the fact. WhiteHat does have web app scanning and a huge knowledgebase that helps you understand why a particular method might have been deprecated. It’s all very much focused around the perspective of stopping everything before it gets pushed into production.
The buzz around this kind of security protection is enough to generate interest for sure. Shortly after my interview with WhiteHat, NTT announced they were acquiring WhiteHat Security, which later closed on July 1. NTT is looking to integrate their security scanning platform into the wider group of offerings that NTT has in verticals such as healthcare. That’s a great way to get their software integrated into places where exposure is a regulator concern or could create massive legal issues.
Bringing It All Together
WhiteHat and Tinfoil both look at things from a slightly different perspective. Which one is better? It really depends on where your focus is. If you want to catch the bugs early in the process looking through source code to catch bad or outdated methods, you should look at WhiteHat. If you’re a company driven by APIs and looking to test your software the same way it would get attacked after deployment, Tinfoil is the way to go. Both have their strengths. And both will do a great job of filling in the gaps. But every development team has a way of looking at things. And you need to know that perspective before you’re ready to commit either way.
For more information about Tinfoil Security, please visit tinfoilsecurity.com. For more information about WhiteHat Security, please visit whitehatsec.com
