Skip to content

Interview: Andrew Jaquith, CTO & SVP of Cloud Strategy at Silver Sky

    
Interview: Andrew Jaquith, CTO & SVP of Cloud Strategy at Silver Sky

 In this interview, I sit down with Andrew Jaquith. Andrew's the CTO and SVP of Cloud Strategy at Silver Sky. At SilverSky, Andrew helps guide strategy, serves as chief spokesperson and works with customers, analysts and the press to advance the company's cloud agenda. Andrew played a key role in launching SilverSky, the successor to Perimeter E-Security and USA.NET. 

Prior to SilverSky, Andrew was a senior analyst at Forrester, where he led coverage for data leak prevention and mobile security. He also wrote "Security Metrics: Replacing Fear, Uncertainty and Doubt," which sold more than 10,000 copies and was praised as "one of the best written security books ever." 

In the podcast, we discuss a predictions blog post that Andrew wrote in December of 2013 where he predicted five security "happenings" for 2014. As 2014 comes closer to a wrap, I was curious how he did in his predictions. Andrew also shares his thoughts on how network security has changed in this era of cloud and mobile. We also spend some time discussing what is going on with the rash of retail security breaches and if Andrew believes there are going to be even more. Does this mark the beginning of the end of the magnetic strip? Is "Apple Pay" a viable security solution?

The following is a brief excerpt of our interview:

Jeff Williams: You've been working at a cloud security company for a while now. I'm curious what you think about the days of network security and how that's changed as we move to cloud and mobile and all that.

Andrew Jaquith: There's the obvious point that there is no perimeter anymore, which is to say that your devices, your employees and your data have moved outside your traditional in-house data center, so keeping it inside with a firewall isn't really going to be effective for you anymore. I think we know that, but I think the subtler point about this is if your data and key workloads are moving to the cloud, your security has to go with it, has to. Otherwise it's not going to be particularly secure.

That can take a couple of different forms. There's securing the data itself, and it's very easy to say if you're moving your applications to the cloud, then the person who's data it is, they need to encrypt it somehow, keep the keys, and have it stored in the cloud. Much easier said than done, but that's certainly one way you can do it. There are third party appliances that are kind of "jokey" because they depend on access from inside the network, ironically. I'm trying to think of a couple examples of vendors - you probably know a few right off the top of your head, Jeff.

Hackers have better tools than you...

Jeff Williams: There are a bunch, there are plugins for various databases and full disk encryption and so on. I guess what I see is, if the application has access to all that data and your typical application is full of vulnerabilities, then it's not a big stretch for a hacker to break in to the app and then use the credentials there to steal the data regardless of how it's encrypted.

Andrew Jaquith: Yeah, I think that's right. I think what it means is that as long as the various cloud vendors aren't particularly serious about encrypting the data at rest in the cloud, it needs to be built in basically. There really shouldn't be an aftermarket at all for this stuff, for cloud based applications, it should be just built in. And actually SalesForce has been doing some work here. They bought Navajo Systems a while ago. They use it as well as some of their own software to basically give companies the ability to encrypt at a field level, parts of their data. That's certainly a good start, and probably more of what needs to happen.

Jeff: So is that the solution? Is that how we make security better? We just keep building it into the platform and just expanding the protection that you get that way?

Andrew: Yeah, I think so. There's the data itself, but there's also the network component. This is where I think cloud becomes very interesting, because you're hosting work loads at scale, as the cloud provider you should have a fair amount of insight about the traffic that's coming in, where it's going, whether traffic is malicious. So the ability to plug in a monitoring capability and either connect it up to an existing MSSP or essentially become your own is really interesting.

For example, Amazon has Cloud Trails which is an API you can use that allows you to monitor various security events of interest in your Amazon Cloud instances. That's super cool. You've got a whole series of vendors that are, for example StackDriver, recently acquired by Google, is one. They basically plug into Cloud Trails, allow you to essentially create a sim almost that takes Amazon Cloud Trail data. Here in Boston there are some other companies that are doing very similar things on a generic basis for different cloud environments. So that's the other part of security going to the cloud, making sure that you've got some ability to at least monitor.

Jeff Williams: Do you think that's really just moving up the perimeter? I get this, we can move the security up a little bit, but it still seems like we're a step removed from the actual code. I think of this kind of weird side effect of building more security into the platform as we get more and more powerful platforms, it allows developers to do more and more dangerous stuff. I feel like we can keep trying to slap controls into the platform, but we're always way behind, right? By the time it's a real risk, we've already gotten to the point where the platform's moving up another level. Are we doomed to just chase the advance of software or is there somewhere we can do to get ahead of the game here?

Andrew Jaquith: This is a really fine point, by the way Jeff. There are a couple ways to think about this. I think the first is that, by the way I was making a point earlier about network monitoring and companies like Stack Driver and Threat Stack, another company here in Boston, they provide network monitoring capabilities. I would characterize it as, in some ways, akin to metadata monitoring. If you look at what the agencies want to do, the reason they're so hot on so-called metadata, it's the who, the what, how long, how much question. They don't really need to see the content, but they need to have some awareness of where the communications are happening, how often, whether they're anomalous or not. That is definitely part of the security equation I think. That's important, but it's an "and", it's not an "or."

Back to the or question, which is what can you do to build security controls into your application, and are we doomed to really be behind it? Cynically I think we are kind of doomed because the number of platforms, the number of programming interfaces, the number of stacks continues to increase, and security has always lagged a little bit behind. Part of it is just the natural phenomenon of the URL strategy that a lot of companies have: ubiquity first, revenue later. You want things to be easily deployed. You want them to be simple, you want them to get out there, you don't want them to be fettered by all these pesky security controls and all these compliance worries. You want to make it as simple as you can.

The trick, and I think those of us like yourself that are either in the development community or have tie to it, or me who's really more of a weekend programmer, this has always been the trick, right? How can you get further up into the developer life cycle so that you can essentially have them doing better things from a security standpoint, better by default at a much earlier point in time? That's where you get your real wins. I think we're seeing some of this a little bit with some of the type safe languages. Java did great things for largely eliminating many of the buffer overflow issues that we see with the languages like C and C++ and so forth. But that's only part of it, as you know.

Jeff Williams: Java takes a lot of heat for its security because it's had some problems in the browser, but as a server side language it's made massive advances in security over C and C++.

Andrew Jaquith: Yeah. You see a little bit of this in some of the frameworks. Some of the frameworks are, like in PHP land you've got things like Symphony which do a lot to take some of the pain out of parameter binding and parsing and all this stuff.

Jeff Williams: Yeah, I think Rails is doing some really nice stuff with security and Spring security as well, really moving the ball down the field.

Andrew Jaquith: Spring is, I haven't fooled with Spring in a while, but last time I checked it was doing some pretty neat things. I do think we're always going to be chasing this a little bit though. A certain amount of that is good, but what I would like to see, and I've always felt this way, is I would to see people that really care about applications security to infiltrate the open source community, just really get embedded. We'll know that we've arrived when there's a really good set of native, good, solid security packages in the Chef world, for example, or Puppet or and of these dev ops environments. And there are certainly lots of start-ups that have ideas in this area, but to me if you can infiltrate dev ops and have that built in very nicely into those frameworks and have your development frameworks that are doing things basically by default the way that they should, then we can start to get some real durable wins and-

Jeff Williams: I think you're exactly right. Actually I was just down at Last Con and there's, that conference is a really nice confluence of dev ops folks like Gene Kim and Josh Corman, and then the applications security community with folks like Nick Galbreath and Zane Lackey was there and James Wicket, of course. There were a bunch of talks there that focused exactly on that problem. I think we're definitely trying to infiltrate. I'm glad you mentioned dev ops, because it think it's a really important trend. What Nick Galbreath said on this podcast a few episodes ago was, he said that dev ops is a great opportunity for applications security because they're establishing the infrastructure to do automated quality testing. It doesn't mean you're going to be secure, but it gives the security folks an opportunity to automate some of the applications security things that we've been plagued with for so long.

Andrew Jaquith: Yeah, I could not agree more. Gene's a great guy, but the way. He's really passionate. He's an interesting cat because he's got a foot in both camps. He's been pretty serious about the dev ops world for a long time, but of course he's got a significant pedigree in security.

To listen to the rest of my interview with Andrew, click here.

%MCEPASTEBIN%
Jeff Williams, Co-Founder, Chief Technology Officer

Jeff Williams, Co-Founder, Chief Technology Officer

Jeff brings more than 20 years of security leadership experience as co-founder and Chief Technology Officer of Contrast Security. He recently authored the DZone DevSecOps, IAST, and RASP refcards and speaks frequently at conferences including JavaOne (Java Rockstar), BlackHat, QCon, RSA, OWASP, Velocity, and PivotalOne. Jeff is also a founder and major contributor to OWASP, where he served as Global Chairman for 9 years, and created the OWASP Top 10, OWASP Enterprise Security API, OWASP Application Security Verification Standard, XSS Prevention Cheat Sheet, and many more popular open source projects. Jeff has a BA from Virginia, an MA from George Mason, and a JD from Georgetown.