BG - Applications and Cloud Hackers, Oh My! - Andrew Hay & Matt Johansen

Stand together. All right, we'll stand together. Just put my hand in your back pocket.

Yep.

Yeah sure.

Yeah, I don't want to walk across and hand you the mic. Yeah, we're good. All right. So, I guess I'm flipping the slides. Jesus. Sure. So, hello. My name is Andrew Haye. This is Matt Johansson. Yeah. Y. So, we are going to talk today about applications and cloud and hackers. Oh my. Uh, we actually came up with the title before even thinking about the slides because we had a lot of buzzwords in there. And that seems to work at conferences pretty well. So, Matt works at White Hat. Um, I guess it's next slide, isn't it? Uh, I work at Cloud Passage, so I handle more server side security such as it is in the cloud. And Matt's more app web app

application security type stuff. This is us at RSA. Don't we look cute at Jillian's? All right. Now, so we today we're going to talk about uh the almighty cloud, that fad that keeps coming up at conferences and show floors and things like that and some of the problems with not necessarily cloud as the infrastructure, but more of hey, I can now put stuff in cloud as fast as I want and screw up things 10 times faster than ever before, which is great. So, break out your buzzword bingo cards. We're going to hit a bunch of them, but uh hopefully we're going to talk about it in like a hey, these are real problems, real solutions kind of way and

not in a, you know, douchy way. Hi, I have a magic button that you can push and it'll make a magic blinky light fix your cloud. No, we're not going to talk about that. We don't we don't sell anything. They don't let us sell stuff. Then we're going to talk about some solutions uh at the end. And it's really, you know, it sounds like really common sense things and then you'll read it and you'll be like, "Yeah, yeah, that makes sense. Yeah, that makes sense." But most people don't do it. And that's what pisses me off more than anything. It is common sense. Nobody does it. Isn't this the greatest animated graphic ever? Do that later. Yeah. Yeah.

Until my back goes out and then we'll So what's in the cloud? You know, people are doing development in the cloud. So actually what's funny about development in the cloud, you hear people saying, "Yeah, I'm going to do dev in the cloud test. I'm going to push into production and everything, but so few people actually will do proper development in cloud environments. You know, they'll do it on their desktop and then they'll push it up when it's ready, maybe do some integration testing just before like right into staging. Yeah, everything's cool." And then right to production. That's not really cloud development. That's, you know, an FTP process transferring files around. permanent application hosting. You know,

this is kind of Amazon's bread and butter. Same with temporary workspace. We're trying to go and burst into public cloud from our private cloud infrastructure and save money by doing utility billing and blah blah blah buzzword, buzzword, buzzword. And there's a lot of companies like just like when we were all kids or when most of us were kids, people were starting companies in their garage, software companies. Well, you know, they're not buying 10, 15 servers anymore to run in their garage. Most times they're just going to cloud, going to Amazon, one of the other cloud providers, provisioning it, getting things up and running because it's cheap. So, this this is a survey that we did at Cloud Passage before I joined.

I've only been there since May, but this came out I think it was like uh Q4 of last year. And the question, it was multiple choice question. I would have added some more answers for the selection, but what security concerns are most important to you regarding public cloud computing? Number one was lack of perimeter defenses and/or network control. I would think that if we put in the multiple choice like you know I don't care about security in the cloud that probably would have been like the biggest bar, but obviously it's a cloud company. So cloud security company, they want to kind of scale this a little bit so it makes more sense. uh the very bottom enterprise security

tools don't work in the cloud. That's probably one of the biggest misnomers. Like if you talk to one of the monolithic uh security vendors out there that has been doing, you know, endpoint security for the longest time, they'll say, "Yeah, your 500 cal license for your antivirus, it'll work fine in the cloud." Or your our uh server firewall that we've got in there, it's going to work great until the IP address changes. and then things all go to hell. So, I'm not going to go over the intric intricacies of cloud computing because that's not what this talks about. Um, because everyone knows what cloud is now, right? It's all fluffy. I really want to talk more about the

separation of responsibility. And so, this is from the EC2 responsibility model. Customers should assume responsibility in management, but not limited to guest operating system blah blah blah application software. So this is infrastructure as a service. So everything you know kind of dips into the hypervisor a little bit. You don't really have control over that. But virtual machine up to your data your responsibility as a customer. Everything below the actual infrastructure. Well, that's why you're going there because they're providing the infrastructure. It's cheap. You don't have to buy servers anymore. Now what about running specific applications in cloud environments? So here again we have the customer provider mix and then you have like authentication going to be shared

between the two HIDS IPS you may get a provider that's going to help you out with that a little bit you know antivirus they're not going to give you antivirus they're not going to say yeah our cloud server that we're giving you or cloud instance is going to we're going to protect you from all the viruses because that would be a lie encryption obviously it's your data you probably should encrypt it self. Uh then you get into like more complex things like SIMs and uh any sort of application or pen testing things like that can be shared between the two whether it's uh the end user system or the end user application. Uh you're probably going to be doing all the pen

testing or you're going to outsource it to someone. It's kind of a messy list. And here's probably one of my favorite slides in the whole presentation. So this was another survey that was done before I started at the company. How do you secure your cloud servers today? Look at this big white section here of my provider does it for me. I think this is way bigger. This is just loud fashion survey. I think this is way way bigger. Yeah, this isn't like a survey that encompassed everyone using cloud or anyone doing everyone using security uh in their day-to-day jobs. This was just the people who responded. But yeah, I agree with Matt. should probably be a lot bigger because there's

a lot of cloud providers out there that are saying, "Yeah, we're a PCI certified cloud." Like, "Oh, awesome. I can just move my stuff over there and I'm PCI certified now. Good luck." And then there's this other big chunk. So, I honestly I would have expected to see this like be half this like almost half and then the rest just kind of like small little slivers. Um, especially if we're talking temporary workload type stuff. Do you need to secure it? Well, we're security people, right? Yeah. Yeah. Secure it. But if you're a DevOps guy, developer, maybe you don't care. Maybe you just want to get your work done, your work done, and uh move on to

the next project that you have. Cool. So, now we're going to get on to kind of like something that we've been talking about for quite a while is in security in general, right? The budget problem. you know uh the budget for uh building an application or setting up an IT network and all that stuff comes first right always comes first and then profit somewhere collecting underpants and then security right so that that it's always a line item after the thought kind of this is the problem we've been dealing with forever right but now it's kind of changing slightly right I'm going to get into that so yeah next so this is kind of what an IT

budget would look like uh you know at a standard organization Right. We're going to uh put a whole bunch of money into software development. We're going to put a little bit less money, but still a whole bunch of money into all the hardware and stuff that goes on it. And then plumbing, right? This is just obviously very general. These I'm not counting dollars in here or anything like that, but this is kind of what it normally would look like, right? And then the security budget turned on its head right? So, we're going to buy firewalls, IDS's, secure the network, antivirus, all that kind of stuff, vault management, secure the host, and then oh, you remember that application thing

that we built on top of it? Uh, yeah, I guess we can throw some money over there and try to secure that, too, right? And then if there's any Yeah, if there's any left, right? But definitely antivirus, right? Cool. Uh, and then SQL injection happens and you lose $121 million in nine days, right? So uh and then so yeah kind of next right so this is kind of what these cloud applications people are starting to see right the big red X over here that you don't have to worry about as much right I mean it it doesn't disappear completely but it's not anywhere near that big pile of money right you don't have to secure all this

stuff and you can actually move your security dollars down this stack here right you can start putting your money into securing the applications that you're developing on someone else's plumbing right that's that's really what it comes down to. So PCI yeah PCI secure cloud right and this is just kind of illustrating where where it needs to be right this is budget prior prioritization so where it is today where security is today and where it all should be right so cloud is kind of the cloud applications are kind of helping this become a reality hopefully is what we're seeing. So, who can name the movie? This picture's from any Brits. Where are the Brits? Train Spotting. Yes. Begby. So, we want

to do things fast and cloud enables us to do things fast. We can deploy applications. We can deploy servers faster than ever before. Is that always a good thing? Depends who you talk to in the business. Um, if you talk to someone in security, they're going to be like, "Hell no, we don't need to do it as fast as you want to go because we still need to secure it. Nothing's changed." But then senior management is like, "Well, yeah, but cloud, look at all the money we're saving. We, you know, we can't really wait for that. We're going to accept that risk and we're just going to move forward, which is always great." So now senior management team knows that

they have these cost-savings initiatives by moving from physical infrastructure maybe over to virtualization environments but ultimately to cloud environments public cloud even private cloud they're now going from capex to opex expenditures and they now don't have to allocate as much budget to doing things so they can get rid of people. uh they can say, "Oh, you know, we're in this secure cloud now, so we don't have to worry about really as much security anymore, so we're saving money hand over fist, but you're still stuck securing this stuff, man. This is not This doesn't make the problem go away." So, who here is a developer? Wow. Okay. So as a developer, have you guys ever been told to cut corners in

order to meet a deadline? Never. Never. Right. Not once. So I used to manage a team of software engineers and my team somehow was a dual report to the VP of engineering and the VP of marketing. So, so a sales request would come in and you know that whole roadmap thing gone. You know, you cut corners. We got to win this deal. If we don't win this deal, we'll never make the sale. We got to get this code in there, push it out. I don't care if it's only, you know, 10% accurate. You know, if we can prove to them on paper that this is working, then they're going to sign that PO and we'll

just worry about it. We'll fix that down the road. Go back to that dancing slide. Yeah. Yeah, that's you, Dan. Yeah. So, this is always what I think of wy coyote just kind of strapping on, you know, I'm going to catch the roadrunner on this big Acme rocket. It's going to get me there fast. I'm going to nail them. And this is really what I think of when thinking of application development in cloud environments because it's all about speed. It's no longer about getting a product out there that works. Who's heard the term minimum viable product before? MVP. Who here works in a startup? Okay, so just 10,000 foot view, minimum viable product. If you are running a a company,

you've got a product developed, you just need to get the base piece of garbage done that has, you know, you're polishing this turd that you can show your investors or your potential investors how awesome this is going to be if they give you 10 million, $20 million to make it happen. So now you got the nice polished turd. It doesn't do anything. Um but it looks pretty maybe. So when box.net came out, does everyone remember the main page of box? It's still there. It's a video. That's how they launched. He had a video first and then he started coding on the train because he forgot his uh he forgot some files at home. So he wanted something he

could transfer. But, you know, the priority was getting that video up to show investors, hey, this is how cool this is going to be if you give me money to do this. So, has anyone read the lean startup Eric Reese? Does it work? Yeah. Who knows? You know, Eric Reese, really nice guy, excellent public speaker. Um, not very grounded. Like, a lot of his theories are very academic and, you know, they worked well for him once. He's not like a multi-millionaire company guru like he's not like the CEO over there uh for for a startup but his ideas are kind of interesting. You know, you create your minimum viable product, you get your investment or some funding,

you draw some developers to your cause, you start you keep refining your product over and over again with the goal of getting it out there first because you got to beat the other guy. And if you don't beat the other guy, then someone else is going to come in and your idea is stupid. You're not going to get your funding. you're not going to get sold to Facebook or you know whoever's buying for ridiculous amounts of money this week. Two things he did say which are very quotable and a lot of people quote this is the only way to win is to learn faster than anyone else. That's true. Not develop faster but learn from your

mistakes faster and that really does include security. He never talks about security because he's not a security guy. He's, you know, develop develop develop. Get it out there first. And then don't don't be in a rush to get big. Be in a rush to have a great product. it kind of goes against what he was saying, but I think that's final product, not minimum viable product, you know, once the turd is broken open, you get something a little better. So, yeah, on that point also, I think there's a Zuckerberg quote. I'm paraphrasing. I'm just pulling this out of my butt here, but uh he he said, uh, if you're not pushing broken code, you're not pushing fast enough. Has

anyone heard that one? Right. Yeah, that's that's the same kind of thing we're talking. Yeah. Yeah. Exactly. So this is kind of the the part that I want to harp on. This is the major problem I see all the time, right? How many of you have heard these? Any of you that do any security consulting or anything like that? Go to a go to a company and say, "Okay, you know, I'm going to test your websites for you." Or they come to you say, "Hey, you need we need some application testing." All right, cool. How many uh websites? At least at least a few, right? Uh no one really knows the exact number. I mean, unless you're a small

enough company where you only really have your flagship, right? But like for larger companies, no one knows, right? And especially now that this cloud, Amazon stuff, Rackspace stuff is so easy. Any department can go and just spin something up and hey, here here's another part of of our company now that exists on the internet, right? Most people can give you an IP range. All right, cool. Thanks for the IP range. How many websites does that represent? Oh, all right. Cool. So, it's a real problem out there. It's a problem that you know a lot a lot of companies are facing because they just don't know they don't know what their footprint on the internet is. So how are you supposed

to secure that? Right? If you're the CISO of some company how what are you supposed to do? Right? So this is a this is a funny story that that that floats around from time to time that we've heard. Right? So the way that one CISO at uh Fortune what 500 company uh found out how many websites he had is he went to accounting. He couldn't he couldn't figure it out in his department. He went to the accounting department and pulled expense reports with Amazon, Rackspace, etc., etc., and then found the people who submitted those expense reports and was like, "What did you stand up?" All right, cool. Now we have a start. Now, now we can go somewhere from

here. Terrific. Right. So, you can hit the next one. So, this is the other big thing now. Right. And I kind of want I'm going to ask ask some opinions on this slide, right? So this is a quote I was literally spoken to me a few weeks ago, right? We push code on average 360 times per quarter, okay? Because we were talking about doing some testing in QA and SDLC and all this stuff and it's like uh QA I don't know. We do this whole push thing all the time, right? We're an agile environment and we just are constantly committing code. What what QA security? We don't do any of our security testing in any sort of QA environment. We do it

all in prod like all right it sounds wrong at first how many people thinks this is bad this is a bad thing a lot of you right it's it's intuitive that this does not sound like a good idea security-wise right but some people are doing it right if you have code review source code review is that automated testing your code right so so that's a great point right so okay when you check in code. You have an automated scanner looking at that code, right? That'd be great. Yeah. Yeah. Absolutely. And so when when uh when I say QA, I'm saying like QA security. When these people said QA, they probably meant does it work right

before we push it to Yeah. Yeah. No, I I agree with you. We're on the same page. You know, the people pushing code 360 times a quarter are probably just trying to get it to work, right? And a big stick, right? Yeah. So, I mean, most of us in here thought it was right. Does anyone think it's right? I don't I don't I don't actually know the answer. I mean, we all have a gut feeling that this probably isn't good, right? But has anyone read about Etsy's development environment and see that talk, right? So, this is kind of what they're doing, right? And they're doing it, right? Like, it's working for them, right? So, who who heard the most

recent story about Etsy, right? that there was some white hat researcher kind of hacking around Etsy and uh found a bug. I forget cross-ite scripting or something like that and uh like I'm going to report it to these guys. I'm going to be the good guy. I'm going to report it. I don't know if they were giving out a bounty at the time or if he was just being, you know, a chivalous security researcher, right? Oh, I'm going to do this, right? Uh he found the bug at night uh and he was going to write the email and report it the next morning and by the time he did, they fixed it. Did anyone hear about this? No.

Okay, a few of you, right? by the time he by the time he wrote the email, they were like, "Oh, yeah, cool. We saw that attack traffic last night and we fixed it." All right. So now this is this is a new layer that that no one's really seen before that makes this work, right? So this is totally counterintuitive to everything we've been preaching and telling people all the time. Secure SDLC QA heavily code reviews, then go to production, right? Well, now with this agile stuff, we need to get to market first. Everyone says boohiss. So, now what? How do we do this, right? I think Etsy is leading the way in a lot of

that, right? They have some good talks. We're not going to get too too far into it. Uh go go do some uh some research if you're interested on on the guys talking from Etsy, right? So, yeah, staging is for suckers. How many people have heard have heard this little quote at the bottom here before? I'm I'm I'm uniquely interested. Yeah. Okay. So, we'll fix it as a road map item later. Yeah. Okay. Submit a Jira bug. Maybe we'll do it at some point, right? Cool. Right. This happens all the time, right? Uh I've unfortun I've had the unfortunate experience of having some public breaches recently, right? Summer of the breach be some of my customers and they

had that vul data like they knew about that vulnerability and didn't do it. It it was a roadmap item. That road map did not come upon them quick enough, right? It it it happens, right? But how fast is fast enough to fix it, right? It's a it's a hard business decision to make, but that's it's kind of what we're talking about here. Do you want to talk about anything, Steve? So, same kind of thing. When when I worked for this other company that had the dual reporting structure, um marketing vetoed the fix for several security flaws and because they got word from one of the engineers that said, well, you know, they the attacker would have to do this in a

really strange way. they'd have to, you know, they'd have to interact with the website with the portal in such a way to make this happen. And I'm like, yeah, this is what people do, you know, but they're like, no, no, no, no. We got to get this out now. Like, okay, well, when can my team fix it? I'm like, well, we can't do it in the dot release because that's not really a road map. Uh, we could probably put it into the next major release, which was about 10 months out. So, yeah, I was pretty happy about that. you just had to shut up and say, "All right, you're the bosses." And the common misconception

about getting applications and servers out there fast is that you're going to get money. The faster you get out there, the faster you can get the money. Um, who's worked support in an environment like a software firm? Anyone? Yeah, couple people. It's awesome when you're the guy or you're the person fielding those calls as to why it's broken and then you have to tell them, "Yeah, it's a known bug. We've known about it for a while, but we're going to fix it later." When I honestly can't tell you later that that's all they've told me. It's not it's a roadmap item. We're going to get to it some point. That really does like you may have their money now, but

when it comes to renewal time, is that customer going to remember that you weren't really able to help them that much? And it's a lot of pressure on support. You know, I worked support doing like dialup ISP support for customers in Tennessee. And I'll tell you stories about how screwed up that was. But it's, you know, it's hard. It's hard on your support staff. So, you're going to lose support staff. You're going to get customers that are pissed off because you can't support them in the fashion that they've become accustomed to. And just because it got out there first doesn't mean that you're going to get the residual money from the support contracts and uh maybe even word

of mouth future sales, you know, but you've got their money right then and there. So you can immediately put that on the book. Not really good for a long-term business model. All right. So now we move on to the other problem, right? How does this scale? Right? How does So you're standing up websites faster than ever in the cloud, right? So now you have thousands of them. You know, some companies hundreds, a lot of companies thousands of them. All right? So everything we were talking about was nice hunky dory when it's a handful, right? Now you have thousands and you don't even know where they are. You don't know who owns them. You don't know

anything. Right? So how does security scale at the same speed that you're scaling the number of websites that you're standing up, right? So it's an interesting problem to solve, right? So do you want it doesn't? Yeah. All right. My builds. All right. So, here's just I Oh, maybe. Maybe recover. Thinking seriously about it. Oh. Oh. Oh. What the Awesome. Ah, someone call tech support.

Jim, sit down. We're not done.

So this is the typical development environment when we're talking about pushing out stuff fast into cloud. So let's say this is your typical deployment. You know you got a couple app servers, backend database, maybe a load balancer to balance things out a bit. You know, you're using firewalls, other security measures. Great. Everything's secure. You tested the hell out of it. Everything's fine. Um, what if you want to start cloning servers? Cloning is awesome, especially in cloud environments because you don't have to stand up servers over and over and over again using, you know, your build scripts. This is just like, hey, this one's working. So, we're just going to clone it over here. It's going to come

up with a new IP address and everything's cool. We've just we've got scalability now. So, the problem is uh your vulnerabilities and your problems scale too. So that polished turd is now multiplied into multiple polished turds. Yeah. Isn't that good? That's good. So we've now provisioned this great little server here with the app. We'll throw another load balancer in there because we're getting hammered all the time. Another database. You know, business is good. Uh it's all about getting money. So people are doing transactions all the time. We have to keep up. But then we get this one server. Some little wy hacker comes in. Oh, hey, they compromised that. Now we can get to the

database server. Now we can get to the other database server. Uh what happens to these other servers? Are they still susceptible to the same attack? Probably. Yeah, because we just cloned from these garbage polish turds over to this brand new polish turd. So what's to prevent someone taking this down then nailing this doing something over here? Sure, they already have access to the data, but they could just be jerks and want to take over here, do whatever they want, right? So, that that's the biggest problem I see with cloning, especially with regards to application security and even server security. Uh, you start cloning those polished turds and we end up with massive problems. And this is our Chris Hoff to

catch a predator picture. It's great. Yeah, this is uh Chris off gave a gave a talk about this stuff a while ago. I just thought this was a good quote, right? It it kind of hit home on the scalability stuff, right? I'm not going to read it out loud, but kind of hits on what Andrew said. It doesn't, right? It it's it's pretty hard. Traditional security does not scale, right? We we need to come up with new ways to be to be solving this problem. So, right. So, this is kind of hit home to what we're talking about this whole time, right? Should never be security or productivity, right? We're trying to stand up all of these web apps. We want

to get them out quick. We want to do all this stuff or should we secure it? No, that should never be the case, right? It should always be both of them. How does this work together? And uh hat tip, Alex, right? We said risk. Did you want to hear that, Alex? We said risk. There you go. Yeah. So, you know, with the exception of Etsy, I think everyone's doing it wrong. And I really hope that some of the developers and some of the founders of Etsy come out with a book in a year or two to say how awesome it is that they're doing their thing in a secure and scalable manner because a lot of

people could learn from that. Uh because just people aren't doing it right now. They're just trying to get out there faster. So, we need to really make security part of the entire life cycle. I know everyone's heard that, you know, there's the SDLC, there's the rugged movement, there's, you know, there's underpinnings of security and agile, but people don't want to do it because it takes time and it doesn't let them get faster. So, you know, as the developers in the room who put their hands up, actually, this is a good question. How much influence do you guys have over security [Music] uh recommendations on whether your code should ship or not? Lots, right? Tons. Yeah, it passed the

unit test. We're good. Ship the QA. Not really a good system. I can't read this because I no longer work at 451. I'm not going to read it out loud either, but this this is kind of telling of of where we are and why it's the summer of the breach, right? Everyone's been throwing that around with all these password leaks and stuff. So, the market for network security, this is kind of telling of of where we're all spending our money, right? 5 to8 billion dollars on network security. It's firewalls, antivirus, stuff like that. Application security, everyone see the number over here. 444 million. That's an M, not a B, right? It's much smaller, right? So

application security is just trying to catch up right now and even uh claim the dollars that network security is is is been demanding for all of these years, right? People are just starting to take it seriously because it's starting to cost people a lot of money, right? Uh I mean, if you read Verizon's, you know, data breach report, most of them are web application data breaches, the vast majority, right? And it's costing people millions and millions of dollars. So hopefully that number is going to get bigger pretty soon, right? So yeah, this is 451 group and I put this slide here, not Andrew. He's even though he's ex451. Yeah. So I just wanted to say something.

So on the bus over here, I was the only one who got on at Caesars's at 9 in the morning cuz I guess everyone else was hung over or still sleeping. And the bus driver was asking me, you know, what's the conference? Like what's going on at the Artisan? And I'm like, oh, it's a security conference. He's like, what? Like bank security? Like no, computer security. And he's like, you know what? I'm I always think that if something is built by man, it can be broken by man. That guy's a bus driver. That's like the most astute thing I've heard all day. Like if it can be made by a man, it can be broken by a man. Like this guy should

be given seminars. Yeah. 5K 5K ahead. That's a Roman model. All right. So now we're kind of getting to the solution part, right? We've presented this problem right here. Then we're going to start tiptoeing into solutions. We don't have a perfect solution. We just have okay, we think this is probably a good start, right? And that's really all we can hope for is secure enough, right? Start to code secure enough, right? So one technique this is, you know, that's that's kind of hammered on over and over again about being a a poor solution is WFTS, right? How many of you are familiar with WS? Have worked with them. Cool. Good number of you. All right. So

all Yeah. No hands. Good, good, good, good, good. So, no, I I'm not saying trust WAPs 100%, right? I just like if I stood up here and said trust, you know, antivirus 100%, you'd boo me out of the room, right? I hope you would, right? But in terms of this scalability issue, a w could help be a mitigating feature, right? It's it's going to stop the lowhanging fruit once you find the vulnerability and you create that Jira bug and you have that security fix on your product roadmap. This is at least a hey, please don't hit me with that giant stick for a few weeks while I fix this, right? This is going to stop a lot of

the, you know, the the bots out there crawling for SQL injection, things like that, right? Targeted attacks, no, right? It's it's not going to do anything. You can get around it, but it's going to buy you some time hopefully, right? It's better than nothing, right? It's it's definitely better than nothing. So, odds are it'll buy support time. Developers, you still have to get it out there. It doesn't buy you an extra week or two. Yeah. No, not at all. It's just a mitigating feature, right? So, yeah, solutions. That probably should have been one slide earlier. Come on. Wrap it up, B. All right. So, application security. Here's a start, right? This, we kind of mentioned this a

few times. The secure SDLC. This has been preached over and over again, right? I'm not going to go too far into it, but it's definitely a start. It's definitely important. It should exist in your development life cycle, right? Requirements design development QA and production, right? Security should exist in all parts of the SDLC, not just down here, you know, not just, oh, it's in it's in prod now. Cool. Let's worry about this security thing that everyone's talking about. No, you should have a security guy in the room with the people setting the requirements for the application that you are building, right? They they that should definitely happen, right? And then the design, you should have architecture built in,

right? Not going to harp too much on this. It's been talked about till everyone's blew in the face. But this is just a start. There is really no supporting evidence that people that do this are more secure than people that don't do this, right? There's no numbers out there that say that, but it sounds like a good idea, right? So it it it it's definitely a a good start. You want to hit So I've got a question for the developers again. So the developers in the room who amongst the developers have a defined SDLC in place or some semblance of guidance. Yeah. Is it a big company? No. Oh, one yes, one no. So I

from my experience I've seen the bigger the company the more likelihood that they're going to have a defined written down life cycle process for new hires instead of startups that are typically flying by the seat of their pants because again faster equals money and if we get the money we can put more money into it develop you know grow big together yada yada yada. So this is kind of what we're pitching a better start, right? So we have this over here still, right? But now you've already pushed all this code to production over the past couple years. Now you're just starting to worry about this now, right? So what about all that, right? Or or all the stuff that that

doesn't handle, right? You're still going to push vulnerabilities. You have a security SDLC. It's still going to some deadline somewhere is going to have someone cut a corner like, you know, like Andrew was saying, and you're going to have vulnerabilities in production no matter what, right? We have to come to terms with that, right? It's not like source code reviewed secure development training and a secure SDLC equals no vulnerabilities in production. That's you know yay cool right like this will this will work right so um and also what I mean by production vulnerabilities and this is kind of uh counterintuitive to what's going on a lot out there with uh consulting uh pentesting and things like that. If you

test a web website, okay, you have a thousand websites, you test the first 10, that first one's already different, right? Now have fun with a thousand. And now have fun with a thousand always. Now have fun with 10,000 always, right? It's it's a really hard problem to solve. So you really need to bring automation, testing with a combination of automation and humans, right? In order to to kind of work on this, right? And then attack traffic, monitoring attack traffic. This is what I was talking about with Etsy, right? You're monitoring real time. Okay, cool. So, we prepared for what we think is going to help. We saw what actually wound up in production. Now, let's see what bad guys are actually

doing, right? This is all the stuff we know about. We're testing for production vulnerabilities that we know about. What about the bad guys not using things that we know about, right? There's zero days drop all the time, right? We see it constantly. So, you got to be monitoring this also things like Okami and things like that. And then learn from all our mistakes, right? Verizon's databach incident report. Required reading for everyone in this room, right? Everyone who's interested enough in being here should be reading the Verizon databach report. It's gold. Agree with the results or not? Yes. No. Absolutely. But it it required reading. Learn from our mistakes, right? SQL injection. How long have we known about SQL injection? Years

and years and years, right? And all you need is that one, right? We do see SQL injection going on a decline, right? White hat puts out a stats report if any of you are interested. Um, and it it's kind of the stats of all the vulnerabilities over all of our websites. It's cool trending over time. And SQL injection is on a sharp decline. But would you guess that? Would anyone guess that SQL injection is on a decline based on this summer or last summer, right? No, not at all. Right. I think it's more prevalent than ever, but it actually is in sheer numbers and mass of how many vulnerabilities out there. But all you need is one, right? And then

here's the other paradigm shift. I I forgot to mention this a few slides ago. Uh shift that that how many times have we said cloud and paradigm shift? All right. Yeah. Cool. So, uh you know the the way that people have been doing it for a while is let's test our flagship website, right? We we we go we go eight miles deep on my company.com, right? And we don't really worry about this other stuff, right? What websites were Sony hacked by? Was it Sony.com or was it a forum in Brazil that had access to that same database right the first couple times? Right? They're not the flagship websites that are being like hacked anymore. Those are

being slammed constantly and and the security teams there are getting free testing by all the bad guys, right? They're just those flagship websites are just seeing all of the constant bot attacks and things like that. The targeted ones, the smart hackers are going after the little peanut website, some forum, some something. you need one parameter that talks to that same database, right? And why go in through the front door, right? When the back door is wide open, right? So, so that's the other the shift. So, now everyone has to test all of their websites, not their not their their crown jewels. So, I used to work for a bank in Bermuda, and I'm not going to tell you

which one, but there's only four, so it's not hard to figure out. Um, the first day I got there, they had firewalls deployed. They had firewalls deployed that were eight years old and hadn't had an upgrade since uh well, yeah, yeah, eight years. And during that 8-year period or at the start of that 8-year period, I worked at Nokia. So, I supported these guys when they first bought these firewalls. And then I get there and I realize, hey, you guys haven't done anything since I talked to you eight years ago. And their response, which is very common, is like, "Well, we've never been breached, so we're, you know, we're going to be fine." You know, no banks in

Bermuda have ever been attacked at a a level where it's a big problem that we have to report it or that, you know, it forces us to invest a lot of money in security. And that's about the time where I knew I had to get out of Bermuda and stop working at that bank. Um, in terms of servers in general, not just cloud servers, but servers in general, it's the old stuff of, you know, know who's running what and where. Asset management is a big plus. Not just come audit time, you know, when you have to care about PCI that one month a year, right? Um, you really need to know where everything is in your network, your

applications, who's using them, who has access to them for administrative purposes, which users are using, who what kind of data is going in there. You need to know this stuff in order to get a hold on what's going on in your organization. Um with regards to cloud be it you know platform as a service SAS is public private hybrid cloud data center you know what are your responsibilities you need to know when speaking to this provider uh you know at what point do you need to start caring about security and at what point are they going to step in and help you or have they too have they gotten to a point where you know this is enough to

cover you off and you only need to do a little bit to maintain the security of these systems or applications and if you're just going to start taking servers in your data center that have been running there like if you who here wants to take Active Directory and put it in cloud instead of their data center. Yeah, Jim. Jim wants to uh not a lot of people just want to forklift existing servers and put them in cloud unless it's the CFO saying, "Hey, look at all this money we could save by forklifting these servers and applications and putting them over in cloud." That should set off all sorts of alarms. You just because you're taking

these servers and putting them in cloud doesn't mean you still have the same protective connective tissue like you had in your data center. Your IPS's are gone. your firewalls are gone. All your network-based defenses don't really exist anymore because your your server is now, you know, looking over the precipice. You're right on the edge of the internet. So, you don't really have those happy shiny protections that you once had. That's why forklifting bad idea. And you know what? Focus on securing what you control, just the stuff that you control. Don't worry about talking to the provider and saying, "Look, you guys really have to do this." You know, they don't care. They're not going to care. They're in

their they're in business to provide you with infrastructure to run. So you give them money for uh access to run on their compute system or their compute architecture. So they uh they will take your feedback on security but don't expect overnight changes. Say, "Oh yeah, well you know we need IPS's deployed on your virtual network infrastructure. We don't want to pay for it. We think you should provide it." And they'll be like, "Yeah, all right. Yeah, we'll get right on that. That won't cost much." one thing I heard. So, not only will they not support some, you know, some of these uh mom and pop cloud providers, whatever, not only will they not support the thought of security, some of them

don't allow it. Some of them will not give you permission to test the application that is on their server. They say, "No, no, no. You don't have permission to test that. You're going to see our internal network infrastructure." Okay, so you're not going to give me permission to test my website. Let the bad guys have fun. Right. Cool. That's That's I I think my favorite thing from the Amazon terms of service was uh and I think it may have been changed lately, but when it first came out, it's like you cannot scan your servers and application using a vulnerability scanner unless you tell us ahead of time what IPs you're going to be scanning from, which kind of defeats the purpose

of any sort of penetration testing because well, as we all know, the attackers will always call you and say, "Hey, we're going to be coming from this IP address, just so you know." So it, you know, doesn't really make testing that much uh or that easy. So development in the cloud again just because you're doing development in the cloud doesn't mean that you don't need to care about security unless you're well know Etsy's doing it right but you know if you're spinning up cloud servers for specific development unit testing integration testing any sort of testing or QA you really need to maintain these servers as if they are production servers within your perimeter because hey you know what you're putting

code out here. A lot of that's your IP. Do you want your competitor to be able to get at your intellectual property, steal your code, and get to market faster than you? Because, as we all know, getting to market faster means money. Um, anyone heard of the Formspring debacle lately? No. Oh, no. Yeah, you should change your password. So, they had production or they had development servers that weren't protected and uh so they attacked the dev servers. They didn't really attack the production servers because attacking dev is sometimes easier than production. Often easier. So yeah, look up the just do some just Google Formspring Formspring breach, you'll get a lot of details. It's pretty interesting, you know,

because a lot of people don't really care about their dev servers because in cloud environments, you're spinning it up for 15 20 minute test and that's it. Spin it down, don't have to worry about it. Why do I want to do firewalls, IPS, blah blah blah? Because I don't need config management, change control, anything like that. It's just going to be up there for 15 minutes until I'm done. Not always the best thought. Documentation. Who doesn't like writing policies, procedures, guidelines? Yeah, everyone. Um I everyone I've written has been ignored in my career. So, you know, you need gold standards and your baselines and these uh informative documents that are out there, you know, NIST, your ISO

standards, things like that. These have to apply to all of your systems, not just the ones protected behind your firewall. If you're spinning up cloud servers, you need to make sure that these guys are as secured as your systems internally. Otherwise, like you're just going to throw your hands up, oh yeah, well, it's a cloud server. You know, what can I do? We don't have antivirus on there. Come on, that's not an excuse. You have to look at the mitigating controls that you can deploy in a cloud server to help get you an adequate level of protection uh for the risk tolerance of your organization. Bingo. Bingo. So that's it. We have about I think like eight minutes left. Uh does

anyone have any questions at all?

Yeah. I had its noticone.

That's pretty cool. Yeah, that that's how you get funding. Yeah.

Yeah. Really breaking ground knowledge right there. Yeah. The guys at Etsy are, you know, they're on the cutting edge, not just technology, but with their ability to share back. It's awesome because I think people can follow that model and just build companies based on that. like people used to do with Apple um or Microsoft, you know, Etsy is the new guard when it comes to like a stick against which to measure how you should implement products and security and things like that. Yeah, I'm telling you there's going to be a book. I guarantee you there'll be a book in a couple years.

I have no idea. I just started talking about

what was that? Oh, yeah. It's not the founders, it's like the Yeah. The head developer guys. Yeah. Cool. Cool. Thank you very much. We're going to be around, so grab us if you need us. We have sponsors.