Competition Rules

Definitions

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the rules documents are to be interpreted as described in RFC 2119.

CDC: Cyber Defense Competition.
ISEAGE: Internet-Scale Event Attack Generation Environment (a simulated Internet).
Blue Teams: Competitors playing the role of the Cyber Security Community. These teams must identify and defend against various security threats via the ISEAGE network.
Red Team: Comprised of professionals from the Cyber Security Community playing the role of hackers. This team must create and implement various attack strategies against the Blue Teams, and capture flags from the Blue Team servers. It is headed by the Red Team leader.
White Team: Comprised of respected individuals from the Cyber Security Community. This team is the judging authority for the CDC.
Green Team: This team consists of members with various computer familiarity and skill levels. They play the role of typical network users. The Green Team duties include regular Internet usage and the execution of predefined anomalies. It is headed by the Green Team Leader.
Flag: A file placed in a predefined location. The Red Team MUST capture these flags from or plant them onto teams’ systems.
Anomalies: These events are injected into the system at various times throughout the competition. The Anomalies are designed to test, or simply just complicate, the Blue Teams’ duties during the competition.
Competition Director: Oversees the operation of the CDC, the final authority on scoring and adjudication, and coordinates the Red, Green, and Blue Teams.
White Team Leader: Oversees the operation of the CDC, leads the White Team in scoring and adjudication and coordinates Red, Green, and Blue Teams.
IScorE: The web-based scoring application tailored to the CDC. IScorE may be used by all teams to submit, view, and alter scores. Located at https://iscore.iseage.org.

Objectives

The purpose of the Cyber Defense Competition is to provide students with a simulation of real-life experiences in Cyber Security for the purpose of education. Students play the role of the Blue Team, or Cyber Security Community, under fire from the Red Team, simulating the attackers of a network. The White Team oversees the competition, judging, and scoring each Blue Team based upon Red and Green Team reports received. The Green Team plays the role of general network users, and the strain they place upon ensuring security within a network.

The Blue Team with the most points at the end of the competition will be named the winner. See the Competition Scoring Guide for more information.

Blue Teams

Students SHALL form teams of up to 8 members to tackle the challenge laid out in the Scenario document. They will set up and secure a network that is usable by the Green Team while defending it against attacks from the Red Team.

Note

Remote competitors should be aware that a fire drill procedure MAY be part of the competition, and some optional anomalies MAY require in-person participation.

Each Blue Team will be assigned a domain name (teamN.isucdc.com) and a subnet of IPs on which to make their services available on the ISEAGE network. Check your dashboard on IScorE for your team’s range.

Some of the services in the scenario will be provided and will need to be secured. If a Blue Team damages a provided service beyond the point of recovery, the White Team MAY provide a fresh image of the system, but the Blue Team SHALL incur a scoring penalty of 75 points per re-install.

Access and functional requirements specified under each server in the Scenario document MUST be met in order to receive any points for that particular server. If these requirements are not met, Service Scanner points will not be awarded and additional penalties may be applied in some circumstances.

Attention

Blue Teams SHALL NOT perform any offensive action toward any other participant, ISEAGE Staff, competition infrastructure, or Red Team during setup or the competition. Doing so will result in a penalty of up to disqualification of the attacking team.

Blue Team members are responsible for any ISEAGE accounts assigned to them for use in the CDC environment. Any actions performed on these accounts will be attributed to the team whom the account is assigned to, and penalties will be assigned accordingly if necessary. Therefore, do not share your CDC credentials with anyone.

Remote Setup

Setup will be available remotely 24/7, see Remote Setup Guide. ISEAGE provides online support via the ISEAGE Discord. Blue Teams are strongly encouraged to provide their team name and number when reaching out for support. Furthermore, any communication involving minors MUST loop in their affiliated coaches or instructors. If an ISEAGE staff member is not available to chat, you can submit support requests to cdc_support@iastate.edu. Rule clarification or procedural questions SHALL also be sent to this e-mail address. Teams are encouraged to seek help from anyone (including White Team) during this phase.

Hardware

Each team will be provided with access to our Proxmox server environment. The White Team operates the administrative accounts on Proxmox. These accounts will not be used maliciously; you will not need to worry about securing the Proxmox environment.

The Blue Teams will be held accountable for missing or damaged hardware at the end of the competition. If hardware becomes damaged or is missing, contact the White Team immediately.

If hardware fails during the competition or there is a suspected network outage, please contact the White Team immediately.

The White Team will provide power, network cables, wired network access, and wireless network access only. Wireless normally comes under heavy load and we suggest to use the wired network access if possible.

Software

All software used in the competition must either be freely available or provided by ISEAGE, see the Remote Setup Guide document. Trials of non-free software that do not exceed the trial period are allowed.

Accounts and Passwords

A list of users and their passwords will be provided
These MUST work for the services described in the Scenario Document
You SHALL NOT change the password for any required user unless instructed to by the Green Team Leader or White Team Leader
- If you have evidence that an account has been compromised, you may request that the password be updated by contacting White Team. You will not be able to update shared passwords.
Scenario Users may be furloughed or fired from the organization and MUST have their access disabled or removed swiftly if this occurs. See the Scenario Document for more information.
Some passwords are specific to individual teams. They are denoted by “****”, “Team-Specific”, or “TSI” and will be provided on IScorE.

Required Flags for Red Team Capture

See the Scenario Document for required flag locations.

You will be required to maintain a “flag” for some of the required services (see the Scenario Document). Once setup commences, you will be given these flag files via IScorE. The file name for the flag MUST be the same as given by IScorE.

Flags are intended to represent data stored in each of these directories, and thus SHALL NOT have more restrictive access permissions than other files in the directory. They SHALL NOT be compressed, encrypted, encoded, or in any other way obfuscated.

In addition to planted flags, there may also be sensitive data that Red Team will want to capture such as passwords, financial information, etc., which may be located in files or databases. If Red Team manages to capture this sensitive data you will lose flag points for each item lost.

If the Red Team determines a flag is missing, it will be considered captured unless the Blue Team can prove it is present. Flags determined to have not been planted SHALL NOT be eligible for earnbacks. See the Red Team section and the Competition Scoring Guide document for more details.

On-site Setup

During the competition, teams WILL NOT be provided with hardware to access their machines. This means that your team SHOULD bring laptops to the competition as a front-end to the virtualization environment. We will provide a safe network, isolated from the red team attacks, onto which you can connect your personal computers and manage the machines directly.

Attack Phase

During the attack phase, the Red Team will arrive on-site and attempt to gain access to your services in order to capture flags, reduce Usability, or take the services offline. This will begin at the specified time (typically 8 am) on the day of the competition. We will announce the start of the attack phase on the competition floor before it begins.

Blue Teams are not allowed to manually block or ban specific IP addresses or IP address ranges; doing so is unrealistic and completely ineffective in the real world of IT. Automated systems that block connections for a few minutes after N failed login attempts (e.g. fail2ban) MAY be used. If you choose to implement this, you SHALL document any blocks made after N failed login attempts within your White Team Documentation. The Competition Director SHALL reserve the right to determine whether an IP blocking policy is beyond realistic and breaking the rules.

Blue Teams SHALL NOT receive help from anyone not registered on that team (including advisors or mentors, professors, family, company recruiters, or friends) during the attack phase. Doing so SHALL result in a penalty of up to 500 points.

Attention

Blue Teams may not make in-person contact with a Green Team member or Red Team member directly. These contacts must go through the Green Team leader or a White Team member.

Green Team Anomalies

In the real world of IT, there is never a dull moment. Green team anomalies simulate the never-ending stream of requests that everyday IT employees must be prepared to handle. During the competition, anomalies will be released via IScorE. They are worth varying point values based on their difficulty. Blue teams SHALL submit anomalies before they expire in order to gain points.

Completion of anomalies is OPTIONAL unless the anomaly specifies otherwise. However, Blue teams that refuse or do not submit an anomaly will not be awarded any points for it. Anomalies account for a significant amount of points and are highly encouraged.

Blue Teams’ members are in charge of making sure that the Anomalies are submitted on time and with responses that are professional.

Attention

Any anomaly that is submitted after the time deadline SHALL NOT be graded unless stated by White Team or the Competition Director.

Communication

During the event, the Green Team Leader, Competition Director, or White Team MAY announce instructions or important information. All instructions MUST be obeyed. At the Competition Director’s or White Team Leader’s discretion a penalty may be assigned to a team that does not follow the instructions in a timely manner.

Service Uptime

IScorE’s automated Service Scanner will be used to check if your services are online every few minutes. This data will be automatically incorporated into scoring results.

Your team SHALL NOT attempt to whitelist or otherwise give preferential treatment to the Service Scanner. This includes heavy rate-limiting. Teams doing this SHALL NOT receive points for any affected services and may retroactively lose service points for those services at the Competition Director’s discretion.

Attention

In order to place you must have at least 70% uptime.

Intrusion Reports

In real-world IT, management will require regular reports on the security of your network, as well as in-depth analysis of any intrusions. Blue Teams MAY turn in an intrusion summary report, at the times designated at the start of the competition, typically at 9:30 am, 12:30 pm, and 3 pm. These times can be changed, added to, or canceled at the discretion of the White Team Leader or Competition Director. This report MUST cover, in detail, any intrusions noted or lack thereof (in your IDS or otherwise), your team’s assessment of their impact, and the mitigating measures your team took, along with evidence to support your analysis. A simple printout of a log file SHALL NOT earn any points, nor will a “No Intrusions Detected” without any evidence to back it up. Each report is worth up to 25 points and MUST be submitted via IScorE. Late submissions SHALL NOT be graded. They are scored on:

Detail (0-7 pts)
Supporting evidence (0-5 pts)
Insightful analysis (0-5 pts)
Mitigating actions (0-8 pts)

Documentation

Danger

If the White Team suspects your team submitted another team’s documentation both teams SHALL receive ZERO (0) points on the documentation!

Network (White Team) Documentation

White Team Documentation represents the reports that real-world companies require of their IT staff. In it, you MUST explain, in detail, your plan for setting up and securing your network. Documentation MUST be submitted in IScorE before the attack phase begins. It is worth up to 100 points and SHOULD include:

Details of your network layout (IP addresses, firewalls, whether you have chosen to use NAT)
Network Diagram(s)
Discussion of the Operating Systems, Software, etc. you have chosen to run each of your services
Anything else that you feel demonstrates your preparedness to the White Team

This document MUST be professional and thorough. It is scored on:

Detail (0-40 pts)
Professionalism (0-30 pts)
Supporting diagrams, figures, and tables (0-20 pts)
Effectiveness of plan (0-10 pts)

The Network Documentation score SHALL decrease by 25% for every 30 minutes it is late. The first penalty SHALL take effect immediately following the start of the attack phase.

Green Team Documentation

Green Team Documentation instructs your users (the Green Team) on how to use your services. Documentation MUST be submitted in IScorE before the attack phase begins. Keep in mind that the Usability scores given by Green Teams will be severely affected if this documentation is not present! Teams often underestimate the importance of usability – it can easily make or break the competition. Ensure your networks have a good balance between usability and security.

This documentation is worth up to 100 points and SHALL include instructions for users with little or no computer experience on how to use all of the services you have provided. HINT: You MAY find a screen capture program such as SnagIt extremely helpful in completing your documentation.

It is scored on:

Detail of Instructions (0-20 pts)
Clarity (0-20 pts)
Completeness (0-20 pts)
Professionalism (0-20 pts)
Supporting graphics, figures, and diagrams (0-20 pts)

The Green Team Documentation score SHALL decrease by 25% for every 30 minutes it is late. The first penalty SHALL take effect immediately following the start of the attack phase.

Red Team

The Red Team represents the “bad guys” – malicious users, advanced persistent threats, or other agents that may want to cause harm to a Blue Team’s infrastructure. The Red Team is staffed by professionals in the Cyber Security community chosen by ISEAGE staff. The Red Team SHALL evaluate the efforts of the Blue Teams at the completion of the Attack Phase.

Red Team Leader

The Red Team leader is chosen by the Competition Director and will coordinate with the White Team Leader to ensure a fair and successful competition. The Red Team Leader SHALL serve as a mediator between the Red Team members and the White Team to settle any scoring disputes, and will, if necessary, set boundaries for attacks to keep the competition running smoothly.

Attack Phase

Red Team members SHALL keep detailed accounts of all attacks performed. IScorE provides a place to document all offensive actions taken. These documents will be made available after the competition on IScorE under the “Red Team Wiki” page.

Red Team members MAY attempt to obtain flags on each Blue Team’s network, see Required Flags for Red Team Capture. Blue Teams start with a given number of flags, and for each of the flags captured by the Red Team, a number of points are lost. The Red Team MUST submit the captured flags via IScorE for verification and scoring. Blue Teams MAY challenge a capture if they feel it is warranted. This SHALL be done by contacting White Team. See the Competition Scoring Guide for more information on the scoring of flags.

Rules of Engagement

Attacks SHALL NOT leave the ISEAGE environment
Attacks MUST be terminated upon request of the White Team
Red Team SHALL NOT initiate in-person contact with Green Team members
Red Team SHALL NOT impersonate the members of the White Team or any persons not related to the competition.
In addition to required flags, sensitive information (e.g. credit card numbers, Social Security numbers, etc) MAY be present on some systems; see the Scenario Document for more information.
Attacks against Blue Team analog phone adapters MAY be done, provided Red Team coordinates with an ISEAGE staff member.
Red Team MAY attempt to plant flags onto each Blue Team’s network in White Team-designated locations.
At certain points during the attack phase, the White Team MAY allow physical access to the competition area without the presence or supervision of Blue Team members (referred to as a “Fire Drill”). Special rules apply during these engagements. Red Team members MUST NOT:
- Search through personal belongings or cause excessive untidiness
- Remove any item from the competition area without explicit permission from the White Team
- Tamper with ISEAGE infrastructure, including but not limited to: servers, switches, power supplies, and cabling. Exceptions MAY be made when ISEPhone is in use.
- Perform any action that is beyond the scope of the competition or inconsistent with the spirit and goal of the Red Team (e.g. installing malware, viewing, copying or removing personal files or data, or otherwise harassing Blue Team members)
- Answer calls from the Green Team from the Blue Team ISEPhones
- Access or interact with the personal computers of any person without their explicit consent

At the discretion of the Competition Director and Red Team Leader, Red Team members who operate in excess of these rules MAY be asked to leave.

Red Team Evaluation

The break down on the scoring of the Red Team Evaluation can be found in the Competition Scoring Guide.

White Team

The White Team SHALL be led by the White Team Leader. The White Team is responsible for setting up and maintaining the ISEAGE network, IScorE, and all CDC infrastructure as well as running the competition. At least one White Team member MUST be present at all times during On-Site Setup and the Attack Phase. In all things relating to the competition, the authority of the White Team is to be considered absolute.

White Team Members

White Team members SHALL be chosen by the Competition Director. The White Team MAY provide assistance to teams during the attack phase.

Grading and Scoring

The White Team is in charge of grading all Network Documentation, Intrusion Reports, and Anomalies. The Green Team Leader may grade the Green Team Documentation and the Green Team SHOULD assist with grading Anomalies as decided by the Green Team Leader and White Team Leader on the day of the competition. White Team SHALL assign penalties if necessary. At the end of the competition, they SHALL determine the final placement of Blue Teams.

Disputes

If a Blue Team member, mentor, or coach objects to scoring, enforcement of the rules, etc. during the competition, they MUST first contact the White Team Leader to resolve that conflict. For Usability Checks, the White Team Leader will reach out to the Green Team Leader. For Anomalies, the White Team Leader will reach out to the ISEAGE staff member that made the anomaly. The Green Team Leader or White Team Leader SHALL make a decision. If the Blue Team member, mentor, or coach disputes that decision, they MAY appeal to the Director who SHALL make the final decision. The Director is the final authority and SHALL NOT be further appealed.

Green Team

The Green Team represents the users of a Blue Team’s infrastructure. They SHALL score each Blue Team on the usability of their services.

Green Team Leader

The Green Team Leader SHALL coordinate the efforts of the Green Team members in order to assess the Blue Teams fairly. The Green Team Leader SHALL also coordinate with the Competition Director in the creation of Green Team Anomalies, and with Green, White, and Red Team members in their execution. The Green Team Leader MAY also assist with grading Green Team Documentation and Anomalies.

The Green Team Leader is the custodian of Blue Team password and other information as described by the scenario. The Green Team Leader or White Team Leader MUST authorize any password changes by Blue Teams.

The Green Team Leader MUST be present if a Green Team member wishes to confer with a Blue Team. Blue Team members with questions regarding scoring of Usability or Anomalies SHALL confer with the White Team Leader.

Green Team Members

Just like in real-world IT, Green Team members will be of varying technicalskill and ability. Green Team members SHALL score Blue Teams in several Usability Checks during the attack phase by completing normal activities such as browsing the web server, connecting to the file server, or logging into the remote desktop server. They SHALL fill out a Usability Form on IScorE during evaluation. This Usability form is unbiased and consists of Items like: “Is John Smith able to login to the RDP Server” with simple Yes or No answers, and in some cases partial points MAY be awarded.

Green Team members MAY also, at the direction of the Green Team Leader, score Anomaly submissions.

Green Team members SHALL NOT confer with Red Team members during the Attack Phase. They SHALL NOT intentionally give passwords or other sensitive Blue Team information to the Red Team. Additionally, Green Team members SHALL NOT intentionally perform attacks or malicious actions against any Blue Team. Unruly Green Team Members MAY be asked to leave by the ISEAGE staff.

Requirements for Services

All services MUST work as described in the Scenario document. If a service type is not defined in this section, it SHOULD follow the relevant standards such as RFCs. In addition, all your services MUST provide the functionality described below. If your service is not following the guidelines it MAY be downed administratively, red on IScorE, by White Team. If White Team determines that your service is not functioning as required they SHALL administratively down that service.

All Systems

All systems MUST allow access to the Internet via the proxy. All required users SHALL have correct access per the Scenario Document. All systems MUST comply with the EULA for any software used.

SSL/TLS

Unless otherwise stated, your services MAY use their SSL/TLS variant if you wish to do so. Contact White Team to adjust the service scanner for your team.

Active Directory

Unless otherwise stated by the Scenario Document, Active Directory (AD) Domain Services (i.e., Microsoft Active Directory, FreeIPA, or similar) MUST be used. Alternatives such as OpenLDAP, 389ds, Active Directory Lightweight Directory Services, etc. SHALL NOT be used, unless otherwise stated by the Scenario Document. Additionally, these services MUST be configured with a NetBIOS name of ‘teamN’ and a domain of ‘teamN.isucdc.com’.

Remote Desktop

Users MUST be able to connect to a desktop environment with macOS, Windows, and Remmina clients. RemoteApps alone are NOT sufficient, all users MUST be able to use a full Remote Desktop session. Administrative users MUST have the correct access as per the scenario. When RDP is used as a terminal server (not just remote admin), more than two (2) simultaneous sessions MUST be allowed. Only automatic blocking of connections SHALL be used.

HTTP

Your service MUST be fully functional as per the scenario. If you use HTTPS it MUST redirect or serve the application on port 80 using HTTP.

Warning

Systems such as CAPTCHAs may interfere with the Service Scanner. ISEAGE staff SHALL NOT support issues with CAPTCHAs.

SSH

Users MUST have access to their home folder and run simple commands, such as ls. Administrative users, as defined in the Scenario Document, MUST have administrative access per the Scenario Document in order to receive Service Scanner points and usability points.

Important

Only password authentication SHALL be allowed for competition users. The Service Scanner and Green Team SHALL NOT do checks with SSH Keys, multi-factor authentication, or other non-password schemes.

FTP

Your team MAY switch to other options such as SFTP or FTPS. However, users MUST be informed of how to use these alternate options in your team’s Green Team documentation. White Team MUST be informed in the White Team Documentation.

Users MUST have access as defined in the Scenario Document.

Email

All required users MUST have access as defined the Scenario Document, and users MUST be able to send and receive emails.

Backups

While backups are not required, they are highly recommended. Having a backup allows your team to quickly restore services and user data if your systems are compromised by the Red Team or accidentally broken during the setup phase, reflecting real-world best practices.

Definitions: * Backup (Proxmox)

A Proxmox backup is a VM‑level or container‑level archive created through Proxmox’s built‑in backup system. These backups capture the full state of the virtual machine or container at the time of creation and can be restored to revert the system to that saved state.

Snapshot (Proxmox)
- A Proxmox snapshot is a point‑in‑time capture of a virtual machine or container that allows rapid rollback to a previous state. Snapshots are stored on the same storage as the VM and are intended for short‑term, convenience‑based recovery.
Custom Backup System
- A custom backup system is any backup mechanism created or deployed by a team that operates inside the guest operating system and does not rely on Proxmox’s built‑in virtualization, storage, or snapshot features.
- Custom backup systems must not interact with Proxmox storage, disk images, or VM‑level state. This means teams may not copy, clone, export, or duplicate Proxmox VM disks, volumes, or configuration files.
- This MAY include, but is not limited to, in-guest scripts, automated backup services, filesystem archives, etc.

Backup Usage Rules: During the Setup Phase, Blue Teams MAY create backups using any methods. Blue Teams MAY also restore backups freely during the setup phase. During the Attack Phase, Blue Teams MAY continue to create backups using any methods. However, Blue Teams MAY NOT restore backups during the Attack Phase unless it is a Custom Backup System and explicitly allowed by the White Team.

More specifically, the following COULD be backed up: * /etc/ * /home/ and /root/ * C:\Users * Application Source Code * Database data

Phone Systems

The ISEAGE Phone System (ISEPhone) is a telephone analog of the Competition Network. It is isolated from the public switched telephone network, as well as from the Competition Network. ISEphone usage may be indicated in the scenario document for each competition. For remote competitors, the scenario document will define what ISEphone usage looks like (e.g., whether teams will be in charge of setting up a phone system to work or if alternative communication is used). When ISEPhone is used, it is the preferred method of communication between Blue Team and Green Team. The availability of ISEPhone SHALL be announced at least 24 hours prior to the Green Team documentation deadline. The Director MAY require that the Phone System is the only method of communication allowable during the attack phase; this decision need not be announced prior to the attack phase.

Blue Teams MAY initiate phone calls to the White team for any reason. Blue Teams MAY call the Green Team to confirm Usability updates once alerted by a Green Team member with a Usability concern. Blue Team MAY call Green Team regarding suspicious account activity after receiving approval from White Team. Blue Teams SHALL NOT call other Blue Teams. Red Team SHALL NOT initiate a call to Green Team, however they are permitted to use other social engineering techniques, website defacement, or other practices to trick Green Team into calling Red Team. Green Team MAY call a Blue team for a number of reasons, including technical support, help, and Green Team Usability Checks. Red Team MAY also call a Blue Team for any reason, including impersonating Green Team.

ISEAGE makes no guarantee to the accuracy of Caller ID information from ISEPhone, nor any guarantee to any pattern of phone numbers. However, once a phone number has been used, it will not be repurposed to a different phone for the remainder of that competition. Green Team SHALL NOT adhere to authentication tables, passphrases or similar procedures. However, the Green Team SHALL provide their date of birth if requested. Users date of birth can be found in IScorE.

Red Team MAY attack the ISEPhone system at the Blue Team location. Any Blue Team analog phone line is in-scope, as well as any network cable which only carries VoIP traffic, provided this network cable is located in the Blue Team area. In effect, this means that scope begins at the Blue Team handset and ends at the ISEAGE trunk switch. Red Team SHALL NOT perform physical attacks against ISEPhone equipment located in White and/or Green Team areas. ISEPhone servers SHALL NOT be subjected to attacks by any participant. Red Team MAY attack Blue Team analog phone adapters, but they SHALL coordinate with an ISEAGE staff member.

Safety Devices

In the pursuit of realism, some scenarios MAY include the defense of simulated security or alarm devices. Please remember, these are NOT REAL. We do not, nor will we ever, provide fake or non-functional physical, real world, safety alarm devices. Additionally, we do not condone the possession of such devices. If you bring a non-functional safety device, you SHALL be asked to remove it. Should you falsely trigger an actual safety alarm, you SHALL be immediately disqualified, and we SHALL give full cooperation to any organization seeking you out for such an action. You have been warned.

AI

Teams MAY use AI tools to assist in the creation of documentation, anomalies, earnbacks, and other written submissions. However, teams are fully responsible for the accuracy and quality of their submissions. Poorly generated, inaccurate, or low-effort content resulting from AI usage may incur a penalty of up to the maximum points allotted for that particular submission, at the discretion of the ISEAGE staff members.

Penalties

Penalties are assigned at the sole discretion of the White Team. The number of points detracted SHALL be determined at the discretion of the White Team, and are considered to be final, outside of the aforementioned dispute process. Penalties MAY be assigned for any reason, and for any amount, again at White Teams discretion. A few common penalties are codified here for clarification. THESE MAY BE CHANGED AT THE WHITE TEAMS DISCRETION, but any change to a codified rule will be in your favor, and apply to all teams for a given competition.

Migrating of systems for which migrations are disallowed are subject to forfeiture of all service uptime points, Usability, and all flag points for flags on the migrated system.
Redeployment of any of your systems by the White Team will incur a seventy-five (75) point penalty.