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 Information Assurance community. These teams must identify and defend against various security threats via the ISEAGE network.
Red Team
Comprised of professionals from the Information Assurance 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 Information Assurance 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 Information Assurance for the purpose of education. Students play the role of the Blue Team, or Information Assurance 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 will 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.

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 teams’ 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 can provide a fresh image of the system, but the Blue Team will 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 may not perform any offensive action toward any other participant or ISEAGE 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 (Remote Desktop, vCenter, chat accounts). 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 chat, available at https://setup.iseage.org. Setup chat is only staffed during specific hours of the day, 8 AM to 8 PM central time. If an ISEAGE staff member is not available to chat, you can submit support requests to cdc_support@iastate.edu. Always include your team number in correspondence. 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 the VMware vCenter server environment. The White Team operates the administrative accounts on vCenter. These accounts will not be used maliciously; you will not need to worry about securing the VMware 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, and wired 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 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.
  • 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 “****” or “Team-Specific” 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 will 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 IPs or IP 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) are allowed. If you choose to implement this, please justify any blocks made after N failed login attempts within your network documentation. The Competition Director reserves the right to determine whether an IP blocking policy is beyond realistic and breaking the rules.

Blue Teams may 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 will result in a penalty of up to 500 points.

During the competition White Team may assign penalties for any poor physical security practices. In order to facilitate this, White Team may physically interact with your devices, however, this will extend no further than the absolute minimum interaction needed to ascertain the security if the device. No files will be read, written, or modified. Valid actions may include pressing a space bar, wiggling of a mouse, and similar actions.

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 will need to 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 will 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 will not be graded unless stated by White Team or the 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.

Any attempts to whitelist, or otherwise give preferential treatment to the service scanner is disallowed. This includes heavy rate-limiting. Teams doing this will 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 60% 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 will 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 WILL 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 will 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. You must provide this prior to the scheduled start of the attack phase by submitting it on IScorE. 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 needs to 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 will decrease by 25% for every 30 minutes it is late. The first penalty will 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. You must submit this prior to the scheduled start of the attack phase on IScorE. 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 will decrease by 25% for every 30 minutes it is late. The first penalty will 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 Information Assurance community chosen by the Competition Director and the Red Team Leader. The Red Team will 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 will 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 will keep detailed accounts of all attacks performed. IScorE will provide 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 will 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. 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
  • Shall not initiate in-person contact with Green team members
  • 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) will be present on some systems; see the scenario document for more information.
  • Attacks against Blue Team analog phone adapters are permitted, provided Red Team coordinates with an ISEAGE staff member.
  • Will 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. 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 to blue 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 will 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 will be chosen by the Competition Director. The White Team may not aid or assist teams in any way during the attack phase except to resolve disputes.

Grading and Scoring

The White Team is in charge of grading all Documentation, Intrusion Reports, and Anomalies The Green Team Leader may grade the Green Team Documentation and the Green Team may assist with grading Anomalies as decided by the Green Team Leader and White Team Leader on the day of the competition. White Team will assign penalties if necessary. At the end of the competition, they will 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 may first contact the head of the area in dispute to resolve that conflict. For anomalies and usability checks, they shall contact the Green Team Leader. For questions about rules, scoring, or anything else, they shall contact the White Team Leader. The Green Team Leader or White Team Leader will make a decision. If the Blue Team member, mentor, or coach disputes that decision, they may appeal to the Director who will make the final decision. The Director is the final authority and cannot be further appealed.

Green Team

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

Green Team Leader

The Green Team Leader will coordinate the efforts of the Green Team members in order to assess the Blue Teams fairly. The Green Team Leader will 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 Green Team Leader.

Green Team Members

Just like in real-world IT, Green Team members will be of varying technical skill and ability. Green Team members will 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 will 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.

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

Green Team members may NOT confer with Red Team members during the Attack Phase. They may not intentionally give passwords or other sensitive Blue Team information to the Red Team. Additionally, Green Team members may 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 will administratively down that service.

All Systems

Must allow access to the Internet via the proxy and 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. The certificates used by these services SHOULD be signed by the ISEAGE Root CA. Contact White Team with your CSR (Certificate Signing Request) if you want the certificate to be signed.

Note

The ISEAGE Root CA is installed on the RDP hop and is available for download here.

Important

While self-signed certificates are allowed, there are no guarantees that Green Team will ignore certificate warnings (that are not caused by the ISEAGE Root).

Active Directory

Unless otherwise stated by the scenario document, Active Directory (AD) services should full Domain services (ie, Microsoft Active Directory, FreeIPA, or similar). Additionally, these services should 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 an actual RDP server (not just remote admin), more than two (2) simultaneous sessions must be allowed. Only automatic blocking of connections is allowed.

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 will not support issues with CAPTCHAs.

SSH

Users MUST have access to their home folder and run simple commands, such as ls, and administrative users, defined the scenario document, MUST have administrative access as per the per the scenario in order to receive service scanner points and usability points.

Important

Only password authentication is allowed for competition users. We will not do checks (either Green Team or the service scanner) with SSH Keys, multi-factor authentication, or other non-password schemes.

FTP

You can 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 documentation.

Users MUST have read/write access as per the scenario.

Email

All required users MUST have access, defined the scenario document, and users must be able to send and receive emails.

Backups

At a minimum, user data, configuration, application code (if applicable), and any additional directories or files listed in the scenario MUST be backed up. Backups MUST be taken at least every 30 minutes. This applies to ALL machines on your network. You backup enough data to make a complete restore any of your systems.

Warning

Snapshots are not a backup solution. White Team may, at their discretion, disable your ability to take and restore from snapshots during the attack phase.

You may use snapshots to assist in the setup phase.

More specifically, at minimum the following need to 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. When ISEPhone is used, it is the preferred method of communication between Blue Team and Green Team. The availability of ISEPhone will 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 Team may initiate phone calls to Green, White, or Red team for any reason. Blue Teams are not permitted to call other Blue Teams. Red Team may 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 will NOT adhere to authentication tables, passphrases or similar procedures. However, the Green Team will provide their date of birth if requested. Users date of birth can be found in IScorE.

Red Team is allowed to 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 is prohibited from performing physical attacks against ISEPhone equipment located in White and/or Green Team areas. Attacks against ISEPhone servers are not allowed. Attacks against Blue Team analog phone adapters are permitted, provided Red Team coordinates 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 will be asked to remove it. Should you falsely trigger an actual safety alarm, you will be immediately disqualified, and we will give full cooperation to any organization seeking you out for such an action. You have been warned.

Penalties

Penalties are assigned at the sole discretion of the White Team. The number of points detracted are 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, and all flag points for flags on the migrated system.
  • Unattended, unlocked laptops will incur a penalty of twenty (20) points per laptop, per incident.
  • Redeployment of any of your systems by the White Team will incur a seventy-five (75) point penalty.