# PLD Requirements
## Elements Critical to Life Support
* Give accurate constant location of user
* Gives accurate and constant life signs to main system
*

**V1** Architecture, Design and Threat Modelling Requirements - Eleanor

- Verify the use of a secure software development lifecycle that addresses security in all stages of development.
- Verify availability of a secure coding checklist, security requirements, guideline, or policy to all developers and testers.
- Verify that communications between application components, including APIs, middleware and data layers, are authenticated. Components should have the least necessary privileges needed.
- Verify that the application uses a single vetted authentication mechanism that is known to be secure, can be extended to include strong authentication, and has sufficient logging and monitoring to detect account abuse or breaches.
- Verify that input and output requirements clearly define how to handle and process data based on type, content, and applicable laws, regulations, and other policy compliance.
- Verify that there is an explicit policy for management of cryptographic keys and that a cryptographic key lifecycle follows a key management standard such as NIST SP 800-57.
- Verify that a common logging format and approach is used across the system.
- Verify that logs are securely transmitted to a preferably remote system for analysis, detection, alerting, and escalation.
- Verify that all sensitive data is identified and classified into protection levels.
- Verify that all protection levels have an associated set of protection requirements, such as encryption requirements, integrity requirements, retention, privacy and other confidentiality requirements, and that these are applied in the architecture.
- Verify the application encrypts communications between components, particularly when these components are in different containers, systems, sites, or cloud providers.
- Verify the segregation of components of differing trust levels through welldefined security controls, firewall rules, API gateways, reverse proxies, cloudbased security groups, or similar mechanisms.
- Verify that the build pipeline warns of out-of-date or insecure components and takes appropriate actions.
- Verify that the build pipeline contains a build step to automatically build and verify the secure deployment of the application, particularly if the application infrastructure is software defined, such as cloud environment build scripts.

**V2** Authentication Verification Requirements - Tommy
##### Section 2.2
- Verify that anti-automation controls are effective at mitigating breached credential testing, brute force, and account lockout attacks. Such controls include blocking the most common breached passwords, soft lockouts, rate limiting, CAPTCHA, ever increasing delays between attempts, IP address restrictions, or risk-based restrictions such as location, first login on a device, recent attempts to unlock the account, or similar. Verify that no more than 100 failed attempts per hour is possible on a single account.
- Verify that the use of weak authenticators (such as SMS and email) is limited to secondary verification and transaction approval and not as a replacement for more secure authentication methods. Verify that stronger methods are offered before weak methods, users are aware of the risks, or that proper measures are in place to limit the risks of account compromise.
- Verify impersonation resistance against phishing, such as the use of multi-factor authentication, cryptographic devices with intent (such as connected keys with a push to authenticate), or at higher AAL levels, client-side certificates.
- Verify impersonation resistance against phishing, such as the use of multi-factor authentication, cryptographic devices with intent (such as connected keys with a push to authenticate), or at higher AAL levels, client-side certificates.

##### Section 2.3
- Verify that enrollment and use of subscriber-provided authentication devices are supported, such as a U2F or FIDO tokens.

##### Section 2.4
- Verify that passwords are stored in a form that is resistant to offline attacks. Passwords SHALL be salted and hashed using an approved one- way key derivation or password hashing function. Key derivation and password hashing functions take a password, a salt, and a cost factor as inputs when generating a password hash.
- Verify that the salt is at least 32 bits in length and be chosen arbitrarily to minimize salt value collisions among stored hashes. For each credential, a unique salt value and the resulting hash SHALL be stored.

##### Section 2.8
- Verify that biometric authenticators are limited to use only as secondary factors in conjunction with either something you have and something you know.

**V3** Session Management Verification Requirements (maybe not important)

-

**V4** Access Control Verification Requirements - *Gabs*

1) Verify that access controls fail securely including when an exception occurs.

*The device WILL fail at some point due to the harsh environment and length of time they will be in use. It is crticial that when they fail there are fallbacks, such as manual overrides for the doors in case of emergency and the PLD is no longer funcitoning*

2) Verify that the principle of least privilege exists - users should only be able to access functions, data files, URLs, controllers, services, and other resources, for which they possess specific authorization. This implies protection against spoofing and elevation of privilege

*Admin actions such as configuring the device should not be available to all users*

3) Verify that sensitive data and APIs are protected against Insecure Direct Object Reference (IDOR) attacks targeting creation, reading, updating and deletion of records, such as creating or updating someone else's record, viewing everyone's records, or deleting all records.

*The door unlocking system will utilise an API and it is critical that this sytem is secure*

4) Verify administrative interfaces use appropriate multi-factor authentication to prevent unauthorized use (in this context that could be configuring the device)

*Admin actions such as configuring the device should only be done by authorised users, 2FA helps confirm this*

5) Verify that the principle of deny by default exists whereby new users/roles start with minimal or no permissions and users/roles do not receive access to new features until access is explicitly assigned.

**V5** Validation, Sanitization and Encoding Verification Requirements - *Tom*

1) Verify that deserialization of untrusted data is avoided or is protected in both custom code and third-party libraries
2) Verify that serialized objects use integrity checks or are encrypted to prevent hostile object creation or data tampering.

**V6** Stored Cryptography Verification Requirements
- Verify that regulated private data is stored encrypted while at rest, such as Personally Identifiable Information (PII), sensitive personal information, or data assessed likely to be subject to EU's GDPR.
- Verify that regulated health data is stored encrypted while at rest, such as medical records, medical device details, or de-anonymised research records.
- Verify that all cryptographic modules fail securely, and errors are handled in a way that does not enable Padding Oracle attacks.
- Verify that industry proven cryptographic algorithms, modes, and libraries are used, instead of custom coded cryptography.
- Verify that encryption initialisation vector, cipher configuration, and block modes are configured securely using the latest advice.
- Verify that random number, encryption, or hashing algorithms, key lengths, rounds, cipher or modes, can be reconfigured, upgraded, or swapped at any time, to protect aainst cryptographic breaks.
- Verify that known insecure block modes, padding modes, ciphers with small block sizes, and weak hashing algorithms are not used unless required for backwards compatability.
- Verify that nonces, initialisation vectors, and other single use numbers must not be used more than once with a given encryption key. The method of generation must be appropriate for the algorithm being used.
- Verify that encrypted data is authenticated via signatures, authenticated cipher modes, or HMAC to ensure that ciphertext is not altered by an unauthorized party.
- Verify that all cryptographic operations are constant-time, with no 'short-circuit' operations in comparisons, calculations, or returns, to avoid leaking information.

1) Verify that regulated health data is stored encrypted while at rest, such as medical records, medical device details, or de-anonymised research records.
2) Verify that regulated private data is stored encrypted while at rest, such as Personally Identifiable Information (PII), sensitive personal information, or data assessed likely to be subject to EU's GDPR.
3) Verify that industry proven cryptographic algorithms, modes, and libraries are used, instead of custom coded cryptography.
4) Verify that known insecure block modes, padding modes, ciphers with small block sizes, and weak hashing algorithms are not used unless required for backwards compatability.
5) Verify that random number, encryption, or hashing algorithms, key lengths, rounds, cipher or modes, can be reconfigured, upgraded, or swapped at any time, to protect aainst cryptographic breaks.
6) Verify that encrypted data is authenticated via signatures, authenticated cipher modes, or HMAC to ensure that ciphertext is not altered by an unauthorized party.
7) Verify that all cryptographic operations are constant-time, with no 'short-circuit' operations in comparisons, calculations, or returns, to avoid leaking information.

**V7** Error Handling and Logging Verification Requirements
*Alex*
- Verify that a common logging format and approach is used across the system.
- Verify that logs are securely transmitted to a preferably remote system for analysis, detection, alerting, and escalation.
- Verify that the application does not log credentials or payment details. Session tokens should only be stored in logs in an irreversible, hashed form
- Verify that the application does not log other sensitive data as defined under local privacy laws or relevant security policy.
- Verify that the application logs security relevant events including successful and failed authentication events, access control failures, deserialization failures and input validation failures.
- Verify that each log event includes necessary information that would allow for a detailed investigation of the timeline when an event happens.

**V8** Data Protection Verification Requirements - *Nathan*
- Confidentiality: Data should be protected from unauthorized observation or disclosure both in transit and when stored.
- Integrity: Data should be protected from being maliciously created, altered or deleted by unauthorized attackers.
- Availability: Data should be available to authorized users as required.
- Verify that all sensitive data is identified and classified into protection levels
- Verify that all protection levels have an associated set of protection requirements, such as encryption requirements, integrity requirements, retention, privacy and other confidentiality requirements, and that these areapplied in the architecture
- Verify that sensitive information contained in memory is overwritten as soon as it is no longer required to mitigate memory dumping attacks, using zeroes or random data
-

**V9** Communications Verification Requirements -
*alex*
- Verify the application encrypts communications between components, particularly when these components are in different containers, systems, sites, or cloud providers.
- Verify that application components verify the authenticity of each side in a communication link to prevent person-in-the-middle attacks. For example, application components should validate TLS certificates and chains.
**V10** Malicious Code Verification Requirements

**V11** Business Logic Verification Requirements (probably not important)

**V12** File and Resources Verification Requirements
- Seems all web-based

**V13** API and Web Service Verification Requirements (if we dont use http then not very important) (will probably have an API though)

- Seems all web-based

**V14** Configuration Verification Requirements *Tom*

1) Verify that authorized administrators can verify the integrity of all security-relevant configurations to detect tampering.
2) Verify that all components are up to date, preferably using a dependency checker during build or compile time.
3) Verify that the application, configuration, and all dependencies can be re-deployed using automated deployment scripts, built from a documented and tested runbook in a reasonable time, or restored from backups in a timely fashion.
4) Verify that compiler flags are configured to enable all available buffer overflow protections and warnings, including stack randomization, data execution prevention, and to break the build if an unsafe pointer, memory, format string, integer, or string operations are found.
5) Verify that the application build and deployment processes are performed in a secure and repeatable way, such as CI / CD automation, automated configuration management, and automated deployment scripts.
6) Verify that all unneeded features, documentation, samples, configurations are removed, such as sample applications, platform documentation, and default or example users.