
good morning i'm dr mark peters from tech incorporation i'm here with agile compliance and risk operations uh talking about some of the things we've done to implement devops some government contractor spaces in the past uh year that i've been employed in those areas i have to remind everybody as i talk about government stuff that i don't actually speak for the government uh program for which i'm employed i'm speaking for myself and my company uh these are my personal views don't necessarily represent any of those other books along the way i also mentioned that i do tend to talk really fast and i'm going to try to slow myself down to make the time moments appropriately
but we'll see how it goes along the way so as all the talks start first we have to move and
i think i've lost my webcam there we go and there we go so who am i a quick introduction i used to work in air force intelligence i spent about 22 years working for the u.s air force i went all over the world and all kinds of different things for different people telling them things they didn't want to know what the secrets were and finding out the secrets from the opposite side of our cyber security working on those opposite perspectives to get things through needless to say working with the government organization for that long i got oodles of experience with compliance practices making sure that the security was in the right place that the tools were in the right place
that things were moving from one side to the other and that all the information got to the people they needed to do so after enforcing those compliance practices for years and years and being on the other side of it i got into cyber security uh and i got into that practice because i spent some time at the nsa and worked with some of their functions i'd work with some of the other cyber functions and i run a couple different units doing cyber things back and forth along the way at those times i got to implement those tools at multiple levels to see how they worked all the way from building your own sets and having them
there and trying to figure out how the computers work to getting those results out to the ops guys so that they could use it effectively do what they wanted to do in the past year that means what i've done is i've worked with two different agile programs your government programs that are enforcing cyber weapon systems for the government and they're trying to build an agile transition their programs for one i worked as the product owner trying to make their pipelines and their platforms work better and for the other i've been the lead security engineer so implementing security all across the way and trying to make those pieces all fit together in a manner that everybody can
use most effectively i'm also a devops institute ambassador if you're curious about devops the devops institute is out there and they talk about the three ways all the time when we talk about flow feedback in continuous learning so i'll mention those later in the talk as we go through uh instant some of my other background just real quick i'm an avid reader i read a little bit of everything i read history i read about devops i read about business i read about sci-fi and fantasy so if you've got any good books feel free to lean out and recommend them i've also done a lot of writing along the way i actually published a book about a year and a half ago called
cashing in on cyberpower where i looked at 10 years of economic attacks for 10 years of cyber attacks and how they developed economic influences all across the world i do have a doctorate in strategic security not in arithmetic but in those reading and writing functions as we move forward so leaping into the talk uh the problem was as we came across as we moved into this new role here as a lead security engineer is how does my security team ensure compliance enforce the standards and still remain agile now this remains a problem for a lot because security is seen as non-flexible as we talked about they look at their own things they don't expand and they don't make this merge
but we want to be committed to the team vision and the team organization in order to do that we have to be agile across the process and that starts with looking at ourselves it doesn't start with pointing the finger at the other side of the fence and looking at someone over there and saying you know what you guys are doing it wrong and you need to fix it to do it the way we do what we want to do is we wanted to fix ourselves so that we could be an example so that we could lean into those things and provide help to those other organizations as the cyber lead as a cyber security lead in the security team we face this
problem daily we go out to everybody we talk to everyone we say you know what can we do how can we help but we weren't getting there because we were making the transition with the government program for what used to be a waterfall program what is now said they're going to be an agile program and in that you still have a lot of the old practices and you have the old ideas and you have the old culture and you need to move that forward and one of those biggest challenges is we're looking at the cyber team is the government that dod that u.s air force sector uses the national institute of standards and technology and use something called
853 which i'm sure a lot of you are familiar with at 853 plus categories and controls and indicators for doing a risk management framework or they call it a risk management framework because it's supposed to guide you in doing your cyber security but what actually happens is you get 19 different families of controls with over a thousand different controls and indicators and the government comes back and says hey guess what we've got a thousand different indicators we'd like you to respond to every indicator with artifacts and examples of what you're doing and how you're doing it and how we move that forward but we didn't want to go there we didn't want to be that tightly tied we didn't want to be
that tightly tied when we sat down with the dev and said hey you know what i need you to answer uh about a thousand questions on how your program is going what you're going to do next we wanted to be in an agile process where we're talking about those four basic principles those four guides to agile where we're talking about people over processes we're talking about working software over uh comprehensive documentation we're talking about moving forward the whole scope of the things and we're talking about using scrum and getting that daily feedback into something that's a uh a very standard process so as we're looking at the problem about ensuring those compliance and forcing standards remaining agile
we start looking at the parameters because the parameters for us are the things we have to consider we have to do because we're working in that government bureaucratic framework and we've got to make sure that we can move ahead we've got to make sure that we can move to the right places to actually accomplish this so we have to meet the standards that they're laying out for us and as a contractor we have to meet the standards that are in our contract as we move forward we have to be able to manage risk and we have to be able to manage risk effectively because in the end that's what security is about it's about tying risk down to
the factor where you can get into the risk and you can find things and then we had to look as always at the third option of where we could buy a solution who could we buy a solution from we just hire somebody else to come and replace us and do the job for us at a lower cost i like the tom sawyer thing where you pay everybody to paint your fence for you and then you just sit back and collect at the end so and looking at our parameters the first as always like we said is to be compliant or agile now what we see is we see compliance or agile is the opposite sides
of the room there's no compromise between being compliant or being agile and that the places that are inflexible in their compliance don't see it any different because we see all kinds of compliance we see the legally prescribed compliance we see the organizationally prescribed components and we see sometimes even internally prescribed deployments what do we have to be compliant with the standard for our organization as we move forward into that setup now this includes something like fits for the cryptographic standards the nist that i already talked about fisma socks for the stocks and the credit exchanges the pci disks for your credit cards uh the gdpr for europe the ccpa that they've implemented in california they're all different
standards many times a lot of them apply many times only some of them apply and many times they're good ideas but they're not formal practices all these compliance standards are usually very administratively heavy there's a lot of stuff that has to be done and they're very difficult to implement and that they're meant to be that way so that you have experts that come in and can enforce those there's a lack of freedom and there's a lot of blockers in those processes but it's not true all the time sometimes it just takes a different way of looking at it and i'd like to think that a lot of the way of looking at that is in those agile
practices as we look at agile as we look at the lean scrum and those types of frameworks that we can get to a devops mindset that we need to a better way to interact those things together and make it more of a loose framework that leads to our high level success in getting the job done but we've got to eliminate that that whole that back and forth on those processes so that we can get to the right area and we can get to the right place where we're talking about the things that we need to do and we're talking in an effective manner about those things we need to do to move forward so we need to be
compliant and we need to be agile in process and being compliant being agile gets to the same spot when you're talking about security and when you're talking about getting security into the practices so that you can deliver effectively on the value for the organization and that means you need to talk about risk you need to talk about risk management and you need to be able to do the math without numbers and that's very contradictory statement because there really is no math without numbers but at the same time you're talking about the various elements of those processes you're talking about the ability to talk about those three elements or those four elements that make up risk and when
you look at a risk equation or a standard risk equation you're talking about rat times vulnerability time or risk equals threat times vulnerability to exposure and we want to lower all those elements but in order to load those elements we have to be able to talk about those almost we have to be able to talk effectively we have to know what the threat is who's coming at us where does it exist and whether that threat is a foreign malware source but that threat is just a loss of business right the threat to us may be that we can't deliver unless we have that product out there the vulnerabilities are those things that exist in our system in our code
in our culture that may cause exceptions may cause gaps in the future whether it's a standard a cve off the enterprise says hey we've got a a break in our program we've got a break in our code and you know it's going to be vulnerable and it's going to be a critical failure unless we fix that immediately if we've got a break in our firewall if we've got all kinds of other vulnerabilities but that also leads to exposure and the reason i say it leads to is exposure is managing risk exposure is one of those key things especially in working with government programs right but you have to be able to talk about effective exposure but
if you've only got a small area and that small area is off-prem and it's behind the number of firewalls and it only reaches out through one way and it only reaches through a vpn that handling it handling a exposure on that backend system may be relatively minimal it may only cause you relatively minimal risk even if some other site like a cve or miner says it's a critical failure because it's so far behind that that there's no exposure to that system that you see so you have to manage all those risks and you have to compare between those risks to be able to manage the structure in a way that you can effectively present those results
as you're sitting down and talking to the devs and talking about your ability to do your risk operations and your azure compliance and that's what we did we said we wanted to be agilely compliant but we still wanted to manage risk and we wanted to manage risk for operations and to us our agile compliance meant that we needed to maintain that compliance without sacrificing flexibility i think earlier in one of the presentations they talked about the inflexible developers well a lot of times security hits that same in flexibility as well that we need to be more flexible and not all of our guys they were kind of rooting the process they're not all good at doing yoga or moving
some of those transitions so the flexibility was in between but we did that agile compliance we worked to get to that agile compliance and we worked to that at the same time to doing risk operations managing our risk and always talking about risk in the same manner and being able to talk about how we were effective in that risk or where that risk structure as we move forward so the third option like i mentioned for us was that buying a solution and everybody knows that you can go out there and buy a solution there's lots of contractors all over the place if you've been in cyber security for any length of time i'm sure at least a third
of your emails if not more coming in are from vendors and they offer a lot of good products and there's a lot of good things out there nowadays that you can get in these product scapes uh that'll help you and they'll help move your process forward and they'll make you more effective and deliver value to your process from the beginning to the end so they fall into kind of different scopes and the first scope is really a who wants to sell method and you get the scaled agile framework for enterprise it used to be scaled agile for enterprise now it's a scaled agile framework uh for enterprise and the government is using that they're using it a lot
they've bought this big framework that goes in and it gives them a structure that they can use when they start talking about implementing agile and implementing a devops mindset to move forward but it does cost and it costs to get trained people and it costs to get the training experience and to bring them in and the next step you get disciplined agile right discipline agile is from the pmi institute uh and i'm a program management professional so you know full disclosure there i've seen discipline agilent's way of again taking that agile mindset and building it onto a structure so that when a big company like the government comes in and says hey you know what
uh i need something and i need a framework but i'm not ready to give up all my culture to get to that framework to get to that agile compliance it kind of kind of helped them along the process then you see deloitte and other companies who will come in uh and they'll bring a consultant in the consultant will tell you everything you're doing wrong and everything you're doing right with more emphasis on what you're doing wrong and tie you in for a long-term contract and it'll get you in the process it'll get you to agile compliance to get you to risk operations all along the way uh so that you can do the right things
uh it makes success and have value in your organization you get overlays itel and cmmi are both great organizations and they both both offer good quality products but still buying someone else's overlaying depending that they're answering the right questions for your organization to move forward in a mix of these is helpful and understanding all of these is helpful and you see sre certifications working with the devops institute that site reliability engineer those are good functions and those are good effective functions that help people do good things and they build in value throughout your organization by having that development from ops all the way through security all the way into depth but you have to be able to
understand what you have to talk about and sometimes that's working through the process first and getting to the first steps uh before you find out that you need an actual asberry certification you actually need one of these overlays from somebody else and then you see people who are just selling experts right i'm not going to give you an overlay instead i'll give you an expert i'll sell you an expert that expert can go into your organization and when they get to your organization they're going to help you fix everything that's wrong with them you see this from a lot of staffing agencies you also see it from government contractors which i can't complain too much because we've come in as a
government contractor although i do have to mention uh in all fairness as we talk about our government contract situation we took over from a previous set of contracts the previous set of contracts for the weapon program we're doing the cyber vulnerability analysis weapon program had three different contracts for three different companies and they had one contract doing maintenance one contract doing sustainment one contract doing development well when our company technical corporation came in we took over all three of those contracts and blended them together which is working for us so far so good as we'll mention some of the other slides but better than the previous three where none of those contracts were willing to talk to each other to get the
maintenance and sustainment development all done in conjunction in time to get to something where they could actually have an agile compliance and a risk operation along the way so how do we discover fixes how do we get there with these problems in this framework around what we need to do how do we find out what it is that we need to fix where we need to fix it and find an effective way to move us forward in what it is and the first thing is adaptive philosophy right it always boils down vaginal and devops in sre that you have to have an effective culture and that means you need to start both small for the culture from the bottom up
as well as from the top down both sides have a culture and you have to meet those cultures in with our security team when we sat down to adopt the philosophy i came in from an outside program the previous three individuals on our security team were already there so they already kind of had a philosophy from that organization from their previous waterfall setup and what we wanted to do was we wanted to move it into that that kind of devops agile mindset and that meant who are we serving where are we building value where are we delivering uh effectiveness into the organization uh through this value philosophy through this devops and the value stream that
goes to the devops as we move forward we talked about first that we have security user storage who uses security right who needs to use our security products who needs to use those security features and the first thought is well the devs are the users right because they actually have to get the security we have to convince them to build the security and we have to convince them to put the security both in their products and in their pipelines uh and in their deliverables so they're part of the user that are using our stories when we say we need this to be effective because in the government in a bureaucracy in a compliance if we don't
do all those things that we need for compliance and an outside organization comes and says hey you know what you're not compliant they can shut us down and they can pull it back and that's not good for anybody most of all the devs because there's a lot of them and because they put a lot of hard work in trying to get the process forward and trying to make it work on a daily basis so what do we see about the devs well the devs also have their user stories right and they see security as an enabler so we have to work through that mindset that we enable them to do more effective things uh when we give them good security we
allow them to deliver more value uh all across the way with those effective things and how do we get them to talk to us on a regular basis how do we integrate with them on a regular basis uh and that has to be part of our mindset too security historically in a waterfall sometimes has a bad reputation or a bad experience of constantly being known but being the culture of know that we only say no because we're just trying to get compliant but we're not really just trying to get compliant we're trying to do the things our value for us that our organization has told us value but we need to integrate to get past that process
to get into the place where we can do the good things for everyone and then we have a product owner store right the person who owns the business the customer who's getting that end goal value from the entire stream uh and that has to be the compliance adds value we have to be compliant to add value and they have to value the new things of compliance and the new security and that agile compliance that comes in through that security is just as valuable as putting in a new feature that new feature loses value if you don't have the security and compliance built in all the way across the process to get you achieved and we started to do
that when we were thinking about it but how do we manage risk how do we operate through risk instead of just saying we're managing we want to talk about risk operations because we want to talk about this change in the cycle in this process that goes through to be able to effectively talk through our risk processes with a number of different people and a number of different factors so we have to be able to manage multiple users we have to be able to manage multiple users all the time in order to manage those users we have to be familiar with those users part of that is integrating into those teams and making sure that we had security
reps in those teams a lot of times i'll tell you about security champions and using a security champion designating someone to represent security for your team and that may work as you get larger and larger but when you have small teams and only a certain number of deadlines i think it works better to get your security team in there every day i get the experience and get the face-to-face and we need to be able to suggest those solutions in those face-to-face experiences by uh talking without leveraging right we can't say this is what you have to do and if you don't do it we're going to shut you down we're going to cut it down right here
instead we have to listen to what the developers are putting forward now what they need to do and suggest how they can find ways to make that go through compliance and how they can make that compliant in the process and hopefully that gives us some long-term success with the short-term compliance and that having an effective process and having effective people that are integrated and they're talking to deliver functional software helps us meet the compliance all the way through so that we can do this easy things in small steps and then use automation to round those up together so we can meet those compliance standards at the barns with our thousands and thousands of controls
so what was our security team problems and what were some of the solutions along the way so with a new contract the first question was where do i start right what occurred before we came in we came into this new government space in working in the government space our first problem was access a lot of these government programs are blocked when you see that you have to get access to the government the government wants certain things to be filled out before you get into those spaces you have to have the paperwork you have to have what's done i always say and i always work that when you work with programs when you work with software when you work
with any process really in any type of operation change creates error but indecision creates disaster you have to be able to make the small uh changes along the way to do things you have to make small decisions in small increments and without the access at first without the access to the old compliance standards that was what we did we went back to the basic security practices we went back to the basics of what was happening how was it happening were we making sure that we were doing the right things we have all the users integrated we have all the users uh passwords we have the secrets protected we have our facilities not just locked down but
blocked out in certain ways that we can make the standards
so we were making these small decisions into these small increments along the way uh and then the next step for us was do we understand the tools at hand do we have the right tools in the places the government came in and processed it to us that we were able to do the right things and that we saw them as effective in the process so we had to challenge the old models because the old model was waterfall and the waterfall development of being able to deliver in five years was no longer affected so we had to look at the new tools so that we could get new cycles out we could test the new tools
we looked at things like di2e which is a framework of developer defense intelligence integration to enterprise uh trello which is the boards for workflow clara which is a container standard sonar cube which is a code scanner a sas tool a static analysis security tool on salt stack it's integration management we were finding ways to integrate those we were finding ways that we even used that we shifted from a jenkins to a git lab in the earlier formats so that we could get more pipeline built in and more that cicd framework uh built in along the process but some of that was learning for us some of that was learning that the security team had to go back and
challenge their previous assumptions and sit down with the devs and say this is what it is and this is what we're doing this how we use it i can't even mention with gitlab that gitlab is a great tool we love using gitlab but uh one of our first debates with the guys over gitlab was that they said hey we're going to gitlab we said that's great uh when you move from jenkins and you're moving out to gitlab gitlab has these great security dashboards we want to see those security dashboards we want to be able to get those metrics and look at you and use those metrics right because those metrics are great those metrics will give us so much of the security
compliance information that we can automate and we don't have to go bug you all the time for this information and the devs came back and said yeah that's nice but we only bought the bronze package and the bronze package doesn't include the security dashboard so you're gonna have to wait till next time uh so instead we have i mean we're still working through a process for that but hopefully we'll be able to get some more success with it along the way and at least we've got our pipeline metrics and with that pipeline we've got the tools in the process right so talking through how you get to that agile compliance if you can go through
to that compliance guy and you can say hey in that compliance with the tools i've got i get every time code gets checked in i get a number of scans i get a number of processes i get that that static code analysis at the beginning and at the end i get that dynamic analysis of how it goes into the platform and i get the scan of everything that's matching up as well as i get a stig which is a government framework for a secure technical implementation guidance it tells you all the things you need to do with every tool to make sure it's compliant so you use the stakes did you apply all the stings
affected we can go and say hey not only is this being done because you came in audit but we're doing this for ourselves and we're doing it every day uh and i've got this whole stack of data so that when the auditor comes in uh i can say i've already got it for you right it's already there uh and it's what we have and that blends into that next part can you see what you need to do are you able to work transparently and communicate often uh again we see security a lot of times a lot of old security practices what happens is that security comes back behind a blocker behind wall nobody wants to talk about the security
nobody wants to talk about the vulnerabilities nobody wants to talk about uh what's wrong we don't see it as wrong but it is potential for fix it is potential to improve and to do better by being able to work transparently we have to be transparent about what we're looking for just as much as we need them to be transparent about what they're working on and what the factors of them actually working with that process are and that's part of that communication often how do we get to a process where we communicate often enough um that we get what we need and not only that the developers keep thinking that we're involved and embedded in those teams
and right now we do we have somebody in one of their teams every day we have four or three development teams and an engineering architecture team and with four security guys we have one person on each of those teams uh every day sitting in their screens offering them advice uh when they need it because a lot of times they don't need it a lot of times they can do their own thing but then taking that information back and building a consulate consolidated security picture of how everything works along the way so this leads to the next step which is it's not just about us right it's not just about my security team it's not just about that development team or this
ops team or that functional underwear we have to have a organizational solution we have to be able to make the culture change both from the top up in the bottom bottom up in the top down to deliver a process where we can build those good teams and we need to be able to work through those through that leadership structure all along the way and that's a challenge and it's a challenge for a lot of people but if you invest in the people and you harvest that process you harvest the good things that come out of the people because it's people over processes but you have to have the right people and having the right people build processes
along the way you have to take the people first and know that the developer is important and that person is important and that lets you get to the point where you have a good process by working through there and building a team that depends not just on their own team but that every other team is functioning along the same way so we talk about being able to integrate we talk about being able to beat the street right now i say beat the street because i had a good senior leader come back to me one time he mentioned that uh somebody asked him why he repeated the same thing over and over when he did talk they said they'd
seen him talk in three or four different places and he said the same thing every time and he said the same three things every time and his response when he came back was that ten percent of the people who hear me hear ten percent of what i say 10 of the time they said he figured if that happened he had to say the same thing 30 times before he could effectively depend on one person hearing him once uh and the same thing applies to security and same thing applies to develop when we go through and we want to talk about security we need to say the same thing and we need to be on the same
message if we're constantly changing our security message and we're constantly changing how that security message is going to affect value then we can't manage our risk and we can't be agilely compliant because somebody will hear a different thing every time we get there and they've got a lot of stuff to do just like we do the devs have a lot of things that they need to take care of so if they only hear part of the message part of the time then we don't get to an effective security platform along the way and that translates into building transparency as well having that transparency all along the way being able to visualize workflow and be able to go and see what everyone
is doing keeps you from having to track that person down and say hey i need you to tell me because you can see it for yourself and you can see it from the beginning to the end of the process across the pipeline and that's a lot of what that flow and feedback is in that devops mode being able to have a clear flow and get clear feedback all across the step and that's what we're working towards with this agile compliance risk operations and then we need to be able to link items and tasks you have to be able to take the item and when you see it know how security fits it and know that security is part of it
all the time just like the operation of it having those acceptance criteria and those definitions are done built in across the way that let you get where you need to be by linking those items together and having a backlog of what you need to get to sometimes security is not the most important priority i know that sacrilege a lot of people on the security teams i know that's sacrilege a lot of people have worked it but sometimes because of that exposure because of that risk management you can put security in the backlog and it can come up the next time or the time after that or the time after that it has to be done before
compliance but what is your compliance framework when is somebody else going to check and what is your risk if you actually let that security go and say hey you know what we have a ci cd i'm going to fix it the next time because it's more important to get that feature out now and that leads to the prioritization how do we prioritize those things along the way for security so once we have the organizational solutions what are those takeaways what are the things we learned from doing this uh all along the way as we're moving our process forward uh and the first is practice practice practice right uh agile is a skill agile compliance is a
skill security is a skill coding is a skill uh there's a great paper by a gentleman named malcolm gladwell who's written a lot of stuff on the process uh it may actually be a book called outliers that was written in the 90s one of the things he talks about was the number of times you have to achieve deliberate practice to be considered good at something and those numbers wind up looking like 500 times you have to be able to repeat it 500 times for familiarity about 5 000 times for some basic level of competence about 50 000 times for mastery and it has to be deliberate practice which means you have to concentrate on those right things that you're doing
to be able to uh move forward um and it's difficult if you think about doing the sprint if you think about doing your your basic scrum meeting that you do every day you spend 15 minutes doing every day and you probably do it 280 times a year if that and if you need to be able to do that 50 000 times before you consider you're effective at that you really have to practice you have to take advantage of every opportunity as an opportunity to practice an opportunity to get that continuous learning from that third way and move it forward so we practice we practice a lot we try to talk about what we practice when we practice
through our screens we practice through our retros and we practice through our reviews of what we're doing so that we can find a way to get to the agile compliance and this risk operations and then we say through that as we're learning we never stop learning we never stop learning about how we manage our backlog how we prioritize and why it's important to prioritize and that's the integration of people that's the communication along the way that actual communication that you have to get there and value those people over processes you have to value change over a plan a compliance is a plan and it tells you to do one thing but we want to value the change so how
do we change to meet the compliance to manage our risk and be able to prioritize and through that we take the time to innovate and adapt our processes so they fit better the next time and they fit better into the things that we're trying to do as we move forward and i can't see ah there we go and the last one is we have to advocate i talked about advocating b will be the street you have to constantly go out there and convince others if we're not doing it ourselves if we're not enthusiastic and passionate about the process of our security then we're not going to be able to convince other people right because everybody's passionate about their own
they're passionate about what they're doing it's building that passion into a broader view that we're passionate not just about our thing but we're passionate about delivering value to the organization we deliver that value through convincing others that compliance is a good thing that getting to this agile compliance that it's not going to slow them down security is not going to break them but it's going to move them forward to the right pieces that they need to deliver success uh all along the way uh and with that we have to build relationships over processes i mean that's agile one in pro building those relationships takes time and building those relationships in a secure manner takes time
so that they trust us as experts that they trust that we're coming to them with the right things that we're coming to them with the right notes and as we have those notes we're moving forward and doing our things and sometimes that means doing the compliance stuff behind the board right they want to talk about having a demo they want to talk about having what the next functional software delivery is and all you've done is address how they've done the controls but when you've automated those things you've taken that work off of the development plate you've taken that work off of the coding plate your success is that you've given them more time to do the functional software
uh and granted that doesn't demo well uh but it helps to build the relationship when you come back and say hey you know what we're good and you don't have to do it as often because we've done one of these things and so as we move forward from that one of the things i like to talk about is being king for the day right everybody likes to think about what would i do if i was in charge how would i make things better immediately what would i immediately fix to make it to the next step to make sure that we were actually compliant that we managed our risk that we were delivering effective processes for the way and here move security
processes and i want to move security processes to the left i want to move as much to the left as possible and i want to move them to the left so that i can integrate software so i can make things quicker so that i can allow humans to do more human things because we're automating more things along the process and that automation is key in getting those results in being able to flood the uh the auditors or the inspectors with the degree of data to which you're doing these things we talked about being able to do a continuous integration continuous delivery but part of that is continuous monitoring that everything that comes out of that
pipeline delivers an artifact and every one of those artifacts has potential uh security value or not security value but compliance value and being able to manage those things to show compliance all the way across the process and being able to understand what's coming out of your pipeline to show that process uh to expedite that security and onboard the people effect uh the better i can integrate the better i can move the security to the left uh the better process i have in getting the right data in the right place at the right time i had a story that was sliding in mind but we continue moving that that pipeline up and that's the speeds up in the pipeline
to get our our process in the right place where we need to go then next we want to be able to move 30 checks to the right so both as we say move security to the left we want to move security to the right because we want to have compliance as acceptance criteria right we want to have security to the right to the fact when they're done they're thinking about it and saying hey i'm done and this is good because it includes security it includes security all the way all the way is the process is being done how do we get the the devs to include that how do we talk to them enough that
they think about security as part of the process they think when they want to include something they come to us and say hey i need to include this and i want to have security and that talks about trust and that talks about people that talks about interactions you used to hear ronald reagan talk back in the 80s you used to say trust but verify you have to trust but verify so we trust all our developers we trust that they're going to do the right things and we verify through the tools and we verify through that knowledge and we verify through scans one of the processes we put in is they do all their scans in the pipeline
and one that when they've done their scans and when they've done their checks and when it's all done and it's gone into delivery we're ready to pull that into production the next step is we go back and run our own scans against it we run our own scans in the process is it sitting in production waiting for that next poll so that doesn't slow them down it doesn't stop them but it's a verification that we verified that our process is matched up against their process and you know what the numbers they got from their tools are the same as the number weeks numbers we got from our tools and that's how we do things effectively
that's how we do things uh in the right way so that we make sure that security is doing the right things and security is doing the right processes and those are integrated processes those processes take everybody those processes take uh the right value to build value for the organization to stick to our goals to stick to our vision move uh one of the personal pet peeves i have is you always talk to people when people say the meeting is boring meeting is important i want less meetings i don't want i don't want to talk all my meetings are boring in a side point i don't think any meeting is boring i don't think any meeting where i can go
and learn something from the people there and being able to interact with the people there and create value and create a process is boring if you go into the meetings if you set an agenda for the meeting or if the person has an agenda set then you can get effective things done through those meetings you can get an effective process and you can learn about the people and you can get better interaction you can get that collaboration you need you can get that change you need by talking about effective things and that ties into the other half of security that no one's issue is ever unnecessary a lot of people i don't want to worry about your issue i
don't want to worry about your issue just like no meeting is boring no one's issues are necessary everybody has a reason they are putting their issue forward and they have something they need to get done and something that's valuable for them you need to be able to recognize their value and you need to be able to prioritize but you need to address across the entire scope of those factors but there are things that we get done to make things happen in a way the best measures everybody and best helps everyone uh to move forward so we try to address everyone's security concerns we try to address everyone's security concerns along the way and make sure that we're talking about
how those things work and what they have and what they need and what their goals are um one of the biggest pet peeves is people will run in and they will go hey we have this uh this new cve just popped up and we have this critical vulnerability on one of the systems we use and or one of the systems we're planning on using and it's back behind all these vpn firewalls but we haven't we have to patch it right now so well if you want to patch it you know we know what the patch is do you have any capacity passion they say no we can't patch it for three sprints but it needs to be patched right
now and this is a security problem so well you know we've kind of already had that discussion if you haven't prioritized it you don't want to prioritize it to right now then it is a security problem let's talk about it as a security problem let's put it on our compliance center but we're not going to fix it for three sprints and if that's what we work with you know that's what we work with as we move forward so we have to address everyone's concerns and we can't be uh dismissive about it uh one of the other frameworks we have in that same type of mindset one of the things that's happened to me on occasion
is our engineer comes up with the same type of question right he comes up and says hey we've got this great big cbe and we need to fix it we need to worry about it and you know what uh the security guys aren't doing a good enough job you guys need to be out there threat you need to be looking at the new malware you need to be looking at how that stuff is coming at us you need to be talking about our the new threats and the new vulnerabilities of the new processes uh in our conversation back a lot of times it's hey we talked about having these the secure technical implementation guides right these
basic standards of security that you need to be able to do and you guys can't get to the basic standards and if you can't do the basic part that we've been asking for and i understand that you prioritize we have functions that we need to deliver but if the basics can't be done how do we get to the advanced part to move forward and that's that deliberate practice again that's working on those silver practices working on those deliberate practices all through the process so that we can manage our risk on threat exposure and not just vulnerability not just talk about where it's open but how do we reduce our exposure how do we reduce that attack surface that's out
there so we can manage our threat so we can do our risk operation so that we can become agilely compliant and we can move along the way so i know i'm short of a little bit short of my hour time but i do have some questions so this is me this was agile compliance and risk operations there's some of my contact information i'll go back and i think i've got questions in a reverse order as we look at them so the first one is any framework recommendations for standing up an information security uh assurance program uh obviously there's good things for infosec all along the way uh being a government guy being a lot of
time in government let's just move the window and create christ from the third application there we go this should be all clear enough but if there's recommendations i i like nist because i've been in the government it's kind of overdone but at least it gives you a good friend gives you some good discussions for how you stand up and how you think about uh what the risk is and what the vulnerability is uh being an intel guy i look at vulnerability as well and i start with some of those vulnerability questions and you start with things about um how do i know once you know how do you how do you prove that if that's true or what do you
see next and if you see something next uh the next step is what are the assumptions that you need to make that true so nist 853 as i mentioned earlier is a great one for sending up that initial information security assurance program i'm sure if you look out there there's a lot of different things sans institute has a lot of good stuff about how to stand up an information security program and work through so i work back through [Music] questions working security found tools that assist you in the process there are all kinds of tools that will help us automate sonotype is a great one it will do things we have been working with salt to get a demo
extensively because salt will do a lot of the automation for the infrastructure and we'll find ways that can automate the infrastructure but not just automate the infrastructure but automate the configuration management to do some of those tedious processes of keeping track of versions keeping track of updates through versions keeping track of um the compliance and the policy associated uh and not only that but we've talked with some of the users themselves who've been fairly happy with it and they can put it in and we'll institute a baseline configuration on their system and track and return everything to that baseline configuration and once it does if they had a custom configuration they can move it back and change it back
to what they had as that custom setup and then you just manage it through that type of process um the yeah the tedious security checklists are long i mentioned nist 853 there's 19 families there's over a thousand controls uh some of it is just being able to talk and having your folks be comfortable with you that hey you know what you really don't have to answer all those questions or in looking at those questions and you being familiar with those questions you can talk to the security folks about how do you automate the tools in the pipeline they give you artifacts that answer those tools for you so you can just pump those those answers into those checklists as
you move forward uh quantifiable details in the federal fiber space some of the kpis related to compliance risk management communicating the effectiveness of scaling agile over waterfall well so one of the biggest difficulties in the government space that we see is that the government wants to be waterfall they have a large bureaucratic process and they want to be agile when they say hey we want you to be agile we want you to do this devops thing and that means you're going to deliver our our new software our new functional software that we're really excited about and you're gonna deliver in three months right so sure great give me a full devops way to go we'll
deliver your software in three months you give us all the resources we'll grid they say well that's great here's all the resources but by the way here's all these paperwork standards that you need to meet while you're doing the resources here's all these bureaucratic things that need to be answered while you go forward so we go into agile we go into this process for our own program and they say hey we need you to be agile we need you to start delivering we need you to start delivering good stuff but one of those first things we need to prove that you're agile is we need a 150 page system engineering management plan that describes exactly how you're
agile in every phase of the process before you get a process up and running so that is difficult when you manage it obviously the the kpi the key performance indicator uh to compliance and risk management is just that we're doing it that you're making process that you're getting there that you're getting things like scans done that you're getting things like uh integration done uh i mentioned we took over from a previous company the previous company had the contract for about three years in that three years they had not delivered a a single release uh not one they were still working on the same version they had when they picked it up three years previously in the nine months our company has had
the contract we delivered our first release our first update they're not major releases right minor releases is what they're calling them uh about three months in six months after that we delivered our second release about five months uh and we're on our way to delivering our third release uh here in the next month and a half um so while we gripe about all the small things that we have and all the problems we still have the fact is that it has turned into functional software and in addition to that functional software with the compliance we went into the process where we have scans in the pipeline previous was doing development work but they weren't doing a pipeline they
weren't doing any type of ci cd pipeline and we're typically doing insect management now every time the code gets checked in it does a full code check it does that full stoner queue with that that static analysis and then we use a tenables a cast framework to do scans on the overall integration to making sure that it's compliant with stigs and cves at the far end and those scans come every time code is checked in and then built on a nightly basis and then we do those scans on a monthly basis to go back and check that what we're building actually matches or the the scans we're getting from the pipeline actually match the scans we've got to build
so those are some of the kpis we use to move forward at the fair risk management i don't think i've seen the fair risk management framework um i will uh look it up and take a look if you want to get me email i'm happy to give you a response back i've seen a lot of stuff and a lot of risk management boils down to that same uh for me that that threat versus vulnerability versus exposure and there's a lot of things we can do along the way to get there and a lot of things we can look at to manage those individual risks but when we look at the risks we still have to manage them effectively
we have to manage them effectively based on our organization uh as a devops ambassador i have to say it manages value right how do you deliver value for your organization how do you get security to a place where you deliver effective value in moving forward okay
so how do we approach organization we're senior leaderships focused on delivering agile with no regard how their organization is currently structured for delivering software how do you approach these conversations uh well when the senior leadership is your boss obviously you approach them very carefully um and that has to be the key and i think it goes back to being the advocate and saying the same things over and over a part of that agile is that transparency and you need to be able to approach them and say hey look you know what this isn't working uh and when they're not willing to change then you kind of do the best you can sometimes uh or you offer different suggestions
i've had a lot of good luck with boston's in the past but instead of saying hey we need to change this and we need a plan for you or i need an approach from you is to suggest um you know here's what i think here's how i think we should do it uh what do you think about that can you give you some some input on the changes and making process that way if you can't agile should not be as defined by the organization structure is by the cultural mindset if you're talking about how you hand off information from one to the other as was a process of reducing the number of handoffs that you have or the dev ops
process of reducing the process that you have maybe one of the suggestions would be if you look at a the sre programs or site reliability engineer to streamline some of those things maybe implementing or enforcing a site reliability engineer could help you get the champion to make the changes where you needed to make the changes uh i talked to her at a speech last year at devsecops up in austin one of the individuals talked about having a batman having a batman on their sock team and every time the guy came in it was bad you called from the outside to get somebody you got back whoever was there for that week was batman right and it's the same type of thing with sre
that you have an individual whose job is to make things flow better and that they do the restructuring they present the restructuring and they make sure that things flow through or they just take it and they walk it from place to place to make sure that things get done and the way they need to get done and i think as you increase the value you've gradually convinced the senior leadership that the agile thing is better and that you're increasing their value when they give you some space to do these type of things uh as i mentioned with government uh one of those challenges is um when they implement devops for the first time and i've been in the two different
organizations i've seen it twice the first thing they really need to do is they need to say all right you're going to be agile we're going to do this thing and we're going to do this flow with devops but here's your first three months plan your sprints but i don't need anything delivered right i have no expectations other than that you build your teams you do the bottom up organization you figure out how your teams are going to work and figure out how the process is unfortunately a lot of organizations don't have time for that but it does speak to the effectiveness of creating your own dojo where you can focus on those things where you can
bring the people out for a while or bring a team out and have them focus on a very specific thing which is training and learning how they should interact and learning how they need to interact with other folks um somebody tell afterwards we uh i don't think i have any more questions we'll move things over to the uh the other track we'll move it over to track two if somebody has any more questions for me i'll be happy to take them there i'll be hanging out thanks again to b-sides for giving the opportunity i really enjoyed the chance to speak uh hopefully you all enjoyed it as well um and i will return it to the uh
the present so that he can have control and he can out the next person get set up for their presentation thank you very much i appreciate your
time
you