WIP: Add tools and other misc improvements

bcp-guide/before_you_soar.md

@@ -11,7 +11,7 @@ Getting started
 Any modern organisation that wants to protect its information assets and
 mission-critical functions must be able to respond quickly to security
 events, preferably before they escalate into serious incidents. SOAR,
-which stands for security orchestration, automation, and response, was
+which stands for **security orchestration, automation, and response**, was
 created with this goal in mind. It enables organisations to collect data
 about potential security risks and respond to security events
 autonomously or with limited human assistance. Furthermore, SOAR forces
@@ -92,9 +92,13 @@ Before you begin, ensure that you have the following covered:
 
 -   You should not embark on this journey if your current asset
     management practises are underdeveloped. If you can\'t answer
-    questions like: what assets are in scope; who owns them; and what
-    the assigned value per asset is, your playbook logic may be skewed
-    by arbitrary circumstances. The asset list will define the scope of
+    questions like:
+    -    What assets are in scope?
+    -    Who owns them?
+    -    What is the assigned value per asset?
+
+    Your playbook logic may be skewed by arbitrary circumstances.
+    The asset list will define the scope of
     your project and provide an indication of your potential SOAR
     roadmap (for e.g. start with the endpoints, then servers, etc.).
 
@@ -143,14 +147,15 @@ want to consider:
 -   SOAR use cases and playbooks must be documented at all times. They
     should include, at a minimum, the following: the playbook\'s goal,
     the owner, the steps, the actors involved, the metrics to be
-    measured, such as mean time to detect (MTTD) and mean time to repair
-    (MTTR), and override options. Also, ensure that these playbooks are
+    measured, such as **mean time to detect (MTTD)** and
+    **mean time to repair (MTTR)**, and override options.
+    Also, ensure that these playbooks are
     easily accessible to those who require them, particularly those in
     charge of maintaining your SOAR system.
 
 -   Your playbooks should ideally be neatly mapped on top of the
-    standard incident management lifecycle: detect, triage, prioritise,
-    respond, recover, and report. While this may appear difficult, it
+    standard incident management lifecycle: **detect, triage, prioritise,**
+    **respond, recover, and report**. While this may appear difficult, it
     will give you a better understanding of what the auto process is
     doing and will make upstream reporting easier.
 

bcp-guide/contributors.md

@@ -16,6 +16,7 @@ The core team (Automation SIG co-chairs) will review them.
 * Braxton Plaxco
 * Guillem Gordillo
 * Jonas Plum
+* Julian Droste
 * Razvan Gavrila
 * Vilius Benetis
 

bcp-guide/overview.md

@@ -2,15 +2,16 @@
 
 This document tries to give an overview of typical, worthy automation tasks in IT security.
 
-We start by defining some terms and limiting the scope of this document (chapter XXX). After all, the term "Automation" is overly broad. Limiting the scope to the most useful and typical automation use-cases in IT Security Teams / CSIRTs / SOCs allows us to stay focused. Essentially, as every IT practitioner knows, there is a tendency to try to automate everything. This is no different in IT Security. But the question "is it worth it to automate" needs to be looked at closely. One of the  first good outcomes of the FIRST Automation SIG's work is therefore the consolidated list of worthy use-cases in chapter XXX.
+We start by defining some terms and limiting the scope of this document (see chapter [Scope](./scope.md)). After all, the term "Automation" is overly broad. Limiting the scope to the most useful and typical automation use-cases in IT Security Teams / CSIRTs / SOCs allows us to stay focused. Essentially, as every IT practitioner knows, there is a tendency to try to automate everything. This is no different in IT Security. But the question "is it worth it to automate" needs to be looked at closely. One of the  first good outcomes of the FIRST Automation SIG's work is therefore the consolidated list of worthy use-cases in chapter XXX.
 
 After the scope discussion, we will describe the common use-cases which CSIRTs and SOCs face.
 
 <XXX add one, two sentences about our process of use-case discovery XXX>
 
 Next, we discuss and list the common standards which help both in modelling as well as in facilitation interoperability between different tools.
 
-The tools chapter (XXX) discusses the common tools for automation. 
+The [tools chapter](./services-tools.md) discusses the common tools for automation.
+Additional tools can be found within the [`tools` folder](./tools/tools.yaml).
 
 The chapter "How to automate with open source tools" gives a few examples on how to automate the typical use-cases we elaborated on in chapter XXX. Since at the time of writing this document, the market for commercial automation tools for IT Security (SOARS, SIEMs, workflow automation tools, etc.) is very dynamic, the next chapter "How to automate with commercial tools" (XXX)  re-visits our use-cases but with a focus on the commercial tools. Where possible, we link to vendor's instructions on how to automate the particular use-case with the vendor's tool. 
 

bcp-guide/tools/chainsaw/index.md

@@ -0,0 +1,14 @@
+# Chainsaw
+
+Chainsaw provides a powerful ‘first-response’ capability to quickly identify threats within Windows forensic artefacts such as Event Logs and MFTs.
+Chainsaw offers a generic and fast method of searching through event logs for keywords, and by identifying threats using built-in support for Sigma detection rules, and via custom Chainsaw detection rules.
+
+
+**Open Source:** Yes (GPL-3.0)
+
+**Category:** Hunting / Forensics
+
+
+
+**Links:**
+- [https://github.com/WithSecureLabs/chainsaw](https://github.com/WithSecureLabs/chainsaw)

bcp-guide/tools/create_tool_pages.py

@@ -40,39 +40,41 @@
 {%- endfor %}
 
 """
-
-with open('tools.yaml') as f:
+with open("tools.yaml") as f:
     doc = yaml.load(f, Loader=yaml.FullLoader)
-    tools = doc["tools"]
-    for idx, tool in enumerate(tools):
+    for idx, tool in enumerate(doc["tools"]):
         slug = tool["name"]
-        slug = unicodedata.normalize('NFKD', slug)
-        slug = slug.encode('ascii', 'ignore').decode('ascii')
+        slug = unicodedata.normalize("NFKD", slug)
+        slug = slug.encode("ascii", "ignore").decode("ascii")
         slug = slug.lower()
-        slug = re.sub(r'[^0-9a-z]+', '-', slug)
-        slug = slug.strip('-')
-        tools[idx]['slug'] = slug
+        slug = re.sub(r"[^0-9a-z]+", "-", slug)
+        slug = slug.strip("-")
+        doc["tools"][idx]["slug"] = slug
 
         open_source = tool["open_source"]
         if type(tool["open_source"]) == bool:
             open_source = "Yes" if open_source else "No"
 
         os.makedirs(slug, exist_ok=True)
-        with open(f'./{slug}/index.md', 'w') as f:
-            f.write(Template(template).render(
-                name=tool["name"],
-                description=tool["description"],
-                open_source=open_source,
-                category=tool["category"],
-                core_features=tool.get("core_features", None),
-                resources=tool.get("resources", None),
-                git_url=tool.get("git_url", None),
-            ))
+        with open(f"./{slug}/index.md", "w") as f:
+            f.write(
+                Template(template).render(
+                    name=tool["name"],
+                    description=tool["description"],
+                    open_source=open_source,
+                    category=tool["category"],
+                    core_features=tool.get("core_features", None),
+                    resources=tool.get("resources", None),
+                    git_url=tool.get("git_url", None),
+                )
+            )
 
         desc = tool["description"] or ""
-        tools[idx]['description'] = desc.replace('\n', ' ')
+        doc["tools"][idx]["description"] = desc.replace("\n", " ")
 
-    with open(f'./index.md', 'w') as f:
-        f.write(Template(index_template).render(
-            tools=doc["tools"],
-        ))
+    with open(f"./index.md", "w") as f:
+        f.write(
+            Template(index_template).render(
+                tools=sorted(doc["tools"], key=lambda d: d.get("name").lower()),
+            )
+        )

bcp-guide/tools/cyberchef/index.md

@@ -0,0 +1,17 @@
+# CyberChef
+
+CyberChef is a simple, intuitive web app for carrying out all manner of "cyber" operations within a web browser.
+These operations include simple encoding like XOR and Base64, more complex encryption like AES, DES and Blowfish, creating binary and hexdumps, compression and decompression of data, calculating hashes and checksums, IPv6 and X.509 parsing, changing character encodings, and much more.
+The tool is designed to enable both technical and non-technical analysts to manipulate data in complex ways without having to deal with complex tools or algorithms.
+It was conceived, designed, built and incrementally improved by an analyst in their 10% innovation time over several years.
+
+
+**Open Source:** Yes (Apache-2.0)
+
+**Category:** Workflows
+
+
+
+**Links:**
+- https://gchq.github.io/CyberChef/
+- [https://github.com/gchq/CyberChef](https://github.com/gchq/CyberChef)