← All talks

Docker Cloudlove: How I Learned to Stop Snarking and Embrace the DevOps

BSides KC · 201829:1824 viewsPublished 2018-06Watch on YouTube ↗
Speakers
Tags
StyleTalk
About this talk
Docker Cloudlove, or "How I learned to stop snarking and embrace the DevOps." As security practitioners, it’s easy to become set in our ways, and decry loudly each new technology buzzword that comes along - and that’s not an unreasonable attitude on the surface. Unfortunately, this tendency can be detrimental to our profession and our careers, by leaving us ill-prepared to provide constructive security advice when the rest of the enterprise is forging ahead. I know; I’ve been there. This talk will make the case for security professionals to not fear the DevOps revolution, but to embrace it, and give real, actionable advice on how embracing DevOps as a security professional can move your security practice to the next level.
Show transcript [en]

you probably know about don't know first Chester philosophy open web application security project we try to sort of bridge the gap between security folks developers and I am also a senior application engineer and mr. price

I think the simplest ways to do so oh let's see [Music] [Laughter] [Music]

okay there you go okay so

I have specimens probably in about almost the past 20 years doing some combination of security application development and system administration and pretty much been full-time idiot in most of those roles at some point so I pretty much refer to myself as cross-functional I worked at large companies to present us to small startups the like working at alland less than 50 and I typically spend a lot of my time immersed in the security community outside or so we're going to talk for a minute about the buzzwords buzzwords we all know as security professionals we tend to be pretty much word resistant we tend to hear something repeated over and over and over again and go that's just a

buzzword that's rare but that's not bad thing always but we are done with management with no helmet folks who are not buzzword resistant and so we all know this cycle management here's that new technology new technologies going to save us everything deploy all right now it's it collects dust organs homes and so suddenly management hears about newer technology and we repeat this cycle that's we've all been there but let's take the example of web application firewalls any of you who were doing it for second you know eighteen years ago probably heard this the statement Louis to point what happened we don't need to worry about application security it's it's all good right well yeah not so much but that

doesn't mean that way us are a useless technology just just because they got overnight and overused there's still a useful technology that can be used for mitigation of individual attacks they can be used for defending against the script kiddies that's I mean that's a big thing right there and they can be used for the all-important checking boxes on compliance force and so my point here is sometimes buried in those words there's a good idea and those good ideas can tend to get miss regarded as high if you have ice water too much it's like it's like we got a good song on the radio that to the radio over an entire day so that brings us to

devops cops which I'm sure nobody will argue with the fact that DevOps and desta cops are the buzzwords of here at least for the past couple years yet I I work for a San Francisco based company you can't walk down the block in San Francisco without tripping over a DevOps company it just happens they're worse than Starbucks and so that oversaturation of high leads to especially InfoSec people who are somewhat start chrome in the first place to be extra snarky about the idea of DevOps in a lot of cases so and I'm going to use the term DevOps in devstack ops kind of interchange here there there are some differences but notice that cops basically blowing

the security component into dev ops concept but I don't the say to have side opposite rotala snake so it's obviously dev ops [Music] so you know we security people I've heard all commentary about DevOps and probably said a lot of it but what we're just going to give the dev to access to deploy whatever they want to we're glad this isn't meant to make firewall changes oh hell no no you want just deploy stuff we blow the day all the time now either ground let those security guys into the code repo you don't want to do that that's caliper goes goes that's and many of us have made those comments so that's not what DevOps do it may

involve some of those concepts but not in the uncontrolled fashion that that those comments are finding out so what if there is some buried treasure in in that in all that height it might be revolutionary a lot of it might seem like common sense but a lot of it may be a route to make things better over security people better for developers better for Ops teams which means it's better for everybody so a lot of the classic view of information security is we're going to go pack all stuff that's that's what we do but I'm sure that most of you out there probably don't view it that way now it's probably more like secure all the things rather

than rather than just breaking all this time security you know blue teamwork is is probably even more prevalent than red team work in a lot of cases it's beautiful so how do we go about securing all the things well we want to do these things and yeah they sound really boring but they're really the core of creating secure applications your assistance - great - so who here and tell me those familiar with determining security glass Wow okay I figured we get more than more than that so okay so moving security to the left again it seems obvious but if you view your software development lifecycle and I didn't get a slight moving security to the left if you view software

development lifecycle and a set of steps you start out on the computer design your second phase is actually Brandon kind of developing the code usually the testing code goes along with them then you go into deployment then you go into maintenance well in a in a classical security model where security is not welcome development team security doesn't really end until about the point where maybe gives her lucky lives in the testing phase if you're not lucky it ends up being in the oh that comes running and somebody just acted phase well moving security to the left is the idea of moving that security engagement with the software development lifecycle back to the left in that in

that process and the reason for doing that is that research experiment that it can be up to a hundred times cheaper to fix a problem in each previous phase than it was so the promise discovered in the Boyd app across 100 times what it would have cost to fix that included been discovered in testing and same things for design it it makes a huge difference in your security perspective so that's what I mean by moving security to the left and that's what a lot of what Josef Dobbs is trying to do is move security the left so all of these things together those are what what along with a lot of other concepts that it's only

25 minute talk so you know didn't want to get two of them those are what makes up javis tech ops

so big question now is how I promised a vegetable in sight so we're going to try and do some of that I'm going to try and provide some ways that you as security people or you as developers or you as operations teams how many folks in the audience who are security security focused most of you how many are development or operations there a few okay good so we're gonna try to provide ways that you guys can make these changes incrementally from internal and he thought leaders in your organization without having to get immediate our management bhaiyya we're also going to try to provide some ideas because the final entrance money is of low-cost tools lower-cost

tools that you can use to implement these things in your environment today so I know most of you out there are going to be going well I'm a security guy not a developer and so I don't want to be involved with development teams well that's you gotta keep an open mind that that's really rule number one for security people if you can't keep an open mind when it has to do with working with your developers you might want to think about being a different field or you might want to think about being at least visible so solar and I'm not saying goes to them and start hammering out code that that's not the answer here

the answer is go sit down with your developers your operations people etc find out how they work find out what their process is look like this doesn't have to be a formal process go buy a cup of coffee and have a channel of talking be their friends don't don't leave those in exchange of company that's you could there are some awesome frameworks out there that you can use to feed yourself into some questions they can give you some great ideas for places to start discussing the two that I really like are OS of Sam which is the OS software assurance maturity model and destem which is the building security in maturity problem they are both freely available resources

on the internet and if you want to get a good idea of where your organization fits in the software start a software security lifecycle there are a great place to start really these we work with both of them noise maturity

so I'm fairly sure that that most of you if you work in an at home and modern development company or motor company at her determine how many how many of you have worked in what considers itself an anti operation okay and so the rest of you first off my condolences but because your it's going to be a lot harder to affect that change if you're not if folks are these not already aware so what is that job so agile is a concept was actually created by a group of folks from other programming paradigms in 2001 it's characterized by a handful of things namely being a lightweight process not having a ton of overhead in managing it releasing often you know

ivory every two weeks to sort the stated goal I know that seems pretty crazy to some of you it would have seemed absolutely crazy my previous to us human interaction it's based on the concept that you get a lot more done by just going and having a quick conversation with somebody then throwing something over the wall our ticketing system that's not to say you're not going to use a ticketing system to track things but it's human interaction and having conversations having stand-ups is keep the automation we're going to get more in automation in a minute reflecting on process and learning from the states it's not agile is not a just coming in you must do

these things angela is there are four ceremonies they call the ceremonies I think it's silly but there are sort of poor to the concept of agile and those are again they some of them seem kind of obvious but sprint planning daily stand-ups which is the one that I'm sure I know probably five years ago when somebody said we have a daily meeting to this project I said oh no way but they're very strong meetings they're called stand-ups for reason she's supposed to stand up you're supposed to keep them short iteration reviewed doing doing demos and share it with the other people on a project team what what worked on and then again retrospective that's being aware of the process and

looking at what worked right what went wrong in a cycle and changing that next I'm not not being beholden to this is the way it should always work but again agile many of you may work in workplaces they consume themselves to have dominant not necessarily all those things where you are fine for instance that's that's simply how how that works it's not meant to be a hard-ass strict regiment of here's how you develop but the reason I digress into agile is because a trial is really the predecessor to demos and in order to be able to bring a DevOps world into your comment lifecycle you need to be aware of that you need to find out

what a cloud means work so the best way to tackle bringing DevOps in making your company DevOps enabled is to be a uniter in my view their oxen and I literally about three things number one tearing down the silos so most companies classic companies you've got silence you got development team over here you've got operations team over here you've got a security team over here you might have project managers up here they kind of try and float between the three and do it badly sorry any project managers out there but that's that's kind of how things normally divided in a lot of cases DevOps is taking those silos of turning them sideways so that each project has

some negative development team members has some operations team members and has some security team members who are dedicated to those projects in general step two is speeding up the cycle like said rapid release doing things on a quicker basis so it's easier to I mean we've all been through big bang deployments that you know tonight it's not a pretty scene nobody wants to do that number three automation automation is really the key to what I've been talking about today so tarragon stylist is harder it requires organizational change but you can do it unofficially so if your organization is not willing to just jump headfirst into the concept you can go in and build those project teams

organically you can ask the development teams if you considered on their meetings for four projects or just everything used in general I know nobody wants more meetings but sometimes you can say those to be a fly on the wall if that's what you have to do but you don't you don't have to make an organizational sea change because a lot of the development team already haven't stand up so if you can sit in on those you can find out what's going on same with the operations team pull them ahead and get engaged with those teams number two speeding up the it really seems counterintuitive faster development it seems like it would be the best security but the key is that

when you're doing faster development you're also doing smaller development you're you're releasing a lot smaller set of code and it's release cycle and again it seems like a great organizational change but if you have teams already had job they're probably hard additionally they've got resistant security teams we don't work with this stuff so that's a that's a big advantage right there but you can also speed up slowly and build momentum momentum is your friend is you speed up those are these cycles and people see it being a success you will get a more engagement with that process so I've saved the biggest thing for last automation PI clients so yep if you if you dive into this world you'll hear the

term pipelines a lot and basically that's the idea of that software development lifecycle I talked about earlier being passed all the way up that pipe that system that cycle in a pipeline in an automated fashion so the goal here is to to stop doing things in a one-off basis to not not still be building networks and servers man knocking into firewalls and handling configuring firewalls not being locked into switches not plugging in you know install this Apple on this server install the other half on this server and so with automation we can do a lot of that and if you're out the team's already have a CIO CD pipeline see that CD that's continuous integration

continuous employment imperative have a pipeline with they're using Jenkins that's that's a technology you probably heard of a surplus CI you halfway there because that's that's a big hurdle but there are Jenkins the free solution so you can download it and start using it it not so we're going to start about start talking up what kind of anyone put in that pipeline automated testing it is huge you can use tools like selenium what's here dojo to encourage your developers to write tests for their applications that can be fashion because having those tests means that if something if somebody makes change that breaks a piece of their code you know a classic example of this is

there was a there was a papal bug a while accident if you if you entered if you entered the wrong thing in the password field it would they would have lots of machine that's something that absolutely be caught with automated testing because it is simply somebody to put the wrong variable interrogative statement it that's the kind of thing testing is or talk to your developers about test-driven design which is writing tests before you write code it sounds kind of I know a lot of people it also sounds like a lot of work and it can be but if you write the tests and then write the code to make the tests work then you have automatically save

yourself all that trouble going back and writing those tests and you know your code works the first time and then every time that code changes it can be tested so as security folks though we want to know about testing security security testing you can insert all of these tools for free into that automated pipeline Arachnia Wapiti are both dynamic scanners for code verb suite if your security person those can all be inserted in that pipeline and run automatically every time code is checked into repository which again it allows for massive amounts of automation possib SAP does another one that's not on there clusters and there are plenty of tools out there to cost a lot of money the final thing

is that I've gotta bring this other buzzword in but this is really the key to why this has been to security because I'm going to talk about the cloud I got to tell you even as a security guy that you should look to the cloud but that doesn't necessarily need a public cloud you can build your own cloud inside your organization you can use dr. swarm or kubernetes or DCOs to create your own and private cloud that brings all of these advantages of deficit ops to your organization without the scariness of putting all your data in somebody else's computer or you somebody else's community that's you can do it either way there's this resistant advantages either way but the great

thing about that the cloud is that you can automate all the components so you can could do what's called creating infrastructure is code which means that even even built into your entire environment can be done in a code based fashion so it is competing it is audible that code would be in a github repository just like just like any other or a git repository is like any other code you'd be able to see who changed it there's a count ability in place it's consistent you don't have to worry about oh I got Jennifer got you Jenna got distracted and didn't run these three commands in the build document the last time you built this system so this this

is what's missing these three components I know so infrastructure is code is hugely valuable from a security standpoint because it brings that consistently to see it it removes from from the human error factor from the process of deploying environments deploying a company and if you stack all of these components together all of these pieces into a pipeline the advantage for security is amazing so to wrap up this is why I as a person have have come to embrace the concept of DevOps which is something I you know I actually computed several years ago because if you put all these patterns together if you put together consistency computability standardization attribute ability and engagement if you have an

environment is a thousand times more secure than if you don't have those components so it's easy to get lost in the idea that the security should be its own silo out there that making these big changes is hard but you can make these changes within your organization just by communicating and that was working with the other people in your organization it doesn't have to be a turn addition of around change it can be a gradual change that makes a huge difference so that's that's my talk any questions you can answer yes [Music]

at all so DevOps does bring a lot of new technologies the challenge is not just bringing in every new technology and making sure they take model of those new technologies that's that's really you know every DevOps person I work with okay there's somebody is a list we have Ian well granted again let let them make you use established technologies so okay I think I'm probably gonna run out of here itself

you