-
Notifications
You must be signed in to change notification settings - Fork 2
Management Function Reform
After considerable study, given the wide variety of ways for presenting management functions, it seems to be too difficult to expressly map the functions to SFRs the way it is done for audit events. So, we have fallen back on one of two implementations for management functions, at the discretion of the TC.
- Use the
<management-function-set>construct and display the management functions in a table. or - Do whatever you want, but don't use a table.
There are some shortcomings to the original management function table. Namely, there is no way to express that management functions are conditional, and there is no way to express that the application of roles to management function is conditional.
The management function table construct now supports use of the <depends> tag to indicate the conditions under which a management function is claimed, and the conditions under which a role is required to support a management function.
If no dependency is specified on a management function, the function will be treated as Mandatory by automation tools. If the Function should be treated as optional, then the dependency should be specified as <depends><optional/></depends>.
The <O> tags may also include dependencies if the requirement that a particular role perform a particular function depends on some condition. If the role to function mapping depends on the discretion of the ST Author, then either the <depends><optional/></depends> may be specified, or no dependency may be specified. In this case, the default behavior is that the behavior is optional.
<management-function id="mf-determine-update-failure-action">
<depends on-sfr="sel-tud2-admin-det"/>
<depends on-sfr="sfr-fpt-tud-ext-3"/>
<text>
Ability to determine the action to take on update failure.
</text>
<O ref="A">
<depends on-sel="sel-tud2-admin-det"/>
<depends on-sel="sel-tud3-admin-det"/>
</O>
<O ref="U">
<depends on-sel="sel-tud2-user-det"/>
<depends on-sel="sel-tud3-user-det"/>
</O>
<app-note>
This Function must be claimed if FPT_TUD_EXT.2 or FPT_TUD_EXT.3 are claimed in
the ST.<h:p/>
The Administrator Option must be selected if "<h:i>by express determination of an [Administrator]</h:i>"
is selected in FPT_TUD_EXT.2.5 or FPT_TUD_EXT.3.4. <h:p/>
The User Option must be selected if "<h:i>by express determination of an [User]</h:i>"
is selected in FPT_TUD_EXT.2.5 or FPT_TUD_EXT.3.4.
</app-note>
<aactivity>
blah blah blah
</aactivity>
</management-function>Management functions generally have three interrelated pieces: Roles, Functions, and a Permissions Mapping.
These appear in FMT_SMR.1, FMT_SMF.1, and FMT_MOF.1, respectively.
In addition, each management function can have an AppNote, an EA, and dependencies.
So, the XML for management functions must support:
- An ID for the management function (e.g. M.RADIO)
- XML that defines the management function
- An AppNote of arbitrary text
- An evaluation activity
- dependencies for the MF (e.g. the MF is only active if a selection is made or in certain use cases)
- Roles that can perform actions relating to the MF
- The actions that can be performed on the MF
- The mapping of actions to Roles
The strategy is to standardize the way these pieces are defined, and allow some flexibility in the way they are displayed by separating the specification from he presentation.
Ideally, the specification of the Roles, Functions, and Mappings would be independent from the presentation, but that could be difficult.
In any case, the priority is to define the XML constructs to include all the information necessary to automate and display a PP's management functions, and do it in a way that works for all the PPs. Then we'll worry about display.
In PPs, Roles should be defined and presented in the Introduction using the <roles> tag.
<section title="Security Roles" id="sec-roles">
This section defines the roles of users with respect to managagement of the TOE. These roles are described here and are
specified in FMT_SMR.1.
<roles>
<!-- Name would be used to refer to the Role anywhere in the document -->
<!-- short would be used at the top of a column in the MF table -->
<role name="R.USER" display-name="User" short="User">
<description>
A user of the device who does not need additional credentials beyond those for using the device.
</description>
</role>
<role name="R.ADMIN" display-name="Administrator" short="Admin">
<description>
A user of the device who has obtained additional privileges for managing the device on the device
by presenting credentials that are accepted in accordance with FMT_BLAH.
</description>
</role>
<role name="R.LADMIN" display-name="Lab Administrator" short="Lab Admin">
<description>
A user of the device who has obtained additional privileges for managing the device in the lab
by presenting credentials that are accepted in accordance with FMT_BLAH.
</description>
</role>
</roles>
</section>All roles should be defined in the <roles> tag, whether the roles are mandatory or optional.
The <roles> element is displayed wherever it appears in the document, which is why it should be in the Introduction, but it could be, for example in the AppNote for FMT_SMR.1 or FMT_MOF.1. If the PP Author defines R.ADMIN-style names for the roles, they will appear in the document as links back to the role definition.
This mechanism does not support an ST Author adding roles that do not appear in the PP. I don't see why an ST author should be allowed to define additional roles, since the PP does not define requirements for any additional roles. Nothing stops the PP Author from using an assignment or selection to support arbitrary additional Roles, but they will not be linked or be automatable. At least not immediately so.
Described above is the specification of the Roles. below describes their presentation.
In FMT_SMR.1, the PP Author should refer to the roles by their R.BLAH names in FMT_SMR.1:
<f-component cc-id="fmt_smr.1" name="Security Roles">
<f-element id="fmt-smr-1e1">
<title>The TSF shall maintain the roles [
<h:ul>
<h:li>R.USER: Unprivilged user of the device.</h:li>
<h:li>R.ADMIN: Authorized administrator of the device.</h:li>
<h:li><selectables>
<selectable id="sel-r-ladmin">R.LADMIN: Lab Administrator</selectable>
<selectable exclusive="yes">No additional roles</selectable>
</selectables></h:li>.
</h:ul>
].
</title>
<note role="application">
These roles are described in <xref to="sec-roles"/>.
</note>
<aactivity>
<TSS>There are no TSS evaluation activities for this component.</TSS>
<Guidance>There are no guidance evaluation activities for this component.</Guidance>
<Tests> The evaluator shall cause the TOE to be enrolled into management. The
evaluator shall then invoke this mechanism and verify the ability to view that the
device has been enrolled, and view the management functions that the administrator
is authorized to perform.</Tests>
</aactivity>
</f-element>
</f-component>
Thinking about defining management functions in an XML element called <mgmt-func-list>, which is just a list of these:
<!-- 36 -->
<mgmt-func-def name="M.MDF36"> <!-- Name probably should be mandatory, even if not used -->
<!-- Dependency: this MF depends on inclusion of an SFR
Could also be a selection, use-case, feature, maybe platform.
Or <depends><optional/><depends> if truly optional
<depends/> if mandatory
If omitted, it's mandatory -->
<depends on-incl="fta-tab-1"/>
<!-- Text of the MF -->
<text>
configure the unlock banner
</text>
<!-- The Mapping of Roles to this MF: No idea how to do this -->
<!-- The ?????? stuff will probably be defined in FMT_MOF. So, it probably
will need to refer to the kinds of actions that the Roles are allowed to perform
with respect to the MFs. Keep in mind these could be optional or dependent on
something, and at a per-Role/Action level. This is going to be complicated. -->
<mof role="R.ADMIN"> ??????? </mof>
<mof role="R.USER"> ??????? </mof>
<!-- App Note should describe selections within the MF if any, and describe the dependencies, if any. -->
<app-note>
Function M.UNLOCK_BANNER must be included in the selection if FTA_TAB.1 is included in the ST.
</app-note>
<!-- MF-specific EAs -->
<aactivity>
<TSS>
The evaluator shall verify that the TSS describes any restrictions in banner
settings (e.g., character limitations).
</TSS>
<Tests>
The test of this function is performed in conjunction with FTA_TAB.1.
</Tests>
</aactivity>
</mgmt-func-def>
Not worried yet about the display of this mess, but it should probably be either the bulleted/selection-style or the table-style.
This requirement is about the mapping of Roles to Functions. In our environment, maybe this part of the construct should simply define the actions that can be taken e.g., enable, disable, modify the behavior of, invoke).
FMT_MOF.1.1
The TSF shall restrict the ability to [selection: determine the behaviour of, disable, enable,
modify the behaviour of] the functions [assignment: list of functions] to [assignment: the
authorized identified roles].
Certainly, the XML should be at least able to represent the CC version of MOF. So, it needs to define a set of actions, and be able to map the actions to Roles and Functions.
<mof-action-def title="B">determine the behavior of</mof-action-def>
<mof-action-def title="D">disable</mof-action-def>
<mof-action-def title="E">enable</mof-action-def>
<mof-action-def title="M">modify t he behavior of</mof-action-def>
MDF actions could be:
<mof-action-def title="M">perform the management function</mof-action-def>
<mof-action-def title="O">optionally perform the management function</mof-action-def>
<mof-action-def title="C">conditionally perform the management function</mof-action-def>
<mof-action-def title="X">may not perform the management function</mof-action-def>
And then an actual mapping might look something like this:
<mof role="R.ADMIN" func="M.MDF03" action="M"/>
<mof role="R.USER" func="M.MDF03" action="O"><depends><optional/><depends></mof>
<mof role="R.ADMIN" func="M.MDF04" action="O"><depends><optional/></depends></mof>
<mof role="R.ADMIN" func="M.MDF06" action="C">
<depends on-sel="sel-blah"/>
</mof>
The MFs can be displayed either a bulleted list in FMT_SMF (with selections or assignments) or as a table.
It should be a table if it's complicated and FMT.SMF should point to the management function table. If the ST Author is allowed to make up more MFs that should be in the requirement and not in the table. The MFT really could be dropped anywhere, but I expect it will be in FMT_SMF.
Column 1: The MF ID (M.MDF01 or whatever)
Column 2: Description of the MF
Column 3: Conditions under which the MF is implemented. Mandatory, Optional, Conditional. If conditional, the condition can be right there or it can be listed in the AppNote (which should be right under each function).
The rest of the columns: One for each Role as defined in SMR. Each entry is the corresponding action as defined in MOF.
If the action is conditional, it has to be indicated somehow. Maybe with a footnote in the AppNote.