Add isAutomated boolean property to Action

[eoghanscasey]

This is a Fast Track change proposal.

Background

There is a need to represent whether an action is automated.

Requirements

Requirement 1

Represent that an action is automated.

Risk / Benefit analysis

Benefits

Adds the ability to differentiate between actions that are automated versus not automated.

Risks

The submitter is unaware of risks associated with this change

Competencies demonstrated

Competency 1

Competency Question 1.1

Which actions in a process were automated?

Result 1.1

List all actions that were automated in a process.

Solution suggestion

• Add isAutomated boolean property to Action

Requirement 1 also fully describes the solution.

[ajnelson-nist]

I would like to consider this a fast-track proposal, but it may come bundled with some non-trivial ontological risk.

The rationale for considering this as a fast-track proposal is that it is "Splintered off" of another proposal on analysis actions (400).

I am aware of at least this risk with isAutomated: We need to decide whether having isAutomated true on an action means there is an entailed requirement that the action cannot have a human action:performer.

I.e. should this snippet raise a SHACL validation error?

{
    "@id": "kb:person-automated-action-c51e0065-ba55-4177-bc08-e71963c22c26",
    "@type": "action:Action",
    "action:isAutomated": true,
    "action:performer": {
        "@id": "kb:person-c6c7ccc6-2b6c-41e0-ad74-d895bd209ac8",
        "@type": "identity:Person"
    }
}

[ajnelson-nist]

Let's say Sam the Analyst sets a cron job or ScheduledTask that triggers a one-off program at 11 o'clock some night. The action is automated. Is Sam the performer?

My opinion is no, Sam is not the performer of the program that executes. He did perform the delayed-start scheduling, but did not perform the program execution.

[eoghanscasey]

I agree - execution of a cron job or scheduled task is automated. The action of scheduling the job/task was performed by Sam (or possibly root/Admin under Sam's account).

Eoghan

On Mon, Aug 15, 2022 at 1:39 PM Alex Nelson @.***> wrote:

Let's say Sam the Analyst sets a cron job or ScheduledTask that triggers a one-off program at 11 o'clock some night. The action is automated. Is Sam the performer?

My opinion is no, Sam is not the performer of the program that executes. He did perform the delayed-start scheduling, but did not perform the program execution.

— Reply to this email directly, view it on GitHub https://github.com/ucoProject/UCO/issues/448#issuecomment-1215473239, or unsubscribe https://github.com/notifications/unsubscribe-auth/A2FNN6HMAZYOG3DMJURKNHTVZJ6GTANCNFSM56M2LP5A . You are receiving this because you authored the thread.Message ID: @.***>

[ajnelson-nist]

Per @eoghanscasey 's and my agreement on whether action:performer can reference a person for an automated action (we agree no), I've added a shape to consider such data an error. The shape follows a design pattern not yet used in UCO, applying constraints directly on sh:NodeShapes instead of in a sh:PropertyShapes, because this constraint necessarily references two properties. The pattern was shown to me in this comment.

The PR needs a PASS test alongside the XFAIL test, but otherwise it will be ready for a vote on Nov. 17. Announcement will be coming tomorrow.

[ajnelson-nist]

Noting this issue has not been forgotten: I'm testing it over on CASE-Corpora, including sanity-checks on uco-action:subaction, a property which was not exercised in CASE-Examples or the CASE website.

The benefit to uco-action:subaction that I've seen is on non-automated case-investigation:InvestigativeActions, where someone linked by uco-action:performer uses a tool that calls internal functions, and it is beneficial for narrowly scoping chain of custody that those internal function calls also be considered investigative actions. It seems consistent with discussion on this Issue that we consider those internal functions as automated actions, with no uco-action:performer. (In the CASE PROV-O mapping, a chain of prov:Delegations can be constructed to tie internal functions to overarching tools, if the objected linked with uco-action:instrument is different between the Actions.) If anyone disagrees with this pattern for isAutomated, please say so.

As an aside with respect to isAutomated, CASE may need to clarify how ProvenanceRecords and generated non-ProvenanceRecord objects should be handled when an InvestigativeAction has a subaction link. This note will become a separate Issue on the CASE tracker.