 All right. Good morning, everybody. My name is John Stoffaker. I am a senior security consultant, a document. Today, I'm coming to you guys to talk about cloud security, what it is, mainly what we're doing wrong as a community, as people who deploy it, as people who use it. In the hopes that once we're done with today, you'll have the ideas to go back to your companies, your installations, and work on turning things around and doing it the right way. I'm not going to give you a product. I'm not going to tell you how to do stuff, what the best recipes are to do stuff. Rather, I'm going to show you what we need to do collectively in each of our own organizations to cut down the attack surface. And speaking of attack surfaces, 1993, what was our major attack surface? What were we dealing with? I mean, 20 years ago, we had Telnet running rampant. We had NFS issues. Most of the solutions out there were all UNIX-based. Modems were a huge thing. Protecting your resources meant you had this very distinct backroom computer. All the data was there. A few ways to get to it. Fast forward 10 years. Let's go to 2003, where we're starting to have this paradigm shift that everybody wants information. They need information. How do we deliver it to them? We created this walled gardening where we had firewalls. We had all these network security things that we're supposed to keep people out and did a good job. We had what we called the perimeter. That's where we kept the bad guys at bay. A lot of people spend a lot of time trying to develop endpoint solutions that focused right around securing your perimeter. And we pretty much let the data fly inside. Nowadays, 2013, they'd tell you the perimeter's gone. With the advance of cloud applications and the prevalence of connectivity to anywhere and people needing data everywhere, the perimeter has disappeared. Every threat today is persistent and all your data is valuable. There's no data out there that isn't valuable because so much data can be linked together to form the contents of whatever people want. Whatever they need to steal can be sold. If you think today that it is nothing, to somebody, it can be a gold mine. People ask me, when should I encrypt my data? Or what data should I encrypt? All of it. Even at rest in transmission, during your APIs, during your applications. Why leave anything to chance? Why leave it to the point that someday someone tells you that some innocuous piece of data is now relevant. If we keep it all encrypted and secure all the time and treat all data as if it were the keys of the kingdom, we won't have any issues. To be effective, we need to cross the boundaries of our organizations. Developers need to talk to your network team. Network team needs to work with the help desk. Your dev ops need to get involved. Every application out there is not deployed by a single person or a single team. Any cloud application today relies on the synergy between various different parts of the enterprise and make sure they're working together. I've worked with clients, deploying solutions where I asked who's in charge of security. The network guys have wanted developers. Developers will point to the network guys. Nobody thinks to put it all together. Security must be at your forefront. Developers. We shouldn't sacrifice security for time. It may be hard. It may take a long time. It may be rough. We may not be able to make deadlines. It shouldn't be a reason to sacrifice. The SDLC was created so that we make security paramount. Ease of use is always a big question. How can we make it secure if it's not easy to use? What if our users can't do two-factor authentication? What if our users are having trouble with doing things the right way? A lot of people say, I'll just push on the rug. We'll get back to it later. Or we'll put some other control in place. It doesn't seem that important is when I hear a lot. People think, oh, it's just a small app. It's just internal. We don't need to go that far. We do that if it was external. Problem is that most of our tax today come from inside. Our enemies aren't necessarily some foreign country who's trying to make our lives miserable, but rather the person sitting next to you, whether it be by malicious intent or just because they messed up, they got a piece of malware. There was recently a large provider of help desk services that was compromised because one of their users got a piece of malware. That malware was able to infect their network and steal credentials. Did they mean to do it? No. But does that mean that we should go off and feel as if nobody's a threat inside our organization? No, things happen. Let's go to DevOps. I love talking about this one because it opens up the line. The tools you guys use to make your day easier, to make your computing easier, to make all this work seamlessly are the same tools an attacker can use to take over your network. You look at Puddy, or excuse me, Puppet. You look at Puppet, Config Engine. They're great, right? You can deploy packages at will. You can do all the system administration you want. You know what else it can be used for? I can distribute any type of malware I want using the same systems. You like storing your SSH keys on your box because it makes it easier to log in as root without having to type in that password again. What happens when your box gets compromised? You think Bastion hosts are the thing? You know you have to log into the Bastion host? Go from there? Yeah, what if that gets compromised? You see, we like to believe that the tools we use for good can't be used for bad, but the problem is, is that they are. I've been a member of a red team for some time working cyber defense challenges, and one of the things we love to do is use off-the-shelf commercial applications that are used for stuff like cloud administration and use it against people because they never think that that could be a weapon. Anything you use that can administrate your box has to have permission to do so. Therefore, it can be weaponized. The other thing I want to talk about is image security in the trusted base. People don't really think that their images would be an attack vector. It's easy enough to slide in malware inside of an image, and then with current applications, your team would go spin up a VM that had a compromised image. Well, now every VM they spin up after that is compromised. It's a great attack plane. It's a great way to come in. How do we fix that? We need to review our trusted bases. We need to make sure that everything we put out there is clean and sanitized and have some way of making sure that the original's never got compromised to begin with. Networking security. One thing I have to mention, VLANs are not security. They are an administrative tool. They are a bit inside a packet. They can be defeated by turning your Ethernet cards for misuse mode. They shouldn't be relied on as your own soul form of separating out your hosts and your networks. All VMs are vulnerable to an attack on the kernel because the kernel itself is providing all the network traffic. We are trusting the kernel to give us network traffic. What's the problem with that? What's the problem with trusting somebody to give us our network traffic? On an Ethernet network, I can sniff the packets right off it and I know that source and destination, I know that that packet is valid. But do we know what is coming from PSA software if it's giving us what we need? This goes beyond just OpenStack or any of the other cloud operations. This is fundamentally the problem with relying on software to give us such a crucial part of our security. Virtual firewalls is another fun one I like to talk about. Again, it goes to the same line that this is software. This is something that somebody wrote. Somebody could easily have modified that we're trusting to do a job for us to secure what needs to be secured, to secure the data that's important to our enterprise. Important enough that we bought the solution. Important enough that we thought we should protect it with something. Let's go right into support. Another low-hanging fruit. These guys are the guys in the front lines. They're the ones the users are calling. They're using the tools to help out other people. Unfortunately, they're the ones who could also be abused. The tools they use generally are almost the same as the admin's tools, except they're used with greater abandon. A lot of times people have the idea that let's just get it done and help the user provide great customer service to the expensive security. And we gotta fix that. We gotta make sure the processes that are followed are identity management systems are set up in such a way that we cannot exploit our own help desk internal systems to compromise more machines. What concerns me about the private cloud? Cost is one. But even so, we're prone to hypervisor attack just as I mentioned before. The worst part is it's internal. Most people don't think they should protect their internal systems from each other, right? I mean, we're all friends here. It doesn't work that way. Like I said before, most of the problems we have today stem from internal people, either by malice or by mistake, compromising our hosts and walking away with the keys. We have this idea of security zones where we compartmentalize stuff and we put applications of a particular order inside certified zones. PCI is for one. The problem is is when we start breaking that to ease of use, we have a development machine right next to a production machine on the same server. There may be two separate VMs, but we're now sharing the same hardware. We're sharing the same kernel, we are sharing the same resources. A breach in one could affect the other. Not to mention we can affect availability. We need to make sure that our zones are discreet. The problem with that is the cost. To implement these solutions, we're talking about a major investment and redo of how we do things. And the problem with that is that it's expensive. To do this right is expensive. So let's go to the next solution. Let's talk about the public cloud. So we're giving all of our data to somebody else. We're set up in a multi-tenant environment. We are assured by our provider that nothing will ever happen. But where's the transparency? Where's the audits? How do we know that our cloud provider is actually telling us and being truthful and being honest and really outlining to us what their methodologies are to handling security incidents? If your cloud provider isn't providing this information, you need to think about what does that mean? Is my truly public cloud in which I'm in a multi-tenant environment, is it secure? Do they have proper things in place to make sure that processes to make sure that when there is an incident, we take care of it? How about background checks? Do they perform background checks on their employees? Do their employees have access to my data? There are some application cloud providers that their employees have access to the data, albeit encrypted, they have access to the keys, to help, to help. You'll hear this a lot. We empower our employees to help you, but at what cost? Poor identity management is a huge thing as well. What is our RBAC system if we're not vetting the people who claim to be entered into it? If we're not asking the questions of who, what, where, is why, and what, we can't be sure that who's we're putting in and who we're assigning to our systems is actually who needs to be there, who has the authority to be there. Cloud providers, public ones, really don't ask these cloud providers, they don't require you to vet who gets access. Sometimes it's as simple as knowing just a little bit about the company and providing some sort of passphrase. Hybrid, I'll skip this one because to me it doesn't exist. If you want a public-facing sector and put all your data private, buy a load balancer. If you're gonna hand your public data or your private data over to a public cloud provider, you need to make sure that you're willing to take the risks of securing that data. If you keep it at home, you're just as risk. That connection between your home data and your public provider is a weak point. It's another place in which we can attack. So how do we fix this issue? How do we come together? How do we find ways to fix all these issues? And that starts here in this room. It starts with you guys. It starts with everybody who works day to day with this stuff to make sure you're reaching out to developers, to your own colleagues, to everybody you work with and let them know that we need to start talking about security when the application starts, not at the end. We need to look at this from a holistic perspective from the day that the projects are announced and walk all the way through and ask the tough questions and don't yield. In California where I'm from, it cost an estimated $6.25 per data record in a database breach for PCI data. Can you afford that? Can your company afford that? Is it worth that or buying extra hardware to do the things right? Or putting in the manpower to make sure that we have addressed all the concerns and made sure that we did our best to secure something or even worse, mitigate the losses when a breach happens. Let's stop enumerating badness. I like this one because a lot of times as IT professionals, we love to enumerate what's bad in this world. Anovirus is a great example of this. We have lists of known viruses that are bad. No one seems to think that it'd be shorter to have a list of just what's good out there. There's a company that actually makes a product that does just that, application-wide listing. We need to take this approach to cloud technology as well. We need to stop thinking of what out there can get to me and rather, what do I need to protect? Let's let everything else go and just focus on what we need to protect rather than all the stuff that can happen to compromise. If we take a strong stance and protect what we need to protect, then we're not gonna have any issues. There's not a product. There's not a point solution. There's not a magic sauce that I can give you today that's gonna solve all these issues and make your cloud secure. I can sit up here and tell you that if you put these three rules into IP filter that you'll be golden or if you install X and X application, you're gonna be golden because it doesn't work that way. Every company is unique. Every application is unique. Every implementation is unique. And you need to balance and you need to make sure that what you are doing to secure yourself is in line with the application data you're handling. Some people will say, yeah, you just need a web application firewall. That works great. But it's not one single solution and a lot of it has to do with people. I was working with a customer the other day and they were asking me for my recommendations on a firewall. And it struck me as kind of odd because they're managing to go into a public cloud and with all their data, all their private data. And right now at the end of the project, they're asking me, what kind of firewall should we choose? At that point, contracts have already been signed, your cloud provider has already been chosen, the application's already been written. We're kind of stuck. We're limited in what we can choose because we didn't think about this at the beginning of the project because we thought somebody else would do it. I hear that a lot from people that they have confusion over whose job security is. Unfortunately, security is everybody's job. It's not yours, it's not mine. Collectively, it's everybody's. For the people who are writing the applications, to the people who are installing the machines in production, to even your support staff. A lot of times we look at custom APIs, for example. You have developers who are writing them and other developers that are using them. But if we don't look at it with an eye for security, those APIs too can be abused just in the same way the application itself. And we wouldn't be the wiser. I kind of touched on this before, but it's not a one-person job. It's not even a team of people's job. We need to get together. Like I said, as a community, that's why I'm starting here. In the last few years, this project from OpenStack has grown tremendously. Even by the amount of attendance here in this room and at this conference in general. If each one of you took up just a little bit from this presentation back home and started putting through some of these fundamentals, making sure that as we go through our design process for our projects and really implement and then push for security now versus security later, I think we can push through. I think we can really turn all this around if we can just focus on what it means to be secure. All right, I'm gonna open this up for Q and A because I know I've said a lot of talking. There's a lot of people in this room and I'm sure you all have a lot of questions and I'm willing to provide a lot of answers. Hello, my name is Esteban Gutierrez, I'm with Intel. Do you have any kind of, we've spent a lot of time thinking about a security framework for cloud deployments and especially for things like hybrid cloud, which is a pretty crazy space. But do you have a, other than just saying that we need to pay attention to application security and starting to integrate that at the get-go, do you have a more kind of general framework for how application security controls would fit into a comprehensive set of cloud controls? And I have some thoughts on this and I'm happy to talk about that, but I wanted to hear more about your take on that. It's interesting. My take is this, the CSA has a great document set up on the secure development model and using those controls within your agile framework and within your coding framework to match up to what we need to do with inside the cloud. I don't know if you're familiar with the document, but it's introducing the security phase into the project and keep going through it as we go through it. Yeah, and I think STL is a big issue in general and it's definitely something that we're striving for. I guess the way that I look at it from an enterprise perspective, I have an environment that consists of a ton of legacy things that have been sitting around for a long time, right? And retraining, and I also have limited resources and limited people and time and money. And so one of the ways that we've approached this is by trying to work towards priorities and establishing an equation for how to find things that are acceptable from a risk perspective. And what we look at is a combination of tenant level controls that are primarily application security focused plus a set of tenant, or I'm sorry, cloud provider controls. In some ways you can think of that as infrastructure control. So what is the provider doing for me? And what is the provider doing to secure themselves as well? And then also a set of enterprise security integration, right? So what are the things that I need to provide as hooks into my enterprise to manage and maintain and secure to the levels that I need to? An example of that would be compliance monitoring for patches, looking at what's out there, integrating into single sign-on for our enterprise applications, that kind of thing, so on and so on. And also threat management, logging and monitoring. And the sum of those three things really kind of equal the overall risk posture, right? And that helps me determine what I should be shooting for. We've also been looking at things like the ODCA provider assurance for work, which has things like bronze, silver, gold, platinum criteria for providers. And we've taken that and looked at trying to figure out how do we come up with an equivalent list of controls and things that we shoot for for whatever business capabilities we're deploying into a cloud space. So that when you look at those three things, the app, the tenant controls, the provider controls and the enterprise integration controls, we want those to kind of add up to either a bronze or a silver or a gold, depending on what we care about, right? If it's kind of like a sales and marketing website, maybe we can tolerate a certain amount of risk there. And so the tenant's control is gonna be good. I'm gonna stop you right there because this is kind of interesting. There have been a couple of cases where that line of thinking has led to, how can I put this? Led to a company getting into a bad light. Recently, a software company was compromised because someone did spin up a marketing server that they thought was just innocuous. And it wound up getting breached and we all know what happens. The acceptable amount of risk in cloud computing, I don't think there should be a question as to how we secured if we're gonna go through the whole process of what we have to do because it is a process, it's a lot of investment. I think we should look to do security as best as we can. Right. But there's also priorities, right? And limited time and resources. And so there's ways to figure out what is the baseline that you should have built into whatever it is you're deploying. In this case, let's say open stack based environment, right? We wanna make sure that that foundation is rock solid. Maybe it's hardened to like a gold level, right? But then we look at stuff that's deploying on there and we take a different approach about what levels those things should be shooting for. So I mean, I guess it's just trying to figure out for me the set of controls that existed each of those points, tenant and infrastructure. The problem where we're facing with today is that there's no clear defined rule as to what those controls should be. That's something that the business needs to decide on their own based on their capabilities and what they have deployed and what they wanna deploy to a large degree. But I do agree though. I think that to your point, we should separate out the controls to what should the provider give us, what should we take on ourselves, what should the infrastructure be and obviously what the application should be. I have another question for you. Do you see a need for security as a service or capabilities that are deployed out as services that can be consumed and reusable and scalable? The problem with that is aside from basic security, obviously hardening and your real general basics, every application out there is unique to itself. Every security problem that is deployed is unique to itself. To sell it as a service is giving the customer a false sense of security. We're telling them that we can wrap everything we know about cloud security up into a service that you can just purchase, glom onto whatever you have and it'll work the best way. Problem with these services is, as most of you know, we tend to start shutting stuff off when it doesn't work. And there you've kind of blown a hole in your whole paradigm there and you're back to where you started. Yes sir, please. So if I understand that correctly, you're basically outlining the issue where as we move into the cloud we have one more independent services that are less and less segregated from each other. Ultimately, from a security perspective, that means I've got multiple entry points, each one of those goes into the whole system. It's a multiple key problem. Which as an application provider, I ultimately can't control all of that. One single bad key leads to compromising everything. So in the final analysis, I'm not convinced that securing things in and of itself is a solution even if everybody plays together upfront, there's always going to be a way in. What do you propose people should do, including developers, to find out what's actually happened and to close holes as they get disappeared? Right, get discovered. That's a great question. And from my perspective, obviously we can go into specific details of log monitoring or just being alerted, being vigilant to what's going on in your application, more information and better, specifically when we get into stuff like Sims, correlating events and making sure as a developer you're writing applications that are as noisy as they can be. Today with space the way it is, make your output logs huge. As long as we can get the most information and better, that we can make good judgments on, that we can correlate events. If we're starting seeing activity with the user somewhere, five failed logins, one accepted login, we can correlate these events and we can grab a better picture of what's going on. You're correcting your assumption. I mean, with multiple entry points, with the perimeter gone now to just nothing, we have to be vigilant and there could be the situation where we have a breach and we need to mitigate that and collapse it and compartmentalize it and stop the spread. If we have a software as a service where we're providing this application to everybody and we find a vulnerability in that application, it can spread like wildfire and we need to be able to compartmentalize and we can only do that with information. There's no magic bullet that's gonna stop a widespread compromise of a popular service but with the right information, the right monitoring, the right alerting, the right people being vigilant, we can at least mitigate the effects down to a small quantifiable sum. Sir, I can hand you my card at the end of this. Unfortunately, I can't answer it, but it's tough, right? Because yes, I'm wearing the shirt. I work for a security consulting company. If I just spend some advice right now and put that camera up, someone's gonna call me tomorrow and say, why'd you do that? But I can tell you to go in through an audit, and I've done a few, actually I've done quite a few and the toughest part is making sure that you're seeing everything you need to see and the reason I bring that up is a lot of times during an audit, we are asking some other person to provide us with some information and our audit is only as good as the information we are provided. If we're asking our cloud provider to provide us with their information, it's only as good as our marketing people will allow them to give to us or their legal department allows them to give to us. If we're asking our own internal developers for information, it's only as good as what they understand it to be. And so you can have the best frameworks in the world, but we need to do an audit, you really need to get down and dirty and you gotta go and you gotta force these people to give you what you need to be effective. Otherwise, PCI is a great example. A lot of people pass PCI, but then we still hear PCI companies getting breached. Well, if they're PCI compliant, why are they getting breached? It's because you can only audit on what you know. There are, there are a few. I can't and I probably won't name them because this isn't an ad, but go out there and find them, search them out, do your due diligence. If you're asking questions, if you want a dashboard, if you want this kind of information and your cloud provider can't provide it to you or won't provide it to you or won't give you information as to where you can get it, use the power of your dollar to leverage them to work better. I mean, ultimately, you're their customer, your security is paramount to how much they do in revenue, how much they do in the consumer's world and their mind. If you're not secure, if you don't feel secure, you're gonna tell the guy next to you, who's gonna tell three people. No provider wants that. I mean, like I said, there are many who are doing it right, who are giving their customers that access and the visibility into their own systems, but we're not seeing from cloud providers as a transparency within themselves. When I, you know, ask for a segregated cloud for my environment, how do I know that I'm the only tenant in that space? We don't. We are trusting what people are telling us. When they say they encrypt a disk and they don't have the keys, they don't give the keys to any of their employees, we don't know this without access to that information. Don't miss anyone? I guess there are things that open stack, should we do it? You know, the beauty of open stack is that it's entirely open. And what I mean by that is that it's under constant peer review. There's so many eyes looking on it, and there's so much availability to do what you need to do. If we need that insight, we can go build it. And if a lot of people have, we're ever so evolving in a situation where this release is getting better and better each time. And it's coming with the features that we need. I'm looking forward to the next release and seeing how much we are growing to get to that point where we can say that, hey, this is my environment. This is what I'm built on. And here are all the things out of the box that it comes with that gives me that transparency that everybody needs. Sir? I have a question. Yes. It is, it is, but unfortunately, when you're speaking of these events. I don't know, we're open to hear. And you know what, this is a great idea. And I pitched this before. A lot of times to get companies to move, you've got to shame them. You've got to point out what they're doing wrong and hope they're good to fix it. Problem is, most of us don't have a legal team to go up against the big ones when they, you know, take offense to you, shaming them. But again, as consumers, we need to make sure that where we're putting our stuff and where we're putting everybody else's information is doing it the best way they can, the best practices and make sure they're secure. I always take the feeling as if my information is in there. If you take that appeal, if you take that idea in your head and say I'm building this system to house my information that I'm gonna put out there, it takes a little bit, you take a bit, a little bit different look into how you operate and how you build things. Your second part. He's asked, the gentleman asked about what is the best resource if you're just getting into cloud security. I am gonna give a plug to the cloud security alliance. They have a wealth of information on how to do this. There are quite a few good books on Amazon about the subject. I'm not gonna plug their titles, but anybody else? I agree. What DCI? DCI have started providing guidance on what you think. Sir? Executives understand one thing, money. Show them the money. Show them what happens when you do get a breach. When that day happens. Come back with what you have, what you know, and how to do it the right way. And if you can present it to them in a way that shows that they're actually making money rather than losing it. Market share, brand identity. Brands are huge these days. Who wants to go through a traipsing in the media because of a breach? A breach that could have been avoided had they spent an extra $25 on security. You need to push. We need to find people up the executive chain that can ally with you and play the politics game and push and push. That's the only thing that you can break that glass ceiling. Throwing technical jargon at them is gonna turn them off. I mean, it's, sir? But if I had just a quick and making the same arguments about security for a long time and when you looked at the hard dollar costs, it's hard to see. But a point that's relevant I think to anyone in this room that's focused on cloud and security, you've mentioned don't slow down my innovation, which beyond the hard dollar costs is probably the second, if not the most important thing people will care about. And we're all here specifically for cloud to figure out how to speed up innovation in an organization. So the recommendation I get to is that from a security team, I've seen a lot of cloud teams that are running off without necessarily security expertise and then the security teams are, oh no, we can't do that. But if they learn from the beginning to work together and the security team learns to figure out how can they enable and operate at the speed that the cloud's allowing innovation to help, that goes a long way in breaking down those barriers. And then it goes back to dollars, but then you have a risk mitigation trade-off. Well, and then, exactly. And if you have, I hate to use the word cross-functionals, but if you have a cross-functional team of security professionals, developers, networking engineers, and management together that are united on a project, and you can produce a concise solution to a problem. At that point, you have a better leg to stand on as you go forward, pushing it up the chain. Throwing it down, we need such and such device just because we need to protect it just yourself is not the leverage you need. If you can come to it with a group saying, look, as a group, we got together, this is what we're doing. It makes a greater push, exactly. Their customers. As IT professionals, we tend to get lost in the engineering details and forget that the people who work with us, they think in business terms. They think of what it means to the business, what it means to their revenue, and those are the things that they really care about. They care less about the engineering and how it helps. If we can get with the business and try to match our projects up with their alignment, things work much smoother. Anybody else? All right, guys, thank you all. Appreciate it.