Denied operations

Card key

docs_31

Status

Ready

Card type

base/cardTypes/page

Labels

Owner

N/A

Information classification

public

One way to enforce cybersecurity processes automatically is to define constraints to be met before a specific operation such as a workflow state transition is allowed. Cyberismo logic programs can define the following terms to deny workflow transitions, moving cards, removing cards, or editing a field of a card.

Workflow transition constraint

To deny a workflow transition, a user-defined logic program can define the following term:

transitionDenied( <card key>, <transition name>, <error message> )

Constraint to move a card

To deny moving a card, a user-defined logic program can define the following term:

movingCardDenied( <card key>, <error message> )

Constraint to delete a card

To deny deleting a card, a user-defined logic program can define the following term:

deletingCardDenied( <card key>, <error message> )

Constraints to edit a card

To deny editing a card field, a user-defined logic program can define the following term:

editingFieldDenied( <card key>, <field name>, <error message> )

A separate term is used for denying the editing of the AsciiDoc content of the card description:

editingContentDenied( <card key>, <error message> )

Example

For example, the requirement SM-5 of IEC 62443-4-1 requires that there must be a process to review security requirements by representatives of architects, testers, customer advocates, and security advisors. Let us assume that we represent security requirements as cards, and that the security requirement template includes four child cards that track the reviews of the requirement by these four roles, so all security requirements will automatically include these child cards. We can deny a workflow transition to accept a security requirement unless all review subtasks have been completed with the following logic program:

transitionDenied(X, "approve",
    "Cannot approve this requirement, because not all review subtasks have been closed.") :-
    field(X, "cardType", "moduleName/cardTypes/securityRequirement"),
    parent(Y, X),
    field(Y, "cardType", "moduleName/cardTypes/task"),
    not field(Y, "workflowState", "Closed").

The rule illustrates the use of default negation "not": the denial is generated by default unless the review substasks are all closed.