Mark Peters – Agile Compliance and Risk Operations

Many organizations attempt adopting dev ops and agile practices only to crash against a compliance wall, but it really shouldn't be that hard in actual compliance and risk operations. Mark Peters with Technica Corporation will share his experience incorporating an agile workplace with US government compliance. Good morning, I'm Dr.

Mark Peters with the Technica Corporation, I'm here with the briefing as you compliance to risk operations at GitLab Commit 2020. Excited to be part of the conference. Excited to be part of the you belong here.

So I'll offer you the standard government caveat going in that these views represent me and not my corporation or the government as a speaker. They do represent the team and the team that I was working with over the past several months and some of the things we found as well. So with that, I'll jump right into it and talk about the government contract.

So first, a little bit about me. I used to work in the Air Force. I retired after 22 years in the Air Force's intelligence operator, which gave me a lot of experience with compliance practices and compliance.

All levels I've seen points to the personal level. I've seen compliance at the security level. I've seen compliance with flight operations.

I've seen plenty of cyber operations. So I've had a lot of experience trying to make compliance work, dealing with the various checklists that the government wants on the way with that, in looking at cybersecurity at built and implemented at all those levels as well, I've worked to the tactical level of working with fighters. I've worked at the strategic level working with national agencies.

But in the past year or so I've worked with two different government contractors. So they've both been trying to attempt an agile transition into a government program in trying to bring that program out of that government waterfall mindset, more of a flexible mindset that we associate with Agile. I was when I was a project engineer.

Now I work as a product owner. Now I work as a lead security engineer. It's more of a grasp on how that security has to roll and overall how we have to do our development work in compliance with everything else.

I'm also DevOps Institute Ambassador. I can just talk to a lot of great people at the Institute to learn a lot of things, which is where I get a lot of these practices from just about me. I'm an avid reader and read a little bit of everything, sci fi fantasy.

And then all the work related stuff along the way, I did write a book about cashing in on cyber, looking at our cyber power, looking at 10 years of economic tax, and I have a doctorate in strategic security and not in arithmetic, but it was good at the time. So with that, I'll jump right into our story about why we belong, how we fit our security into belonging in our overall team. The problem that we were facing as we sat down and we looked at this program, we were coming to, how does my security, my small security team four people on the security team, reference about 100 developers or so in the probably about 40 or 50 out in the .

How do we ensure compliance, how we enforce those standards, how do we remain agile along the way? So we face this problem daily because we want to be agile. We want to be more flexible.

We don't want to hang in a corner as the security team. It just kind of be there and be the standard of offering. No, every time we talk, we want to make the developers work and create value for the overall product.

So I'm looking at this problem, looking at this problem, looking at this problem. We started to categorize what it was that we needed to do to be both agile and compliant. And we saw that we had the next eight hundred and fifty three, the National Institute for Standards and Technology that the government uses.

So with that, they had about 19 categories of control families, and with those they have about a thousand different indicators. So instead of looking at those indicators as risk management, the governments, those that you have to answer everyone and in answering everyone, you manage the risk, which is an ideal solution for administratively heavy organization, but not so ideal for agile. So we had to match that into Agile.

We had to look at our four principles of taking people over processes of delivering functional software. And we looked at our scrum guy to move us forward. And then we tried to categorize the problem because looking at that is a problem that people trying to solve for a long time.

So we try to standardize parameters and we came up that we needed to standardize through those standards, through business standards. We had to be able to manage risk. And then, of course, we had to look at whether we could just buy a solution, whether it's somebody can already solve this problem for us and we can move forward from that point to the next step.

So to be compliant or agile as we move forward, compliant and agile are normally seen as opposite ends of the same rule that they pull on each other. You can be one, but not the other. If you go to Agile, the thought is you go so fast that you're not compliant.

If you try to be compliant. The thought is there's so much standards there that you can't be. Actual compliance is normally seen as a legally prescribed method, something someone comes in from the outside who has no idea what you're doing and assigns this to and tells you this is what you have to do.

They say things like FIPS, FISMA, SOX in various other degrees of various standards, whether they're organizationally prescribed in terms of what your organization or your group of organization tells you to do or their government prescribe where the government comes and tells you, hey, you have to do this because the statute we need to be careful because we want to protect people's privacy. We want to protect their situation. So we see a lack of freedom.

And blockers in most instances and the other hand agile, we see things like Lean, Scrum and DevOps, things that are moving faster, that are bringing people together, that are trying to work and trying to create value throughout the entire organization and delivered to the customer as soon as possible. The more of a loose framework Or guide and a culture than that standard. Step by step framework that you see compliance.

This can lead to high level success. But sometimes she's getting the job done at all costs and sometimes people feel that being agile drops that compliance behind. So we have to deal with risk in dealing with the government.

We work at risk. We look at risk and we try to look at where that risk is. We have to be able to talk to our customers about risk because ultimately what compliance wants is to reduce the risk of your organization.

They want to look at something that's a threat. They want to take that down. They want to minimize the risk as much as possible and say that because we're compliant, we reduce the risk.

Therefore, we're safer. Therefore, we're creating value for the customer. So in order to reduce the risk, you have to know the elements.

You have to look at the various elements. You have to look at where risk becomes threat, times vulnerability, times exposure. And that's a little math that we have.

But I don't like using the numbers. So we don't use the numbers. We talk about those things.

We talk about those things in combination. We talk about how a new threat or new vulnerability creates that threat, creates that risk. Then we talk about whether or not it's exposed.

Obviously, if your firewall is behind multiple other solutions, behind a VPN, behind connections, behind two factor authentication, behind other security rules, you don't have that exposure that you would for a Web API for being out there in space, that everyone could see it. So how do you manage those things? How do you make that it's awareness and not trying to reduce everything to the lowest element possible, but to work through the compliance to the various elements and get to the place where you need to be in order to move forward.

So in our agile compliance and our attempt to deliver a compliance, what we wanted to do was we wanted to maintain that compliance. We want to make sure that we answer those new standards without sacrificing the flexibility and find a way that we can do that. And we also wanted to have a risk operation, like we wanted to effectively manage multiple risks across the way because everybody has their own risks and everybody has a different set of security.

We have to understand everyone's risk because everyone's problem becomes necessary and they come to you and say, I've got this new vulnerability. It just popped last week. You came out on CVE list.

And, you know, you need to take care and we need to be able to say, well, it's great to understand your vulnerability, but being agile, we're going to deal with that at a time. And right now we think we've got limited exposure. So how do we look at these things?

How we break these things out in a manner that we can deal with them and we can deal with them effectively to manage a compliance risk? The first step, of course, is looking at who wants to sell us methods, who's out there that can already offer us a method to do things. And we see skilled, agile for enterprise.

So the skill, natural frameworks, we see that somebody already has a solution. Are they at least they have the steps of the solution. But you still have to implement those solutions and you have to find a way to work through agile.

You look at disciplined, agile, which is the program management professionals view of agile and how they make agile work in a framework for them, how they make agile work against a standard five characteristics of the program management, how they work it through the steps in the families. And then, of course, you have companies that want to come in and just sell. You bring you an expert and show you the experts say they'll come in, they'll fix all your problems.

I'll give you all the solutions and then they'll leave you with the problems to fix on your own. Today, we have to see overlays. A number of companies that were in the overlays are great.

They can be good things. And depending on the level of the journey that your company is at, depending on how much you belong to the overall process, those overlays might work because we see things like the I tell overlay and the frameworks that they use in the CMMI, my site reliability engineering certifications that help you and help you answer the questions of those processes again at various levels, because you can always get a company to come in and use that certification for you and associate your maturity overall. And then who wants to sell you?

Just experts. Who wants to give you an expert for your organization? And in full disclosure, as I mentioned earlier, I am a contractor for a government organization, for an organization that contracts to the government.

It's applied as an expert and one of those positions. So we've kind of already gone that route. So we've already kind of made this decision.

But still, the next step is how do we get to that agile compliance? How do we move ourselves forward? How do we find out what those fixes are for us and angels of our culture?

So first we had to adopt a philosophy because the government is very waterfall heavy and has been waterfall heavy for a long time. And they do have reasons to be waterfall happy, because for a lot of times the stuff is important. It matters to people's lives and it matters to the defense of the nation.

And they wanted to be careful about everything they put out, that they didn't want to introduce vulnerabilities and they didn't want to introduce exposure. So they came back. But we looked at our philosophy for our security, for our local team with the constraints of what we were trying to do for the government.

And we look at it as a security user story, who uses security, who needs to use security. And in talking about that, we decide that our debts are useless because they need to have secure products. And if they don't have a secure product, it won't create value for the customer at the end of the day.

And then all the work, however, needs, however exciting, however creative they get, doesn't get that value to the government. And we looked at our devs from their perspective, what was their use or store, and they saw us as enables, so we had to be enablers. That means being part of the process, being get involved with them, understanding their terms, understanding their language and talking to it.

And we had to talk about the product, her story, because compliance adds value. How do you get to the right compliance and how do you make sure that you're compliant? I can go back to a story back a long time ago on my intelligence career where we talked about compliance and I was working in an active operation and found out that one of the terms wasn't defined in a way that could potentially threaten our overall security and our overall national security.

And so I turned it off and sure enough, 10 or 15 minutes later, I had something finger poking at my chest saying that I turned it off and I was risking everything and it's threatening the whole process. And we needed to get to a better place. I needed to find a way to rename it.

We did and we worked through it. But we found a way that was compliant, that was compliant in a hurry to get to that place because that compliance adds value to make sure that we're doing the right things. And with that, we need to manage multiple users through a risk operation.

Everybody who comes in every different dev has a different risk and they want to manage the risk or they may not want to manage the risk. They may want to produce the product. But we need to make sure that the product as risk in a careful, measured way to the entire structure, that we understand how that fits into our agile inwith that we suggested solutions without really having leverage, because, as we mentioned, security team that devs are the users.

So you really have to suggest a way that allows them to get to their end state or the ops guys to their end state without. Compromising what they're doing without reducing the functionality of their feature as we move forward. So while we're shooting for long term success, we're looking for short term compliance because we're trying to be agile.

So we're trying to manage that compliance in small bits, in small pieces that help us move forward. And part of that understanding, part of being able to move forward in small bits is being able to understand the tools. When we jumped in the government, we try to understand what tools we have in what's there and whether or not the right ones, because we want to know if we can use those tools.

We can take those tools to challenge the old models, to use those tools, help generate transparency along the way, help us get involved in the screening process and security, understand what the developers are doing without having to get in their faces all the time and tell them, no, you just can't do it. So we looked at the tools we have. We'll look at testing new tools.

We looked at D2IQ for Kubernetes, we looked at Trello for workflows as opposed to the DI2W. That's the defense intelligence that we use for workflows through Jira and Confluence. We looked at Klar for containers.

We looked at SaltStack for automations. We look a lot of these things and we look at these things all the time because security, we want to know what the newest tool is out there and not just from a security perspective, but how do we integrate these tools in a way that makes the process better. And we actually, because we're GitLab Commit 2020 people after we did start using GitLab, we instituted a GitLab from Jenkins' for CI/CD.

We took that pipeline. We put it into place. We put Sonarqube in place for code scanning.

We put ACAS at the other end to do our security technical mentation guidance that the government likes and CVE scans on kind of a nightly basis to make sure that we're working on those processes through. But in all fairness here, with that open transparency, when we started talking about moving from Jenkins' to GitLab, I started looking at GitLab and I started looking at all those security tools that were out there. I thought, this is great.

Everybody's going to be transparent. Let's get be involved. And I went back to our Devs and I said it's great we can turn on all these security features.

Got by that package. So you have to talk all the way along the way. And we try to talk about the right things.

We try to talk about security, but that transparency is making everyone along the stream understand how things work. So when we launched in part of our solution was that we were a new team, we were a new contract. We tried to figure out where we started and what occurred before.

We tried to delve into the previous events in the previous story so that we can find out exactly where we were on this risk matrix in being part of the government means we needed access. We need to be able to get into those things. And sometimes that takes time.

And the government had to verify everyone and get everyone into their computer systems and get everyone to their networks and their property and try to help us all. But along that process, we saw that resistance to change, that initial reluctance to make the changes to be more transparent, to open things up. When we look at it, we know that change creates er things change if things are different than they were before.

There's some error involved, there's some exposure and there is some vulnerability and there's some threat and that creates the risk. But overall indecision creates disaster. If you don't make the decisions and you just let it go, it's going to break eventually.

So what we want to do with our agile compliance mindset is we want to try to create small systems in small increments to the right. You can see one of the pipeline structures we have the used now where we put steps and we put testing in at every phase. And with that testing, we create a transparency.

We create transparency and metrics that are good not just for the devs to develop their products, but that we could use a security, we could take them back so that we could actually see the risk and we could quantify the risk and we could talk to the devs about that small steps where in the testing they were having problems rather than coming in at the end and saying, well, it's not compliant, just stuff, but just stop. Right. It's not the right thing.

So we had to communicate, had to communicate all the time. With these different folks to make sure that they were getting the message and they were being compliant with what we needed to do, but it wasn't just our team that needed to make solutions. We needed to make an organizational solution.

We needed to come in across the process. And we need to look at how we could fix our our contracting process. So we had a complete ops solution for our actual compliance and risk operation, not just a little feature.

We need to work through our leadership structure, make sure that we're building good teams. And part of that building good teams was assigning one of our security team. We only had four, right, including myself, but we had four teams of.

Probably 20 developers, as well as ops teams, as well as other teams, making sure that everybody had a functional responsibility to be part of that team, to be in their meetings, to be in their daily standards, to be able to be in their structures so that we can do the right things for them and that we can enable them to create value. And that meant investing in people to have to get the right people. And we had to be able to harvest the process back and forth and reinvest in the people as we taught them, as we spent our time explaining what it was we were looking for, we could harvest those results in the process, the foreign as we got better security and better to be agile, compliant for integration.

We really had to beat the street. We had to go on. We had advocates security all the time and we had to advocate security and we built transparency, but also creating value.

Again, I talked to stories because part of one is telling you right stories and telling the stories in the right place. I had a senior mentor for years and years ago, and one of the things she told me was he said he was going out and this was a flat level officer in the military. He was making these speeches and he had an individual come up to him and said, hey, every time you go out, you make a speech, you say the same things, you say the same three things.

And I've got it. I heard you the first time. I'm really invested.

I'm really excited. Why do you say the same? Three things.

I want to hear something different. I want hear something new. And he said he turned to me, said, look, he said, I figure.

That 10 percent of the people here, 10 percent of what I say, 10 percent of the time since it was to get the message across, I figure I've got to say the same thing or to get the message across to everyone. I've got to say the least 30 times and I've got to keep on those messages. So rather than switch my messages and switching what we're talking about, what I do is I focus.

And that way by saying enough time so I can assure that everyone hears me, everyone gets the message and we can move forward. And that's what we're trying to do by talking about security all the time, by talking about how we intend to be actually by talking about the president, talking about creating value, about moving forward. And we do that through linking the items and tasks, linking the items in our workflow.

Again, we see a CI/CD pipeline. We see how that workflow includes security, includes a static at the front and ACAST scans at the end so that we can both levels of security. And we're working on integrating more tools all across the steps so we get more visibility into how these tools work and we build those through a backlog.

When something fails a test, it doesn't just stop. It goes back into the backlog. We find a way to fix it.

We find a way to move forward and we prioritize the that creates value for the customers, for the things they want to do. So our organizational takeaways, first off, practice, practice, practice, right? Malcolm Gladwell wrote a paper called Outliers back in the 90s.

He talked about using deliberate practice to get better. He suggested that you had to do something five hundred times four familiar, five thousand times your confidence and possibly up to 50 thousand times to get mastery of that single task that you're looking for. So if we considered Scrum to be a task to think you who would do it 50 thousand times is just an unrealistic expectation.

So you really have to work on a deliberate practice. How do we get it better? How do we work it every day and how we focus on those things, the small things that are important to us in order to move forward and make our organization get better.

And part of that practices are never stop learning. We work through a backlog. We work through a prioritization.

We learn about what is going on. We learn about the product. We learn about the customer.

We learn about how we can manage our risk and what each risk is individually so that we understand that risk and talking. We can talk about the threat, you can talk about the vulnerability, we can talk about the exposure, and we can innovate through this process is to create a way that creates the right key performance indicators or so that we can measure each risk separately and individually to produce a collective answer that generates value as a multiple rather than as an individual. And then eventually we got to advocate you got to beat the street.

You got to say it all the time and say it. We have to be doing it ourselves so we convince others. We have to be talking about where our risk exists and the risk that we're managing for us as we attempt to get compliance, because there's always a risk in that as well.

If we don't meet our compliance standard, then we can get shut down by other pieces. The government that loses the program for everybody, not just for the compliance folks, but it mainly starts with compliance folks having the right process in place. And we try to build relationships over processes we want to be involved.

And that's kind of the edge of one on one zero. So finally, if I was a monarch for a day, if I was in charge and everything, I have to offer a couple of solutions going away because you have the opportunity. You always want to make things better.

I would shift more security process to the left. I have more scan's in the CI/CD pipeline. I'd be able to integrate the software.

I'd be able to talk about the risk and I'd introduce people as they started into this risk operations and after compliance, as our devs started, they'd all come in and talk to security, not as a compliance check, but so we'd get to know them so we'd understand where they are, what they're working, what they're doing, what their individual goals are as they move into the new teams. So not just the teams, but the individual people, because it's those individuals that make the difference to the overall team through those relationships that you're trying to generate in an agile and then comparatively I'd move more security checks the right and I say to the right, but not all the way through, just a little bit to the right, as devs complete their stories as they move forward and they do their features and they do development, I've had them get the mindset to get to the cultural mindset where they think about compliance as well as their acceptance criteria. They have to move it through the government, so it has to be compliant.

So they need to think about it early. But that means they need to be just as familiar with what the compliance standards are looking for as I and that talk to me, talking to them and working with them and working them through how they bring up these definitions of President Reagan used to say in the old Cold War days who say trust but verify. And it's a lot of that.

We trust everyone, but we need to verify the compliance is there. And it's not us doing the verification, it's the government doing the verification because the government needs to know we're compliant. And they've established a standard that says here's what you'll be compliant with forever.

And since that's the standard for value for the product and that's what leads. And then finally, we talk about integrating processes, I like to say no meetings, every board, one of my pet peeves is people come in and say, hey, this meeting is boring. I don't get it.

I don't like it. I'm not going in. It's just boring.

But no meeting is boring because no one's issues on this, especially from risk and compliance, you have to know what the threats are and you have to know what the vulnerability and the exposure. You don't get those without going to the meetings. Everybody has something that they need to bring.

And whether that directly applies on your situation or not, it's up to you to kind of make that connection, to come in with an agenda, to come in with the same set of things you want to talk about and be able to create value out of the meeting. If it doesn't create value. There's no sense in having that meeting, but a lot of meetings do.

And it's up to us to really make those changes in that process. And that's what we do. Security, integrating with the deaths we made, the changes we made, the integration.

And then finally, we want to manage this kind of threat and exposure, not just fine. We don't just want to talk about the factors of liability. We want to reduce our threat through reducing our exposure.

The threats are going to be out there, but we can reduce how well we see them. We can build the firewalls, we can build the victims. We can build the password complexity.

We can build the other solutions. We can put the encryption in place so that we reduce those things. So those are my thoughts overall, if I was in charge of the day, I took some of the other organizational takeaways and I hope you enjoyed it and learned something.

Thanks again for the opportunity to GitLab. I had a really good time. This is my briefing on annual compliance risk operations.

I'm Dr..