Challenge Task 2022

- Template for the CT slides is available here (direct link), or here (page).  

- Presentation schedule (R6), defined as below. Five groups will present on Day 1 (L14, 21.12), and two will present on Day 2 (E14, 22.12).

- Time: 7 mins (A), 7 mins defense (D). Around 4 mins Q&A. 
- Send the slides at least 30 mins before the CT presentation. They will be presented from a single laptop to be efficient time-wise.

- Confirm whether the received source-code works. Via e-mail until E10, 24.11.2022.
- Template for the challenge task report is available here (ZIP, 590 KB) (.ZIP file). You can upload it directly to Overleaf.
- Stage 3 - "The Offense": Exchange of source code as in the Table below:

This semester's Challenge Task (CT) will happen in three stages. 

In the first stage, each group will have to prepare a simple Web application containing a service that may store user credentials and service-related data. The application will be a Web-based TODO list in which users can define tasks at a future date/time defined by the user interacting with the front end. All data should be stored in a database at the backend, and a user may also be able to retrieve certain tasks that happened in the past. Since the developed application should be straightforward to deploy and operate, groups strongly recommend using Docker and docker-compose to implement the application. 

Example of a simple Web-based TODO list

In the second stage, each group will design and implement security policies and services they deem necessary to protect the application and its users' data. Once again, it is a key requirement that all security services and measures are deployed within the same docker-compose file. 

In the third stage, the groups will exchange their source codes and perform a penetration test on the application to assess the application and data security. Two talks (offensive/defensive) should be presented, and a report should be delivered (6 pages disclosing the defensive and offensive measures - 3 pages each).

The full CT's description is also available in PDF (PDF, 405 KB).

The learning objective of this CT is to have students discuss and decide in small groups which theoretical concepts to use in practice, exercising the different aspects of network security (i.e., offensive and defensive security). Thus, this exercise is expected to foster students' creativity and ability to use adequate defense and offensive techniques and mechanisms in different environments (Web services) selected by the groups. 

The groups shall inform the teaching assistants on the topic and discuss the proposal's feasibility. Each group must hand in their proposal until E03 via e-mail. Even though the groups are free to choose the application to be implemented, all groups must ensure that all requirements are met and follow the defined deadlines. The necessary information to complete the CT, assumptions, libraries, tools, and impact on the grade are detailed in the next sections.

A group will have a maximum of three two participants. Any special cases/requests should be agreed upon with the TA. During the challenge task, each group will be able to ask questions and get support from their supervisor(s):

• Temporary link to form groups: docs

Portability is a key characteristic that must be ensured in all stages of the CT, meaning that the Web-based TODO-list application should be easily deployed and operated on different machines. However, for each CT group, the following key requirements need to be met:

• [R1] The application must have a frontend, backend, and database. It is possible to use the code of an existing TODO-list application or build one combining different services. The core functionality must be implemented and executed entirely in a docker-compose file to ensure portability. 
• [R2] At least one security feature should be designed and deployed to protect the application. There is no upper limit on the number of security mechanisms deployed by each group. Important to note that, due to requirement 4, the portability of the application should be a top priority.
• [R3] The application, all additional security services, and associated configuration files should be executed within the same docker-compose file. Any additional configuration file should be automated to ease its deployment.
• [R4] Each group will do a penetration test on the application provided by another group. The penetration test should provide documentation specifying its methods, tools, and found vulnerabilities. Groups will be arranged to ensure that all developed Web services will have their security mechanisms tested, i.e., all groups will perform attack and defense roles.
• [R5] Each group will provide a single report of a minimum of 6 pages disclosing its (1) application and security mechanisms and (2) penetration test in another Web service application. Thus, a minimum of 3 pages for (1) and 3 pages for (2). An intermediate report for (1) should be delivered on the date specified below, and the complete report at the final deadline on the presentation date.
• [R6] Each group will provide two talks. One presents its application and security mechanisms, and the second talk presents the penetration test. Talks will be organized by Web application, i.e., Group A: Application 1 functioning and security mechanisms, Group B: Application 1 penetration test. Group B: Application 2 functioning and security mechanisms, Group A: Application 2 penetration test.

This year's CT will be executed in three main stages and different tasks within each stage. The first stage concerns the definition and implementation of a Web service; stage 2 is the addition of protection services, mechanisms, and policies; and stage 3 is the penetration test. Figure 2 illustrates the main stages.

Figure 2 - Challenge Task Stages

Clarification: Deadlines consider until 23:59 of the day given in the description (and not the day before. Thus, it is possible to use exercise lectures to discuss (and remind) the necessary details.

Stage 1 - "The Service"

• R1.1 - Groups defined: CT will be presented in the first exercise class (E01) and students will have to form groups (limited to a maximum of three participants) sending a confirmation via e-mail until the second exercise class (E02). Special cases or requests should be confirmed with the TA. 
  • Note: The number of students in each group will be defined based on the number of students enrolled in the course, being released in E01.
  • Deadline: until E02, 29.09.2022.
• R1.2 - Define Web service: groups will define the details of their Web TODO-list application until the third exercise class (E03). It is possible to either use existing ones or implement the desired service. 
  • Note: The choice of additional services will be checked by the TA to avoid the use of an application that already has security features ``out-of-the-box", thus, defeating the purpose of the CT. 
  • Deadline: until E03, 06.10.2022. 
• R3.1 - Application implemented: service is shown operational until/at the fourth exercise class (E04).
  • Note: Considering that basic already available TODO-list applications can (and are recommended) be used, the deadline is relatively short. Exceptions can be discussed with the TA. 
  • Deadline: until/at E04, 13.10.2022.

Stage 2 - "The Defense"

• R2 - Security services implemented: at least one additional security service(s), mechanism(s), and/or policy(-ies) are added to the Web service. Hand-in of the prototype until the ninth exercise class (E09).
  • Deadline: until E09, 17.11.2022.
• R5.1 - Intermediate report delivered: an intermediate report of 3 pages minimum including a short description of the Web service and covering the technical details of the security services must be delivered until E08. It should also include instructions on how to deploy the service (i.e., guiding another group in its deployment).
  • Deadline: until E09, 17.11.2022.
• R3.2 - Web service exchanged: the exchange (i.e., defining which group will analyze which Web service) will be done by the TA at E09.
  • Note: Groups will have one week to report any issue in deploying/operating the received Web service. Confirmation of whether the received service is operational as delivered must be sent until E09 by each group.
  • Deadline: exchange at E09 17.11.2022. Confirmation sent until E10, 24.11.2022.

Stage 3 - "The Offense" 

• R4 - Penetration test performed: the test must be based on a methodology and make use of offensive tools as presented in L07. 
  • Deadline: until E13, 15.12.2022.
• R5.2 - Final report delivered: includes the intermediate report and must have a minimum of 6 pages. The final report should also include the findings of the penetration test.
  • Deadline: until E13, 15.12.2022.
• R6 - Talks presented: two talks must be given. One presents the Web service and its security, and one on the penetration test findings. Talks will be organized per Web service in a way that their overview, defense, and offense are presented together.
  • Note: There will be two presentation dates: L14 (21.12.2022) and E14 (22.12.2022).
  • Deadline: until or at E14, 22.12.2022.<\strike>

The CT's grading will be based on objective and subjective criteria. While objective criteria are the basis to check whether groups have achieved or not the minimum requirements (and within their deadlines), subjective criteria are used to assess how well these requirements have been implemented. A discussion between the professor and TAs will define the subjective criteria based on a qualitative assessment of the group's work based on the produced/delivered code, reports, and talks. Deadlines are based on exercise classes (e.g., E02, E03, check here), and involve the requirements defined in Sections 3 and 4. Deadlines for the minimum requirements are defined as follows (cf., Figure 3):

Figure 3 - Challenge Task Deadlines

• E02: 29.09.2022. Requirement R1.1 must be delivered until E02.
• E03: 06.10.2022. Requirement R1.2 must be delivered until E03.
• E04: 13.10.2022. Requirement R3.1 must be until or at E04.
• E09: 17.11.2022. Requirements R2, R5.1, and R3.2, in which both R2 and R5.1 must be delivered until E09.
• E10: 24.11.2022. Confirmation for requirement R3.2 is needed until E10.
• E13: 15.12.2022. Requirements R4 and R5.2. Both R4 and R5.2 must be delivered until E13.
• E14: 22.12.2022. Requirement R6 must be delivered until or at E14.

Thus, if all the aforementioned requirements are met on their specified deadlines, a group is approved with a minimum grade on the CT (i.e., 4.0). A subjective evaluation by the course TAs and professor will adjust the grading based on the quality of the code, report, and talks.

Reference Architecture 

An overview of architectural components is given in Figure 1. The application should be exposed at ports 80 (443 preferably) in the localhost. As mentioned in the requirements, it is possible and recommended to use existing applications as a basis to develop and deploy its security mechanisms. That would allow groups to get familiar with the syntax and functioning of the application.

Additional security services and mechanisms can be freely chosen and adapted to application design. For example, it is possible to harden the security of a backend/frontend while adding additional security services (i.e., containers) such as firewall, authentication, intrusion detection system, and others. It is important that all security services are declared within the same docker-compose file and any additional configuration file shared between the localhost and containers, is also provided. Figure 1 shows a basic reference configuration serving as a starting point for each group to implement its own Web service and security mechanism(s).

Figure 1 - TODO-list Webservice - Reference Architecture

It is also important to note that security should be improved as much as possible without sacrificing portability. The use of any additional security service that impairs its straightforward deployment and operation should be avoided. For example, adding a two-factor authentication that requires the use of external tokens or sending SMS. Given the CT goals where each group should play both the defensive and offensive roles, it is key that the developed application can be easily deployed in different machines. As such, any additional configuration should be automated (e.g., Python/bash script).

I found a mistake in the description, what should I do?

• Please, get in contact with the TA as soon as possible. Although the TA improved over time, this description may contain inconsistencies.

How many participants are allowed in a group?

• Help me to help you, read the description. Anyhow, the maximum defined (HS22) is 3 participants. 

Is it possible to use a different platform rather than Docker?

• It is key for the CT to have easy portable/deployable Web services (prototypes will be exchanged between groups). If this requirement can be maintained in your proposal, please contact the TA to discuss the proposal.

Should we contact a TA only during exercise classes in case we need assistance?

• Nope, send an e-mail as soon as possible. If the question cannot be answered via e-mail, it is possible to schedule a meeting online/on-site.

Is it possible to reuse code for my application or security mechanisms?

• Not only possible but recommended. Do note that it may not be allowed to use an application already containing several security mechanisms/protections (as this will defeat the purpose of the CT).

Our code requires additional/external configuration files, what should we do?

• Automate the application configuration using scripts. These scripts should be provided with instructions to execute along the source code. Remember that another group will deploy your code and it is key that it works.

Can we use the time allocated to exercise classes for implementing the CT?

• Yes, whenever it is possible, i.e., assuming there is available time after exercise solutions are discussed. Otherwise, it is recommended to use homework times to work on the CT.

We are lost, what should we do/ask? 

• First, discuss within your group what are the possibilities, scenarios, outcomes, risks, benefits, externalities, and whatnot. If this is not helpful, ask the TA for directions. Second, thinking "what should we do/ask?" is already a question, so that is something positive to remember. The third point and perhaps the most helpful one, a "starting point" is available below. Remember that the CT goal is to practice "defensive" and "offensive" security and not to provide a "product-level" application. Have fun!

Starting point(s)

[1] https://docs.docker.com/get-started/02_our_app/
[2] https://hub.docker.com/r/thoba/todo-list-app
[3] https://github.com/julianoboese/docker-todo-list
[4] https://a7medayman6.github.io/projects/devops/todolist/
[5] https://learn.microsoft.com/en-us/visualstudio/docker/tutorials/docker-tutorial
[6] https://www.google.com/search?q=todo+list+docker&oq=todo+list+docker

Reminder: always be extra careful with running non-verified third-party code (such as the application developed by another CT group).