Working to document a runbook based on some recent IR stuff, so that when particular remediation actions come up in future incidents, we’re not making it up on the fly. Nobody seems to have a template for what they use, so I thought I’d ask the community. I’d seen Ask IFIN: Favorite Documentation Tools? - General - IFIN and I’m already using Obsidian, although not well, but I figure any template is probably somewhat generalizable from or to any other tool (e.g. Google Docs, Word).
I was once a Documentum admin within a medical device documentation and localization team. As I quickly learned, localization costs add up!
To reduce translation hours and improve documentation accuracy, they used what was called DITA (Darwin Information Typing Architecture).
DITA would be over kill for most IR teams, unless you’re global and life-safety are involved, but there are great lessons we can use within infosec.
I’ve applied what I learned in DITA, OOP (Object Oriented Programming), and UML (Unified Modeling Language) to make documentation as modular as possible, where appropriate.
A “phishing runbook” and “malware detection” will have different overall procedures, but the job aids (tasks/actions) within could be shared: web proxy block, identity containment, endpoint containment, detonate in sandbox, add IOCs to EDR, lookup asset and identity information, etc.
They could even be small tasks commonly included in multiple run books.
Ideally you reduce documentation lifecycle costs, improve reliability and set yourselves up for real automation work.
This really helps your automation/SOAR/integration engineer know what to prioritize and how to implement.
A team can see how many run books include an action, estimate of ann analysts time, quirks related to the action, and the inputs/outputs.
I believe a job-aid based approach to automation vs number of “complete” automated runbooks (or playbooks if you believe that word to be SOAR specific) is a more realistic approach, solving the easiest wins , across a breadth of procedures first. There’s always going to be some quirky, legacy, or goofy actions that prevent a runbook from 100%, and that’s ok.
MediaWiki, SNOW SIR, SharePoint, or Atlassian, the tools are all just meh but this approach works in any of them. Smaller, scrappy teams may find the modular approach suits them. I’ve done this in both a NOC and SOC.
Consolidated “tool lists” are another easy win that solves a lot of dumb problems. Sure, your doc has an extra click to go to a tool list first. But if that link updates, that’s one place to update and regularly review. You can also include login formatting quirks: with domain, slash directions, capitalization, sAM, UPN, resource account? If resource, link to that vault object.
For high-level IR docs, I still prefer simple, single documents, that should be available in alternative forms and in your OOB (Out of Band) solution.
I think the reason you might struggle with finding useful templates is because of how different every org is. No two orgs have the same tooling around Identity management, network protection, EDR, etc, and they won’t have the same business processes or overall culture when it comes to handling IR.
The most useful IR documentation that I have ever seen or produced came out of what it sounds like you have just experienced - actually handling IR for the org. The second best is doing it as a tabletop exercise. Every time you run through IR either for real or as an exercise, write down every action that was taken, and see if there’s a reasonable way to slip it into your documentation.
I really like what @BadSamurai said about modularity. I believe that good SOPs/runbooks should be modular, and composable for a given situation.
I’m also a big believer in decision charts, flow diagrams, and clear checklists. The idea is to make the procedure impossible to screw up, even in a crisis.
Templating is a challenge because lots of orgs have pre-existing rules about documentation. For example, all our runbooks must be in a specific format used across the whole org, and expected by auditors. So you kinda have to play in the sandbox you’re given.
That’s fair, and I’m not necessarily looking to crib somebody’s notes on their processes (although I wouldn’t sneeze at comparing them, because even with tooling differences etc., over any large enough collection there are likely useful steps to be learned from vicariously, before learning the hard way in IR). Less about “do 75% my job for me by letting me modify your process to match me” and more “I don’t have any policy-driven requirements to format against, and wanted to see if anyone had opinions on format to let me narrow down the greenfield”.
The one thing I’ll say on format, which isn’t really format, but:
Avoid proprietary documentation platforms
Confluence, SN KBs, etc., are where documentation goes to die. Ideally the necessary docs would be Markdown in a managed Git repo with proper change management/PRs for updates. This also facilitates modularity, as hyperlinks can let you “Choose your own adventure” through SOPs as needed.
Sadly, I’m in the opposite boat on templating. I don’t have a format I need to meet constraining me, and that opens up way too much room to waste cycles figuring out a good format myself. The advice here has been great though.
The first KB I used c. 2010 required you to handwrite the HTML, which made crosslinking onerous, especially since you wouldn’t get the new article ID until after it was saved, at which point you had to go manually update every document with backlinks if you wanted them. The proprietary WYSIWYIG editors were a godsend compared to that. But agreed, the open tooling is much better now (and was probably much better then, but our solution was what we had).
I’m a big believer that lowering the barrier of entry to a process is the best way to get people to follow the process, but that has its own issues where adding “reading and writing Markdown” and “understanding git” either become part of the barrier, or added complexity is needed to support the folks who aren’t there (and may never need to be).
That’s fair, and other tools can make sense. My bigger point is that documentation that relies on a vendor contract to survive, and requires migration in the event of a contract change, is a liability.
This might be a useful starting point for you, it’s an attempt at high-level IR playbooks guided by the MITRE framework. It’s super high level, so you’ll need to flesh out the details to suit your toolchain, and of course create entirely new ones where your environment might need specialized IR plans.
Many thanks! I’ll give this a look
You mean Archer’s entire business model?
And double yes on check lists. Like I used to tell my team in a NOC, “if professions with God complexes like surgeons and pilots use them (checklists), they aren’t beyond us in IT.”
If you have an IR retainer to burn, you can use it for documentation review, such as 1st and 3rd party IR. The results will be fine-to-good, but internal audit, legal, regulators, and insurance will love that extra stamp.
So in looking, I’m reminded that my grounding in MITRE ATT&CK is theoretical at best, as in theoretically I’ve heard of it. Not sure I want to layer learning that on top right now. I also ran another round of asking more senior folks internally for anything they use to template, without much success, but I did track down a guidebook with template from an agency setting standards for my employer’s industry.
At this point, I think I’m going to try to adapt that from Word to a minimum viable product in Obsidian, and incorporate the recommendations I’ve gotten here.
