fix links and structure

Author: rpietzsch

docs/build/tutorial-how-to-link-ids-to-osint/define-the-interfaces/index.md

@@ -31,7 +31,7 @@ The first dashboard to do for our use cases is the list of IoCs with classic SPL
 Here, the figure 3 is nice but before this first schema during the project, there are a lot of shemas and all were minimalist and ugly often only on a whiteboard. This  type schema before the technical feasibility is only to validate the objective with the analysts before starting the development. During the technical feasibility, we can decrease/increase step-by-step your objectives to show finally a first result in figure 4 in a real dashboard.
 
 <figure markdown="span">
-![Figure 4. First interface with only SPARQL queries in SPLUNK static tables.](./../../link-IDS-event-to-KG/demo_ld_without_html.png)
+![Figure 4. First interface with only SPARQL queries in SPLUNK static tables.](./../link-IDS-event-to-KG/demo_ld_without_html.png)
 <figcaption>Figure 4. First interface with only SPARQL queries in SPLUNK static tables.</figcaption>
 </figure>
 
@@ -182,6 +182,6 @@ With the interfaces, the available data and their links in head, the analyst can
 
 Tutorial: [how to link Intrusion Detection Systems (IDS) to Open-Source INTelligence (OSINT)](../index.md)
 
-Next chapter: [Build a Knowledge Graph from MITRE ATT&CK® datasets](./../../lift-data-from-STIX-2.1-data-of-mitre-attack/index.md)
+Next chapter: [Build a Knowledge Graph from MITRE ATT&CK® datasets](./../lift-data-from-STIX-2.1-data-of-mitre-attack/index.md)
 
 Previous chapter: [Define the need, the expected result and the use cases](../define-the-need/index.md)

docs/build/tutorial-how-to-link-ids-to-osint/lift-data-from-STIX-2.1-data-of-mitre-attack/index.md

@@ -10,8 +10,7 @@ The MITRE ATT&CK datasets in STIX 2.1 JSON collections are here:
 * [mobile-attack.json](https://github.com/mitre-attack/attack-stix-data/blob/master/mobile-attack/mobile-attack.json){target=_blank}
 * [ics-attack.json](https://github.com/mitre-attack/attack-stix-data/blob/master/ics-attack/ics-attack.json){target=_blank}
 
-[Structured Threat Information Expression (STIX™)](
-https://oasis-open.github.io/cti-documentation/stix/intro.html) is a language and serialization format used to exchange cyber threat intelligence (CTI).
+[Structured Threat Information Expression (STIX™)](https://oasis-open.github.io/cti-documentation/stix/intro.html) is a language and serialization format used to exchange cyber threat intelligence (CTI).
 
 The "ontology" of MITRE ATT&CK with STIX is here: [https://github.com/mitre/cti/blob/master/USAGE.md](https://github.com/mitre/cti/blob/master/USAGE.md)
 
@@ -747,10 +746,10 @@ After this tutorial, you want probably to navigate in your new knowledge graph b
 
 4. Split the workflow in two workflows:
 
-   * "Transform all STIX data to RDF" to calculate the inferences after RDF triples
+    * "Transform all STIX data to RDF" to calculate the inferences after RDF triples
            ![](23-1-ex-workflow-STIX.png)
 
-   * "Assemble the global knowledge graph", it will import all the graphs of projects
+    * "Assemble the global knowledge graph", it will import all the graphs of projects
            ![](23-1-ex-workflow-gen.png)
 
 5. Create a new workflow "MITRE ATT&CK® workflow" where you will insert the other workflows, like that:

docs/build/tutorial-how-to-link-ids-to-osint/lift-data-from-YAML-data-of-hayabusa-sigma/index.md

@@ -111,61 +111,61 @@ This new transformer are building the following RDF model for your use case:
 
 5. Create the transformer for "SIGMA Hayabusa rule" to build this RDF model.
 
-Rule object:
+    Rule object:
 
-- type: `ctis:Rule`
+    - type: `ctis:Rule`
 
-- IRI: concatenation of "<http://example.com/rule/>" with the result of this regular expression `^.*?([^\/]*)$` on the rule path
+    - IRI: concatenation of "<http://example.com/rule/>" with the result of this regular expression `^.*?([^\/]*)$` on the rule path
 
-![](23-1-iri-rule.png)
+    ![](23-1-iri-rule.png)
 
-- property `ctis:filename` with the result of this regular expression `^.*?([^\/]*)$` on the value path `rulePath`
-- property `rdfs:label` with the value path `title`
-- property `rdfs:comment` with the value path `description`
-- property `rdfs:seeAlso` with the value path `references`
-- property `ctis:mitreAttackTechniqueId` is building with this formula with the value path `tags`
-    - Filter by regex: `^attack\.t\d+$`
-    - Regex replace `attack\.t` by `T`
+    - property `ctis:filename` with the result of this regular expression `^.*?([^\/]*)$` on the value path `rulePath`
+    - property `rdfs:label` with the value path `title`
+    - property `rdfs:comment` with the value path `description`
+    - property `rdfs:seeAlso` with the value path `references`
+    - property `ctis:mitreAttackTechniqueId` is building with this formula with the value path `tags`
+        - Filter by regex: `^attack\.t\d+$`
+        - Regex replace `attack\.t` by `T`
 
-![](23-1-formula-mitreid.png)
+    ![](23-1-formula-mitreid.png)
 
-- property `rdfs:isDefinedBy` on the value path `rulePath` is building with this formula to link the rules to their Web addresses.
-    - Add two "Regex replace"
-        - replace `\./hayabusa-rules/` by `https://github.com/Yamato-Security/hayabusa-rules/blob/main/`
-        - replace `\./sigma/` by `https://github.com/SigmaHQ/sigma/blob/master/`
+    - property `rdfs:isDefinedBy` on the value path `rulePath` is building with this formula to link the rules to their Web addresses.
+        - Add two "Regex replace"
+            - replace `\./hayabusa-rules/` by `https://github.com/Yamato-Security/hayabusa-rules/blob/main/`
+            - replace `\./sigma/` by `https://github.com/SigmaHQ/sigma/blob/master/`
 
-![](23-1-rules-isdefinedby.png)
+    ![](23-1-rules-isdefinedby.png)
 
-So the rulepath `./sigma/rules/windows/process_creation/proc_creation_win_bcdedit_boot_conf_tamper.yml` becomes the link `https://github.com/SigmaHQ/sigma/blob/master/rules/windows/process_creation/proc_creation_win_bcdedit_boot_conf_tamper.yml` and `./hayabusa-rules/hayabusa/sysmon/Sysmon_15_Info_ADS-Created.yml`becomes `https://github.com/Yamato-Security/hayabusa-rules/blob/main/hayabusa/sysmon/Sysmon_11_Med_FileCreated_RuleAlert.yml`
+    So the rulepath `./sigma/rules/windows/process_creation/proc_creation_win_bcdedit_boot_conf_tamper.yml` becomes the link `https://github.com/SigmaHQ/sigma/blob/master/rules/windows/process_creation/proc_creation_win_bcdedit_boot_conf_tamper.yml` and `./hayabusa-rules/hayabusa/sysmon/Sysmon_15_Info_ADS-Created.yml`becomes `https://github.com/Yamato-Security/hayabusa-rules/blob/main/hayabusa/sysmon/Sysmon_11_Med_FileCreated_RuleAlert.yml`
 
-!!! Tips
+    !!! Tips
 
-    To test your transformer, you can use the tab "Transform execution". Here, the knowledge graph will not be cleared after each workflow or execution to test your transformer because the option "clear graph before workflow" is disabled. However during the steps to build this transformer, you can enable tempory this option to see and test the final transformer.
-    You need only to disable this option when your transformer is finished.
+        To test your transformer, you can use the tab "Transform execution". Here, the knowledge graph will not be cleared after each workflow or execution to test your transformer because the option "clear graph before workflow" is disabled. However during the steps to build this transformer, you can enable tempory this option to see and test the final transformer.
+        You need only to disable this option when your transformer is finished.
 
-!!! Success
+    !!! Success
 
-    Your example of rule exists now in your knowledge graph:
-    ![](23-1-success-extract-rule2.png)
-    ![](23-1-success-extract-rule.png)
+        Your example of rule exists now in your knowledge graph:
+        ![](23-1-success-extract-rule2.png)
+        ![](23-1-success-extract-rule.png)
 
 6. Make the workflow "Import rules" with one input
 
     ![](23-1-success-workflow.png)
 
-And don't forget to allow the replacement of JSON dataset because it allows to replace this specific JSON by all other rules during the execution of this worflow.
+    And don't forget to allow the replacement of JSON dataset because it allows to replace this specific JSON by all other rules during the execution of this worflow.
 
-![](23-1-workflow-allow-replacement.png)
+    ![](23-1-workflow-allow-replacement.png)
 
-![](23-1-add-worflow.gif)
+    ![](23-1-add-worflow.gif)
 
-1. Copy the workflow ID
+7. Copy the workflow ID
 
     ![](23-1-id-worflow.gif)
 
-!!! Success
+    !!! Success
 
-    In this example the ID of workflow is `RulesHayabusaSigma_671e1f43d94bbc36:Importrules_6ccbc14b656c75c9`
+        In this example the ID of workflow is `RulesHayabusaSigma_671e1f43d94bbc36:Importrules_6ccbc14b656c75c9`
 
 ## Apply the worflow to all files