 So thank you very much everybody for coming. Right now we're gonna talk about securing a cloud migration, which is about taking an application that you have either running on premise in existing data center or taking a new application and getting those systems and applications up into the cloud without having those applications get taken over and owned either at the application level or at the system level. To introduce myself, my name is Eric Costlow. I'm a member of the developer relations team for contrast security. We focus on the context of self-defending software. Prior to contrast, a couple of roles that are interesting to a number of people in this area is I was one of the principal product managers for Java 8 in Oracle. If you remember before Java 8 shipped, there was a series of hold the train events when it had a set of nominal security events going on in its ecosystem. And we took it from being frequently exploited to having almost a two year shutout in zero day attacks against the Java platform, the JDK. Also, I was on the product management team for an organization called Turbonomic, which focuses on IT performance assurance of ensuring that applications are running at peak performance in the desired state and helping them go from on premise into the cloud both to maximize performance and availability as well as optimizing cost. I also have several different courses available through packed publishing just on general software development for anyone who is interested. Now, the way that I wanna structure this talk about securing a cloud migration is to first talk about a couple different cloud migration strategies that people use to get their applications up into the cloud. Then I wanna talk about how those applications are at risk when they're up in the cloud. And I wanna focus on mechanisms that you can use to defend those applications. So we're gonna primarily spend our time at the application layer itself, not necessarily at the infrastructure layer because it's the applications that are generally attacked because they have a lot of that data. One of the things I'm gonna avoid is I'm just gonna assume everybody here at Pivotal Cloud Foundry Summit knows why you wanna go to the cloud. So we're just gonna go straight into doing that in a secure manner because we already know all the importance of the cloud and why we wanna do that. Now, some of the ways that people use and the strategies that they used to get to the cloud follows this AWS cloud migration white paper during which a series of consultants for Amazon and their partner ecosystem just mapped out the ways that organizations take their existing assets or new assets and how they get those up into the cloud. There's a revision of this paper. This is the 2015 layout. There's another version that they released in 2018 but I think they tried to simplify it a little bit and I don't like it as much. And the nice part about this is this is just a basic migration strategy. So you can actually take all the same principles and you can use and apply them to anything. So you can apply the same principles to Pivotal Cloud Foundry, any of the Cloud Foundry distributions, or Azure, or just about anywhere that you wanna go. Now, they broke those layouts into a couple different words, what they call the six Rs of a migration. So rehost, replatform, refactor, repurchase, retire, and retain. And in the security industry, Edward Amoroso has a couple different mechanisms that he broke it down into, which are three of explode, recognize that there's no perimeter, offload, which is essentially to virtualize it or get things off of specific hosts, and then to reload and continually take those things and aspects that work. Now, going back to the diagram, one of the techniques that a lot of people use in cloud migrations is what's called the lift and shift pattern, which is I have my application, I have my assets that I use, I just wanna pick that up from the area in which it runs right now, I wanna move it over into those assets, that platform as a service, or infrastructure as a service, and I just wanna have my exact same application run with no changes because I want it out of my data center, I want it in that area where the system is cloud managed. So because we're in the context of the AWS white paper, I'll put it in their parlance rather than using the PCF distributions. But essentially, if I wanna just take an application, I could pick up that application if it's like a war file or a Python web app, and I can just move it over into Elastic Beanstalk. If I have a Kubernetes item, I could just pick that up and pop it into Elastic Container or Fargate, or if I have things like virtual machines, then I can just use that and move it into things like LightSale, Elastic Container, Fargate, or wherever they need to go. But in a sense, all I'm doing here is I'm just picking up my asset, I'm moving it over to the cloud, and I'm setting it right back down without any changes. Now if I do wanna make some changes to that, then I can do the refactor mechanisms, which is refactor for, in this case, AWS or PCF, or whatever I have, but I go through and I modify my application to work with the APIs of those cloud providers and to take more advantage of the individual service. So the benefit of the lift and shift is it's easy. There's no changes that need to take place with the asset or application itself. The benefit of the refactor is that you're more native for the cloud, you can take advantage of some of their APIs, and you have a little bit more integration. However, it does require some extra work that you have to do simply because refactoring involves making changes to the code or the way that the application runs. Now when I go to do that, there's a couple different questions that I have or difficulties that I need to answer in that, which is, which cloud provider am I gonna use? Am I gonna use the PCF abstraction? Am I gonna go to AWS? Am I gonna go to Azure? And it's important to get that right as early on as you can because things like the cost differences are relatively significant. And if I'm gonna do that lift and shift approach of just picking up my asset, my application, and migrating it over to the cloud and putting it down, I can't just do that on an individual application basis because I need to know what that application actually talks to. For example, I can't just take an application and say, yes, I'm migrating this to the cloud while it communicates frequently with a database that's on-premise. And the reason is now I have a lot of back and forth chatter and when you pay that egress cost from the cloud to constantly go down for every SQL query that you wanna run is both silly and slow, but it's also very expensive because there's a lot of data interchange that goes through where every single query that you do goes back and forth. So the lift and shift is a nice asset when you know specifically what you have to lift and shift, but you wanna be able to move the whole thing that happens. Now the difficulty with refactoring is it's possible then to bind yourself to the architecture of a particular cloud provider or to engage specifically some of their services, not at the abstraction layer, so you have that difficulty of things like a vendor lock-in. One other difficulty is a crazy long bills that you get, like this is an actual picture here, this took place in the state capital of California where they got someone, probably an intern, to dress up as a human-sized receipt, presumably for some reason, I don't really know, but at any rate you get these crazy long bills and you go and you migrate things into cloud providers so you wanna know what you're picking up and what you're bringing over and you also have the difficulty that security still needs to be built in. You can't just take something and say, I'm gonna pick that up and I'm gonna move it into the cloud and therefore it's going to be secure. I have had conversations with people where they say, but the cloud provides security, so if I put my application in the cloud, it's gonna be secure. There's a rule that's called Betridge's law of headlines which is if you ever see a headline that ends in a question mark, the answer is always no. And the reason is if someone's gonna write it as a, if the answer was yes, then someone would just say it as a statement. So in this case, does the cloud secure my applications? It really doesn't. If I take an application that has known vulnerabilities like known SQL injection vulnerabilities, known deserialization vulnerabilities or anything like that and I pick it up and I just put it in the cloud, now really all I have is a set of vulnerabilities that are present in the cloud, which have higher accessibility because there's no perimeter. So does this take place on a regular basis? Yes, it does. Here's a set of headlines that I grabbed about people configuring in the cloud. DRA firm left 1.1 terabytes open. Somebody leaked 48 million Facebook profiles. That's probably not that much nowadays. Booze, Allen, Hamilton, somebody took over Tesla's account to mine cryptocurrency. People took over the Uber account. This stuff just happens all the time. And one of the things we might say is, does this happen only to big companies? Are people specifically going after them? You know, Uber, Tesla, Booze, Allen, Hamilton, those are big names. Is that just gonna, that might not happen to you because maybe you're at a smaller shop? Yes, it will. People just generally get pretty good at going through and combing and finding vulnerabilities to find. So in this case that Ryan Hellyer was just an individual developer who was working on some code in his application. He went to bed and he woke up in the morning with a $6,000 bill from Amazon because someone had taken over his account credentials, gone in and provisioned a series of instances that just mined cryptocurrency. Whether that cryptocurrency is worth anything or not, I would say no, but that's beside the point. However, it was worth about $6,000 to him that he had to go and debate, which he was on the hook for because it's his account. So what do these things have in common? What is it that we're looking for? It's not necessarily important what the individual mistake is for each instance. It's not like the lesson learned is, oh, I've gotta watch my account keys. It's not like the lesson learned is, oh, I have to do my composition analysis to figure out what my dependencies. It's not about the individual vulnerability. The key thing that happens here is, do you have the ability to detect when a mistake is made or when something's going to impact the security of your applications? Because if that answer is yes, then you're gonna find something before it's a problem. And if that answer is no, then you're just gonna be hit with a problem at some point later on. So what is it that people are actually looking for and what's gonna harm a cloud application? It's really the same thing that's gonna harm any of my on-premise applications. And there's a couple different organizations that analyze these assets. So OWASP, which is the open web application security project, they maintain a series of what they call the top 10 security vulnerabilities, which is just an analysis of the types of flaws that people use to break into applications. So it has things like injection flaws, buffer overflows, misconfigurations. Another organization called SANS maintains something that they call the top 25 issues. So it's 10 versus 25. Everyone wants to pay attention to the ones that are relevant to them. So in this case, we have things like mitigations of SQL and NoSQL injections because each of those speak a different syntax. So I can't just watch my NoSQL Mongo databases for SQL injection and assume that makes sense because I'll never find them and it's kind of wasteful to watch for the wrong thing that could never happen. You have a couple other examples here like compromise JavaScript package caught stealing NPM credentials. And this has happened to NPM a couple times in the last year or two where somebody takes over an existing module, they put in their bad code, everybody downloads that module and just runs it on their system and all of a sudden they're just executing exploits and the faster you can execute your node code, the faster you can execute your exploits. So it's very exciting in that if you only focus on performance and not security, you really just end up getting hurt faster. Now how do people find my app to attack? Are they specifically going after your application, looking for it, hunting through your code, reverse engineering things? Sometimes yes, but for the most part, not really. So this is an article, I actually wrote this article about Tomcat and Kafka being selected for an EU bug bounty program called Fossa where they budgeted a million dollars to pay people to find security flaws in software and publish them with an additional bonus if you can contribute a fix that remediates the security flaw. And when you go through and do an analysis of how a lot of people make money in these bug bounty programs in their spare time, what you find is that people, they're not spending time hacking the individual application, what they do is they learn to find a particular type of flaw, they look through the programs for applications that have that particular flaw and then they just report them. So yes, you could go through and say, I'm gonna become the expert at hacking Apache Tomcat or Apache Kafka, but more often people just find a particular class of vulnerabilities and then they get really good at scaling out like kind of like a search engine where they just learn how to find it very quickly. So what happens is somebody will be good at finding a particular flaw and they'll discover your application, it's less so that they find your application and then seek specific flaws in it. Now, when I go to defend these things, whether I have an application that's on-premise or in the cloud, the key aspect there is that the perimeter disappears because there's no concept of coming into the network because when we have something that's deployed up in the cloud, it's really the whole point is to make it accessible or to have wide network availability according to NIST. But the thing that I focus on is this aspect that the cloud uses the same run times. So we have a common point here in that when I run a Java application, it's still a Java application. When I go to run a Node application, I'm still running it on Node and when I go to run a Python application, I still have it in Python. So essentially, the commonality to all code and all dependencies that you use is that that code is designed to run and if the main aspect of code is that it's supposed to run, then the logical place to evaluate it for security is in the run time. Now I look for allegories in different areas and there's a comment from Jeff Bezos in an interview that he did quite a long time ago now where he focused on the concept of instead of chasing the things that change or instead of going after and saying, well, what's gonna change over the next year, you focus on the things that won't change. So when we look at retail, people always wanna get their packages faster. They always wanna buy things at a cheaper price. There are common things that they always want. So rather than focusing on how to improve individual aspects, you focus on the core, which is what is it that people want? And in this context, one of the things that we can focus on is the run time is common. The run time is not gonna change. It's still, the Python app is still going to be a Python app. A Node app is still gonna be a Node app. So if we hit that common point and we focus on that commonality that's not gonna change, we can insert defenses that are actually going to work and are not gonna change out from under us. Now some of the things that we wanna do in order to secure these applications is to focus on the top to the bottom of the stack. So what's the application API and then what's underneath it? And one of the nice things that PCF does do is it focuses on container, host, network, and all those availability aspects that you need in order to run your applications. And the way that I go through to secure my actual applications is to focus on the application and APIs themselves, inserting defenses where it's appropriate within the application so that I can defend against the right attack at the right location. For example, I don't wanna worry about things that are not gonna impact me. Like if I'm gonna be using MongoDB, I don't constantly wanna be searching for SQL ejections and saying, oh, this attack looks scary because it's bad input. If I'm not actually using SQL, why does it matter? If I have an application that's a database like MySQL, why would I worry if somebody's attempting to give me cross-site scripting attacks that are not gonna be inserted into the database because it's not even a web application? So I wanna make sure that I defend my applications against the things that are actually relevant to them. Now, how do I effectively secure myself anywhere? The nice part that I do is I focus on the run times, those items that are all the way over on the left, the Java, the node, the Python, and I focus on securing those because they're common and then if I put them into Cloud Foundry, then I can take my application, secure that in a common way, put it into Cloud Foundry that's common and then it really doesn't matter which Cloud provider I run it on. So I can run it on AWS, I can run it on Azure, I can run it on Google, or if I wanna run it in my own data center, I'm welcome to do that also through the typical hybrid cloud model. Now, is this my idea? I would like to think so, I would like to take credit for it, but it actually comes in part from David Zendian who is Pivotal's Information Security and Compliance CTO and also Jeff Williams who's the CTO of Contrast where I work so he did a great job on this presentation too, but it's just nice to go through and evaluate this embedded security model of making sure that we have things, the right defense at the right location in order to actually work and defend against threats that are relevant. Now, what does the non-embedded model look like? When you don't embed security into the aspect of development, what you get is a whole bunch of tools shoved around all over the place that each do a different thing and do it very wrong or do it from the outside in, just looking for things because nobody looked there originally. So what you end up with is this concept of, oh, we got a schedule for the penetration tester. Well, he's not gonna be available for the next month. So can you wait to deploy? No, ah, what do we do? You end up with these things like you need a WAF which is a web application firewall. Oh, but you also gotta have your next generation WAF because that's different. Oh, in addition to those, you need an intrusion prevention system. So what you end up with is we call it this kind of tool soup where you just get all these things and you just throw them in a pot and eventually something comes out and it really has no form, but there's sure a lot of ingredients in that tool soup. Now the way the Pivotal goes through and pushes this cloud native security vision is the concept of being able to repair, repave, rotate. So I was just in a conversation about Vault where he was talking about frequently rotating credentials so that in the event that somebody does take access to the credentials, which is how that guy got his $6,000 bill, that credential is rotated. So the window of exposure is very limited in the event that you do actually get attacked. Repave that way if somebody does manage to compromise the system after a short time, something comes through and just restores it to a known good state. So maybe that guy can hack it again, but they have to so it increases their work factor. But the main one that I like to focus on is this notion of continuous compliance because we don't wanna have this level of strobe light security where we go through and we're like, all right, boom. Hey, we were secure two weeks ago and that's great. Are we secure today? I don't know, we deploy eight times a day so code is totally different. So what we wanna have is this continuous visibility of being able to actually look at our applications and actually see, are they secure right now? So you convert what is like the strobe light where you only get this visibility like once a week or once a night of getting a visibility of your security posture or worse if you use a manual penetration tester into something where you're continually watching the security without requiring the expertise of somebody who's dedicated to security. So in essence, the system is constantly watching. Now, what does this continuous process look like? If you want something to be continuous, the easiest way to do that is to go after the development aspects that have the word continuous in their name, like continuous integration and continuous deployment. So if you go to secure the runtime which is typically done through in Java, it's instrumentation in Node and Python, it's monkey patching, you focus on integrating a sensor into the code so that security can be separated as a concern and it can just happen. And that way you have a continuously adaptive defense that can go through and monitor while you focus on the concept of the business logic and what you want the application to do. So just like we've done with unit tests, integration tests, system tests, what we do is we constantly monitor across the circle of DevOps where at each level we have the ability to test and monitor it. So as you're writing the code, something can go through and analyze the code. As you build it, something can go through and analyze those unit tests as they execute. What level of coverage do we have? Well, did we monitor them for security also? Yes, we did. As you go to release it and deploy it, you have something that continually watches it. As you go to operate it, this is probably the most important one to be watching because that's when the application is actually running and if somebody is going to attack an application, they can only attack it if it's running. So that's where I would spend a fair amount of time gaining visibility in terms of monitoring and then I want to take that information in, I want to plan it and I just ultimately feed this back in as a cycle where I can continually watch the security of my application just over the entire course of how it works. Now, embedded security with everything, you just hook this in with your continuous integration systems so you get it while people are developing code. You have the ability to monitor the code through the run times because we're running things local on your machine. You run it in a local instance of wherever you're going to deploy it before you package it and put it in a container. You hook that into a continuous integration system so that it can run. Security sensors are woven into the test and you constantly get visibility and reassurance. Then as you go to deploy it into production, you now have the ability to actually monitor what goes on in production rather than having that strobe light view of somebody who tested it like three or so weeks ago. Now, let us take pictures. All right, now, what are some tools that I can use to do this for free because we always want to have tools that we can use and different things that we can utilize in order to remove and reduce the level of human effort. And I want to talk about three of these things right now. One of them is a tool by SAP which is their vulnerability assessment tool that you can use during continuous integration. A tool called Dependabot which follows on where SAP's vulnerability assessment tool leaves off and then contrast community addition which you can use during test and operations just to monitor applications continuously. Now, what the SAP vulnerability assessment tool does and its link is right there is it focuses on Java and Python apps and it scans dependencies to identify in cases where you have a dependency with a known common vulnerability enumeration so that you can actually know that that vulnerability is there and present within your code. And the way that you would do this is you would take that application, you would hook it in to scan your code during continuous integration, so as you built it, you look at any libraries that you have and you say, if I deployed this, will I actually deploy any vulnerabilities along with my code? If the answer is yes, then you should probably upgrade them. And the reason that this matters is that those libraries are code and ultimately it doesn't matter if the exploit is gonna be in a library that you ship or in your custom code. It's your application that's gonna get owned and taken over anyways so we need to take responsibility for the libraries as well as the custom code. Nobody's gonna take it as like if you say, oh, well the reason that we got broken into is that I let that third party code operate. They're gonna say, why didn't you update that library and why did you ship something that you knew was vulnerable or even worse, why were you not actually looking when there's free tools available that would have told you about this? Now Dependabot is another tool that sort of picks up where that leaves off which hooks into the build system and it can scan and identify those CVEs but what it does instead is it will actually contribute a pull request to update that library. So constantly it will look and it will say, this library here contains a known vulnerability. You should not ship that. By the way, here's a patch to upgrade to that next one. So it will actually continually update you so that you don't deploy against those CVEs. So the nice part about that is it simplifies the updates through its automated mechanism and all I have to do is to accept those pull requests and just let the application rebuild without those vulnerabilities from that library because Dependabot has gone through and done the upgrade or that version change which is what I should do as the human reading the code and acting on that vulnerability. Last one is contrast community edition which is right now focused on Java applications and the key difference with this one from the other two is that it will find vulnerabilities inside of custom code because we don't wanna sit there and wait. Nobody's gonna file a common vulnerability enumeration against code that's custom to you and you wanna pick out ways in which your application is vulnerable. So if you've taken two libraries that are each safe on their own and you've combined them in a way that's unsafe, you want something that will tell you about that level of combination in terms of, hey, you took this input here and you ultimately use that to run a command or you took the user input and then you use that in a file name so somebody can go through and take over any other file on your system and return its results. So the key aspect that it does that's different is that number one, everybody becomes a security tester because it's hooked into the application and continually watching just what happens. But number two, you don't need somebody, you don't need that static list of CVEs specifically because that will never exist in your code. So it will actually watch your code to pick out vulnerabilities that occur within it based on how it's put together and how it executes rather than from a static list that's reported and managed by the government, which a lot of people use the vulnerability database. So the end goal that we have here is just continuous automated security whereby when you're working on the code you have something that can go through and pick out different errors based on what you're executing and what you're testing, continually hooked into those continuous integration systems, those defect tracking systems to constantly look as the code is built, give that constant visibility based on how it's tested, how it's executed, and then report that information into bug tracking or different integrations like Slack and things so that the right information goes to the right people at the right time. Finally, you wanna have something that's hooked in and actually monitoring production because if there is any kind of attack that's going against the application that would actually work you want something that will tell you about that. You don't wanna be caught off guard so the point of this is to get that continuous visibility to the right aspect at the right time and understand what's actually there. That was animated. All right and with that I know these are 30 minute talks so I'll wrap it up and we have an opportunity to ask some questions of cloud migration strategies, how applications are at risk, what the types of attacks are and how to defend applications. Yes. Yeah so those are static code analyzers where what they do is they look at the source code as it's built or in their case they look at binaries and that's kind of a strobe light level of visibility. When you give them the binary somebody goes through a whole process looks at it and then several hours later you get the result back. So you don't have the visibility of something that actually runs so you can't actually do anything about those vulnerabilities. So number one you're finding out about them later. Number two if you wanted to do something and say like stop this particular attack because I don't have to fix it, time to fix it right now you can't actually do that through code analysis. Yep, how does contrast address the ability to stop an attack? Because contrast is hooked into the actual runtime it's in part of the running code like through Java which is my core background. It's using instrumentation APIs so it's actually a part of the running system so it's essentially in the JDK, in the code and it can modify the byte code to insert an instruction beforehand and say the thing that you're about to be doing is user controlled so don't access that file because they've clearly entered some dot dots and whatnot to just manipulate around your system. Right so the way that these systems work is let me go back around here. Well this will do. Yeah so what they do is they go through they have specific aspects of what they wanna look for and where those occur. So for example, SQL injection attacks occur in the SQL drivers. Like right before you're gonna execute that SQL statement that's where that's gonna happen. Similarly if somebody's gonna go through and they're gonna do a file path manipulation attack to take over certain files or return something then the location to watch is the file API. And so what you wanna do is you have a specific number of places to be and a specific number of things to look at when you get there. And the nice part about doing it that way is if somebody's gonna go through and they're gonna try to do an attack like command injection and my code doesn't use a command at that particular location it doesn't matter. So the nice part is by being hooked into the API where something actually happens you watch for that thing that will actually happen. So ultimately if an attack is not gonna work what's the point in looking for it? Yeah, if there are threats that are unique to everybody or particular applications you can always extend and enhance systems but the piece there is a lot of these systems or the technical flaws themselves you use a lot of the APIs. So if you have an application that's custom to you where you access a certain type of data you still have to use the key assets like if you use a NoSQL system you're gonna be communicating through the NoSQL driver or a particular REST endpoint or something there. So your code generally delegates to the other APIs to go access the data or use things. So again if you watch those APIs they're kind of a nice flow point where you wanna know what you wanna look for when you wanna be there so that you can actually go through and pick out that the thing actually happened. And with that I think we can wrap it up and if anybody wants to go through other questions I will go step back in the back. All right, thank you very much.