A conversation with Randy Bias
Last week we were able to sit down with Randy Bias — a cloud pioneer and a technology visionary who currently oversees Juniper Networks cloud strategy.
We have asked Randy to share his thoughts on the security of private and public clouds and specifically cloud-native applications. Here are a few key points from that conversation:
Wallarm> Welcome Randy. Could you introduce yourself?
Randy> My name is Randy Bias. I currently work for Juniper Networks and am an advisor to Wallarm. I found myself almost fortuitously in this spot to be kind of one of the main thought leaders for the cloud when cloud got really big in the early days. At Juniper, I focused predominantly around being an internal agitator in a kind of “disrupt before you get disrupted”-type model.
Wallarm> When you say cloud-native applications, what do you mean?
Randy> If you’re thinking about cloud native, these are the applications that were born in the cloud. And so, the cloud tells you a whole bunch of things like it’s not 100 percent available. It will fail. You need to plan for your applications to route around failures. You need to plan for your applications to be tied into their APIs and other services. Cloud-native is a mindset. it’s a way of thinking about your application so that you are taking an approach that is not centered around any kind of infrastructure. That’s designed for failure, that’s designed for scale-out instead of scale up. That has that sort of more next-generation-type look to it.
Wallarm> What are some key security considerations when selecting which cloud to use?
Randy>Lean-forward folks have considerations that are really more about very practical things. “How much does it cost?” “What kind of services and technologies can I deploy on top of it?” “Is it friendly to my DevOps practices? and so on It’s pretty clear public cloud is our default model going forward.
Wallarm> As far as the security considerations, what is there to look for?
Randy> So, I guess what I want to say about security and public clouds first is that people have been outsourcing security even in IT since the beginning. If you look at the financial services industry, for example, it’s a big long extensive supply chain of folks who provide some kind of financial transactions for other folks. It’s not like everything that Wells Fargo does stays within its four walls. They outsource a lot of the types of financial services they have to other businesses, and then they have to go through a process, usually using a SAS 70 audit, to validate the outsourcer who they’re basically outsourcing to. And if you look outside IT, if you look at other utilities that are not say, public cloud, not IT utilities, more like electrical utilities. All of those utilities are effectively outsourcing security for our power, gas, and so on, to somebody else. We know how to trust other businesses, we know how to validate them, so that’s pretty straightforward. We want to see transparency, we want to know what kinds of control objectives people have in place so we can validate them. So the more transparency there is, the more information we have about how they run their security, the better shape we’re in.
Wallarm> I’m glad you brought up AWS because they’re actually pretty clear about what they feel is their responsibility in security, and what should be a responsibility of the clients who run the applications on AWS. They call it shared responsibility model.
Randy> This shared responsibility model they have makes a lot of sense. They’ve basically drawn this line and said: “hey, we do everything below the waterline, you’re responsible for everything over it.” So I Think that’s a great model. And if we look at folks like Amazon and Google, and even Microsoft, their security teams are at a whole other level than the average enterprises’ security team.
Wallarm> So that’s obviously about infrastructure security and general security practices. Let’s look at the application security process. There are tools that we typically use for applications security when we’re in our own data centers. As we move to the likes of Google Cloud and AWS, do the tools change? Do we still need the Nessuses and scanners and WAFs of this world?
Randy> It’s not public vs private clouds per say, but more on cloud-native versus non-cloud-native application architecture, whether it’s behind your firewall or not. Cloud-native applications are designed to be multitenant and scale up and down based on the load. There are multiple environments, devs, staging, QA, and so on, usually on the same infrastructure because you’re taking CICD pipelines, your DevOps practices and using those in concert with your private or public cloud. I think that the classic security system procedures are starting to break down in the face of this because a lot of the tooling and the way we went about it in the past is much more sort of “moats and castle”-type approach, right? We sort of build big walls around what we’re trying to protect and we pretend that the environment never changes, and the reality is that with cloud-native or in teh environments where the environment is changing all the time, your security model has to adjust so it’s more dynamic, and it’s more application and data-centric. You’re seeing some folks like Wallarm start to address those issues but I still think we’re a ways away because when I talk to classic enterprise security teams, they’re just still very focused on “now I need to build this castle, and then they cannot break in”, whereas if we look at the Googles of this world and again what would Google do, you know they’re not really focused on that, so much as let’s make sure we’ve got defense in depth, we’ve got security everywhere, we’ve got transparency and visibility with what’s going on with the system and we’ve got ways to respond very, very quickly to any kind of problem.
Wallarm> What can you share with us about security in the APIs, especially if you’re talking about microservices and applications that are highly distributed?
Randy> I think this is a whole new ball game that we are going to learn about together. I think it’s still early days. As we decompose these applications into lots of microservices and these services are talking to each other more and more over HTTP predominantly. Each time somebody is building their own internal API between their microservices I think that it’s getting trickier and trickier to implement security around that sort of decomposed model. One of the things that’s funny about security is that, again, in the perfect world, as a security person, you’d like the environment to not change. You’d like to have some understanding of what’s going on. But then, what you’d also like to do, is you’d like to learn over time about the particulars of your environment. Your particular APIs, your particular codebases, you know sort of what’s the normal behavior profile, what does it look like. That’s very difficult and so if you also aren’t really in sync with your developers who may be deploying new microservices and new APIs very rapidly say, every week every month. Then you get further and further away from that ideal because not only are things dynamic in terms of the way the environment moves around, but they are also dynamic in that the code velocity and the changes in the code and the changes in the API interfaces which makes it very hard for any kind of security personnel to stay on top of that manually.
Wallarm> I hear you. Here at Wallarm we’ve been working on making security more dynamic and this is one of the main drivers for us. So, last question for you. What to choose, private cloud or public cloud, and which is more secure?
Randy> Yeah, I hate to paint anything with a broad brush. I would say probably generally the public cloud is more secure, but I think it varies from business to business. The sophistication level and the maturity level of different security teams vary across the board quite a bit.
The complete conversation is available as a podcast on Wallarm SoundCloud channel: https://goo.gl/kogi5X
We are always looking for new topics and guests for our podcast. Please, share your ideas and feedback in the comments.
