A lot of emphasis and focus is put on the investigative part of SOC work, with the documentation and less glamorous side of things brushed under the rug. One such example is the simple SOC ticket: this could be internal or customer-facing, it could include a few sentences or paragraphs, it could contain everything necessary or be found lacking. I’m here to help you see your SOC tickets in a different light. 

There are a few core pieces to a good ticket, as well as some general criteria that must be met, whether that ticket is internal or external facing. For the sake of this blog, I will be writing with the assumption that a customer might see the ticket you are working on. 

## 1: A Good SOC Ticket Includes All the Necessary Evidence 

Our investigations should build a case for the final part of our ticket — the assessment. Most of that case needs to be your supporting evidence, whether that is screenshots, logs, artifacts, etc. Weak evidence is not going to fly; probably not internally, and definitely not externally. 

Based on the alert type you are working on, you need to provide solid log evidence, links, and screenshots that build a case for whether or not the alert is a true positive. 

## 2: A Good SOC Ticket is Clear and Concise 

There is such a thing as too much supporting evidence. Your ticket doesn’t need to include every unproductive rabbit hole you went down. As I mentioned above, the goal of your investigation is to build a case to support your assessment: what you think occurred and whether or not it is malicious activity. You can certainly do so in a few paragraphs, and while you do need to support your notes with evidence, you don’t want to overwhelm a customer or waste your own time by going over the top. Should more evidence be needed in the future, you can always build on your original investigation. 

## 3: A Good SOC Ticket Needs Solid Logical Reasoning 

One of the biggest things I’ve run into when performing quality checks on SOC tickets is that analysts will sometimes think either too broadly or too specifically about the alert they are working on. There is a middle ground to be had. If you think too broadly, you may be looking across weeks and months of logs, looking at unrelated activity, or looking over hundreds of hosts. If you are thinking too specifically, you might be missing one of the most important facets of an alert: it is supposed to be a warning sign of an attack, not an isolated task. 

A story that I often use to illustrate that point is about a SOC ticket I once returned to an analyst at a prior organization. The alert that created the ticket was a data exfiltration alert that fired when a certain amount of data left an organization within a short timeframe. This alert hit on a cloud provider’s domain, specifically going to one of their storage services. However, since we used some services from that provider at our company, the analyst closed the ticket as an upload to a “vendor,” missing the key point that anyone could utilize the storage functions of that cloud provider. 

Another good example is if during your investigation you discover that the alerting activity was blocked by a security control. That should not mean the ticket gets closed out and we move on. In a real attack scenario, the attacker isn’t going to shrug and say, “Well you got me,” and go home; they are going to try and find a way around that control. As previously stated, a SOC alert is often just an early warning system for an attack. 

## 4: A Good SOC Ticket is Reproducible 

Including queries used, links to results, or chains of events that brought you to a certain conclusion isn’t often going to make or break your ticket, but it will save you time and pain in the future. When looking at another analyst’s ticket, you should be able to reproduce their results or follow their reasoning. This also helps tremendously in cases like I mentioned in point 2 if you need to expand on an issue in the future or if you get an alert similar to one that was worked in the past and want to compare them. 

## 5: A Good SOC Ticket is Educational 

Most SOC tickets will never see the light of day, but the ones that do should illustrate and explain the circumstances of what is going on to the recipients.  

For example, if you are escalating a ticket to a customer regarding an individual using a disreputable “free” VPN service, you should take a few sentences to explain why they should even care. To a nontechnical user, they might see nothing wrong as the VPN service is FREE and protects you against all malware forever until the end of time and even does the dishes for you (at least that’s what their website says). Take a few sentences to explain why the customer should care about the ticket you are sending them, and maybe even offer a few suggestions on actions they could take. 

## 6: (Bonus) A Good SOC Ticket… 

Now for some rapid-fire tips! 

• Include timestamps and *time zones* related to specific events; not everyone lives in the correct time zone (EST). 
• When escalating a ticket, put the key information at the top; customers and even other analysts might skim, and in a long investigation, you don’t want the assessment or key details getting buried. 
• If investigating different facets of an alert or going down different avenues, consider separating them with a divider to make the ticket easier to read. 
• In the same vein as the above, take advantage of the formatting of your ticketing system; you don’t need to write the whole investigation in Times New Roman 12pt. 
• Don’t be afraid to be honest in internal tickets; if you don’t know exactly what is going on, say so- but give your best assessment with the evidence you have. 
• Think about your investigation almost like a court case; you’re building a case with your evidence, even if you won’t always have a definitive answer. 
• Include links to relevant documentation; if you’re referencing a specific O365 error code, link to that Microsoft page. 
• Be concise with escalations and ask clear questions so that the recipient isn’t confused as to what you are asking them to respond to. 
• And last but not least, don’t take things too seriously; computers are complicated and weird little machines, and not everything that looks weird is a nation-state-level attacker on the host. Sometimes, computers are just quirky. 

---

---

Ready to learn more?

Level up your skills with affordable classes from Antisyphon!

Pay-What-You-Can Training

Available live/virtual and on-demand

---

---