Ticketing systems are ubiquitous in nearly every organization. They are a primary mechanism that humans (users) use to navigate through a workflow or business process, while documenting actions, relationships, and status updates along the way.
I am fine with my examples in this change proposal being transcribed and credited when others can re-use this content.
As an example, I use a popular ticketing system Zendesk as a primary mechanism to receive requests from cyber domain investigators when they request a tool, specialized data, or have a question that needs to be answered. In my use case, the Zendesk ticket can be created two different ways:
Submitting information to a Zendesk bot on my website where the website user provides some basic information: (a) your name - an optional field, (b) email address, and (c) answering "how can we help you" before pressing the send button.
Sending an email to support@mysubdomain.zendesk.org - "support" can be tailored to any other string by the Zendesk account administrator
I receive the tickets in the Zendesk dashboard where I then use a customized workflow to advance them to a completed state.
The general ticket fields are:
"Requestor" - with a URL to the name record of the submitter
"Created" - a date time group
"Updated" - a date time group
"Priority" - low, normal, high, or urgent
"Assignee" - a URL to the name record of the assigned person who is responsible for actioning the ticket
"Ticket ID" - an integer (i.e.; 1340)
"Created via" - web, email
"Organization" - a string with the requestor's organization name
"I am interested in" - assignee assigns a classification from a list of strings unique to the organization
"Tags" - assignee assigns one or more tags to further classify this ticket
With this submission I hope to achieve a general concept coverage for a new ObservableObject named something like "ActionTicket" that can represent the generally agreeable fields for work tickets produced by a variety of ticketing systems.
This applies to many use cases encountered within the cyber domain sub disciplines that we are familiar with in the Cyber Domain Ontology Community:
A smart phone arrives as physical evidence to a digital forensics laboratory. It gets processed into the lab's evidence process. Then the phone is assigned via a work ticket to a digital forensic acquisition specialist. That acquisition specialist does the work, then updates the ticket to the next workflow step so that the acquired forensic image can be analyzed.
A cyber threat detection sensor identifies a suspicious event from a high-priority YARA signature. The threat management/investigation product that receives this event from the sensor has a pre-programmed workflow to open up a work ticket so that a human cyber threat analyst can review the event. This human reviews the event in context and moves to disposition the ticket either to incident response or to close it.
These tickets are highly customizable by the administrators and the users of the ticket management system. As an example, here are the fields within a Zendesk ticket. Other ticket management systems may be similar to this but also wildly different. This change request seeks to find the common ground of a basic ticket representation.
Requirements
The ActionTicket concept should represent the basic properties that are found in most vendor ticket standards. A faceting approach could be used so that adopters have flexible to add more properties if desired.
Requirement 1
The ActionTicket should be able to be connected to manual and automated business workflows like: ticket created, ticket submitted, ticket received, ticket reviewed, ticket dispositioned.
Requirement 2
The ActionTicket should be able to be connected to cyber domain events (i.e.; discrete security or business events, intrusion incidents,)
Requirement 3
Added 2023-10-26 during Ontology Committees call
WorkTicket, as an ObservableObject subclass, must adhere to the independence-of-observation principle.
Risk / Benefit analysis
The submitter is unaware of risks associated with this change
The benefit of representing an ActionTicket concept should make it possible for developers of ticket management tools used in the cyber domain industry to implement UCO.
Background
Ticketing systems are ubiquitous in nearly every organization. They are a primary mechanism that humans (users) use to navigate through a workflow or business process, while documenting actions, relationships, and status updates along the way.
I am fine with my examples in this change proposal being transcribed and credited when others can re-use this content.
As an example, I use a popular ticketing system Zendesk as a primary mechanism to receive requests from cyber domain investigators when they request a tool, specialized data, or have a question that needs to be answered. In my use case, the Zendesk ticket can be created two different ways:
I receive the tickets in the Zendesk dashboard where I then use a customized workflow to advance them to a completed state.
The general ticket fields are:
"Requestor" - with a URL to the name record of the submitter "Created" - a date time group "Updated" - a date time group "Priority" - low, normal, high, or urgent "Assignee" - a URL to the name record of the assigned person who is responsible for actioning the ticket "Ticket ID" - an integer (i.e.; 1340) "Created via" - web, email "Organization" - a string with the requestor's organization name "I am interested in" - assignee assigns a classification from a list of strings unique to the organization "Tags" - assignee assigns one or more tags to further classify this ticket
With this submission I hope to achieve a general concept coverage for a new ObservableObject named something like "ActionTicket" that can represent the generally agreeable fields for work tickets produced by a variety of ticketing systems.
This applies to many use cases encountered within the cyber domain sub disciplines that we are familiar with in the Cyber Domain Ontology Community:
A smart phone arrives as physical evidence to a digital forensics laboratory. It gets processed into the lab's evidence process. Then the phone is assigned via a work ticket to a digital forensic acquisition specialist. That acquisition specialist does the work, then updates the ticket to the next workflow step so that the acquired forensic image can be analyzed.
A cyber threat detection sensor identifies a suspicious event from a high-priority YARA signature. The threat management/investigation product that receives this event from the sensor has a pre-programmed workflow to open up a work ticket so that a human cyber threat analyst can review the event. This human reviews the event in context and moves to disposition the ticket either to incident response or to close it.
These tickets are highly customizable by the administrators and the users of the ticket management system. As an example, here are the fields within a Zendesk ticket. Other ticket management systems may be similar to this but also wildly different. This change request seeks to find the common ground of a basic ticket representation.
Requirements
The ActionTicket concept should represent the basic properties that are found in most vendor ticket standards. A faceting approach could be used so that adopters have flexible to add more properties if desired.
Requirement 1
The ActionTicket should be able to be connected to manual and automated business workflows like: ticket created, ticket submitted, ticket received, ticket reviewed, ticket dispositioned.
Requirement 2
The ActionTicket should be able to be connected to cyber domain events (i.e.; discrete security or business events, intrusion incidents,)
Requirement 3
Added 2023-10-26 during Ontology Committees call
WorkTicket, as an
ObservableObjectsubclass, must adhere to the independence-of-observation principle.Risk / Benefit analysis
The submitter is unaware of risks associated with this change
The benefit of representing an ActionTicket concept should make it possible for developers of ticket management tools used in the cyber domain industry to implement UCO.
Competencies demonstrated
Competency 1
Competency Question 1.1
Result 1.1
Competency Question 1.2
Result 1.2
Solution suggestion
Coordination