Create a new top-level Action construct to act as common basis for human-oriented actions or action decisions

[sbarnum]

There are currently a range of places within the STIX model that involve information around human-oriented actions or action decisions.
The most obvious is the COA construct itself but it would also include ActivityType within Campaign, Attack Patterns within TTP (action pattern defined from action), Kill Chain within TTP (action pattern defined from action), investigator/responder actions within Incident, etc.

It would seem beneficial to reduce complexity and ensure better semantic consistency if we were to define an abstract Action construct to act as common basis for these sorts of actions.

[athiasjerome]

For references, the ''Action type'' (as defined in XORCISM as ActionObjectAssociationType) is currently defined in both CybOX:
Initiating
Affected
Utilized
Returned

and MAEC
input
output
side-effect

Also for ref., the XORCISM type 'ActionRelationshipType' (coming from CybOX):
Preceded_By
Followed_By
Equivalent_To
Related_To
Dependent_On
Initiated_By
Initiated

[athiasjerome]

Suggest to consider the 'action' concept/enumeration(s) of IODEF v2 (so incident-centric)
NB: linked to COAs (and somehow to the RFIs/Query)
Ref. https://www.ietf.org/id/draft-ietf-mile-rfc5070-bis-15.txt
e.g. 3.17. Expectation Class

  1.   nothing.  No action is requested.  Do nothing with the
       information.

  2.   contact-source-site.  Contact the site(s) identified as the
       source of the activity.

  3.   contact-target-site.  Contact the site(s) identified as the
       target of the activity.

  4.   contact-sender.  Contact the originator of the document.

  5.   investigate.  Investigate the systems(s) listed in the event.

  6.   block-host.  Block traffic from the machine(s) listed as
       sources the event.

  7.   block-network.  Block traffic from the network(s) lists as
       sources in the event.

  8.   block-port.  Block the port listed as sources in the event.

  9.   rate-limit-host.  Rate-limit the traffic from the machine(s)
       listed as sources in the event.

  10.  rate-limit-network.  Rate-limit the traffic from the
       network(s) lists as sources in the event.

  11.  rate-limit-port.  Rate-limit the port(s) listed as sources in
       the event.

  12.  redirect-traffic.  Redirect traffic from intended recipient
       for further analysis.

  13.  honeypot.  Redirect traffic to a honeypot for further
       analysis.

  14.  upgrade-software.  Upgrade or patch the software or firmware
       on an asset.

  15.  rebuild-asset.  Reinstall the operating system or
       applications on an asset.

  16.  harden-asset.  Change the configuration an asset (e.g.,
       reduce the number of services or user accounts) to reduce the
       attack surface.

  17.  remediate-other.  Remediate the activity in a way other than
       by rate limiting or blocking.

  18.  status-triage.  Conveys receipts and the triaging of an
       incident.

  19.  status-new-info.  Conveys that new information was received
       for this incident.

  20.  watch-and-report.  Watch for the described activity and share
       if seen.

  21.  training.  Train user to identify or mitigate a threat.

  22.  defined-coa.  Perform a predefined course of action (COA).
       The COA is named in the DefinedCOA class.

  23.  other.  Perform some custom action described in the
       Description class.

  24.  ext-value.  An escape value used to extend this attribute.
       See Section 5.1.1.

also referenced by
The Incident class has eight attributes:

purpose
Required. ENUM. The purpose attribute represents the reason why
the IODEF document was created. It is closely related to the
Expectation class (Section 3.17). These values are maintained in
the "Incident-purpose" IANA registry per Table 1.

[athiasjerome]

(Primary comment)
For IM and mainly UML, I suggest reviewing
8.4.3 Class Information Action
(and other references to Action)
in
http://www.threatrisk.org/spec/RevisedSubmission/Revised%20Operational%20Threat%20Risk%20Submission.pdf