Secure product life cycle - *Security requirements specification*

# Secure product life cycle - *Security requirements specification* By Jürgen Humenberger, Urban Suhadolnik and Stefan Kreiner  ## Setup IoT package An IoT camera's video feed is continuously received by a backend service, which maintains private patient footage in a data storage system. A mobile application can receive the live video feed from the backend service, including notifications based on motion. The IoT package is assumed to be deployed within a medical environment. ![](https://i.imgur.com/Zotxw6m.png) # Based on the threat and risk analysis from the preceding assignment, this document will provide a complete design description, including security and verification requirements specifications. --- ## **Security requirements** Based on the risk assessment process, the following relevant threats have been found to not be acceptable:  | # | Component | Threat / Vulnerabilitiy | Security Requirements | |:---:|:------------------:| -------------------------------------------------------------- | ------------------------------------------------------------- | | 1.1 1.2 | Mobile Application | Leakage of sensitive data | Signed NDA, Authenticated encryption | | 1.3 | | Malicious application | Personalized download to protect app integrity | | 2.1 2.2 | Backend service | Malicious tampering with credentials | Multiple approvers | | 2.3 | | Vulnerable credential verification | Independent security audit of credential verification process | | 3.1 3.2| IoT Camera | Reading video data from cameras local storage | Encryption of data using a public key | | 3.3 | | Tampering with camera process to send data to attacker as well | Restrict camera connection to local network | # ### 1.) Security requirements for Mobile Application #### 1.1) Secure data transmission When the mobile application communicates with the backend server, a "TLS 1.3" connection is established using both the backend's and the mobile application's public RSA-4096 communication keys. #### 1.2) Leakage of sensitive data: Access to the private patient information is restricted to those who have been authorized and assigned to a user profile, created by the management board. Users must sign a Non-Disclosure-Agreement in order to prevent the leakage of sensitive data. To guard against theft and manipulation with the sensitive data, authenticated encryption must be used. ###### 1.2.1 Authenticated encrpytion: Creating new user profiles: - AES-256-GCM, Encryption via higher privileged (management) user RSA-4096 private communication key ###### 1.2.2 Asymmetric encryption signature: Signed NDA: - Publish user RSA-4096 public key from the mobile app to backend - Sign NDA via RSASSA-PSS with user mobile app's RSA-4096 private key ###### 1.2.3 Authorization via login: - 2 Factor Authentication - Time based One-Time Password (TOTP) - 1st step: Login via username and password - 2nd step: Secret token sent as text message #### 1.3.) Malicious application: Personalized downloads lessen the chance of propagating harmful software. Authorized users receive a time restricted download link via email for downloading a certified version of the software from the backend server. Integrity checks ensure that the software has not been altered during the download. ###### 1.3.1 File checksum for integrity check: - Hash function: SHA-2 256bit - Verification tag has to be sent via TLS-1.3 - Time restriction for accessing the download link via email: 24 hours ### 2.) Security requirements for Backend service #### 2.1) General interacting with backend Whenever the backend server communicates with the mobile application or the camera, the backend servers public RSA-4096 communication key is used by the mobile appliction or camera to establish a "TLS 1.3" connection. #### 2.2) Malicious tampering with credentials Malicious tampering with credentials mitigate against the three main attack vectors: * Physical security * Manipulation by admininistrator with direct root access to the running server * Manipulation with admininistrative/management privilage on the credentials database ###### 2.2.1) Manipulation by admin with direct administrative(root) access to the running server Adminisrative IT personel needs to be sufficiently vetted. All commands by admin accounts are to be logged and sent to a central logging server which is managed by a different administrator or read-only. ###### 2.2.2) Manipulation with admin/manegement privilage on the credetials database All actions above a certain privilege level (new admin accounts, large database manipulation) need to be approved by multiple administrator or manegement users. Second approval should not be from (system should block) someone with personal interdepedency (e.g. spouse) #### 2.3) Vulnerable credential verification User credential verification needs to be done with secure - *industry standard* algorhitms with enough security margin for operating the forseable operating time of the system such as Aegon2 or Bcrypt (recommeded by NIST) with sufficient configuration. ###### 2.3.1.) Password guidelines Mandatory password guidelines must follow established NIST 800-63B or equivalent. Passwords have to compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised: (taken from NIST 800-63B) * Passwords with less than 8 characters are not allowed. * Passwords obtained from previous breach corpuses. * Dictionary words. * Repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’). * Context-specific words, such as the name of the service, the username, and derivatives thereof. ### 3.) Security requirements for IoT Camera #### 3.1) Reading video data from cameras local storage ###### 3.1.1 Encrypted data storage Encrypt all video data that is stored on the cameras local storage device using hybrid authenticated encryption with the backend servers public RSA-4096 storage-encryption-key and AES-256-GCM. #### 3.2) Tampering with camera process to send data to an attacker ###### 3.2.1 Secure configuration management The camera has a local user management system and only users in this system may alter the camera configuration. ###### 3.2.2 Prevent configuration tampering All the changes in the camera configuration should be logged and securely stored inside the camera such that all changes can be read by any user but no user can modify the log. The necessary attributes that need to be tracked are: - username - timestamp - configuration parameter - old value - new value ###### 3.2.3 Secure backend-endpoint configuration The camera should have a configuration parameter to specify the URL or the static ip address of the backend server, the backend endpoint. This is the destination the camera will try to connect to when sending video data. ###### 3.2.4 Secure backend-public-key configuration The camera should have a configuration parameter to specify the public key that should be used for establishing a secure connection. ###### 3.2.5 Secure data transmission Whenever the camera and the backend server communicate, the configured backend servers public RSA-4096 communication key is used by the camera to establish a "TLS 1.3" connection. This key can be changed in the cameras configuration. --- ## **Verification requirements** ### Verification requirements for App ###### Verifying 1.1: Secure data transmission The subsequent verification tasks require the establishment of a secure TLS connection as a prerequisite. - A TLS handshake is performed correctly and the resulting session key can be used for communication. - Initiate a communication to the backend server using its public communication-key. - Check whether all the steps in the handshake are done in the correct order - Check whether all the steps in the handshake are done correctly. - Check if the resulting session key is correct. - Send a message using the session key and check if it can be correctly decrypted on the backend server. - A TLS handshake with the wrong server is detected and the communication is aborted without leaking any sensitive data. - Initiate a communication to a server using a different public TLS-key. - Check whether the mobile application aborts communication as soon as it detects that it communicates with the wrong server. #### 1.2) Leakage of sensitive data: ###### Verifying 1.2.1 Authenticated encrpytion: - New created user profile is securely transmitted and decrypted at backend service - Create dummy user with sensitive user data - Encrypt with management user's private RSA-4096 communication key - Send Authenticated Encryption with Associated Data to backend (Nonce, Associated Data, Cyphertext, Tag) - Decrypt user data with management user's public RSA-4096 communication key and verify integrity - Verify failing integrity check via tampered Associated Data ###### Verifying 1.2.2 Asymmetric entryption signature: - Ensure sender authenticity of digital signed NDA via mobile app - Setup NDA template and sign document with users private RSA-4096 key - Securely exchange users public RSA-4096 key via TLS - Transfer signed document to backend server - Verify signee of NDA via users public RSA-4096 key - Ensure failing message integrity and non-repudiation checks via tampered signatures ###### Verifying 1.2.3 Authorization via login: - 2 Factor Authentication via TOTP - Create dummy user with sensitive user data - Login to mobile app with dummy's username and password - Verify incoming text message with secure token - Verify successful login with secure token - Check failed login with wrong user credentials / wrong token / expired token #### 1.3.) Malicious application: ###### Verifying 1.3.1 File checksum for integrity check: - Ensure valid application download from trustful source - Create dummy user with sensitive user data - Send personalized download link to dummy's email adress - Access and download compressed mobile application from backend via dummy's user credentials - Ensure secure transmission of hash tag from backend via TLS - Verify integrity check before installing application - Check for failed downloads after the download link has expired. ### Verification requirements for Backend #### 2.2) Malicious tampering with credentials ###### Verifying 2.2.1) Manipulation by admin with direct administrative(root) access to the running server * List all accounts with admin privilege * Review their privileges * Review if logs on a central logging server can be deleted by the same administrator that made those actions * Perform a penetration test with administrative privilege accounts where attack covering actions (e.g. deleting logs) are performed. ###### Verifying 2.2.2) Manipulation with admin/management privilage on the credetial database * List all admin/manegement privilege accounts that can perform *dangerous* actions (new admin accounts, large database manipulation) * Try to perform dangerous accounts with single account * Review also personal interdepedency be between holders of admin/manegement accounts. (Can two of them be exterted at the same time (e.g. spouse)) #### Verifing 2.3) Vulnerable credential verification Independent security code audit and penetration test of the credential cerification. ###### 2.3.1.) Password guidelines Password that does not met the specified criteria (password length etc.) should be rejected by the backend. ### Verification requirements for Camera #### 3.1) Reading video data from cameras local storage ###### Verifying 3.1.1: Encrypted data storage - Video data stored on the local storage device can successfully be decrypted using the backend servers private storage-encryption-key. - Record a video with the camera - Take the resulting encrypted video data from the local storage device - Bring the encrypted video data to the backend server - Try to decrypt the data using the private storage-encryption-key of the server. #### 3.2) Tampering with camera process to send data to an attacker ###### Verifying 3.2.1: Secure configuration management - Users with valid credentials are able to alter the camera configuration. - Create a user and related user credentials - Use those user credentials in order to change the configuration, this should work. - Users with invalid credentials are not able to alter the camera configuration. - Create a user and related user credentials - Choose the user and try to change the configuration using different credentials, including the credentials of other users. This should not work. - Users that are not in the user management system are not able to alter the camera configuration. - Find a user that does not exist in the system - Choose any credentials, including the credentials of other users, and try to change the configuration. This should not work. ###### Verifying 3.2.2: Prevent configuration tampering - Changes in the camera configuration are stored in the camera and every user can see them. - Create two users - Make two changes to the configuration from the two users - Look at the change history - It should be possible to see which configuration changes was performed, their order have to be correct and all relevant modification information (who, when, what, old value, new value) have to be correct. - Tampering with the changelog of the camera credentials should not be possible. - Create a user - Make a change to the configuration - It should not be possible to remove that change from the log ###### Verifying 3.2.3: Secure endpoint configuration - When trying to establish a connection, the camera process actually uses the endpoint specified in its configuration. - Set the endpoint to the backend server - Check whether the camera tries to establish a connection to the backend server ###### Verifying 3.2.4: Secure backend-public-key configuration - When trying to establish a connection, the camera process actually uses the public key specified in its configuration. - Set the backend public key in the configuration - Check whether the camera tries to establish a connection using the configured public key - Set another public key in the configuration - Check whether the camera tries to establish a connection using the newly set public key ###### Verifying 3.2.5: Secure data transmission - A TLS handshake is performed correctly and the resulting session key can be used for communication. - Initiate a communication to the backend server using its public communication-key. - Check whether all the steps in the handshake are done in the correct order - Check whether all the steps in the handshake are done correctly. - Check if the resulting session key is correct. - Send a message using the session key and check if it can be correctly decrypted on the backend server. - A TLS handshake with the wrong server, or when having the incorrect public key configured, is detected and the communication is aborted without leaking any sensitive data. - Initiate a communication to a server using a different public TLS-key. - Check whether the camera process aborts communication as soon as it detects that it communicates with the wrong server. --- ## **Requirements for the usage** - An email address-based personalized download link is sent to users of the mobile application. The user can download the application by using this URL and logging in with their credentials at the download site on the backend. - After a verified download and successful installation of the mobile app, the user has to login via TOTP and a private RSA-4096 key is securely stored at the device. The corresponding public RSA-4096 key is automatically sent to the backend server once a TLS connection has been established. - The backend server needs to create and securely store a RSA-4096-private-key, the communication-key, while the corresponding public key needs to be stored inside the camera. After downloading the mobile application, the app-configuration needs to be updated with the public communication-key of the backend server as well. This key will be used from the camera and mobile application to establish a "TLS 1.3" connection. - The backend server needs to create and securely store a RSA-4096-private-key, the storage-encryption-key, while the corresponding public key needs to be securely stored inside the camera. This key will be used for hybrid RSA-4096-AES-256-GCM encryption of the video data on the cameras local storage device. - The default user-management-password on the camera process needs to be changed and each person responsible for managing the camera configuration shall receive their own local credentials in order to prevent repudiation. - The camera needs to be placed in a room that is equipped with an external access control system in order to prevent the general public from observing operating staff while entering their credentials and spoofing them afterwards. - The internet connection of the camera needs to be restricted to allow outbound requests to the backend server only in order to prevent leakage of sensitive data. - Backend server needs to be installed in a server room with sufficient physical security policy like one described in NIST SP 800-53 or similar. * Server room has to be "break-in-proof" including a break-in-prof door door. * Access has to be allowed only to authorised personel * Every access needs to be logged and periodically reviewed