Application Security in the Cloud

Security.

Hi there.

Welcome to the Cloud Security Podcast. Thanks for joining us today. Your hosts here are Tim Peacock, the product manager for threat detection here at Cloud, and Anton Chuvakin, a reformed— mind you, reformed analyst and member of Cloud Security team here at Google. You can find this podcast wherever podcasts are distributed and at our website, whenever we finally launch it. Yes, this is happening. You can also follow us on Twitter at twitter.com/cloudsecpodcast. Now, for the fun part. Our guest today is Alisa Miller, a Business Information Security Officer at S&P Global. So, this sounds like a fun title, Alisa. Would you care to give us a brief outline of what the BISO really means?

Yeah. So, I get that question a lot. What is a BISO? I know what a CISO is, but what is this BISO thing? Why is it a B instead of a C? And really, the easiest way to explain it is that it's like a CISO, but I'm specifically focused on one division of our organization. And instead of being like a divisional CISO that reports into a centralized CISO organization in infosecurity, I actually report into the division and into the division's CTO. So, my goal ultimately, and the focus of my role, is to bridge that gap between the business and the centralized security team, helping the business understand how they can apply these requirements and practices from the security team, but also the other way around too, pushing back on the security team and giving them more business context. So as they're trying to develop new policies and standards and other things, they can do it in a way that makes sense for what we're doing within our engineering teams and across the business lines.

Ah, okay, that actually does make sense. And I wish more large global federated companies would have that because sometimes the team is kind of confused about this whole central, decentralized, centralized requirements. So I think to me that makes sense. So we wanted to hit on the topic of application security in the cloud because I do see a fair bit of confusion in the industry about like whose responsibilities are those, how to fix problems. So in your opinion, Alisa, how do application security practices change as organizations launch their cloud transformation, cloud migration efforts? What changes and how?

Well, so you touched on one already, right? The responsibility really begins to shift. I guess security people, we've been talking about push left for years, probably better than 2 decades, I think, trying to get devs to take on more responsibility for security and get them to understand it from a secure coding practice. But when we start moving into these cloud-native technologies and we start expanding into things like infrastructure as code, or then we get into containers and even now functions as a service, And all these things are defined in code. So suddenly, our developers have a lot more responsibility across more than just the software that they write. And you've got now our infrastructure teams have really shifted, right? We're launching SRE teams who now kind of seem to manage the bulk of the infrastructure, if you will, in our cloud environments. But that infrastructure, again, could be Lambda, it could be Kubernetes and Docker, it could be EC2 instances running whatever flavor of whatever operating system. So, from an application security perspective, first of all, that means that that responsibility has to lay across all of those teams. So, when we think like DevSecOps, for instance, which is so often a part of people's cloud transformation, that speaks right to that. Like, we need those SRE teams to understand information security. They need to understand app security. They need to understand infrastructure security. We need the devs to be a part of it, and we need security to become a better part of the development process. Security can't be this gate anymore that slows us down, and instead, it's got to be something that's well integrated. So, with all these challenges of new technologies and faster development and faster deploys and different ways we build that up, that's the biggest change is everybody has to be a part of it. And that's where a lot of those transformations really struggle is how do we bridge application security across all of these disciplines?

So let's imagine the case where we fail to do that and we just do a big old lift and shift of somebody's big fat complex application to somebody else's IaaS. What are the bad things that happen there? How does that go wrong?

Well, inevitably you just end up with configuration issues. No matter how much we think cloud is going to secure us, and honestly, I tend to see more with the organizations that do just do like a straight lift and shift and forklift bare metal servers into EC2 or something. There, that's where we see most that attitude of, oh, well, it's in the cloud and the cloud provider is going to secure me. So Google or AWS or Azure or whoever, they're going to make sure that I'm safe and secure. And so we miss a lot of like the really simple configuration things that create a lot of vulnerabilities. And then from the application side, you're in a whole new environment where networking is a little different, right? You launch your virtual private cloud. And the communication isn't the same as what we're used to in normal environments. And so it creates new vulnerabilities or new attack vectors that if we're not aware of and we're not testing for in our application security processes, we tend to miss those things. And so what you see is this real explosion, and then you get a lot of finger-pointing, right? When there's vulnerabilities everywhere and nobody's fixing them, everybody's pointing at everybody else. Is it the cloud provider? Is it infrastructure? Is it the development team? Who's supposed to be responsible for fixing this? Because you never really laid it out and you didn't look at what it was going to be. You just picked up an environment and threw it into somebody else's data center.

You touched on something fascinating, which is sometimes people don't trust cloud security, and then sometimes people trust it too much and make crazy assumptions. Like sometimes people would think in the morning, no, no, no, no, no, I'm not moving to the cloud, it's not secure. And in the evening they're like, I moved the app to the cloud. Cloud provider is taking care of it. It's all secure. So I've seen it happen literally like a schizophrenic switch of a mindset from like, no, no, no, it's bad security. Oh no, it's completely secure. So I don't know like how people actually process it in their brains.

People look at cloud and unfortunately we did everybody a disservice, right? How many times have you seen the meme, the cloud is just somebody else's computer? So great, our management thought that like, oh, I can just put my stuff to run on somebody else's server and they're gonna manage it. And so a lot of these organizations never really sit down to think about cloud is a completely different world. You're not co-locating a data center here. You're actually managing a completely new environment that operates in completely different ways. It is not the equivalent of your bare metal server just sitting in somebody else's racks.

The thing that brought me to Google was this, you know, like generational shift in how we think about computing. And it's a bummer to me that we're not thinking about it that way. Did we get this wrong last time we had generational shifts in computers? Like, did mainframe admins start thinking PCs were just mainframes under a desk? Like, did we screw it up before or is this time different?

Oh, we screwed it up before. We screwed it up in different ways. I mean, I can tell you 'cause I lived through a lot of that. I mean, not the early days of shifting, but, you know, I go back to my earliest days as a programmer and I was working in financial services at that time too. Funny how that came back around. And there we had, I was just actually tweeting about this the other day, we had 2 sets of system admins. We had the mainframe, which was, you know, your OS/390s, your MVS, your VMS, you know, and that was what they managed. And then you had the quote unquote open systems support, which referred to anything that they could run on commodity hardware. So basically Solaris and Windows in our case. And those people that were dealing with mainframe, like they didn't wanna touch that open system stuff. They didn't wanna touch Windows. They didn't wanna touch Unix because it was all big and scary. And so they understood it was different. But then on the flip side, you had all the people who that was all they ever knew who were like, Hey, but this is so much better. It's greater. Look at all the cool things we can do. We knew how to do security in a RACF world, right? On the mainframe, we understood that. It was so different when we moved to Unix servers or we moved to Windows servers because we lost a lot of the granular control we had and we gained a lot of features and privileges and things that quite honestly, even initially Windows didn't give you the ability to really manage privileges for. And so we screwed it up then too. It was just very different because there you had everybody assumed that their thing was the greatest thing. And, you know, we knew they were completely different and we didn't care. And so that caused its own problems.

Yeah. And this reminds me, by the way, when you brought up the whole somebody else's computer bit, like I tend to get pretty aggravated when I hear this because sometimes I'm like, okay, here is serverless. Tell me how is it somebody else's PC or somebody else's Unix box? Like, no, no, come on, tell me. Tell me how this function is just somebody else's Solaris machine. Please tell me. Like, I mean, it's impossible. So to me, this is why, well, the AppSec presumably changes when you depart from the world of yours or somebody else's computer and you come into the world of containers, serverless. Presumably you cannot do code review sometimes, testing is different. So what else is different with AppSec in those environments?

First of all, what do you even define as an application? You just touched on it. Like, I've got functions. That's not a server. That's not an app. That is this ethereal little component. Things that I used to define in an object or a class are now like functioning objects in my infrastructure. That's such a weird, mind-blown thing right there. And so, how do you even define an application? Well, you can say it's source code. Well, does source code include YAML and Terraform and all the other stuff you're doing? Because you should really be looking at that too, because all that plays into it. If you've got a configuration issue, someone launches an S3 bucket that's, you know, not being encrypted, or they've left it open to the world. Well, whose fault is that? Who's supposed to support? Is that application security? Is that your infrastructure team? So back to the it's just someone else's computer. Tell that to the Cloud Native Computing Foundation when you see their huge map of all of the cloud native technologies. It's gigantic. I mean, I've got a 30-some-inch, you know, wide monitor over here and I can't fit it on there and actually be able to read anything. It's that much. So where did all those technologies suddenly come from if it was just somebody else's computer? It's not. And so from the AppSec perspective, this means we got to have a lot more tooling around how are we even going to assess it. So you mentioned like code reviews, maybe I can run my traditional code review tool, my SAST tool, if you're familiar with the term. But maybe not. Maybe I'm doing something with something like Scala where, oh my gosh, try to find scanners that can actually handle Scala right now is pretty tough. There's a few, they're expensive, and they aren't really the most feature-rich yet, right? And so we have all these things that are just all a part of this explosion of cloud-native technologies. Trying to understand containers and Kubernetes environments, try to find yourself a commercial scanner that'll scan your Lambda functions.

Forget it.

Good luck. I mean, it's a struggle. And so I think that changes the face of it too, because each one of them right now has its own niche tools and practices. And a lot of those things don't even come together then on the backend when you're trying to manage it from a vulnerability management perspective. Like I'm getting vulnerabilities from some tools that work in real time that are monitoring my cloud configurations, but then I got other tools like my code scanners and my dynamic application security testing tools That are point in time when I run them, and I'm getting those. And when am I getting those results? And how do I correlate those to what I'm seeing from the cloud? And then I've got container scanners that are scanning my container images, and that's a whole other set of vulnerabilities. So, it's just the complexity of cloud. And I know this sounds like a cliché and kind of a duh, but AppSec in the cloud is so much more complex. than it ever was when we were running everything on-prem and we just had to worry about, we wrote this web app, we need to test it. That was easy compared to what we're doing now, and we couldn't even do that that well. So there's a lot of challenges.

All those challenges. One thing you mentioned is real-time scanning of infrastructure for vulnerabilities. Is that a case of good news? Is there good news of how we can actually be more secure in cloud compared to an on-prem?

Oh, for sure.

Yeah.

There's so much that we can do now in cloud that we couldn't do before. It just takes being coordinated about it. So yeah, you know, you mentioned cloud configuration tools. I mean, we have tools at SMP where, you know, they run real time. You know, anything gets introduced to the cloud environment, if it's not configured properly or, you know, it's got some insecure configuration, immediately that becomes an alert. Now you would hope you find those things in the dev environment. So hopefully you've got that same tooling, you got your dev environment in one cloud environment, and then you've got a separate prod and you catch it in dev before hits prod. But you've got that tool. You have this ability that, yes, your containers are defined in files. So instead of having this server with operating systems and everything else that all had to be understood and patched and everything, we still got to do that patching. It still happens, but it's easier to analyze it because I can feed that into a container tool that just pummels through that in minutes and provides me, hey, you know what, you're running this old version of Java, or hey, you've got this particular base image that's got a bunch of vulnerabilities, but if you upgrade to this base image, you'll be okay. So not only our ability to identify the vulnerabilities is much quicker, but we can also fix them a lot faster. I mean, think of how easy it is now to take a container image that's got vulnerabilities, update a base image, update maybe some of the other aspects of that container, and just relaunch that. You don't have to take the environment down. You don't have to plan for some major weekend upgrade. Once you've tested all of it, you go out there, you deploy your new image, you deconstruct one cluster at a time, and up come the new ones immediately. And you got, you know, the fix already introduced. So the hard part of it definitely is not tooling. We've got great tooling that really helps us. It's just how do we coordinate it on the backend? So it's very much more of a process issue.

It's kind of big good news and occasionally big bad news when people really come to the cloud with very much on-prem thinking and they kind of try to shove the on-prem thinking into the cloud. then bad news mostly happens. But if they adopt the practices and the tooling, then we sort of have the good news shine. I mean, maybe this is my unscientific summary.

No, absolutely. That's very true.

Let's try to touch on the other domain of cloud is, of course, the SaaS tools. Like, there are a lot of discussions about the typical enterprise using, I don't know, 50, 60, 70, 500 different software-as-a-service tools. And of course, there you don't even have the code to scan and you haven't built the app. So, is there anything that we can do to improve the AppSec of somebody else's SaaS? We can VA scan their IPs, but I think that's kind of pathetic, right?

And they get kind of upset when you do that. They generally don't like that. I don't know why, but I mean, I get yelled at if I do it. So, you know, and SaaS, it comes down to the same thing it always has, even with commercial off-the-shelf tools that we would install, you know, in an on-prem environment there. I guess you could test it if it was in your own environment. But yeah, now we're using it in somebody else's, so you can't do the same things we'd like to. And this is where it really comes down to governance. I know that that's a dirty word. Anytime I say that in front of developers or security people, they all cringe and shiver and sometimes go into convulsions. But really, you have to have strong third-party management in your organization, and that falls to, you know, a governance perspective. What are we doing with our third parties to make sure that we, on the way in the door, understand their security practices and make that meaningful? I mean, we can send them a questionnaire. And they can bend the truth, they can just outright lie to us. How do we verify any of that? Do we have right to audit clauses? And honestly, I can't stress that enough. If you're going with a SaaS solution, you should be demanding that you have the ability to test their environment once a year or something, that they provide you with that capability. Or if they're really not going to give you that, at minimum, they should be providing you very detailed updates on what their security posture is. So if they have a pen test, They should be providing you some level of pen test results. I'm not saying they should give you the deep dirty details of their report. You know, I mean, I get why they're defensive against, hey, here's how to hack our system in one, you know, 40-page document. But they should be giving you some level of not only here's the vulnerabilities that were found, here's our remediation plan, here's when they're going to be fixed, here's the releases they're planned for. This is a partnership when you enter into a SaaS tool Like that. If you're going to use software as a service, you're in a partnership with that organization because you're both, quite honestly, in many cases responsible for each other's security. So working together, having that visibility and that transparency has to be a part of your contracts. And then the last part of that, of course, is what happens when contract renewals come up? What do you have in there built in that allows you to leverage what occurred before if there were issues in particular to maybe get a better deal in your contract? Or if you're the SaaS provider, heck, if you're performing well and you didn't have any vulnerabilities or you had minimal vulnerabilities and you reacted to them all really fast, you did everything you're supposed to do, maybe use that as justification to make an extra 5% in the next contract.

Yeah, but it sounds like it's going to be a lot of paper security, right? Where we don't really have the strong technical controls, we kind of have the tools of lawyers rather than tools of technologists in our favor. Kind of, we are having the paper defense, which to me always makes me nervous, right?

Yeah, I mean, you know, a lot of it does come down to that because at the end of the day, if you're dealing with a SaaS tool, you're giving them your data. Like, you're probably not connected to their systems. You might be safe that way, but your data is there and that's what you're trying to defend with them. And so, you know, there's only so much you can do from a technological side because you don't own those systems. But at least making sure that they're doing the right things and that you're seeing proof that they're doing the right things makes it a little better than just paper security because at least you're getting evidence.

Yeah.

That they're actually doing what they say they do and that they're doing the right things. Of course, that also requires you as an organization to understand what those right things are because you have to be doing them too and building them into your contracts.

Because I think to judge that they're good, you need to know what good is. And I think that sometimes is confused by clients. So let me try this. This is kind of where we are kind of starting to wrap up and I want to hit you with maybe a hard question. What's your advice to a security leader who insists on doing application security in the cloud the same way they did it on-premise? They just stick to the old ways and they pretend none of this cool DevOps CI/CD stuff exists. They just want to do it the same way. What's your advice to them? Like, yeah, sure, we can say stop doing it, but like anything more nuanced than that?

Oh, for sure. And let's just start with something that has been a mantra in security as long as I've been in development or in security. When it comes to business versus security, business will win every single time. I don't care how committed your leadership is. To the security of their products and everything else. At the end of the day, if they're butting heads, security versus business, the business ends up winning. That's just the way it is. And so, understanding that from a security perspective is important. Where I think security people struggle is they still think in this idea, I mentioned it before, of building gates into the process. Well, the problem with building gates is, of course, as we know, Every gate you put in somebody's way, especially when you're talking to developers and engineers, they're gonna find a way right around it, right? I mean, that's what they do. And gates are just this thing that creates friction. And so, if we're talking, for instance, like a DevOps CI/CD type pipeline, things that stop the pipeline, or worse yet, push it backward, those are the things that really threaten to just destroy the pipeline. They go against everything that CI/CD stands for. And so if you introduce that as your security practice, your devs are just going to work around it, they're going to do the bare minimum. So when you bring security into the space, the best way to do it is to bring it in a way that you can demonstrate to your engineers and your devs, hey, this is actually going to make your life easier, this is going to streamline your development, I'm going to put a SaaS tool in your IDE, so you can go ahead and you can program to your heart's content, write all the code you want, it's gonna alert you when there's mistakes so that now when you commit that and you promote it and the pipeline kicks off, it doesn't break the build because you had some super ugly vulnerabilities sitting in there. So now you can avoid those break-the-build situations. So show them how that happens and how pushing left truly, like, into their desktop helps. The other one I really push, and this is like the ultimate push left, Threat modeling. And I know there's a big ugly word, right? That takes forever.

We have a whole episode on it.

Forget about this idea we're gonna, you know, draw a huge diagram of our system and talk about all the possible threats. Break your threat modeling down and just do it at the user story level and literally document it in the user story and put it in plain English. You don't need to have all these technical terms, but put it in there because now what that does is your business people can write that stuff. Like, they understand what threats are in terms of theft and loss of data, and they understand where the critical assets are so they can talk about, here's what's most important based on just this user story. Your devs get that. They can take that and they can internalize that and they can build security controls around that, right? I mean, it suddenly now it's like, this makes a little more sense. I'm trying to defend against this very specific thing. Okay, so they can build that in, but now you've got that documented so you can also know what you're testing for. So if you're trying to do CI/CD/CT, continuous testing, now you can start to automate those test cases, or at least prioritize which automated test cases you need based on the user story. And then when you get all the way to production, your SREs have information that they can leverage to build better monitoring because they know what the main threats are. They know what the attack vectors are from that threat modeling information you did way back in the user story, and they can build that into their tools. So now you start to show them Here's how this makes your life easier. You don't have to go through big design for security. You're not going to have all the vulnerabilities you had because you're accounting for this from the start. It makes it easier for you to sit down and just build these things because you've already got it documented. And that one step you did back at this user story flowed through the entire process and made everything easier for you.

Well, I really like that. So we're going to ask the final question, and this is becoming the traditional final question. What do you recommend as follow-up reading or materials for listeners to go check out so that can, you know, keep getting deeper on this stuff after they're done listening?

Oh my gosh, anything that you can do to start to dig into cloud security. I think I saw Google was offering some cloud security training right now for free. Yeah, do look at the cloud security training out there right now because even if you're a dev, it's so in demand that devs come in with that ability. It gives you, if you want to look at maybe pivoting into a security role, I mean, people are dying for anybody that knows cloud security. And there's a lot of information out there right now from the cloud providers on how to secure their networks. People just aren't reading it or they're not understanding it. So that's where I tell people to really dig in. The other one is just, I mean, I love reading devops.com. They've got their DevSecOps section of that. And I go in there a lot just to read through, see what people are talking about. And you can go back to the other DevOps sections and you get a lot of really unique perspectives out there. And there's a lot of discussion again about security mistakes and security strategies. That's one website in particular that I really love.

Well, hey listeners, Alyssa, we are at time today. Thank you so much for joining us. You can find this podcast wherever podcasts are sold. You can follow us on Twitter as well, twitter.com/cloudsecpodcast. My co-host @anton_chuvakin, myself @timpeacock. And our guest @alissam_infosec. There's no B in your Twitter handle though. No. For a BISO, we're missing the big.

No Bs.

Please listeners, tweet at us, email us, argue with us. If we like or hate what we hear from you, we might even invite you to the next episode. And with that, we'll see you on the next episode of the Cloud Security Podcast.

Security.