Audit events based on SFR type

[jfisherbah]

The tag is used to generate audit events for SFRs such that tables can be defined to list all auditable events for SFRs of a given type. This capability is known to exist for mandatory SFRs and the various types of optional and selection-based SFRs. However, I'm not sure whether the capability exists for Modified SFRs and Additional SFRs when defined in a PP-Module.

If this capability does exist, guidance is needed for how to create the table itself. Presumably the table="mandatory" attribute of would be changed, but the allowed values for this parameter are unknown.

[robertmclemons]

It does exist for Additional SFRs (not yet for Modified SFRs) under Base PPs in Modules. It is brand new. Look at the module-reform branch of vpnclient for examples. You have to declare an audit table and assign the specific audit events to the table by matching the table attributes of the table and the events.

Also see https://github.com/commoncriteria/pp-template/wiki/Audit-Tables and https://github.com/commoncriteria/pp-template/wiki/Audit-Events

[jfisherbah]

Confirmed - I would suspect that we don't need events for Modified SFRs because a module would never be refining one of those in a way that adds new events, and any audit requirements for that SFR would be inherited from the Base-PP.

The only use case I can think of would be an SFR in a Base-PP that doesn't define FAU_GEN.1 where the PP-Module does, and it now wants to go back and make something from the Base-PP auditable. Hypothetically, this could happen in a PP-Module that extends the App PP and defines its own audit function, if the module wanted FMT_SMF.1 behavior to be auditable. I don't think that situation currently exists or needs to exist; it hypothetically could, but there's no urgency to add support for this scenario.

[robertmclemons]

Yeah, if this becomes a problem, I can just do the same thing for Modified that I did for Additional. It was very painful at the time, but time has healed the wounds.

On Thu, Dec 21, 2023 at 1:07 PM jfisherbah @.***> wrote:

Confirmed - I would suspect that we don't need events for Modified SFRs because a module would never be refining one of those in a way that adds new events, and any audit requirements for that SFR would be inherited from the Base-PP.

The only use case I can think of would be an SFR in a Base-PP that doesn't define FAU_GEN.1 where the PP-Module does, and it now wants to go back and make something from the Base-PP auditable. Hypothetically, this could happen in a PP-Module that extends the App PP and defines its own audit function, if the module wanted FMT_SMF.1 behavior to be auditable. I don't think that situation currently exists or needs to exist; it hypothetically could, but there's no urgency to add support for this scenario.

— Reply to this email directly, view it on GitHub https://github.com/commoncriteria/transforms/issues/82#issuecomment-1866727536, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGQFJ5ZPGFHQLQPN7SRLN73YKR3F5AVCNFSM6AAAAABA5JKUW2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRWG4ZDONJTGY . You are receiving this because you commented.Message ID: @.***>

[jfisherbah]

closing as unplanned for future consideration if there's ever a use case that requires it

[robertmclemons]

Closing