001_Infrastructure Design

The NCCDC recommends the following as a practice environment (From a very outdated guide):

A typical CCDC competition provides each team with a small business network.
Network size, design, and composition will vary between events but a sample CCDC
network might be composed of the following devices:

• 5 Servers
• 5 Workstations
• 1 Firewall
• 1 Switch
• 1 Printer

The goal is to try and emulate these guidelines as best as possible, while also referencing newer documentation provided by competitors. Hardware limitations, procurement, or budget issues will effect this however it can be worked around. This design document will attempt to set a framework to build out a practice environment regardless of budget and hardware.

Networking

The networking stack should be kept very simple, a device running pfSense, OPNsense, VyOS, etc. should provide firewall capabilities. This should connect to any size managed network switch, as long as it can provide enough connectivity for all of your devices (if you can't provide enough connectivity for all devices a small wireless solution should be devised).

Managed switches are preferred here as it allows for features like VLANs which are very useful for standing up the lab in an industry standard way. This could also serve as a good teaching experience for students with minimal networking experience. An example configuration would look something like this:

------------
| OPNsense |
------------
     |
     |
-------------------     ----------------
| Cisco 3750X     | --- | Server Infra |
-------------------     ----------------

Systems

Servers and compute notes are often the most expensive part of small labs like these, cheap networking gear can run around $100, where as cheap enterprise servers can easily cost four times that without RAM, CPU's, or storage. Organizations need to consider budgets, as well as hardware requirements. For low budgets, hardware capabilities will unfortunately drastically decrease and it will need to be worked around in later stages.

Specs

Depending on configurations, software suites used, and other requirements you may require more or less resources than another team. This is highly dependent on many things throughout your stack. A rough number to aim for is ~16 vCPU's and 64GB of RAM total across all of your lab infrastructure.

Some easy options for systems that could accomplish this are the following:

Enterprise

• Dell PowerEdge R630 / R730
• HP ProLiant DL380 Gen9
• Lenovo System x3650 M5

Consumer

• Dell OptiPlex 7060/7070
• HP EliteDesk 800 G4/G5 (Mini or SFF)

There are much more systems that could fit the bill for your requirements and your organizations budget. Spreading VM's across machines can also help decrease single node costs, but might require slightly different software stacks.

Lab Infrastructure

When we are creating the lab environment we want to expose team members to as much as possible to prepare for the competition. Some system for managing and configuring a multitude of VM's should be setup (Outlined more in Deployment) to make the overall management experience a breeze. Proxmox VE is the recommended Hypervisor to use as it is free to use and easy to configure QoL features.

Below is an example list of services, OS's, and vulnerabilities that could be used in a practice environment:

To make deploying these VM's and environments easier and less time consuming to rebuild, create, and change an automated infrastructure as code approach should be taken.

Deployment and IaC

Through some research I've landed on a few tech stacks that could work in a multitude of environments. Some of these can also be used parallel to each other for different learning environments.

The main criteria for these stacks is repeatability, customization, and ease of maintenance. Environment deployments should be able to be deployed multiple times, with little downtime, while also allowing for tweaks to support learning.

Red Team Simulation & Scoring

The Red team is one of the most important parts of the lab, as well as the NCCDC competition. While some organizations might have some experienced red team personnel, many organizations do not. Other organizations may have a red team but need to hold regular repeatable practices, or learning experiences for team members.

To solve this issue we can build in an automated red team option for such scenarios, while also still allowing for actual red teams to participate.

Both automated and manual red team operations can be done from the same machine, which should be placed on the WAN side of whatever network you have setup. It should look something like this:

------------  WAN   ---------------------
| OPNsense | ------ | Caldera / Jumpbox |
------------        ---------------------
     |
     |
-------------------     ----------------
| Cisco 3750X     | --- | Server Infra |
-------------------     ----------------

The real networking setup might look slightly different to this diagram, for an example you can look at 001_Network Implementation.

Automated Red Team with Caldera

Caldera offers a system to simulate persistent threat actors through an easily automated C2 engine that uses threat profiles to help test defenses and train blue teams. Caldera uses a mixture of easy to use configs and pre-built profiles and plugins to simulate red team operations.

For practice sessions where learning or practicing blue team is the largest focus, automation will be the biggest tool for any organization. It is also useful for organizations only focusing on blue team operations.

Caldera also offers the GameBoard plugin, this is completely different from the scoring engine as it provides very different but useful metrics to isolate techniques and skills which need improvement.

Non-Robot Red Team

Manual red team engagements can also be conducted through the jump-box. Caldera can also be utilized as a tool to assist red teams in their work, and this is documented within Calderas documentation.

Red teams working with teams should be facilitating the learning process, systems can be destroyed as a proof of concept but only at the end of practice sessions (unless you are practicing backup procedures),

Scoring Engine and Injects

The NCCDC uses a few metrics for scoring teams, and teams should be familiar with how they are being scored and how the actions they are taking will effect the overall team score. There are a few scoring engines available to organizations that are easy to work with and can be built into the existing deployment stack.

Injects are something that the NCCDC outlines in their rules and other documents, and functionally they are tickets that a normal IT function would receive. For example, configuring an FTP server, adding a printer to the network, configuring firewall rules, etc.

Injects should be designed by a team organizer to target specific learning objectives, or struggle points within the team. Example injects can be found in this document: https://nccdc.org/files/CCDCteamprepguide.pdf

References

NCCDC:
https://nccdc.org/files/CCDCteamprepguide.pdf

Proxmox:
https://pve.proxmox.com/wiki

Terraform:
https://developer.hashicorp.com/terraform

OpenTofu:
https://opentofu.org/

Ansible:
https://docs.ansible.com/projects/ansible/latest/index.html

Ludus:
https://docs.ludus.cloud/docs/intro/

Containerlab:
https://containerlab.dev/

K3s:
https://k3s.io/

KubeVirt:
https://kubevirt.io/

ArgoCD:
https://argo-cd.readthedocs.io/en/stable/

Caldera:
https://github.com/apache/caldera/
https://caldera.apache.org/