Working in the SOC can be a grind. Whether triaging alerts, escalating to clients, or just trying to understand why users download malicious files, we feel the need to get through tickets as fast as possible. But in that rush, we can actually hinder our progress and slow ourselves down.

What can we do to make tickets, notes, and escalations aid the SOC in the past, present, and future? Using structure, “building upon,” and clear and concise direction, we can set ourselves and the SOC up for success.

Structure

In one of Jason Blanchard’s “Job Hunt Like a Hacker” BHIS livestreams, he emphasized using bullet points when listing job experience rather than a big wall of text, as “people will get lost and stop reading.” I took this advice to heart in the way I structure the internal notes of my tickets.

I use structured, cascading bullet points to document each step taken and each piece of evidence discovered during triage. This format makes it easy for any teammate to pick up where I left off — or for a lead to QA my work without asking me to explain it.

Building Upon

Now that we know how to structure our notes, what should we actually document? While triaging the alert, begin with steps taken. This could be “- Ran query: {the query itself or link to SIEM platform of query used}”, “- Investigated User’s recent login history”, etc. From there, gather evidence (log data, artifacts, screenshots, etc.) pertaining to the events that occurred and add them to your notes as you discover them.

Just because you add something to your notes, doesn’t mean it’s set in silicon (excuse my play on words...). If an event or evidence is not actually linked to the alert, you can remove it. It’s better to capture too much and trim later than to miss something you’ll need to reconstruct hours or days from now. This is a key part of the “Report-As-You-Go” process.

Clear and Concise Direction

We have our structure and our evidence... now what? It’s time to edit down and proofread what we have in the internal so that it only contains necessary information. Clear away any rabbit holes or evidence not pertinent to the alert in question. Your thought process should be apparent from the information you present. A final bullet point stating your verdict will enhance this clarity, such as “- Atypical behavior of user, will escalate and confirm expected.”

With the evidence well-documented and your verdict made, you are set to either update the client or close the ticket, setting everyone up for future success.

Documentation Muscle

Just like regular muscles, you need to constantly work out your reporting-as-you-go muscles. The more you exercise these muscles, the stronger they become. It’s an ever-improving process: the first couple of internals you create are not going to be great, but you will see improvement the more you work at it. Another way to work this muscle is to start a blog and write walkthroughs on different cyber rooms, CTFs, or topics you’re studying. Get started today!

Resources

How To Write Practical Lab Notes with Obsidian and Notion with Daniel Lowrie and Antisyphon Training

The Formula for Great SOC Tickets by Hayden Covington

David Fletcher // Reporting is a penetration testing topic that doesn’t have a whole lot of popularity. People have a hard time being inspired to write about the technical details of […]

The post How to Not Suck at Reporting (or How to Write Great Pentesting Reports) appeared first on Black Hills Information Security, Inc..