Re: I-0369: Security Management Functions To Be Provided Must Be Enumerated
- Subject: Re: I-0369: Security Management Functions To Be Provided Must Be Enumerated
- From: James Arnold <email@example.com>
- Date: Mon, 15 Jan 2001 14:19:42 -0500
- Content-Transfer-Encoding: 7bit
- Content-Type: text/plain; charset=us-ascii
I-0369: Security Management Functions To Be Provided Must Be Enumerated
I think that it may be a good idea to add a family to address
requirement of security management functions, though I disagree that an
interpretation is the appropriate vehicle for so doing.
I think this interpretation does not clearly state its goal.
Specifically, it states that implicit requirements that a security
management function must exist should be tested. What exactly are we
talking about testing. I think that the current requirements serve to
impose restrictions on management functions should they happen to
exists. This makes sense since a PP author may not care whether given
capability are managed via TSF interfaces, off-line capabilities, or are
statically defined in the TOE. On the other hand, it is not clear
whether, should the security management function exist, the function has
to work correctly (while it is clear that the restrictions and auditing
be evaluated). I think this could use clarification since it is only
implied and is very important.
It seems reasonable that a PP author should be able to require that
specific security management functions exist and work correctly, though
they should also be encouraged to carefully select such requirements to
encourage use of their PP. In other words, a PP author would be
probably be making a mistake to arbitrarily require every security
management function that should be restricted if it exists to actually
be present in every conforming TOE.
Date Index |
Thread Index |
Problems or questions? Contact firstname.lastname@example.org