There is certainly some ambiguity when dealing with some of the terms mentioned above, as they are defined by the context in which they are used. In general, the SOAR industry is an extension of the SIEM market and this is important to note as terms are defined.
The simplest place to start is with events. Events can be viewed as the building blocks of everything else since they are the raw data that is ingested into the system in question, whether this be a Security and Event Management Tool (SIEM) or Orchestration and Automation Tool (SOAR). So in the IT space, events are any piece of information ingested into the platform, ie log events, packet sessions, endpoint processes, etc.
As these events are ingested into your SIEM, alerts are generated by rules that have been put into place, applied to raw events and match certain conditions. For example, a rule could be created to say if there are more than ten failed authentication attempts to a system within 2 minutes, create an alert. As the Active Directory (AD) logs are monitored and the raw log events are ingested into the SIEM, if this condition should occur an alert is created.
Just as basic rules are created to capture and alert analysts as to activity within their IT infrastructure, more sophisticated scenarios and rules can be implemented. Lets say another rule is created so that when a users permissions are changed in AD and alert is created within your SIEM. Now it is possible to create a chain of requirements for notifying an analyst. So another more complex rule is created to capture multiple failed login attempts followed by account privilege escalation by way of AD changes. So if both of our previous rules are met, we will create an incident within our SIEM. This incident would have two alerts associated with it.
Here the term incident is used as it is more generally accepted than the word ticket, as Incident management is a big part of a SIEM platform. But this IT security incident may have larger impact to the business. In this case a ticket would be created in order to increase the visibility of the security incident to a larger scope of teams ie finance, accounting, devops etc. Tickets are generally created in a case management platform such as RSA Archer, ServiceNow or JIRA. So a ticket is very similar to an incident, but is usually implemented at a higher level of the organization.
Now to loop back around to the specific problem domain of SOAR. SOAR is an evolving space that is generally being seen as an extension to SIEM. It is managed by Security Operation Center analysts and leveraged by taking security incidents from the traditional SIEM and automated a response. This might be IP enrichment, security scanning, etc. Essentially when we see an incident of a certain type created in our SIEM, we want to implement x,y,z steps in response. These steps are automated by making api calls to other tools within the IT space. So in essence the SOAR tool is ingesting incidents from your SIEM.
This is not to say that tickets are not ingested from say Service Now or Jira for automation. This is the other common source of initiating playbooks in your SOAR tool. So tickets and incidents are very much the same thing, as they serve the same purpose, it just depends on if you are talking to the web dev, SOC analyst, project manager etc.
Source: I work as a Systems Engineer on SIEM and SOAR platforms.
