5.2.6 Protection of the TSF (FPT)

[mafgani]

Comment Type	Comments	Rationale
A	FPT_W^X_EXT.1 has not been added to SFRs yet.	FPT_W^X_EXT.1 is referenced in the SFR rationale table as a mitigation against T.NETWORK_ATTACK

[destineeb]

comment from TC: I do believe in my opinion that having strong mitigations against a network device web application's exploitation based attacks are important LiFi networking devices. The SFRs and EAs should be applied similar to how Application PP has them implemented under FPT_AEX_EXT.1 Anti-Exploitation Capabilities .

recommended changes would be to use FPT_AEX_EXT.1 Anti-Exploitation Capabilities as the mitigation for T.Network_Attack and apply similar verbiage from "Application PP" for the SFR and EA.

[jfisherbah]

FPT_AEX_EXT.1 from App PP with the following modifications added to the module but there are significant issues that need to be resolved for this before it can be closed.

1. the App PP version of the SFR has the TOE as an application so the requirement starts off with "The application shall..." - this needs to be updated for the NDcPP/LiFi use case. Based on this comment we changed it to "The web applications used by the TOE shall..." But is this correct/appropriate? The TC comment is explicitly about "a network device's web application" but this implies that every network device has one or more web applications. What if it doesn't have any? Should this SFR not be claimed in that case?

2. the EA from the App PP lists several desktop and mobile OS platforms - iOS/Android/Solaris have been removed because these will likely never apply to a conformant TOE but Windows and Linux have been kept. However, there may be other platforms that underpin a network device that aren't covered by this, and some consideration needs to be done for this. We don't want it to be an implicit requirement that a conformant TOE has to run a specific OS because the OS it runs on isn't covered by the testing for this SFR.

3. the EAs as written don't really make sense in the context of something bundled on a network device. For example, if the TOE ran on Windows Server the following EA would apply as currently written - "The evaluator shall run the same application on two different Windows systems and run a tool that will list all memory mapped addresses for the application." This implies that 'the application' is portable across arbitrary systems, which doesn't make sense in the context of a network device. Additionally, the A.NO_GENERAL_PURPOSE assumption in the NDcPP assumes that the TOE doesn't even have general-purpose functionality so what is the expectation for executing these tests if that assumption is fulfilled and there is no way for the evaluator to interact with the TOE in the manner needed to run these tests? Is the expectation that the evaluator be provided with a debug version of the TOE that allows the user to execute arbitrary programs on it?

Additionally, it is still unclear why this requirement applies to LiFi and not to any other type of network device. If the threat is against a web application running on the TOE that seems like something that should be a universal concern at the NDcPP level and isn't specific to this technology in particular.

[mafgani]

We've already had a similar debate in the past in #6 and came to the conclusion that the APP based PP SFRs are simply not applicable in the context of an embedded network device where A.NO_GENERAL_PURPOSE/OE.NO_GENERAL_PURPOSE applies. I would urge that we stick with the equivalent SFRs from OS PP as originally agreed.

@jfisherbah - I agree that this requirement is not LiFi specific and should really be considered at a higher level (NDcPP). I brought up the same point at the last WLAN TC meeting but did not get a conclusive answer.

[destineeb]

Until this requirement is elevated to the NDcPP level it needs to be included in the module. We will again confirm with the SMEs on whether to use the APP PP or OS PP SFRs. Please hold on further changes.

[ajsoum]

This requirement will be sent to the ND iTC for discussion. This will be considered for a future branch/version of LiFi, as the requirements will need to be rewritten to work for LiFi..

[mafgani]

While this is discussed within ND iTC, my suggestion is to still include FPT_SBOP_EXT.1, FPT_ASLR_EXT.1, FPT_ACF_EXT.1, and FPT_W^X_EXT.1 from OS PP in this version as a mitigation against T.NETWORK_ATTACK since that threat still remains relevant.

[jfisherbah]

Added these for requirements as-is in place of FPT_AEX_EXT.1. Should still be reviewed for appropriateness given the EAs are tailored to a GPOS specifically and may not be executable as-is on a network device with a non-modifiable and potentially inaccessible OS platform.