[2600] External net work environment and T.TSF.SW
(Sorry if I have sent same e-mail before)
Hi
Addition to DOS threats issue, I would like to discuss two more items
at the next P2600 meeting at Piscataway NJ.
1) Is External Network Environment appropriate to set as asset for HCD?
We have discussed this issue at the December meeting last year, and the
conclusion was "Yes it should be asset to be protected based on the
example of the ST of the fire wall which sets External Network Environment
as asset.
I would like to re-visit this issue because,
a) The asset to be protected is really "User Data". The function of
firewall is to check the "User Data" from outside, and relay the
"User Data" to intranet if there it did not find the problem.
In that meaning, External Network Environment is the asset for firewall
because it function as a relay of the user data from outside to inside
(External Network Environment).
In the case of HCD,it does not have "direct"relay function.
The "User Data" coming to HCD is basically a input for HCD to be
processed. So the asset to be protected is the input of HCD and user
data in the HCD. Nothing outside HCD.
So it is not appropriate to set External Network Environment as an asset
for HCD.
b) At the Hawaii meeting on this February, we have agreed that "Packet
Filtering "is not the effective way to protect External Network
Environment. OI&A is more effective, but there is no fundamental way to
protect External Network Environment.
So my proposal is to leave External Network Environment as an asset in
IEEE main body because it should be a best practice, but remove from PP
because it is not appropriate in the current CC world.
2) I would like to propose to remove T.TSF.SW (in PP-a 24a) or
T.SW.STORED.ALT (in P2600.1 26d) from PP.
The reason is,
a) In Paragraph 450 of CC3.1 part3,it says that
" Generally, the vulnerability assessment activity covers various
vulnerabilities in the development and operation of the TOE. Development
vulnerabilities take advantage of some property of the TOE which was
introduced during its development, e.g. defeating the TSF self
protection through tampering, direct attack or monitoring of the TSF,
defeating the TSF domain isolation through monitoring or direct attack
the TSF, or defeating non-bypassability through circumventing (bypassing)
the TSF. Operational vulnerabilities take advantage of weaknesses in
non-technical countermeasures to violate the TOE SFRs, e.g. misuse or
incorrect configuration. Misuse investigates whether the TOE can be
configured or used in a manner that is insecure, but that an
administrator or user of the TOE would reasonably believe to be secure. "
It clearly says that vulnerability assessment activity covers the vulnerability
against tampering, direct attack or monitoring of the TSF etc.
That means that security functions against these attacks have to be
mandatory implemented in the TOE, and not necessary to set as the Threat because
evaluator have to evaluate them.
b) On the other hand, it become too restrictive for the implementer if
the SFR is set for this Threat because they are implementation specific.
(Each vendor has ther specific way of updating software. via network, or
USB, or via special service pot, etc.)
So it should be written in ST if it is necessary, but should not be
written in PP which should be general.
If T.TSF.SW (in PP-a 24a) or T.SW.STORED.ALT (in P2600.1 26d) is not
required as threat in PP, O.Genuie will also not required.
Regards,
Shigeru Ueda
Canon