Ben Allison – How the U.S. Army Cyber School Created ‘Courseware as Code’ with GitLab

When do you think of innovation, you don't necessarily think of the Department of Defense, but Captain Ben Allison with the US Army Cyber School is here to talk to us about how the US Army Cyber School created Source code with GitLab. They were able to streamline their courseware process using git to track all their instructional material as code. This enabled them to reduce effort and increase efficiency and transparency necessary to maintain their curriculum, relevance and currency.

Hello, my name is Ben Allison, and today I'm going to be talking about how the United States US Army Cyber School is using GitLab to track and manage our curriculum and courseware as code to briefly introduce myself. I'm an Army captain. I've been in the Army for about six years.

I studied computer science and in my undergrad and I've been at the cyber school for the past two years working on building a new pipeline for officers who are going to join the army as software engineering and a new specialty the Army is creating. The cyber school itself was founded in 2014. The first students came less than a year later in twenty fifteen students graduate.

They primarily work in the cyber mission force. The Cyber Mission Forces a joint force that works under United States Cyber Command. And so that's our mission force.

They work in a joint environment with the Air Force, the Navy submarines, and then, of course, the Army. Additionally, we have soldiers who now are going out to the broader army beyond the cyber mission force. So they'll go to regular army units as well.

So when we talk about the cyber branch in the army, this this memo was drafted and published in August of 2014, so that kind of shows how young the cyber branches in the army. When you say the term branch, everyone's familiar. Many people are familiar with the DOD has the Air Force, the Navy, the Army and and the Marine Corps, which falls under the Navy technically, but then within the Army.

We also use this term branch to just talk about how we group specialties within the army. So you have branches like armor or infantry. So those are more familiar combat arms roles that the army associates or the people associate with the army, other things like field artillery, aviation.

So they fly helicopters to aviation armor, tanks, actually, they manage the artillery, the mortars, things like that. Then you have more technical specialties such as the Signal Corps. So the Signal Corps is what enables the army to communicate.

So all the soldiers who focus on telecommunications and more IT centric communication, now that we have the 21st century with actual computers, that all falls under the Signal Corps. However, the army create the cyber branch. It's similar to the signal.

But rather than being it centric, the cyber branch is focused on what they say the phrase uses creating offensive and defensive effects in cyberspace. So when you say effects, we're thinking the ability to create an outcome. So degrade deny.

So we're trying to deny enemy the ability to create effects in our own equipment and are trying to support Army forces in a state of war to create effects against our enemies, and when we say cyberspace. They're talking about primarily in this context, IP centric computing and RF based computing. So so that entire space is kind of what we group under cyberspace within that which is, of course, cyber is used everywhere.

But that's kind of a more specific term when we use cyber in the Army. So in that context, when the Army is building a new schoolhouse and a new training pipeline for for a whole new specialty, normally when the Army has training, they focus on things like what we see in the lower left hand corner you have that's the Abrams tank. It was created in the 80s.

It's approx, about 40 years old now. Until then, 20 and not much has changed over that time. There are improvements and upgrades and so on.

But you're trying to teach someone how to operate this vehicle. The generally there's not many changes. And when they do change, they're very controlled changes.

So you'll get a list of, hey, there's a new approach, this new system, and here's how it changes, how you teach it, which then feeds into a very slow, controlled process for how the army is going to update its curriculum. And generally, this is OK and this is more what you want because tactics are not changing very often. Maybe over decades, technology might change things or different types of warfare might change how you would teach things in your curriculum.

But you want to be controlled and you want to be able to monitor it and make sure you're not changing things in a way that's harmful. And that ties back to what we see here as a checklist mentality. And that's where if if there's a maintenance you need to do in this vehicle, there's a checklist of maintenance you need to do.

If there's a task you're doing, you want to do follow this procedure in the same way every time to ensure everyone knows how to do it and you train it and it becomes muscle memory. That way, when you're in stressful situations, the muscle memory takes over. And so that ties into what we see next to this picture of the tank.

It's a web interface called training development capability. So the Army uses this this web interface in the back and database to train all of its curriculum so that they map essential tasks, which are things that units have to perform at an individual and collective level to prove that they're ready for for their mission. And they tie those back to lesson plans at schoolhouses for their respective specialties, for how they train their soldiers.

And so this process is very labor intensive. There's when you create a lesson plan, there's several different clicks, the typing and manual entry use with a mouse and a computer and someone who's trained and has access to the system. The point is it doesn't have API access.

So if you're trying to update something you wanted to automate and update, unfortunately, this entire process has to be done manually human so that the cyber school we're creating the cyber branch and creating the school to go with it. The individuals who are here when they were first ending up, they wanted to find a way to be more agile in how they manage things, because the information security space is much different than than the traditional Army apparatus that supports training, for example, where things don't change very often in typical warfare training, the information security space changes very often. A three year cycle would mean that we're always behind the curve because things constantly change.

And information security, something three years ago, is not necessarily true now. And the tactics and techniques change. Operating systems update all of that.

Those type of changes we want to be able to capture so that we're not stale and three years behind whenever we're teaching curriculum. Likewise, we're the operational force typically in the Army is focused on checklists and a very defined definition of what it means to be ready for their mission in cyber that that's not really the case. Information security, the problems are not as concrete that you can follow with the checklist.

Instead, we want people to be able to absorb and understand poorly defined problems and then break it down into technical steps and apply what they've learned and learn how to find out what they don't know, to teach themselves to solve problems. So we're very focused on outcomes that are focused on problem solving rather than solving checklists. And then additionally, when we look at how the government has approached us before, we're not the first corse in the Army or in the DOD that has technical courses.

But one thing that we saw in other places is that many times when they have technical environments, they build virtual labs that might be manually configured. And so someone would go in, who knows what they're doing. They configure an environment for to teach students and they might stave it as a snapshot.

And then if you want to give it to every student you had a snapshot of multiple times or copy the snapshot across the board, there's some very well known industry certification courses that distribute their course material and thumb drives to students in virtual machines that you copy over. Well, this can work. It's very difficult to scale and it creates a very high cost to develop new curriculum.

And so if you want to maintain your curriculum or update it, there's a lot of labor that's involved. So at the cyber school, we decided to apply software engineering principles when we're developing and managing our Coursera instead. So when we talk about Coursera, this is all the instructor material is student material and the lesson plans that support training development capability that come out of our our curriculum, that support a lesson outcome.

And then additionally, it is the environment, the virtual ranges that students practice activities to demonstrate their skills and learn that all support that outcome. So for us, the are primarily we use Asciidoctor, and mark down for all products that would be as a replacement to PowerPoint or word or things like that. And then we track and version control using git and GitLab and then provide this pipeline version control and we can receive feedback for that versus PowerPoint, which is a binary blob that you can't really drop.

You could you could store in GitLab or in git, but you wouldn't be able to see changes by line in between new commit. And finally, once we have all coursera managed we build pipelines that support different end users. So if the students we want to take this product and build for our students, we write it once in a pipeline, we'll pull out anything that's restricted to the instructor and the students would get a view of their content.

Likewise, for instructors, they would get their own view with all the products that have to go with them to help them teach. That way, the people who are teaching don't have to actually go in to get in and view products. That way they can actually just pull open the web interface, which we store and GitLab pages to view their products.

And so and so it a quick example here. We see on the screen we have a this is a byline change that was very cosmetic. So it didn't need to go to a serious process.

They just wanted to add syntax highlighting so we can track to say, hey, who made a change to this facilitation guide for the instructor? And we can see what was changed and when was changed. And then there was the reason why.

And so what this builds for us is a web interface. So this is a static page hosted and GitLab pages together. Pages also gives us the access control so we can say some repositories have a list of users who can access this, and then a second repository can have a list of users who are students and students can only access, maybe get access to this project and they can see all the pages that go with it.

So this one is using ASCII Doctor and Antora, which is limited to ASCII Doctor. So it provides all the material necessary for the CYBERCOM and Technica Corporation, which is one of our primary technical courses. So here's a different view.

Using Hugo supports ASCII Doctor and markdown, and so this builds again, this is a student view. So this would show the the slide in the student guides and all of that in a web format and any additional files or handles that would go with it support an outcome for our lesson. Finally, the next piece that goes with this is as we have the coursework for the actual the guides for instructors and students, which are the slide decks and books and all of that material.

We also have the infrastructure. So the infrastructure, we apply the concept of infrastructure Eficode, which means you define your networks, your virtual machines, your servers, all of that in code using we use YAML, which is a simple markup language to define an entire template for a network for classroom activity or for an entire module in some cases. And in those templates, they have what's called user data for a virtual machine.

And that is where we put all the configuration scripts that get fed into the virtual machine. So what happens is we have a single standardized set of Windows and Linux virtual machines or other different architectures and operating systems as necessary. And they are stored as we saw that once we manage those once.

But then when we want to deploy for a class, we use these templates, which are those YAML templates to get fed into open stack, which is our private cloud, and then the user data feeds into cloud in post boot and custom configurations can be applied across all those machines. So one individual or one instructor can build an exercise for a student once and then we can scale it across the board as many times as we want. So every student can get their own identical Range, which gives us then the guarantee that everyone's getting the same experience when they're testing, when they're when they're completing exercises.

And testing additionally allows us to take advantage of GitLab, CI pipelines. So when we make changes and then say we want to update it for the next class and there was a cosmetic change, we just make all of our changes in code making it, and then we have a manual pipeline that can then deploy all of our infrastructure into OpenStack automatically through GitLab. And so we can see again here, here's an example of the bylined version control for this.

So here with someone's fixing a typo, and that's one of those is examples of the granular control we get from it. And so once this deploys, we have this here's an example of this pipeline for that course we saw earlier. This is a security model for that.

It's one of the sub modules. And so they have they deploy every student gets one deployment for their entire class. Since the pipeline runs in a clone's, all the repositories and needs, it uploads any objects to open stacks, direct object stores and builds all the template into open stack, saves the output from those templates which are you can configure.

He attempts to return variables like public IP ranges and IP addresses that get assigned, and then it builds a capture the flag framework using CTFD, which is an open source project to manage capture the flags that builds custom activities for the students with guides and prompts and all of that tailored to that specific deployment, and finally is able to validate all of that to ensure that all the stacks deployed so that every every student's environment, we know that more or less is actually deployed the way we wanted it to. And someone's not going to get to class and be in the middle of an activity. And we find that, oh, this didn't deploy.

Right. We have to go back and manually do it while students are in class. The goal is to get that done before ahead of time in case something fails.

It's in the product that we see here, this is a student Range, this is a single identical Range deployed twice. So in the left, you see in the lower left hand corner, those the same environment and then the top, it's the same thing deployed. And this is this is a security model of CCTC deployed by the framework.

And this is what it looks like, an open stack when it's deployed. And that was all done through a pipeline. So we only had to do it once and then we were able to repeat it across for the entire class.

In the rest of the screenshots, it's cropped out, but you can see the entire classes in this project and all of their ranges are built at the same time in the same fashion. So it's this done for us. We've gone from a three year process.

What is what the Army provides us before. And now we have the ability to support instant feedback and then we can tailor how we change our curriculum based on the nature of that feedback. It's a small cosmetic change and we can make it immediately.

If it's an outcome altering change, it has to go up a more formal process. But we can tailor that based on the need of the change. We now have version control.

It's bylined versus no version control. We don't have automated build versus manual infrastructure deployment. So we can automatically build it after we have it set and ready to go.

And then we have interactive tests. So rather than having paper test which where it was before, in the early days of the course in schools, rather, now we have interactive test, especially in the courses like where the entire capstone is a several hour test in an interactive environment. In the future, we'd like to do standardization, so become cloud agnostic with technologies like TerraForm, standardize how we're doing it across all classes rather than every class implementing its own on its own, and then implement gamification as code to make CTFD really standardized.

We'd also like to collaborate with other partners in the joint environment. So other service branches like the Air Force we are working with to help build a way to work towards an outcome where we have a standardized technical curriculum across the board that we can share downstream and not repeat ourselves. And then finally, we'd like to apply these standardized formats in the future to make technical curriculum available to people in high schools who may not otherwise have access to technical curriculum by reducing the cost, by employing Coursera Our source code across the board.

This concludes my talk, I would like to say thank you to GitLab for the opportunity for this our source code to tell our stories and thank you for your time for watching.