Close DevSecOps Awareness and Guide to Practical Implementation

besides DC would like to thank all of our sponsors and a special thank you to all of our speakers volunteers and organizers for making 2018 a success so the topic today was about DevOps and security and DevOps and so I my name is Tish Lutra and before we kind of start I wanted to provide a little bit of a disclaimer from what little there's a little bit of feedback okay all right so I just came out from a really bad cold and I'm still kind of running through it so I'm gonna try not to yell or loud would be too loud otherwise that's gonna be the end of me but anyhow this is just to kind of talk about that there's some

of the things that we are doing in our development shop and there are some forward-looking statements also and we're also talking about some you know there's not much confidential information in this deck as such as all private and wherever the sources are I've actually labeled where the sources for those information and and documentation is but if you if there is any future or any forward-looking statement I'll probably pointed out but just to kind of keep that in perspective so my name is stage I worked in Berlin and Merl International is is a good 21 plus year old company and prior to that they had a different part of the business so in eight years that did a

lot of web development and over the years Marlin has had different today but they wore different hats we built a lot of software for many major companies and that business sort of car divested about maybe 10 some years ago and then morpho reseller and solutioning business but overall for the last 21 plus years it's been predominantly cybersecurity so and our market has been federal as well so many of the agencies we've had working with every working with they are we've had some really good relations with them over 15 16 years and running and we are also moving a lot more into into the commercial space and last year we we changed a little bit of direction

it wasn't been a massive shift again but we retained our reseller and the distributor business that we have but then we also took on product development and this was again after probably a lapse of a few years we went back into pearl of them the main reason was to to provide IP our own IP because we felt we could solve a lot of these problems that we come across in a day to day to day basis in a very different form and start a different yet in the market so not being as a as a reseller of anymore but not this becomes much more bigger when we go to our customers we not only stitching them a solution that's

important to them to solve their problems or aligned with the mission but we also look in that ways to kind of solve security problems with our own with our own product as well join with me here is Devesh Arora over here and he runs the engineering pardon we have a available since it's a young shock we kind of broke a lot of norm in terms of how we wanted to set up the shop and it's very young to like many of our developers they are roughly at is 6-7 months old as when we started you know stacking up the shop and then we have a team about maybe 25 people now so we really grew very quickly so he leads the

micro services and web development you know of our engineering division so today we're going to talk a little bit about DevOps we're gonna lay the foundation and then talk a little bit about what security means in DevOps and kind of translate that into some of the requirements that we see come in what are the challenges set of guidance that might be relevant to many of you or if you come across situations maybe these you know guidance can actually play a huge role but fundamentally what I really wanted to do was kind of open up as a broader discussion and kind of give you examples as much as possible and also talk about some of the

practical experiences that we had over the years my past experience came from Netflix where we really ventured into dev also we really built it out from the ground up and then I went to IBM it was totally flipped completely different but then we could see how we could apply the same devoir principles to this massive company and try and bring the same you know efficiencies that we wanted to bring so I've had that kind of passive experience I want to bring some of that back to you guys and then you know kind of talk in broad sense also go a little bit technical where I can but also leave at a policy level upfront so you guys

can actually see from a broader sense where it makes sense and kind of give you some you know anecdotal examples as well so I wanted to start with this slide and it's it's kind of good to understand where the market is going and and what industries and companies are really looking into and if you are in a certain industry it's always good to keep track of what your industries moving towards and what they're trying to achieve so what this chart actually shows is it's predominantly for adoption of security in DevOps and this was published by Gartner I think in earlier this year I can remember movies for 2018 or 2008 2017 report but it's pretty

evident that there is a shift of bringing security into DevOps and with that there are tons of opportunities and benefits and I wanted to start with talking about you know laying the foundation let's say we know and understand what DevOps really is and we implemented some level of that framework an organization the opportunity that you know security and DevOps presents is about continuous assurance and providing continuous information assurance to the way we deliver software and this has been pretty much you know it's been more and more evident with cloud native technologies with adoption of cloud by moving into you know you know infrastructure as a code if you if you look at these different paradigms that

we've started to adopt within the organization you start to see that that's actually been you know feeding into this requirement of information assurance and that's where the big opportunity really lies and DevOps so fundamentally I mean if you kind of look at the adoption rate within a year or two like I mean what garden kind of talks about on the on the top that will pull it over there from mere 15% to they see about 80 percent adoption and incorporating of these capabilities within you know the existing devops pipeline and there are tons of challenges to I mean it's not that it's you know here's a tool just implemented and here it goes there is there's a

massive undertaking and understanding of why we need to incorporate these physical aspects into you know all the processes that we do or the tools that we that we utilize even the mindset of the people who are implementing their ops I mean that becomes a big factor as well but if you guys are looking into you know building a startup I think this is a great area to kind of focus into because the market is fresh there's not too many standards out there and there's a lot of requirements coming in but the growth is phenomenal I mean that's pretty much what it is and it kind of boils down to so you know along the course of this this presentation I'm

gonna the components of DevOps as well and you know you'll probably you probably you've already used some of this or maybe you know it but soon you will realize that it's not actually a tool that's really a practice it's a methodology that we want to implement and we want to leverage the best of what it provides so you'll see you know things like continuous integration continuous delivery continuous deployment those kind of artifacts become really important in a DevOps environment and that those are again the key components of how you know a DevOps organization succeeds in a way to be able to provide what they need to provide to their customers and we'll talk a little bit more about that as

well benefits are huge I mean you know predominantly it's about staying closer to your customers being able to deliver your software to your customer in a short period of time and it's all about being competitive and have that competitive edge so the whole idea of DevOps is not just about you know here's a new process and take it over and that's about it it's really about providing that content to your customers and being closer to them and being able to deliver these features and in smaller components rather than these large monolithic applications or large features that we are traditionally you know used to kind of delivering it kind of breaks that norm down into smaller

chunks smaller manageable chunks and then provide that as a feature set back to your customer base so it's really about you know going back and then you know the benefits of bringing security inside this are phenomenal because as we're getting into this new mode of continuous delivery and being able to you know shorten the time of providing this content back to your customer base or into your production application it also brings a lot of risks because you're kind of running at a very fast mode you do not want to overlook a lot of these components about security about code quality about you know you know just common sense that you would normally use in any core

development process so there are you know lots of benefits of doing bringing security back into DevOps because it can reduce your risk it can reduce your cost quite a bit and I mean as we all know that if there is a bug fix that needs to happen in production it's probably 10 times or 20 times more expensive than actually fixing the bug you know you know much earlier and in the in the cycle like you know in the development cycle so kind of wanted to start with that but there is there is phenomenal opportunity that we see so let's spend a little bit of little bit time about what DevOps I kind of talked a little bit

about this I don't know how much of a jalloo you know but DevOps to me is you know agile on steroids I mean this is how I see this I mean agile kind of took this huge paradigm of waterfall and took you know these massive projects and then waterfall was literally about you know following step by step by step see but then it took a very long time so agile what that does is it starts the formation of smaller teams more collaborative more functional teams in a way so we talk about a lot of a full-stack teams coming together providing a feature delivery so the mindset kind of changes from a project delivery to a product delivery that's

really what agile really did and when you get into a product delivery mode what you start to see is that you're more in tune with features that are going out to the customer you kind of less worried about infrastructure you kind of less worried about the mechanics of how things are actually functional I mean it's important but you started liver based off of a business requirement that's out there so if certain feature requires it needs it's maybe there's a requirement going into the business function then you would spend time on it otherwise you put it on the backlog so what DevOps allow you to do is implement of implement a methodology to deliver software using

agile methodology so and really the the focus here is to accelerate the product delivery for customers I mean that's the basic goal of it and there are many other you know components of why you would want to do that and there are some conversations about I'm sorry I'm trying to figure out where the mouse goes yeah so the core components of DevOps that we talked about it brings a lot of continuous components to it which is continuous integration which is a principle of implementing code changes or deploying code in a pipeline and a pipeline is radically different from you know siloed applications because pipeline become part of a functional operation and they all kind of deliver an end product at

the you know at the end of completion so continuous integration provides the code into that pipeline what continuous delivery and deployment is about taking that piece of code and cycling it through different phases of code promotion and deployment and you know getting into the state where it needs to be and what you should also see is a lot of components around continuous testing about continuous quality governance all these become part of the you know how a DevOps organization really is formed and those are the core tenants of any DevOps component the question becomes you know why DevOps you know why do we need it and it's fundamentally really you know the basic requirement of DevOps why it

came around was the business need to accelerate product development and in the way they can accelerate delivery and it was really a business function for it so the the focus of DevOps has been how to move new features to the customers as soon as possible but then then there's a there's a radical change of culture that we talk about and the change is really on providing the developers the keys to the kingdom because now they are much more closer to your customer because they are not only developing their code but they are now responsible for deploying the code into production and also managing it and that's where operations and DevOps comes into play because your development team

is also know your operations team so you kind of take that whole paradigm and you squeeze it into one you give them the freedom you give them the responsibility but then they have the ownership of fixing things if they were to go wrong so there's a lot of ownership that comes into the team on delivering that piece of component and the basic functionality of all the basic you know requirement for for DevOps is that it tears down the traditional silos of IT especially around development and operations excuse me

you do I just emptied my hyper Cola I was thinking of calling in sick today I had a perfect reason to do that let's see how it goes I'm gonna talk less and skip some of the advantages that we've seen across the board from puppet labs from Bank of America and others is really about delivery and reduction in the bugs that they are actually seen by implementing this process so it's really it's beneficial I mean when you when you go across seeing what companies have done and what they have achieved there is phenomenal growth but the journey you know to that point is really it's something that everyone has to undergo like you can't just plug in

devops and say I'm DevOps and you're good to go it's really a journey and it's not a destination that's how I kind of see this but once you kind of incorporate that journey in your process there is huge increments I mean guilt for example had this IV for 4.5 guilt is an online shopping app basically I mean you can go in and you can choose your you know what kind of clothing you want and stuff like that they implemented DevOps and the use of micro services based application delivery methodology and for about two years it was really about building the core components building the platform you know getting things set up so the number of features

that they delivered was probably you know relatively ok I mean not too many but once the platform was kind of set up they had an exponential growth of delivery of each feature set so that's what happens when DevOps goes right because you get phenomenal growth in terms of delivery in terms of providing more features to the customer without adding the cost of additional development to your organization so there are phenomenal advantages of implementing your application using a DevOps process or methodology and it's also you know something you have to get realize whether you know how your current development processes are how do you support your current applications it's really easy to do this in a Greenfield

way if you have you know nothing you're starting from scratch this is perfect this is great but if you already have a process and you have to maintain all applications or you have to refactor something then those are kind of things that you can probably have to think about you know why you would like to implement or why would you even wanna you know you know embrace DevOps in a way so just like any other you know process or tool or a method there's always you know pros and cons and here are some of the challenges you know when we get into this DevOps kind of mode getting an understanding of what kind of auditing is is required what standards

that standardization is required how much reporting do you have to do how much oversight you have to do all those things in implementation of controls you know constantly changing assets in the delivery in delivery of those components of the features is really important and I'll talk a little bit more about these changing assets because you're moving into a cloud based methodology you're virtualizing everything you're straining out servers on and off so it becomes really difficult to kind of understand you know what is changing what's not changing where your configuration store because you don't have a physical asset anymore you're kind of moving everything into code and when that becomes another challenge on segregation of duties like

how do you you know provide compliance when your development is a guy who's building but is also making bug fixes in production and things like that or the operation team is so much more closer to your development team so you want to be able to understand the segregation of duties the other thing is around you know this virtual acid that we talked about you know what kind of authentication schemes are they leverage the use what kind of cloud provider are using are you building everything yourself are you you know leveraging some capability provided by someone so you have to kind of decide and understand what do they give you and how do you adapt your

requirements to or your processes and your standards to what they are providing so it becomes a little bit of a challenge kind of kind of starting out with so because you kind of relinquish in control as well you know you're kind of giving away of control when you move to a public cloud so you have to sort of come to an understanding of whether it really aligns with what your ultimate goal is but there are opportunities because you're constantly improving there's a lot of automation you kind of bring in you break down these you know siloed processes of you know not only code development but all the way to the end so when this happens when this kind

of automation and you're kind of crossing across between teams you start to see a lot more collaboration in many you know companies that have been you start to see a lot of buzz and you know lots of small team Huddle's because they're constantly people from different you know parts of the business and they could be the line of business it could be the security team they could be the DevOps team or the developers and the architects they're all kind of coming together and this is a very healthy thing that happens because traditionally if you see in a waterfall model you are typically designing something throwing over the fence does the next person takes on something produces an artifact

you know throws it over the fence to somebody else and then so on so forth goes I mean there's very little interaction that's happening so those are some of the opportunities where teams start to come together they understand you know there's much more communication and it also avoids these last-minute manual audits that we kind of look into because you're continuously developing and implementing standards as you're building the process or as you're building the application so there's much more oversight into how you are actually deploying quality and if there are some audit requirement that are coming in those become continuously deployed we talked a little bit about threat and vulnerability management as well so there's this is where you know lots of

opportunities do exist the whole paradigm of DevOps is really about shifting left and security is no different you start taking all your processes whether you are you know designing or you are probably doing you know security checks or you are getting together with your business you start to bring them early on into the development phase you start with shift left a little bit and you know so so that's another big change that starts to happen quite a bit but then it also provides you standardized configurations for example things and frameworks that you have that code frameworks that you might have to use across the board you know you start to see everybody kind of leveraging the same kind of framework so

if if your container izing all the applications everybody decides on what kind of container applications you would be using or if you're using a certain framework for java then you know everybody kind of comes in consensus that yes this is a right way to kind of go so you start to see a lot of these things happen early on and it makes the team's actually much more productive in a way so I really wanted to quickly touch on this end-to-end product life cycle because the rest of the that kind of talks a little bit about these different components and how security kind of plays a role but I've kind of broken the zone into three different

sections that develop and integration and then you have production and we talked about DevOps it was really about development coming together with production and kind of breaking the silos a little bit but there has to be a handshake between them it just doesn't happen overnight that you're not build something a built in artifact and then it's gone and then it's the operations guys in a turn or when it goes into production that's when I'm gonna start looking into it so to be able to provide you know quality code it has to sort of process follow some sort of a sensible process but many of the tooling that are available to today like the C sed

processes given by Jenkins for example or others they all do incorporate many of these components within so the tools are kind of getting mature in the way to provide this kind of automation but if you kind of start from left to right we look at the development portion kind of starting first where the relevance get together developers get together and they produce some sort of an artifact and it's typically is a form of a code maybe a Java file or a class or something or maybe you know a package that's available and that package is then tested it could be the developer who's testing maybe it's a unit test test but then it could also be a

dedicated testing team who's actually applying a lot of tests to it and there's that's where security scans could also happen once that is done it's validated to for certain you know KPIs that you were trying to measure for those particular tests so that's when the business validation component comes into play and then once a component is is produced then the security checks need to happen at the same time because what you're trying to do is not wait for the application to go to production to do the test or the checks but you want to do them early on so you provide guidance in terms of what kind of tests what kind of checks you want to do

whether it's you know checking for hard codes or bad vulnerabilities in the code or you know cross-site scripting or any kind of other tests that you would want to get done you would want to do them early on in the development phase and that's where all this kind of sticks so once that is done what you have is a secure package that is ready to be shipped or deployed and the integration component really talks about you know how do I take components that I've built during my build phase and transfer it to the next phase which is either it could be a staging environment or it could be a load test environment or I'm ready to

kind of take it to a certain level and it's almost production ready right so I want to be able to get to that point so that's what you see the integration come into play where you have those packages and you start building platforms specific delivery artifacts and platform specific is as we kind of you know getting into this multi cloud environment you want to be able to create your code once and deploy it into any any kind of cloud environment if you want to and that's where it becomes really important for the platform to be agnostic to what kind of cloud you will be deploying your application into or it should be aligned with what is your

target environment so if you are if you are using containers makes it so much easier because you built a container and you basically ship it off to you know wherever the container orchestration engine might be whether it's you know at Linux or if it's a kubernetes based or wherever it is you know newer technologies going to make it easier but then if you're looking at other applications which are you know kind of running as virtualized in VMware or KB M's so you have to kind of think about how you're going to deploy it but the platform becomes really important for that now when the platform is created when you have the images that are created the journey doesn't end

there because you have to constantly go and check and make sure that those images or the packages that you've created they are still clean and there are no vulnerabilities in this so constantly scanning them for CVEs or known vulnerabilities or patches that need to be applied let's say you have a version of Java running in there which is you know known to be wonderful so you need to be able to go and scan those images constantly over time to be able to find when they are susceptible or one river before somebody comes in exploits there so you want to be able to do all that in the integration environment and those applications validated ones are

the ones that run in production so you can see that the ownership is really on the left hand side and not really on the production should still be very light it should be running as designed because that's where your user experience really gets your user should not be you know the one suffering because you were trying to deliver features faster it's really our own ownership on the left-hand side to be able to produce quality product you know and and so that this kind of explains quite a bit about the whole journey that is typically in any kind of an agile shop and in a continuous delivery environment as well so going into a little bit of you know

these different components we have CI CD so we've touched on a few of them and this is something that we've implemented in our environment as well but it's kind of just kind of giving you a very high-level view in the continuous integration you really have the build phase that you're trying to build code and you kind of see the whole process around the code combined which is really where the developer comes in and you're kind of committing the code it goes through quality scans it goes through a building unit test and then you know you want to sort of package it somehow whether it's a container or somehow whether it's a jar file and once

that packages could be it's ready for the next step so you basically have a compiler code at the end of CI at this frame that's really what it is but what it allows you to do is frequent code checks and check-ins you can check into a master you know you don't have to have multiple branches so it kind of keeps your codebase very lean but it also brings a little bit of you know complexity if you have to do that but these are things that your team can actually sit down and identify and feel whether you know this is the right process for us how do we put make pull requests how do we deploy into a branch

how many branches we should keep because now you're looking into multiple teams providing multiple features and they're all running in parallel so if you have too many branches after one year you might have a really hard time understanding how many branches you have and how many of these features are kind of growing you kind of break away from the norm of keeping things nimble and you start to complicate things so those are some of the decision decisions one will have to make in the CI phase itself on how one has to manage the code and deploy them so this is where you know some of these processes become really important now the delivery phase is

really when you've created a package which is really you know a piece of compiled code it could be an image it could be you know some artifact that you have and you put it into a central repository and this repository kind of advertised not advertisers but this is a place where everybody kind of subscribes to to pull the final piece of information that they need for deployment so if you have built you know a UI component the you know the image for the UI component would be in this in this artifactory well this artifact repository and from here you will the the continuous delivery process whether it's built on champ Jenkins or bamboo or whoever that is whatever their program

might be they will pick it up from there and droid into a target environment which is your test or the staging environment it doesn't go into production because you're not doing continuous deployment right you continuous deployment you kind of break the norm and you're touching production right away in this case you're only going up to staging but you're doing full functional integration security checks up to that point before releasing the code into production so that becomes a big part of you know how you manage code and how you start with deliver code within the organization and the next one is Bart continues to premiere see it's kind of more or less the same but what you're trying to do is

now you're breaking the barrier and you're going directly into your final production environment and this is where you have either you've enabled live updates in your tool chain or you're considering you know building a plan a deployment plan that goes directly into your production server so some companies do that you know many apps that you actually use today on your phone they typically go do work on this philosophy but the whole idea is that we've tested the code enough that it's now ready to go into production and it's it's faster delivery in a way but the whole idea is that this the article decode promotion actually happens all the way to production at that point so so let's talk a little bit

about you know security intervals and why would that be really important first of all you know security is everyone's business and we as application developers as applications users we all have the responsibility of making sure that the enterprise is secure typically we talk about secure DevOps from an application development standpoint but then the question becomes like what if an applicant what if an organization does not build an application what if they you know don't have any development shops it doesn't still apply to them fundamentally the process of security applies to everyone it's just that everyone has to define the process and procedures and flows and workflows because what they define will be applicable to how the applications are

consumed in organization so it's important because at the end of the day we have hackers and chemical criminals who are literally coming in to find these vulnerabilities in your application and basically try and breach in and then you know exploit and then once they are in they try to go laterally elsewhere to find you know critical assets and essentially basically take control so having security not only in the DevOps but overall as an application in a sense in the organization is is fundamentally very very important and it should be part of a security strategy that you have and the security strategy is driven by many many different reasons it could be because of compliance it could be

because of regulation it could be because of the industry you're in or the kind of application that you're building they all mandate certain requirements around security so before getting into any kind of development whether it's for an application or is it if it is for delivery or whatever it is it's very important to spend time before the first piece of piece of code is written before the first dollar is even spent to find to define what the security strategy is going to be and when we apply security and DevOps these strategies need to be transferred back to the PMO office who is going to be putting together the plans for development because that communication needs to be transferred

and shifted left in the right form and in the right expected otherwise they will never get done if we say that we will build the policies and we'll do something afterwards we just need to deliver software to the customer and let's just get going with with our application development that would be probably a recipe for really you know a lot of pain at the end so you want to be able to provide what the you know processes and protocols are up front kind of give it give it you know to the relevant teams up front so some of the challenges you know people say that here we are trying to run at the speed of

light and now we have these processes that we have to take care of and it all goes down to cost the cost of fixing about cost of a breach cost of you know defame a brand situation where you know company has been breached those costs outweigh any of these other things so as you know as an organization one has to obey the risks and it all comes down to how much risk am I ready to take and how much risk I'm not willing to forgo so it's not that you know it's not binding anymore you know so you use the security themes since they are working much closer with the development teams they have you know

policies and procedures provided to them but they're also constantly Valarie evaluating the risk and if it turns out that there are certain features that are going into production that do not form or conform to the policies then it's important for them to convey the risk back to the business owners because then a proper decision can be made to let the feature go with a known set of risks or maybe with a known set of roadmap that yes this will be fixed in certain amount of time you know what is the valid date around it a lot of times the challenges come out that you know the team say hey listen we're behind the firewall we're

in a private cloud so we probably don't need all this stuff which is probably the really wrong thing to think about because all the hackers or you know what they need is really one you know one vulnerability and once they are in it doesn't matter whether it's a private or public cloud I mean there's a lot of conversation about blockchain and you know here we have you know appear to be a validated Network and if it's a private blockchain then it's you know really really close but you know security security I mean and once you're breached it's you know the same security principles they will apply so so how what I mean kind of you know I even

talked about the considerations but that's really the you know understanding what the methodology we are leveraging what kind of physical infrastructure are we using so and so forth what kind of testing methodology is being used I mean all those things can away into interment understanding what's the router security and DevOps so let's talk a little bit about the lifecycle I mean we talked you know this in the larger sense but if you look at the chart this is where you know all the development is happening and the developers are checking in code into the build process so during all these steps where we are we are providing you know code as a delivery pipeline right we're

providing features in a pipeline rather than a silo we this is this is all the pipeline and we are soliciting feedback directly from the customers so if things break we're getting understood we getting an understanding of why it's breaking people can actually you know hop on a chat and they are literally connected to the developer who wrote that application nowadays so there's this constant feedback loop that's coming in so we in this kind of paradigm where we're connected to the customer or to the in application and you have you know very few kind of you know hops in between from the developer to the concept consumer the lifecycle becomes really complicated because you want to

be able to provide all those capabilities upfront so common things that you can do up front is a you know provide static dynamic testing for example or vulnerability testing which is you know if a code smells or if a code is you know not written correctly like your left API keys and they're something I mean those are kind of things that you know we gotta be able to scan we also need to be able to scan the images as such you know the baseline the operating system what kind of you know ports are open on those baseline images and and what are we using to kind of secure them you know because if we go through a stake process

it's very very evident what they really want the systems to be and how they want to operate on those systems so all these security policies and requirements they need to be provided early on and the feedback going back to the cease or to the security application and security team is in the form of reports because they need to understand how these tests are coming out so if somebody is running a pen test on the development systems or on the image the outcome of those pen tests are really important to see because it tells how those vulnerabilities can be exploited what methodology was used because at the end of the day the pen testers are really

thinking like hackers they want to exploit the system just like any hacker could do and they formulate a process saying hey this is how I'm going to come into your system and these are the steps I'm going to follow to come into your system and do a certain preacher attempt to do a breach so getting an understanding of the kill chain and understanding the process that the hackers use that's really what comes out from all these different tests so getting all this information back to the security teams is really important so these are some of the common requirements that come about again it goes back to design there are three major components to this we look at the

architecture we look at continuous monitoring and then the documentation at the end and on the right-hand side you see some of the key aspects of what the common requirements are whether you know somebody's trying to log into the system how do you do log management what kind of configuration management do you do you know what kind of physical and personal security data security are there data retention and also you know disposition of the data is also really important because in the cloud form you kind of use the potty floor you know persistent environment where data is kind of stored in different kind of stores and they are really built for purpose so you could have a time series

drive you can have an object store you can have so many other things so having a consistent policy across the board is really important goes back to what kind of architecture you put together and architecture is really a non your compliance requirements you know what services are being used are the sources trusted were you getting the data from for example you know are we leveraging cloud native applications you know all those kind of decisions need to be made in during the architecture phase and then the continuous monitoring is really about governance about you know what kind of tools we leverage what information do we get from them what processes are being used so and so forth and even the

artifacts in the SLA that are being defined they're all part of the second pillar and the last one is about documentation so you know we have a security plan you execute it and then you want to see the outcome and you want to be able to log those and they eventually become a backlog because if you're using an agile process all these pieces of information they get a score and they become a backlog because they have to be resolved during the lifecycle of the product development so there are some guidance I don't know how much time I have but I might have to skip through some of the guidance but you'll have them all in the deck there are these are

sets of guidance you know they are kind of broken down predominantly into how security objectives are adopted how do you integrate security across the tool chain for example you know how do you bring a code in how do you automate the process how do you deploy it how do you test it how do you go back and we do you know the the the entire lifecycle again and again so in the next few sections I'm going to try cover most of these but I'll try to run through them the first important thing about you know implementing security in the organization is about understanding what the known vulnerabilities are right so not go hunt for something that you

that's an unknown unknown because it could probably you know be a widening shades at times but knowing a known vulnerability and knowing a way to kind of address it is really important so in today's development paradigm also we started leveraging a lot more frameworks and these are standardized frameworks so your actual custom code that's written has dropped drastically to about maybe 10 15 percent depending on what can I in your building but predominantly since you're using a framework it's easy to kind of go scan those frameworks for known vulnerabilities and you know so it's it's kind of tricky because some of these frameworks also come from open source and knowing what the open source component is and what kind of

vulnerabilities exist I mean that's important decision that you probably have to make but setting up a process along the way to address many of these normal abilities is always a good way to kind of start I mean using this I mean majority time so you can address all the major flaws that are you know probably in the application up front the next important component is about hardware and software now this becomes really important because what we are delivering back to the customer is infrastructure as a code and software as a service right so you've kind of taken away or abstracted a lot of the fundamental physical you know aspects of application development so you're going

directly into a more coded way of deploying infrastructure so where does that where is that stored it's all in configurations so it's important to understand what those configurations are because what's going to happen at the end is if you have a cloud provider they will be spending up machines and giving to you without any tracking possible so you can't really understand whether you know let's say there's a problem that occurred on system a you the remediation is destroy the system let's move on let's deploy the code to a new system let's bring it up and running and we just basically destroy the old system in a cloud environment when we're trying to scale we do the same thing you know we

want from one web server to maybe a thousand web servers we quickly scale up and down so we get all these virtual ephemeral machines which have no traceability at the end we kind of you know lose them as soon as we lose the machine so knowing all those configurations upfront understanding the baseline OS images that are being leveraged to deploy on those machines is really important because you're supplying all the security construct constructs to that image using code using configurations using manifests so all those things are really important to understand in the tool chain itself in the in configured CI CD tool and that we talk about so all those aspects are actually included now if you kind of go through

CIS website they actually do provide a lot of benchmarks out of processes so and that's a really good place to kind of go look for these resources and many of the tool chains that exist today for example chef you know ansible jenkins and salt and tuffet you know all they have they've simplified the process of rolling this out so you will probably see a lot more capability in these tools you not have to you probably don't have to write everything from scratch so next kind of comes about you know if you have orchestrated this continuous delivery methodology using configurations and infrastructure as a code then how do you go and make sure that these are being

deployed properly so there are certain testing methodologies that are out there which is one is called the blue-green deployment your prime model might have also heard about a/b testing but Bluegreen is really about you have your existing system that's running and then you stand up a new infrastructure and you know so you have a green infrastructure that's a new one so you start to you know direct a little bit of lower into the new one and you keep the old one running as well and you test it out and make sure everything is fine and then you do a final cut over so in that situation you are basically you know providing new feature sets with

literally no downtime so there is no you know the application doesn't even know that you know it's basically being cut over to this new system because everything is now running in parallel and then you sort of gracefully switch over to this new system it's also great for open to early adopter scenarios for example where you have maybe tons of agencies or departments and each department has their own requirements around you know certain features that you want to release so instead of doing a company-wide release you could actually you know compartmentalize that release only focus for that particular department or agency or for that mission so you then you can gracefully roll out to all the other divisions as well so

this methodology becomes much more kind of useful in in that respect as well the continuous one durability assessment and mediation this again is really important because you know every so many CVS actually get released off and on every time and and you want to make sure that is the CD applicable to what we are doing is the CPE applicable to me is there a risk control that is getting impacted because of the CBE you know what kind of container so if you are following regulated industries it all boils down to what kind of regulation is being impacted by that particular vulnerability and is that vulnerability in your system so having this automation framework constantly scan the images based off of those

vulnerabilities and how it impacts your organization and providing your risk assessment a business identifiable risk assessment is really important so that's again where a be testing and blue queen kind of become really helpful and all these scans the more you can shift to the left during the development process it makes it much more easier because you don't have to kind of deal with this as an after-the-fact because apps act typically is a different organization and development is a very different organization so they won't they don't necessarily talk to each other but it is you know if you embrace that wathcing organization it's very important for these two teams to start coming together and even have a champion you know

deployed from security into development so they can actually you know provide those that guidance early on into the development cycle application software security is again really something that is important and most of these tools they are able to provide I'll talk a little bit about this tooling as well but they can provide security assessments and and multiple you know code checks that you can do and you can run through these apps fairly you know on a constant basis it's just a matter of how much noise are you willing to take because every scan you do through an application is going to result into an action that some developer has to kind of go and answer or remediate so

you want to make sure that there's a good balance between what kind of scans you do to how much information is really relevant and our most important to kind of fix you know and typically in a developed environment you're delivering smaller pieces of code there's often a notion of maybe quality can be kind of you know reduced a little bit but that really goes back to the development team and the principles of the development team kind of follows on still providing quality code so it's not saying that you know you have to relax your coding standards but it's about being more cognizant that you would be tracking and capturing these errors of fun and there

should be a way to kind of handle those upfront as well so the charts actually kind of show you like you know somebody leaves an access key in their code base the scanners will actually go and pick that up pretty quickly so this is really important and what happens in infrastructure the code in the fundamental nature of DevOps is that you have probably handing the keys or the King keys of the kingdom to one person or a process for example infrastructure is a code you know the process that's deploying the server is the admin also it has a lot of privileges to actually do stuff if you look at the DevOps paradigm for a developer that developer

is fixing code in production so that person actually has the ability to go and fix something in production as well and we all know from regulation that it becomes really hard to kind of manage that if the same person is kind of doing the both things so controlling those credentials becomes really important so figuring out how to manage that how to secure it is really important so many of these newer tools that are come in they do leverage keys and certificates and there is a process of generating the surge and then rotating the keys and delivering the keys as and when the requirement is there so having those processes inbuilt into your development process makes it much more easier to

develop infrastructure as a code and be able to implement all these automation components that you want to do because if you don't do that then essentially you are publishing username/password out in the open or there is some methodology that is probably not validated and it's not we're going to leave a lot of vulnerabilities into how you know any hacker could probably come in and start using your system so things like hashing core vault and conjurer SSH management so those are good examples of where they actually let you manage keys they provide rotation capabilities as well they give you one time access as well so if you know somebody just needs access to deploy a certain piece of code

during deployment is just that key that expires after the first use so makes you know much more harder to kind of you know hack into those systems or leave keys around quite a bit and also kind of helps not designing a rocket ship like you see on the top that the carton kind of talked about a little bit so this is I kind of came across these guidelines and I think these are really good guidelines in terms of implementing security in your application environment and they talk about pretty much all the fundamental things regardless of it as DevOps whether it's anything it's really good sense that any application development shop should be taken care of so

understanding you know what sequel injection is and what the processes are understanding you know security misconfigurations foundational security hygiene is really important hygiene really doesn't come with a with a piece of code it is really again a practice it's something that you know we clean our house we clean our house because it's a practice and it you know we instill that practice security hygiene for an organization is again something of that you know you constantly have to make sure that you're high valued assets are secure and you're doing the right things to protect your company so there are some tooling that I came across I mean this is not an endorsement for any one of them but I would probably you

know say encourage you guys to kind of go take a check out these tools they all kind of do one thing great and the other thing now some have great UIs and great logging techniques but then the others you know don't do stuff that you really want them to do so take a look at you know these are open sores as well as you know that's available through these big vendors like IBM and HP and others but they all have their pros and cons so overall you know recommendation is you know one thing that happens with infrastructure Zak or did you start treating your end deliverable as an immutable you know component and the immutable component is that once you

validate it once you've figured everything out that it's clean and great it goes out and it's published out in the open for consumption if things have to change you can't change that one you can't change that artifact anymore you have to create a new and immutable artifact and then replace the one that you had published you have to destroy the one that's out there so that's where the immutable concept kind of comes into play again we talked a lot about integration and security compliance testing into your DevOps pipeline that's important scanning is important scaling is really important because it can get really you know busy if you have a pen testing machine and an info SEC team

that's sitting with development and you're doing a whole bunch of code checks the application code checks there's other security checks in your code it could actually amount to a lot of things but you know all these recommendations are important in terms of automation about how users are accessing and so and so forth and most importantly it's also about the culture you know having an understanding of how your application delivery is going to change or what you are taking on as an organization is really important so in closing all that probably want to say is you know security first it's never an afterthought it's I think it's the older dodge we should never stay away from it

and it's again about the culture it's a lot about the culture you know all these policies and frameworks are available a great way to start is you know look at the NIST framework and you know those policies can be converted into checklists and those checklists can be provided to your PMO office for implementation in the court you know if that's a really great way to start if you don't know how to start a where to start you know it's also about what we talked about was how to bring security into the vault and that's where it's important for the security teams to adapt to this new culture of DevOps as well so it's not just about DevOps getting more

control and they're free but then security teams need to come back in as well and the develops teams need to understand regulated environments too they can't relax that you know because in our case as well I mean although we are very new shabi of building stuff but our end consumer is a federal agency and we know how cruel they are in terms of adapt you know accepting any piece of software so ownership is really on all of us to kind of do a good job and test all the tools that are out there and there is a need for best practices although we do see a lot more coming out but using those and making applicable to

your company in enterprise is really important all right so with that I want to thank you for the time and I really want to thank you because

so any questions yes please

[Music] why

so so I have to be honest about those companies I mean that's not where we deploy DevOps as Marlon we are actually managing their hosts and intrusion prevention so we architected and we also manage their large all the endpoint management systems actually we manage them as well so we deployed them we stood them up but then none of these organizations actually have a DevOps component that goes in with it the only one that we are actually working with right now is the homeland security and it's in the very early stages but in that case we are so early in the game we are defining the application so we are defining all the security requirements during the design

phase of the application and we're bringing all those constructs up front on how we want to leverage their valves what the PMO office is supposed to do when we put the tickets together for the roles that people have I mean we made sure that the testers part of the the development team a product owner is available during the development phase as well the security analyst is available during the you know so we had head counts for each of those roles to come in so I think it kind of starts building that culture upfront so in a Greenfield we were able to do that many of these are the deployments that we've done they were already existent or you

know so we didn't have much leverage and we just kind of adopted what they had actually done right yes [Music]

yes I have to yeah I'm really bad at powerpoints although this looks really pretty but I hate PowerPoint and most of my stuff is on confluence I will actually remove confidential and I'm going to produce a PDF and then pass it on yeah oh thank you yeah any other questions it isn't

so do you so the question is like what if the security teams are very far away from the development teams how do we kind of still kind of bring them together it's a question I have is like this development team that you talked about I mean are they already using agile methodology and they've already set up that way okay so I think it's important for the stakeholders to have a conversation and make sure that the the risk of not doing something is exposed across I think that making getting that awareness is first thing is really important I always start with it because that is process you know but if I don't have a standard I can put a process I

can't put a procedure together so showing how this would be important even providing requirements that you know hey we need to know what standards to operate against we need that understanding I'm pretty sure Caesar would be all years I mean they would want to know that hey this is something that he 7 CIO and C so I think they should definitely be very close and most in most organizations we kind of see the kind of channeling up to the CEO so they're both their objectives is really to keep the company safe and operational although their functional requirements change you know after that point because one's on security others are an application of time so but you

know they still have the same you know channel to kind of go up to so I would say escalate it up and and try and get buy-in from leadership yeah ok yes please company not me it is really hard no it's because it's a culture you know because oh sorry so the question is like piggybacking on this question around silo teams like who's the ultimate responsibility on the top I mean I always go back to the business owner right to me a business owner is spending the money and they have an objective in terms of revenue attainment at the end and if they see that you know teams are working in isolation and I've seen that happen in

North Face as well I've kind of seen that that every company every team is given their own funding and they go and do stuff on their own but at the end you know the mission ends and nobody knows whether there was it was fruitful or not so getting that you know focus from the business owners is really important getting an understanding from the development team owners of the development team not the developers itself but the ownership of the of that whole stack and getting those people to talk about that this is how we are changing the company or this is how we are moving forward because we want to align with these deliverables that the

business has it's always a business conversation in my mind I mean most of the time that I'm spending today is really making sure and making the case that I'm in alignment with the with the sales and the marketing and and those teams and the security team so you know we are always delivering a product that sells you know so I thank you very much for for the time again and hope it was useful [Applause]