Commit 0b1ec244 authored by Valerie Aurora (Bow Shock)'s avatar Valerie Aurora (Bow Shock)
Browse files

Move notes on security requirements into Notes annex

parent 6e5da5c4

EN-304-626.md

+242 −244
Original line number Diff line number Diff line
@@ -1833,250 +1833,6 @@ _Description of mitigation implementing the requirement in "shall" format._ 
|---------------------|----------------------|

|                     |                      |



### NOTES



Could requirements be tested by checking for the configuration options? Or do we want to give some instructions to the manufacturer on how to tell what settings or features will satisfy the requirements?



https://kspp.github.io/Recommended_Settings



Technical requirements notes/sources:



Guidance on tools (see English translation in annex):



https://cyber.gouv.fr/sites/default/files/2022-10/anssi-cc-note-26v1.0-methodologie-analyse-de-code_v0.3-fr%5B1%5D.pdf



From BSI tests for Windows:



https://www.bsi.bund.de/EN/Service-Navi/Publikationen/Studien/SiSyPHuS_Win10/AP2/SiSyPHuS_AP2_node.html



https://www.bsi.bund.de/EN/Service-Navi/Publikationen/Studien/SiSyPHuS_Win10/SiSyPHuS_node.html



https://www.bsi.bund.de/EN/Service-Navi/Publikationen/Studien/SiSyPHuS_Win10/AP5/SiSyPHuS_AP5.html



https://www.bsi.bund.de/EN/Service-Navi/Publikationen/Studien/SiSyPHuS_Win10/AP10/SiSyPHuS_AP10.html



From NIAP PP for OS:



* Cryptographic support

  * Cryptographic key generation

  * Cryptographic key establishment

  * Cryptographic key destruction

  * Encryption/decryption

  * Cryptographic hashing/signing/authentication

  * Random data generation

  * Secure encrypted data storage

* User data protection

  * Access controls

  * VPN

* Security management

  * Management of security functions

  * Minimum security functions provided by user type

* Protection of security relevant assets (?)

  * Access controls to system data/assets

  * Address space layout randomization

  * Limitation of Bluetooth Profile Support

  * Software Restriction Policies

  * Stack buffer overflow protection

  * Boot integrity

  * Trusted update for OS

  * Trusted update for applications and other components

  * Read-only executable memory

* Audit data generation

  * Logging with timestamps

* Identification and authorization

  * Prevent brute force

  * Multifactor auth

  * Certificate validation

  * Certificate authentication

* Trusted paths/channels

  * Allows communication via secure channel (TLS etc.)



From BSI Operating Systems Protection Profile:



* Audit

  * Audit data generation

  * Audit review

  * Audit review restriction

  * Protected audit data storage

  * Notification of possible audit data loss

  * Prevention of possible audit data loss

* Cryptographic services

  * Cryptographic key generation

  * Cryptographic key distribution

  * Cryptographic key destruction

  * Cryptographic operation

* Data access control

  * Access control of persistent data (files)

  * Access control of temporay data (pipes)

  * Network information flow control

  * Import user data with access control

  * Secure deletion

* Authentication

  * Detect and prevent brute force attacks on auth

  * User attribute storage

  * Secret verification

  * Auth before accessing any security functions

  * Multifactor auth

  * Obscure auth feedback

  * Identification before access

* Secure configuration change and data access

  * Something about ACLs?

  * Security roles

* Reliable timestamps

* Session locking

  * Automatic

  * User-initiated

* Trusted channel (secure network access)



From Ubuntu Security Features:

* Privilege restriction

  * DAC / MAC

    * AppArmor

    * SELinux

    * SMACK

  * process privilege restrictions

    * PR_SET_SECCOMP

    * seccomp filtering

  * file system capabilities

* Storage and Filesystem

  * Full Disk Encryption

  * LVM Encryption

  * File Encryption

* Network and Firewalls

  * No Open Ports

  * SYN cookies

  * Firewall

* Cryptography

  * Password Hashing

  * Cloud PRNG Seed

  * Disabling Legacy TLS

* Process and memory protection

  * Sym-/Hard-Link restrictions

  * FIFO restrictions

  * (process-internal) memory protection

  * Stack Protector

  * Heap Protector

  * Stack ASLR

  * Libs/mmap ASLR

  * Exec ASLR

  * brk ASLR

  * vDOS ASLR

  * Default compiler and linker flags

    * Built as PIE

    * Built with Fortify Source

    * Built with RELRO

    * Built with BIND_NOW

    * Built with -fstack-clash-protection

    * Built with -fcf-protection

  * Non-Executable Memory

  * /proc/$pid/maps protection

  * ptrace scope

  * 0-address protection

  * /dev/mem protection

* Kernel protections

  * Kernel Lockdown

  * /dev/kmem disabled

  * Block module loading

  * Read-only data sections

  * Kernel Stack protector

  * Module RO/NX

  * Kernel Address Display Restriction

  * kASLR

  * denylist rare protocols

  * dmesg restriction

  * Block kexec

* Platform protections

  * UEFI Secure Boot

  * usb-related

    * usbguard

    * usbauth

    * bolt

    * thunderbolt-tools

  * TPM

* Security updates

  * Livepatch

  * Automatic security updates



Random ideas



* Disable debugging interfaces in many many places

* TPM and TEE support

* Secure boot/ crypto authenticated boot

* Measured boot

* Remote attestion

* Don't require login to online account

* Make rules about opt-in being required

* Everything shipped/included by manufacturer is the responsibility of the manufacturer (would cut down on junkware)

* Opt-in for all network functionality

* What about commonly disabled features for minimization



Potential additional sources of security requirements



* [NCP Checklists](https://ncp.nist.gov/repository)

* MSCERT (?)

* [MITRE EMB3D](https://emb3d.mitre.org/):

* https://trustedcomputinggroup.org/resources/

* https://trustedcomputinggroup.org/wp-content/uploads/TCG-Secure-Update-of-SW-and-FW-on-Devices-v1r72_pub.pdf

* Read exploit reports and CVEs

* [ETSI EN 303 645](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/03.01.03_60/en_303645v030103p.pdf)

* [CHERI BSD](https://www.cheribsd.org/)

* [ETSI EN 103 732](https://portal.etsi.org/webapp/workprogram/Report_WorkItem.asp?WKI_ID=69549)



Probably the most digestible is Ubuntu:

https://documentation.ubuntu.com/security/docs/security-features/



they have the "qa regression test" suite, which has a bunch of

security testing (search "security" in here):

https://git.launchpad.net/qa-regression-testing/tree/scripts



for example, config testing:

https://git.launchpad.net/qa-regression-testing/tree/scripts/test-kernel-security.py



behavioral testing:

https://git.launchpad.net/qa-regression-testing/tree/scripts/kernel-security





Chrome OS security principles:

https://www.chromium.org/chromium-os/developer-library/reference/security/security-whitepaper/#principles-of-chromeos-security



Much of the Chrome OS testing has been slowly getting merged into the

much more complex Android stuff below...



Android. This is weird to navigate, but start here:

https://source.android.com/docs/security/overview



on the left will be "Kernel security", "App security", "Implement

security". Linked in there is the Compatibility Definition Document

(CDD), which is "you have to do this to say you're and 'Android' device":

https://source.android.com/docs/compatibility/cdd



The latest is 16:

https://source.android.com/docs/compatibility/16/android-16-cdd



the CDD has an extensive security section:

https://source.android.com/docs/compatibility/16/android-16-cdd#9_security_model_compatibility



including specific features:

https://source.android.com/docs/compatibility/16/android-16-cdd#97_security_features



The _testing_ for the CDD is the Android Compatibility Test Suite (CTS):

https://source.android.com/docs/compatibility/cts



Which has kernel security tests, for example, though it is a bit minimal:

https://cs.android.com/android/platform/superproject/+/android-latest-release:cts/hostsidetests/security/src/android/security/cts/KernelConfigTest.java



**Hardware-Based Countermeasures**



* Secure boot with HW Root of Trust: Ensures that only authenticated firmware is executed, anchored in immutable hardware

* Hardware-backed Key Storage (e.g., TPM, Secure Enclave): Protects cryptographic keys from software-level attacks and unauthorized access

* Memory Protection Units (MPU and/or MMU): Enforces access control policies at hardware level, isolating critical OS components

* Hardware-enforced Execution Zones (e.g., ARM TEE): Enables secure execution environments for sensitive operations.

* Bootloader Locking and Firmware/SW Anti-rollback: Prevents downgrading to vulnerable firmware/SW versions.

* Hardware Watchdog Timers: Detects and recovers from system hangs or malicious loops

* Secure Debug Interface Management: Disabling or restricting access through state-of-the-art security mechanisms debug access







## 5.3 Risk Mitigation Sets



> **TODO**: Connect the technical security requirements in clause 5.2 to specific Risk Factors, and define these as sets of Risk Mitigations that will be referenced in clause 6.
@@ -2698,6 +2454,248 @@ Special case of verified/measured boot partially implemented outside the operati 


Special case configuration files? Not code in most cases, but substantial impact on the security configuration of the operating system.



### NOTES



Could requirements be tested by checking for the configuration options? Or do we want to give some instructions to the manufacturer on how to tell what settings or features will satisfy the requirements?



https://kspp.github.io/Recommended_Settings



Technical requirements notes/sources:



Guidance on tools (see English translation in annex):



https://cyber.gouv.fr/sites/default/files/2022-10/anssi-cc-note-26v1.0-methodologie-analyse-de-code_v0.3-fr%5B1%5D.pdf



From BSI tests for Windows:



https://www.bsi.bund.de/EN/Service-Navi/Publikationen/Studien/SiSyPHuS_Win10/AP2/SiSyPHuS_AP2_node.html



https://www.bsi.bund.de/EN/Service-Navi/Publikationen/Studien/SiSyPHuS_Win10/SiSyPHuS_node.html



https://www.bsi.bund.de/EN/Service-Navi/Publikationen/Studien/SiSyPHuS_Win10/AP5/SiSyPHuS_AP5.html



https://www.bsi.bund.de/EN/Service-Navi/Publikationen/Studien/SiSyPHuS_Win10/AP10/SiSyPHuS_AP10.html



From NIAP PP for OS:



* Cryptographic support

  * Cryptographic key generation

  * Cryptographic key establishment

  * Cryptographic key destruction

  * Encryption/decryption

  * Cryptographic hashing/signing/authentication

  * Random data generation

  * Secure encrypted data storage

* User data protection

  * Access controls

  * VPN

* Security management

  * Management of security functions

  * Minimum security functions provided by user type

* Protection of security relevant assets (?)

  * Access controls to system data/assets

  * Address space layout randomization

  * Limitation of Bluetooth Profile Support

  * Software Restriction Policies

  * Stack buffer overflow protection

  * Boot integrity

  * Trusted update for OS

  * Trusted update for applications and other components

  * Read-only executable memory

* Audit data generation

  * Logging with timestamps

* Identification and authorization

  * Prevent brute force

  * Multifactor auth

  * Certificate validation

  * Certificate authentication

* Trusted paths/channels

  * Allows communication via secure channel (TLS etc.)



From BSI Operating Systems Protection Profile:



* Audit

  * Audit data generation

  * Audit review

  * Audit review restriction

  * Protected audit data storage

  * Notification of possible audit data loss

  * Prevention of possible audit data loss

* Cryptographic services

  * Cryptographic key generation

  * Cryptographic key distribution

  * Cryptographic key destruction

  * Cryptographic operation

* Data access control

  * Access control of persistent data (files)

  * Access control of temporay data (pipes)

  * Network information flow control

  * Import user data with access control

  * Secure deletion

* Authentication

  * Detect and prevent brute force attacks on auth

  * User attribute storage

  * Secret verification

  * Auth before accessing any security functions

  * Multifactor auth

  * Obscure auth feedback

  * Identification before access

* Secure configuration change and data access

  * Something about ACLs?

  * Security roles

* Reliable timestamps

* Session locking

  * Automatic

  * User-initiated

* Trusted channel (secure network access)



From Ubuntu Security Features:

* Privilege restriction

  * DAC / MAC

    * AppArmor

    * SELinux

    * SMACK

  * process privilege restrictions

    * PR_SET_SECCOMP

    * seccomp filtering

  * file system capabilities

* Storage and Filesystem

  * Full Disk Encryption

  * LVM Encryption

  * File Encryption

* Network and Firewalls

  * No Open Ports

  * SYN cookies

  * Firewall

* Cryptography

  * Password Hashing

  * Cloud PRNG Seed

  * Disabling Legacy TLS

* Process and memory protection

  * Sym-/Hard-Link restrictions

  * FIFO restrictions

  * (process-internal) memory protection

  * Stack Protector

  * Heap Protector

  * Stack ASLR

  * Libs/mmap ASLR

  * Exec ASLR

  * brk ASLR

  * vDOS ASLR

  * Default compiler and linker flags

    * Built as PIE

    * Built with Fortify Source

    * Built with RELRO

    * Built with BIND_NOW

    * Built with -fstack-clash-protection

    * Built with -fcf-protection

  * Non-Executable Memory

  * /proc/$pid/maps protection

  * ptrace scope

  * 0-address protection

  * /dev/mem protection

* Kernel protections

  * Kernel Lockdown

  * /dev/kmem disabled

  * Block module loading

  * Read-only data sections

  * Kernel Stack protector

  * Module RO/NX

  * Kernel Address Display Restriction

  * kASLR

  * denylist rare protocols

  * dmesg restriction

  * Block kexec

* Platform protections

  * UEFI Secure Boot

  * usb-related

    * usbguard

    * usbauth

    * bolt

    * thunderbolt-tools

  * TPM

* Security updates

  * Livepatch

  * Automatic security updates



Random ideas



* Disable debugging interfaces in many many places

* TPM and TEE support

* Secure boot/ crypto authenticated boot

* Measured boot

* Remote attestion

* Don't require login to online account

* Make rules about opt-in being required

* Everything shipped/included by manufacturer is the responsibility of the manufacturer (would cut down on junkware)

* Opt-in for all network functionality

* What about commonly disabled features for minimization



Potential additional sources of security requirements



* [NCP Checklists](https://ncp.nist.gov/repository)

* MSCERT (?)

* [MITRE EMB3D](https://emb3d.mitre.org/):

* https://trustedcomputinggroup.org/resources/

* https://trustedcomputinggroup.org/wp-content/uploads/TCG-Secure-Update-of-SW-and-FW-on-Devices-v1r72_pub.pdf

* Read exploit reports and CVEs

* [ETSI EN 303 645](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/03.01.03_60/en_303645v030103p.pdf)

* [CHERI BSD](https://www.cheribsd.org/)

* [ETSI EN 103 732](https://portal.etsi.org/webapp/workprogram/Report_WorkItem.asp?WKI_ID=69549)



Probably the most digestible is Ubuntu:

https://documentation.ubuntu.com/security/docs/security-features/



they have the "qa regression test" suite, which has a bunch of

security testing (search "security" in here):

https://git.launchpad.net/qa-regression-testing/tree/scripts



for example, config testing:

https://git.launchpad.net/qa-regression-testing/tree/scripts/test-kernel-security.py



behavioral testing:

https://git.launchpad.net/qa-regression-testing/tree/scripts/kernel-security





Chrome OS security principles:

https://www.chromium.org/chromium-os/developer-library/reference/security/security-whitepaper/#principles-of-chromeos-security



Much of the Chrome OS testing has been slowly getting merged into the

much more complex Android stuff below...



Android. This is weird to navigate, but start here:

https://source.android.com/docs/security/overview



on the left will be "Kernel security", "App security", "Implement

security". Linked in there is the Compatibility Definition Document

(CDD), which is "you have to do this to say you're and 'Android' device":

https://source.android.com/docs/compatibility/cdd



The latest is 16:

https://source.android.com/docs/compatibility/16/android-16-cdd



the CDD has an extensive security section:

https://source.android.com/docs/compatibility/16/android-16-cdd#9_security_model_compatibility



including specific features:

https://source.android.com/docs/compatibility/16/android-16-cdd#97_security_features



The _testing_ for the CDD is the Android Compatibility Test Suite (CTS):

https://source.android.com/docs/compatibility/cts



Which has kernel security tests, for example, though it is a bit minimal:

https://cs.android.com/android/platform/superproject/+/android-latest-release:cts/hostsidetests/security/src/android/security/cts/KernelConfigTest.java



**Hardware-Based Countermeasures**



* Secure boot with HW Root of Trust: Ensures that only authenticated firmware is executed, anchored in immutable hardware

* Hardware-backed Key Storage (e.g., TPM, Secure Enclave): Protects cryptographic keys from software-level attacks and unauthorized access

* Memory Protection Units (MPU and/or MMU): Enforces access control policies at hardware level, isolating critical OS components

* Hardware-enforced Execution Zones (e.g., ARM TEE): Enables secure execution environments for sensitive operations.

* Bootloader Locking and Firmware/SW Anti-rollback: Prevents downgrading to vulnerable firmware/SW versions.

* Hardware Watchdog Timers: Detects and recovers from system hangs or malicious loops

* Secure Debug Interface Management: Disabling or restricting access through state-of-the-art security mechanisms debug access



# Annex F (informative): Change history



The "Change history/Change request (history)" annex shall be included in every revised or amended harmonised standard and shall contain information concerning significant changes that have been introduced by it. It shall be presented as a table.