RE: Application TOE SFRs



  I am willing to assume that many labs, including ours (This is my personal opinion and not that of 
  the CSC CCEL), are resigned to the fact that the Scheme's edicts have to be adhered to and the 
  evaluation move on, in order to run a business. It is obvious that Jim, and or his organization, have 
 >  a vested business interest involved. 
 
While I believe that apparently other evaluation labs simply adhere to the demands of the scheme, my interest is for the protection of all of the labs and their customers (sponsors). I have begun this change because of an injustice (in my opinion) done to an evaluation sponsor by the scheme. An injustice represented in a decision that has not been technically defended and was denied any sort of appeal (appealing to the individual making the original decision is not an appeal at all).
 
From my perspective, it is important that evaluation labs understand the rules so that they can be objectively applied and the sponsors 'can' understand the rules so that they can effectively develop the necessary evidence for appropriate claims. I have argued for years that it is unreasonable for the scheme to say things like 'we'll know if it is good enough when we see it'. The problem is that an evaluation lab must be able to know when it is good enough or their business is impacted at the very least due to trial and error.

  In this same thread, the concept of "intent" has surfaced again. I assert that the concept of intent 
  is not present in any other professional standard. I have yet to hear from someone at the Scheme, 
  in this forum, or any other, discuss, or even show evidence that it used in any other Standard, the 
  same as it is applied in the CC. 
While I certainly agree that the scheme has justified many position based on intent, they have now started to base decisions based on the potential that a consumer might be confused in some manner. We apparently are to assume that consumers don't know anything about the CC and that they will read only some selected parts of an ST, for example, and hence those parts need to better represent the whole. The point is that things are changing and it is not clear why or how leaving those of us closer to the problem (e.g., in evidence development and evaluation) at a disadvantage.
 
  A good example are the FIA_UAU.1 and FIA_UID.1 requirements - I know there have been interps, but they 
  serve to prove my point. 

  FIA_UID.1 states: The TSF shall allow [assignment: list of TSF mediated actions] on behalf of the user 
  to be performed before the user is authenticated. 

  The English of the above statement is clear and concise. Nowhere in this requirement is the phrase 
  "by the TOE/TSF/whatever" present. However, through the "intent" mechanism words are added to the 
  requirement. This is how the engineering concept is "torn asunder." IF the requirement does not specify 
  the "intent of the author" the requirement should be removed from the CC, or a new requirement that 
  captures "the intent" should be created. No, what is the Schemes answer -  provide PD-099, saying 
  that the English does not mean what the words say, they mean something completely different, because 
  the Scheme thinks they should. Then over 1/2 a year latter, an inter is published that even changes that 
  PD. 
 
This example represents a very clear change in Scheme direction given that there are U.S. Scheme-validated STs that clearly allow first-party TOE enforcement supported by third-party IT environment authentication and there are also some validated PPs that clearly explain this situation and have chosen to explicitly state FIA requirements to ensure that the TOE must provide the authentication mechanism. It is examples such as those that I claim represent precedent - not a single mistake, but multiple cases including things produced directly by Scheme representatives in the past.
 
As indicated above the PD was not based on technical issues, but rather someone's intent. Note that part of the justification was that there was no FIA requirement that clearly required the TOE to actually perform authentication. However, there are FIA requirements to require the TOE to enforce specific strength of secrets (FIA_SOS) and to have multiple (assigned) authentication mechanisms. Regardless, a new requirement could readily have been crafted via the interpretation process. I tend to believe it was not because the CC is being bent to fit the intent of specific PP authors rather than fixing or creating the PPs to adequately address that intent in the first place. In response, the CC should not be changed because some PP author did not understand a given requirement.
 
  Which brings me to another issue - What would the Scheme response be to a laboratory saying the "intent" 
  of the developer was to ....? 
 
I tend to think that too much effort is being applied to nail down the precise meaning of each and every requirement. I tend to believe that requirements should really only be understood or specified at a fairly general, abstract level and it is up to the TSS clarify the answer more precisely. I also tend to think that implementations should not be dictated.
 
  Finally, you brought up the issue of money. Well it is not the way to run an entity that is both an international 
  and national standard by saying - we cannot "do it" correctly because of money, but we will throw something 
  out, right or wrong, but we will do our best, given the funds we have. 
 
I have to admit I was surprised this was brought up. The Scheme should be prioritizing its resources efforts as best it can, it should elicit help from the community where it can, and the rest of the government should help if it truly supports the program.
 
  So I think there is much of the same sentiment that Jim is discussing by the other labs - it is probably business 
  concerns (e.g., not upsetting the Scheme representatives because we need to get this evaluation through 
  in a cost effective manner for us and our customer) that are of importance to them. 
 
I appreciate any support I get from our peers in the evaluation business and I certainly understand the desire not to upset the Scheme. Other than on this forum we do handle issues selectively, but we weigh not only the cost (in more forms than just money) to the customer at hand but also to future customers and we also run into cases where we essentially no longer have anything to lose. However, we always strive for consistency and as a result we have historically chosen to drop claims (or alternately rework them) rather than to state them incorrectly as perhaps recommended by the Scheme so as not to create a bad precedent for future evaluations.


Date Index | Thread Index | Problems or questions? Contact list-master@nist.gov