1. Introduction

1.1 Problem statement

Public Safety personnel and emergency responders utilize sensors, other wearable devices, and modern communication technologies to preserve life and property. Public safety personnel and emergency responders depend on the security of their devices and communications. To improve the secure use and operations of these devices, a common, unified method for displaying and notifying users of key network information and system/security vitals is needed. These vitals include but are not limited to: network status, devices connected to a Personal Area Network (PAN), the security posture of the network, etc. A centralized dashboard displaying the connection (e.g. Cellular, Wi-Fi, VPN Connections, Bluetooth, NFC, GPS) status of a mobile device can provide useful information for the emergency responder and their IT support personnel. While much of this information is available within the disparate settings of devices, it is often difficult to navigate through the user interface to find the location of this information, and the location of the information is different depending on the device. In addition, limited security contextual information is provided to the user. To re-enforce the effectiveness of this dashboard, a non-intrusive notification to alert the emergency responder of the status of a functioning or malfunctioning connection would save time and effort during an incident or event.

This device vitals dashboard is designed to improve emergency responders’ confidence in the communication channels required to relay the sensitive information from the field to the organizational units needed to coordinate and perform lifesaving duties.

For secure communication, public safety needs:

  1. An effective dashboard that organizes and displays device connections and available security information for those connections.
  2. Intuitive navigation to retrieve detailed information, such as Ciphering Indicator.
  3. Status of assets connected to the device, displaying the history of the asset’s use if the asset has been connected previously.
  4. Asset inventory to help perform analysis, determine the threat landscape for a public safety individual and help identifying rogue and potentially malicious assets or non-secure network connections.

USE CASES

a. Paramedic responding to an emergency

During a medical emergency response, a paramedic uses an application to collect a patient’s information (name, age, gender, etc.), record the patient’s vital signs (heart rate, blood pressure, temperature, etc.), and look up medications. In addition, the app forwards the patient information to the hospital to which the patient will be taken. The paramedic, focusing on their duties, does not necessarily have the information technology background to notice irregularities in the functions of the technology to perform these tasks. The data collected by the paramedic could be lifesaving information to the patient, but this information, in the wrong hands, can enable a malicious actor to commit identity theft with the use of the exposed personally identifiable information.

b. Undercover officer communications

As part of a covert operation, an undercover officer is using a mobile application on his/her mobile device to provide operational information back to the operation’s command center, relaying confidential informant information, video, voice, location, etc., from the officer. The success of the operation, the informant’s life, and the officer’s life could depend on the confidentiality of this data. Now, imagine if the undercover officer could see a gauge that displayed the security of the PAN and the undercover officer’s device knew to hold on to the video or text message until they returned to a more secure operating environment, reducing the risk of compromising the officer, informant, and information.

1.2 Objectives

The objective of this contest is to create an application that will communicate to emergency responders the security posture of their device via a simplified dashboard and automate the use of different applications based on the level of security related to data arriving and data transmitting from the device. Allowing access control to secure applications should be accessible even if the device’s security posture is not fully secure. The dashboard should be able to act as an information source with options, and never impede the emergency responders’ mission.

The application will communicate to emergency responders:

    1. LTE, Bluetooth, NFC status with security information real-time or simulated for demonstration.
    2. Connected device inventory/history, to inform the user of recurring and new, never before connected devices to the UE.
    3. Ciphering indicator to inform users of their over-the-air cellular connection encryption status.

1.3 Resources

2. Evaluation criteria

Participants must adhere to the basic application requirements listed below. Failure to do so may result in non-grading of the application.

Criteria #0: Basic Requirements

Rating: Pass/Fail

  • Application will communicate security status and information for:
      • LTE: User data confidentiality and integrity
      • Bluetooth: Current and recent connected devices
      • NFC: Current and recent data transmissions
      • Local hardware encryption: On or Off
      • VPN:
        • Current and recent VPN connections
        • Security Data for current connection (TLS 1.2)
      • Wi-Fi connection
        • Current and recent Wi-Fi connections
        • Security Data for current connection (WPA2)
      • GPS: Status
      • Antivirus application status: On or Off
      • MDM Status: Operating status

Criteria #1

Rating: 20/100

  • Application’s ability to toggle between the different security and connection settings within the dashboard
      • LTE: User data confidentiality and integrity
      • Bluetooth: Current and recent connected devices
      • NFC: Current and recent data transmissions
      • Local hardware encryption: On or Off
      • VPN:
        • Current and recent VPN connections
        • Security Data for current connection (TLS 1.2)
      • Wi-Fi connection
        • Current and recent Wi-Fi connections
        • Security Data for current connection (WPA2)
      • GPS: On/Off
      • Antivirus application status: On or Off
      • MDM Status: Operating

Criteria #2

Rating: 20/100

  • Application’s ability to respond to and communicate the changing scenarios provided:
      • Does the application dashboard respond to changing variables within the provided scenarios in a timely manner?
        • LTE security status changes
        • VPN status changes
        • Bluetooth changes
        • Time and location warnings/information

Criteria #3: UI/UX Evaluation (Part 1)[1]

Rating: 20/100

Emergency responder and UI/UX SME judging of:

  • Learnability: degree to which a product or system can be used by specified users to achieve specified goals of learning to use the product or system with effectiveness, efficiency, freedom from risk and satisfaction in a specified context of use
  • Operability: degree to which a product or system has attributes that make it easy to operate and control.

[1] https://iso25000.com/index.php/en/iso-25000-standards/iso-25010?limit=3&limitstart=0

Criteria #4: UI/UX Evaluation (Part 2)[1]

Rating: 40/100

Emergency responder and UI/UX SME judging of:

  • Functional completeness: degree to which the set of functions covers all the specified tasks and user objectives.
  • Functional correctness: degree to which a product or system provides the correct results with the needed degree of precision.

Functional appropriateness: degree to which the functions facilitate the accomplishment of specified tasks and objectives.

[1] https://iso25000.com/index.php/en/iso-25000-standards/iso-25010?limit=3&limitstart=0

3. EXPECTED DELIVERABLES FROM PARTICIPANTS

Review the How to Participate instructions in section 3 of this document to ensure that you are prepared for the in-person Regional Codeathon or Online Contest. The following deliverables will need to be included with the submission:

  • A completed submission form through techtoprotectchallenge.org
  • A 3-minute narrated PowerPoint file or 3-minute narrated video with the following sections:
    • A summary of the submission.
    • Basic information about the participant or participant’s team.
    • Specific requirements of the contest that are being addressed by the participants.
    • Two to four screenshots of the solutions or prototype.
    • Overview of key functions included in the submission.
  • Any available files or links to the developed solution or prototype.
  • Any additional files based on the contest description.

 

 

Tech To Protect
Rules & Guidelines