Keith Rhea & Tim Jones – How we Married Policy-as-Code and Compliance with Automation

Move towards cloud migration and modernization, public sector organizations must transform their existing processes to obtain an authority to operate, also called an ATO and how we marry policies as code and compliance with automation. Keith Rhea and Tim Jones of the MindPoint Group. Talk about how they took their federal customer from an average ato time of three to four months for application to only one to two weeks.

Let's listen. All right, welcome, everyone. First of all, we'd like to thank everyone for attending today, and we'd also like to appreciate GitLab for giving us the opportunity to come tell our story of how we're helping ease the pain of public sector compliance.

So the use of automation and policy as code. So first, a quick intro on ourselves. My name is Keith Rhea, I'm a senior cloud security engineer at MindPoint Group.

I've been at MindPoint for a little over five years outside of work. I enjoy outdoor activities in the wintertime. I love skiing, summertime, just doing anything outside.

I live in northern Colorado, checking out the local breweries and seeing what all they've got on tap. Thanks, Keith, I'm Tim Jones, I'm a cloud automation engineer at MindPoint Group, I've been here for a little under a year and I live in San Diego, California, so I like doing fun in the sun surfing. I also snowboard and I also like to golf.

So I'm going to hand it back to Keith and we'll get started a little bit about my MindPoint Group. We are a cybersecurity focused consulting firm. We have a great team of experts and all disciplines of cybersecurity.

And today we'll be talking about the areas of security, engineering and automation, as well as governance, risk and compliance. com. com.

It's a really the model that we use for our environments as far as consumable framework. com. OK, so let's talk about why we're here today, public sector compliance, automation.

So we'll talk a little bit about what it looks like, why we need it, and what are some of the common pain points associated with it. So first, looking at the graphic, we can see the public sector compliance landscape obviously complex and multifaceted, and there's a laundry list of governance, regulations, standards and policies that all dictate dictate how we implement our IT systems. It's our job as It security professionals to culminate those requirements, incorporate them into the RMF and determine how we can implement controls and satisfy requirements and then ensure they're continuously enforced throughout the lifecycle where IT systems going to do all this on top of actually getting our IT systems to work and deliver on the mission that they are intended for.

That sounds fun, right? So if compliance is so hard and complex, why do we need it? Obviously a rhetorical question.

T. systems, trying to prevent attackers from having the ability to exploit the compromise our systems. We've all seen the constant ticker-tape of IP security incidents that affect both public and private sector organizations, costing hundreds, if not hundreds of thousands, if not millions of dollars.

So that in mind, we see that there's still a gap that exists between perceived compliance and actual security. So we know what we need to do, why we need to do it, and what are some of the barriers? What are some of the blockers preventing it from preventing us from getting there?

We've broken that down into a few areas the first time and gathering all the requirements, building solutions, testing the solutions, document documenting and audit, auditing the IT systems. All of that takes time. And there's a constant competing in time for developers and engineering support to deliver content, to deliver feature requests, deliver bug fixes.

All those types of things are definitely competing on time. And we've consistently seen security take the backseat when it comes to prioritizing those tasks. Secondly is cost all the activities that we just listed, they all take time and time obviously translates into associated costs.

In addition to that, implementing and auditing security compliance requires highly technical skill sets. And those aren't easy to come by. And the costs associated with those resources obviously reflects that.

Next, the ability to be accurate, so like we've all seen the systems that were implemented that meet the low watermark of compliance or the ability to get authorized, and we really want to avoid the bare minimum implementation of security. And lastly, the ability to be consistent, so across the organizations and IT departments, there's typically applications that are similar, if not the same, that get deployed and having the ability to implement those security controls the same across those applications is different. Definitely hard without automation and building solutions and code.

So we want to avoid the lack of ability to be consistent. So what's our approach to solving the issues that we were just asked about? So the first area we want to solve problems, ones we want to build solutions in code and build a way to automate them and deliver them through a pipeline.

So when you build a solution and code, it allows you to be modular, declarative, and it really makes it reusable and consumable across your IT organization. Secondly, we want to reduce the complexity of compliance. So building solutions and code allows us to provide a common framework, a single language that developers, engineers and even auditors can all speak to provide a commonality between all those teams.

Next, we want to increase control, accuracy and consistency. So like we were talking about on the previous slide, you know, the implementation of security controls to a low watermark is something we're definitely trying to avoid to help fill that gap between compliance and actual security. So when we develop solutions and code, we want to make sure that we're implementing security controls to the fullest extent possible.

In addition to that, in the same vein, when you develop that solution and code and have that modular and declarative and reusable, that allows it to be consistent and durable across the organization. So I think we really just want to avoid the deploying of these systems with default options, people just crossing their fingers, hoping that it meets the low watermark for compliance. And lastly, a single source of truth, so having all your control implementation details, documentation and code and a single location allows for all your stakeholders, your developers, your engineers and auditors, all to be able to rely on that single source of truth to get accurate UP-TO-DATE information.

So I really want to avoid the death by spreadsheets. I think we've all been through a compliance effort where there's multiple copies of the same spreadsheet. There is tens of tabs, hundreds of controls, talking about control, implementation, details, whether you're passing or failing.

And we really want to be able to. Boil that out and have that be a single source of truth and avoid information drift. And, you know, all that sort of thing.

So how do we take that approach and build it into a process? So the five steps you see here are breakout of the risk management frameworks, steps three through six. So you're full implementation all the way through your continuous monitoring.

The first like we talked about. But we want to automate our control implementation, build the solution and build a pipeline to automate the deployment of that solution. Second to that, we want to continuously delivered that solution to our IT systems, so we've all seen systems that were built very well by an engineering team, a development team.

It was well documented, went through the authorization process, got out of them, passed with flying colors. We circle back a year from now and go through our annual assessment. And that system is nowhere near where it was originally baseline and approved the war authorized for approval.

So we want to prevent that drift control and we do that through automating the continuous implementation of our our controls. Actually, we want to validate that process, have automated control testing, so we don't want to go through an annual assessment every year. We want to have that continuous feedback that is near real time and up to date.

And the output of that, so when a controlled test fails, how do we handle that? The automated control remediation, is it something that we can respond to automatically and remediate? Because it's something that requires engineering, developer support, a code change.

So how do we handle that feedback from our systems and make sure it gets into the right hands, whether that be a system or person to resolve a failed control test? And lastly, compliance status integration. We want to take all that technical information, extract it from our system, incorporate, incorporate that into a system of record for our compliance status on our IT systems, and have that continuous feedback so that stakeholders and decision makers for our systems are confident in our process when they go to make decisions, whether it's authorizing it or making any other high level decisions around the system.

So that's our approach at a high level. To our solution, and I'm going to turn it over to Tim and he's going to walk through our technical solution for implementing this process and I'll get labs helping us do that. Thanks, Keith, and thanks to everyone to get love for an audience and share our story with you.

I'll be discussing the ways our team has used GitLab to help us automate compliance and provide secure development environments for our clients. So the first thing I'll be discussing is the modern DecSecOps environment and how it's impacted our industry now. So I'll be going into our modular and consumable code framework and how we provide not only infrastructure as code, but desired state configuration as code, as a service to our clients.

And lastly, I'll be discussing how all this fits into our information security continual continuous monitoring solution, which is the end goal for achieving continuous and automated compliance environment. So one of the major ways we are able to achieve rapid compliance is through adopting a DevSecOps framework. And this means integrating security into each stage of a systems development lifecycle.

T. and security sort of operate in these siloed teams, you're now seeing these teams come together as a more cohesive unit around development and providing security appropriately at different stages in our development process. And this allows you to deliver products more quickly while achieving compliance at the same time.

So this is going to bring about a culture change where teams are going to have to be more development minded and security focused. But this is going to allow them to practice the traditional agile software development techniques while also being cognizant of the accreditation of the system. And so we achieve this with three main pillars of our automated compliance environment, and one of them is GitLab.

Second is going to be terraformed enterprise and the third is Ansible Tower. And so GitLab enables us to organize our code bases into modular and consumable automated code that our clients can then import into their own build pipelines. So this allows us to customize our workflows for security, relevant events, using GitLab pipelines and run our containers and commit policies to not only deploy secure infrastructure to the cloud, but also desired state configuration playbooks for the OS platforms and applications running on those OS is in your environment.

And so we're able to maintain the source code for these modular code bases and provide the knowledge base and the documentation for our clients to then interact with those code modules and execute that code in their environments by providing input variables into that code. So this gives us the consistency and accuracy that we're looking for. And this also gives our clients the ability to relax specific security controls in a development environment to know what changes they need to make on their application in order to confidently deploy that application into a production environment securely.

So here we have a high level overview of that workflow, where you see a developer on the right hand side. If they want to make an infrastructure change or a change to the configuration stage of a server in their environment, they're going to push a change to GitLab. They're going to push that code up to a repository in which we actually have policies as code running in that environment to make sure that they're making appropriate changes and the systems are checking out before being deployed into production.

And you can see here that using platform neutral and provider neutral languages like TerraForm and Ansible, we can allow this to take place in a cloud environment like AWS, where you have a dev stage and production environment and you're able to deploy code to those different environments appropriately. And at the end of the day, this is going to allow us to feed information into our continuous monitoring solution. And that's where you see aggregated information being sent to that single source of truth in your system solution and also all the scanning that's going on for the activity occurring in your environment in real time, collecting all that and being able to display that in a dashboard format to system owners and other improvement officials gives them a lot more confidence in assuming risk on the system and allowing for the accreditation of that system to pass.

And so here's a typical policy as code example that might be. Seen in our environment, so this particular example is about how we deploy allies to our environment and those are Amazon machine images. So we like to use Packer to be able to baseline those in this pipeline file goes into a little more detail on how we can abstract that to a three step build pipeline where you're actually going to validate the Packer configuration and inject a stig test in the middle of that.

And what that will actually do is run a molecule scenario. On your two instance, that gets provisioned in a dead environment and then it's going to run the same consumable Stig playbook and whatever change that you're trying to make to that server, it'll run that in that dev environment and based on the success or failure of that process. Then you're allowed to build that Amite into production.

So this is a good way for us to control the security of a system before it even hits the environment. And the point with all this, it's not to make the job of the developer harder. It's not to create an additional roadblock.

This is actually making it easier to deploy codes here in my area because we're using all these automation technologies and we're giving the developers confidence to not only find the specific configurations in their application that may apply to a security component, but we're providing that knowledge base to make it easier for them to go and discover where those security configurations lie, how to remediate them, and then how to confidently deploy systems into their production environment. And so if you structure something like this where you have a three stage build of two separate OS platforms happening in parallel, if you can ensure that these are pushing to a master branch, then you can schedule a nightly build and have clean AMIs the next day to build new resources off of or to support. Systems that are already in production, you might have a cluster configuration for a server or maybe an auto scaling group.

So this provides you the ability to deploy that quickly and securely. And so here's a higher level overview of what that modular consumable framework might look like, where you can have application rules securing your application, you can have separate rules that are going to secure your operating system multiplatform, and you can also import Terreform modules to deploy different resources to your cloud environment. And so at the end of the day, the goal of this is to be able to capture the activity on your environment, so you're breaking down those security relevant events to pipelines.

And so not only you're still collecting the logs, the audit data off of all your system, the Stig outcomes, but you're also collecting the outcomes of those pipelines and those security relevant events, whether it's adding a new system, adding a new user, taking a system out of the environment, making a change to a baseline, you're able to collect all that data and analyze it and then aggregate it into a single source of truth. And that's how you're going to be able to. Take that information and create dashboards that can represent the actual activity occurring on your network, and that's going to give stakeholders like system owners and approving officials to make the right call on the accreditation of your system and to be able to continuously accredit and monitor your system.

And so what are the benefits in the results of this number on speed? You're taking time to deploy infrastructure and secure baseline configurations to your cloud environment from what used to take months. Now we're talking about taking that down the weeks and even days and really to the speed at which an approving official is willing to assume risk on the environment and providing that real time data and analytics into actually what's going on is going to allow them to make a more educated decision on acquiring the system and continuing to accredit the system.

And this gives us the ability to have consistency and accuracy and also modularly deploy code as a service to our clients consistently and scalable. So when you're talking about an up to date to, let's say, a Stig baseline, you know, there could have been a week or a two week turnaround on being able to provide those updates. We can take that time to updating those playbooks down to just, you know, a day or two in which that code can then be deployed to our master branch version, controlled and then accessed by our clients.

So this allows accuracy and consistency and being able to fine tune your control implementation so you're more confident in deploying resources to your environment. And so if you have any questions about how we're doing this, feel free to reach out to Keith or I. And here's our email addresses.

com. com for more information. Thank you.