4Ws and An H

Once upon a time in a global security opetations team (a SOC) … We had some problems with SOC incident tickets that really symbolised the growing pains and cultural struggles our security organisation was going through. The time spent on incident tickets, number of tickets worked, and especially thae notes in the incident ticket varied tremendously across a team of folks who all had different skills and the same job responsibilities, though of course some had been on the team / at that company longer. People were starting to get upset at each other…

Challenge

The worst symptom (perhaps) was a one word code that some of the clever responders had invented and started using. It still kinda makes me twitch to think of it: “Redtop”. By that one code word and closing out the incident ticket without anything further, they meant: “Activity was on system assigned to our Red Team, so I’m not going to investigate further because it’s Probably Fine.”

This wasn’t policy and isn’t a good idea. Even if your own Red Team has permission to do suspicious things on the network (but do they though?), that doesn’t preclude them from: making mistakes, getting compromised, or misbehaving. Don’t shut down events from my system just because I sometimes do malware analysis either!

We wanted to do all the good things every service desk and ticket-driven team needs: peer review and leadership review of tickets to promote a culture of learning, get better records in the system for future-us (and auditors), to inform process and technology changes, and eventually to influence advancement and compensation appropriately. “Redtop” (and the attitude behind it) had to go.

Solution

We discussed these problems as a team and I suggested a structured answer format for the “big empty box” in the incident tickets. After knocking ideas around, we started using a version of the 5Ws of journalism (swapping in an H): Who did what to whom, Where, When, and (where possible) How … leaving off the Why. I created a simple template to use in the textarea and we promoted its use to help with the peer reviews of tickets we also started.

Who:
What:
Where:
When:
How:

Now we had a lightweight standard that made peer review a bit more possible. Responders were encouraged to look for the 4WH block and share notes on where their answers might differ with the original response or ask followup questions from there. Folks who sneered at or simply declined to use the standard format had to explain why to their leaders. We got much better case notes and better connections within the team (across schedules and locations!) through the lightweight standard, the discussions around it, and the peer reviews it enabled.

Afterword: Although 4WH was pretty succesful there as a starting point (and some folks carried it with them to their next organisation :purple_heart: ), I think the VERIS Framework’s 4As might be a good next step: Action, Asset, Actor, and Attribute(s). If you aren’t familiar, their “Getting Started” page is excellent: https://verisframework.org/howto.html

Getting all of your incident data VERIS aligned is a great accomplishment and worth several other articles of discussion :D, but using just the the 4As or the 4WH approach on its own can be very helpful and it’s easy to start. It’s important to work with the team, leadership, and your data consumers ( metrics, audit, regulators? ) to try and meet everyone’s needs as you make changes.

Or just get everyone (everywhere) agree to use the CJCSM “10 Cat” system, which is nearly perfect :smiling_cat_hearteyes: