Remove all risk factor mappings from requirements (d3e7d0d4) · Commits · STAN4CRA / EN 304 626 Operating Systems

EN-304-626.md

+6 −102

Original line number	Diff line number	Diff line
		@@ -698,14 +698,6 @@ _Description of mitigation implementing the requirement in "shall" format._

		[Any other mitigations available]

		\| Risk factors \| Requires mitigations \|
		\|---------------------\|----------------------\|
		\| \| \|

		\| Security Profile \| Requires mitigations \|
		\|---------------------\|----------------------\|
		\| \| \|

		## 5.2 Technical security requirements specifications

		### 5.2.1 General
		@@ -950,30 +942,9 @@ The documentation provided to the user shall document the risk of microarchitect
		* Verdict: Documentation sufficiently describes the risks and mitigations => PASS, otherwise FAIL
		* Evidence: Documentation provided with the product


		#### 5.2.X.x Mapping of mitigations to risk factors and security profiles

		Mitigations satisfy technical requirements only under when they mitigate the relevant risks appropriately. Risk factors are used to determine this. The below table shows which mitigations are appropriate to which use cases or security profiles based on the risk factors determined in the risk assessment.

		\| Risk factors \| Requires mitigations \|
		\|---------------------\|--------------------------\|
		\| all risk factors 0 \| None \|
		\| CUSR = 0 & SWMD = 0 \| SSCA \|
		\| CUSR < 3 & SWMD < 2 \| SSCA, MMAC \|
		\| CUSR < 2 \| SSCA, MMAC, CCON or UCON \|
		\| CUSR > 2 & RT-High \| SSCA, MMAC \|
		\| CUSR > 2 & ADMN < 2 \| SSCA, MMAC, TRMD or PMSC \|
		\| CUSR > 2 & ADMN > 1 \| SSCA, MMAC, PMSC \|

		\| Security Profile \| Requires mitigations \|
		\|--------------------------------------------------\|--------------------------\|
		\| LR \| None \|
		\| IoT-\, OT-\ \| SSCA \|
		\| WE-1, ST-1, PC-\, LA-\, SE-\[1,2] IF-\, FI-\ \| SSCA, MMAC \|
		\| MOB-\* \| SSCA, MMAC, CCON or UCON \|
		\| SE-3 \| SSCA, MMAC, TRMD or PMSC \|

		> TODO: Consistency check above
		See Section 5.3 for which mitigations are necessary for which security profiles and Annex C.4 for the rationale.

		### 5.2.X TR-MIME: Mitigate memory errors

		@@ -999,16 +970,6 @@ The product shall enable Address Space Layout Randomization (ASLR) by default fo

		* Evidence: Output of scan for ALSR enabled, base addresses collected

		\| Risk factors \| Requires mitigations \|
		\|---------------------\|----------------------\|
		\| RT-High \| none \|
		\| RT-Med, RT-Low \| ALSR \|

		\| Security Profile \| Requires mitigations \|
		\|----------------------\|----------------------\|
		\| FIXME list RT-High \| none \|
		\| FIXME RT-Med, RT-Low \| ALSR \|

		### 5.2.3 TR-LMII: Limit incident impact

		#### 5.2.3.1 Requirement
		@@ -1562,18 +1523,7 @@ All exposed interfaces on the product in any state that is part of its reasonabl

		#### 5.2.X.x Mapping of mitigations to risk factors and security profiles

		\| Risk factors \| Requires mitigations \|
		\|-----------------------------------------------------------------\|----------------------\|
		\| RT-High \| none \|
		\| PHYS < 1 & CUSR < 2 & UEIN < 1 & SWMD < 1 & TNET < 1 & FNET < 2 \| none \|
		\| any \| JSTY \|

		\| Security Profile \| Requires mitigations \|
		\|------------------\|----------------------\|
		\| RT-High \| none \|
		\| any \| JSTY \|

		> FIXME: When full use case risk factor and tolerances are available, update above table.
		See Section 5.3 for which mitigations are necessary for which security profiles and Annex C.4 for the rationale.

		### 5.2.X TR-LOGG: Logging and monitoring

		@@ -1594,18 +1544,6 @@ The product shall record log messages indicating security-relevant internal even

		Guidance: One type of event whose log message must take care to not accidentally include a secret is failed password authentication attempts. Since people often type their password into the username field, including the username field in the log message may result in including a secret in the log message.

		\| Risk factors \| Requires mitigations \|
		\|--------------------------------\|----------------------\|
		\| SNDS < 1 & SNDS < 1 & SENF < 1 \| none \|
		\| all others \| LOGG \|

		\| Security Profile \| Requires mitigations \|
		\|------------------\|----------------------\|
		\| FIXME \| none \|
		\| all others \| LOGG \|

		> FIXME: Update when risk factors are updated

		### 5.2.X TR-SCDL: Secure deletion

		#### 5.2.X.x Requirement
		@@ -1650,6 +1588,8 @@ The product shall reset to its secure-by-default state after a reinstallation th

		The product shall reset to its secure-by-default state after the secure deletion function is used.

		> TODO: Make the method of deletion depend on risk tolerance (low or med: simple reformat, high: overwrite once or delete key to encryped storage)

		* Reference: TR-SCDL

		* Objective: Secure deletion
		@@ -1664,17 +1604,7 @@ The product shall reset to its secure-by-default state after the secure deletion

		#### 5.2.X.x Mapping of mitigations to risk factors and security profiles

		\| Risk factors \| Requires mitigations \|
		\|--------------\|----------------------\|
		\| SNDS < 1 \| None \|
		\| all others \| RSET or INST or DELE \|

		\| Security Profile \| Requires mitigations \|
		\|------------------\|----------------------\|
		\| LR, IoT-1 \| None \|
		\| all others \| RSET or INST or DELE \|

		> FIXME: Make the method of deletion depend on risk tolerance (low or med: simple reformat, high: overwrite once or delete key to encryped storage)
		See Section 5.3 for which mitigations are necessary for which security profiles and Annex C.4 for the rationale.

		### 5.2.X TR-SDTR: Secure data read and transfer

		@@ -1716,17 +1646,7 @@ The product shall provide a method by which an authorized user can securely tran

		#### 5.2.X.x Mapping of mitigations to risk factors and security profiles

		\| Risk factors \| Requires mitigations \|
		\|---------------------\|----------------------\|
		\| DATA < 1 & CONF < 2 \| None \|
		\| DATA < 2 & CONF < 2 \| SDRF \|
		\| all others \| SDRF & SDTR \|

		\| Security Profile \| Requires mitigations \|
		\|--------------------\|----------------------\|
		\| LR, IoT-1, UC-OT-2 \| None \|
		\| IoT-3, WE-1 \| SDRF \|
		\| all others \| SDRF & SDTR \|
		See Section 5.3 for which mitigations are necessary for which security profiles and Annex C.4 for the rationale.

		### 5.2.X TR-MIMP: Impact minimization

		@@ -1756,22 +1676,6 @@ The product shall mitigate abuse of network services that amplify network traffi
		* Verdict: Every method of sending network data is documented with how its impact on others has been mitigated => PASS, otherwise FAIL
		* Evidence: All configuration files for network services, documentation of network services and their impact and methods to minimise it, internal lists of listening ports, results of an external port scan, calculation of traffic amplification factors

		\| Risk factors \| Requires mitigations \|
		\|---------------------\|----------------------\|
		\| TNET < 1 & FNET < 1 \| none \|
		\| TNET > 0 \| MNET \|
		\| FNET > 0 \| MAMP \|

		\| Security Profile \| Requires mitigations \|
		\|------------------\|----------------------\|
		\| LR, IoT-1 \| none \|
		\| IoT-2, IoT-3 \| MNET \|
		\| all others \| MNET, MAMP \|

		### 5.2.X Additional requirements

		> TODO: Look at the [notes.md](notes.md) document for ideas for requirements to write.

		## 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.

Original line number	Diff line number	Diff line
		@@ -698,14 +698,6 @@ _Description of mitigation implementing the requirement in "shall" format._

		[Any other mitigations available]

		\| Risk factors \| Requires mitigations \|
		\|---------------------\|----------------------\|
		\| \| \|

		\| Security Profile \| Requires mitigations \|
		\|---------------------\|----------------------\|
		\| \| \|

		## 5.2 Technical security requirements specifications

		### 5.2.1 General
		@@ -950,30 +942,9 @@ The documentation provided to the user shall document the risk of microarchitect
		* Verdict: Documentation sufficiently describes the risks and mitigations => PASS, otherwise FAIL
		* Evidence: Documentation provided with the product


		#### 5.2.X.x Mapping of mitigations to risk factors and security profiles

		Mitigations satisfy technical requirements only under when they mitigate the relevant risks appropriately. Risk factors are used to determine this. The below table shows which mitigations are appropriate to which use cases or security profiles based on the risk factors determined in the risk assessment.

		\| Risk factors \| Requires mitigations \|
		\|---------------------\|--------------------------\|
		\| all risk factors 0 \| None \|
		\| CUSR = 0 & SWMD = 0 \| SSCA \|
		\| CUSR < 3 & SWMD < 2 \| SSCA, MMAC \|
		\| CUSR < 2 \| SSCA, MMAC, CCON or UCON \|
		\| CUSR > 2 & RT-High \| SSCA, MMAC \|
		\| CUSR > 2 & ADMN < 2 \| SSCA, MMAC, TRMD or PMSC \|
		\| CUSR > 2 & ADMN > 1 \| SSCA, MMAC, PMSC \|

		\| Security Profile \| Requires mitigations \|
		\|--------------------------------------------------\|--------------------------\|
		\| LR \| None \|
		\| IoT-\, OT-\ \| SSCA \|
		\| WE-1, ST-1, PC-\, LA-\, SE-\[1,2] IF-\, FI-\ \| SSCA, MMAC \|
		\| MOB-\* \| SSCA, MMAC, CCON or UCON \|
		\| SE-3 \| SSCA, MMAC, TRMD or PMSC \|

		> TODO: Consistency check above
		See Section 5.3 for which mitigations are necessary for which security profiles and Annex C.4 for the rationale.

		### 5.2.X TR-MIME: Mitigate memory errors

		@@ -999,16 +970,6 @@ The product shall enable Address Space Layout Randomization (ASLR) by default fo

		* Evidence: Output of scan for ALSR enabled, base addresses collected

		\| Risk factors \| Requires mitigations \|
		\|---------------------\|----------------------\|
		\| RT-High \| none \|
		\| RT-Med, RT-Low \| ALSR \|

		\| Security Profile \| Requires mitigations \|
		\|----------------------\|----------------------\|
		\| FIXME list RT-High \| none \|
		\| FIXME RT-Med, RT-Low \| ALSR \|

		### 5.2.3 TR-LMII: Limit incident impact

		#### 5.2.3.1 Requirement
		@@ -1562,18 +1523,7 @@ All exposed interfaces on the product in any state that is part of its reasonabl

		#### 5.2.X.x Mapping of mitigations to risk factors and security profiles

		\| Risk factors \| Requires mitigations \|
		\|-----------------------------------------------------------------\|----------------------\|
		\| RT-High \| none \|
		\| PHYS < 1 & CUSR < 2 & UEIN < 1 & SWMD < 1 & TNET < 1 & FNET < 2 \| none \|
		\| any \| JSTY \|

		\| Security Profile \| Requires mitigations \|
		\|------------------\|----------------------\|
		\| RT-High \| none \|
		\| any \| JSTY \|

		> FIXME: When full use case risk factor and tolerances are available, update above table.
		See Section 5.3 for which mitigations are necessary for which security profiles and Annex C.4 for the rationale.

		### 5.2.X TR-LOGG: Logging and monitoring

		@@ -1594,18 +1544,6 @@ The product shall record log messages indicating security-relevant internal even

		Guidance: One type of event whose log message must take care to not accidentally include a secret is failed password authentication attempts. Since people often type their password into the username field, including the username field in the log message may result in including a secret in the log message.

		\| Risk factors \| Requires mitigations \|
		\|--------------------------------\|----------------------\|
		\| SNDS < 1 & SNDS < 1 & SENF < 1 \| none \|
		\| all others \| LOGG \|

		\| Security Profile \| Requires mitigations \|
		\|------------------\|----------------------\|
		\| FIXME \| none \|
		\| all others \| LOGG \|

		> FIXME: Update when risk factors are updated

		### 5.2.X TR-SCDL: Secure deletion

		#### 5.2.X.x Requirement
		@@ -1650,6 +1588,8 @@ The product shall reset to its secure-by-default state after a reinstallation th

		The product shall reset to its secure-by-default state after the secure deletion function is used.

		> TODO: Make the method of deletion depend on risk tolerance (low or med: simple reformat, high: overwrite once or delete key to encryped storage)

		* Reference: TR-SCDL

		* Objective: Secure deletion
		@@ -1664,17 +1604,7 @@ The product shall reset to its secure-by-default state after the secure deletion

		#### 5.2.X.x Mapping of mitigations to risk factors and security profiles

		\| Risk factors \| Requires mitigations \|
		\|--------------\|----------------------\|
		\| SNDS < 1 \| None \|
		\| all others \| RSET or INST or DELE \|

		\| Security Profile \| Requires mitigations \|
		\|------------------\|----------------------\|
		\| LR, IoT-1 \| None \|
		\| all others \| RSET or INST or DELE \|

		> FIXME: Make the method of deletion depend on risk tolerance (low or med: simple reformat, high: overwrite once or delete key to encryped storage)
		See Section 5.3 for which mitigations are necessary for which security profiles and Annex C.4 for the rationale.

		### 5.2.X TR-SDTR: Secure data read and transfer

		@@ -1716,17 +1646,7 @@ The product shall provide a method by which an authorized user can securely tran

		#### 5.2.X.x Mapping of mitigations to risk factors and security profiles

		\| Risk factors \| Requires mitigations \|
		\|---------------------\|----------------------\|
		\| DATA < 1 & CONF < 2 \| None \|
		\| DATA < 2 & CONF < 2 \| SDRF \|
		\| all others \| SDRF & SDTR \|

		\| Security Profile \| Requires mitigations \|
		\|--------------------\|----------------------\|
		\| LR, IoT-1, UC-OT-2 \| None \|
		\| IoT-3, WE-1 \| SDRF \|
		\| all others \| SDRF & SDTR \|
		See Section 5.3 for which mitigations are necessary for which security profiles and Annex C.4 for the rationale.

		### 5.2.X TR-MIMP: Impact minimization

		@@ -1756,22 +1676,6 @@ The product shall mitigate abuse of network services that amplify network traffi
		* Verdict: Every method of sending network data is documented with how its impact on others has been mitigated => PASS, otherwise FAIL
		* Evidence: All configuration files for network services, documentation of network services and their impact and methods to minimise it, internal lists of listening ports, results of an external port scan, calculation of traffic amplification factors

		\| Risk factors \| Requires mitigations \|
		\|---------------------\|----------------------\|
		\| TNET < 1 & FNET < 1 \| none \|
		\| TNET > 0 \| MNET \|
		\| FNET > 0 \| MAMP \|

		\| Security Profile \| Requires mitigations \|
		\|------------------\|----------------------\|
		\| LR, IoT-1 \| none \|
		\| IoT-2, IoT-3 \| MNET \|
		\| all others \| MNET, MAMP \|

		### 5.2.X Additional requirements

		> TODO: Look at the [notes.md](notes.md) document for ideas for requirements to write.

		## 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.