add initial storyline for itsec people

docs/the-top-10/introduction.md

@@ -1,39 +1,60 @@
-# The OT World for Security People: Why is it problematic?
+# The OT World for Security People
 
-Maybe we should get to a more conceptional level, this might not be the list of Top 10 Vulnerabilities but rather an introduction how the concrete top 10 came to be. For example, "Insufficient Network Separation" is rather a problem with a mitigation and not the root cause vulnerability.
+!!! Info "Work in Progress"
 
-Then link the top 10 items from this conceptional walkthrough.
+    This should be an introductory text that explains to IT security people why OT security looks the way it looks.
+
+    This should also link most of the final top 10 items, as they should be related.. and should provide an IT-centric storyline how all of those Top 10 items 'play together'
 
-We have a simple high-level storyline.
+    I want to link other areas of the introduction too (and just go over them on a high-level here).
 
-## Problems specific to OT
+    I also want a similar storyline for the 'OT people'
 
-Devices that cannot be updated
+## The OT World
 
-Examples: due to availability concerns, vendor not providing updates, devices without update capabilities
+Some "special" issues:
 
-## Devices that must be protected
+- **Long lifetime of products**: decades rather than years. Remember computer security thirty
+  years ago? This is our current security level in some OT setups.
+- **Hard to Update**: it's rather hard to update a powerplant. To do this you might
+  need a spare power-plant to bridge the loss of power generated by the currently
+  being-updated power plant. In other domains, e.g., life-sustaining medical devices, the
+  update might not even be possible without endangering users.
+- **lack of integrity-protection or encrypted protocols**: due to the long lifetimes,
+  many OT protocols neither support encryption nor integrity protection. Within some
+  scenarios, e.g., on a manufactoring floor, encryption is actually not a wanted feature
+  as it makes network monitoring more complex.
 
-- We are a bit different to typical IT environments
-  - devices with (known) security vulnerabilities
-    - **related to**: device cannot be updated
-    - missing vulnerability management
-    - missing patch management
-  - unauthenticated/unauthorized communication without integrity protection
-    - **note** this might be better suited for a "general problems in OT" and not a direct vulnerability
-    - maybe replace with "attackers able to forge network requests"
+These are realities within the field with which we have to deal. Very often, we do not work in greenfield projects but have to adapt existing systems while improving securiyt. In addition, we have security problems such as vendors not providing security updates or devices lacking proper access control semantics.
 
-- we cannot do too much about existing devices, so we depend upon mitigations
+## Devices must be protected
 
-## We depend upon mitigations
+As shown before, in the OT world we often have to deal with potentially inherently insecure devices that might not be updated or upgraded too.
+
+Typically this issue is mitigated by accepting some devices to be insecure and preventing attackers from accessing them in the first place. This is typically done through mitigations such as network separation or through adding physical security controls.
+
+We would prefer to have secure devices (or even zero-trust enabled devices) but until then, often those mitigations are the only way of keeping critical infrastructure operational.
+
+!!! todo
+
+    - We are a bit different to typical IT environments
+      - devices with (known) security vulnerabilities
+        - **related to**: device cannot be updated
+        - missing vulnerability management
+        - missing patch management
+      - unauthenticated/unauthorized communication without integrity protection
+        - **note** this might be better suited for a "general problems in OT" and not a direct vulnerability
+        - maybe replace with "attackers able to forge network requests"
+
+## We depend upon Mitigations
 
 (and very often physical/network separation)
 
 - depending upon physical security
 - invalid air-gapping, see stuxnet
 - remediations are not a `get out of jail free` card and impose limitations and maintenance burden
 
-### Problem: what happens, if this separation is not upheld?
+## Problem: What happens if Mitigations fail?
 
 - dependence upon / defect mitigations
   - attackers abusing unexpected attack surfaces
@@ -48,7 +69,7 @@ Examples: due to availability concerns, vendor not providing updates, devices wi
     - maintenance access
     - adversaries being able to stay on the network
 
-## Overall: how do we react to an incident?
+## Overall: How do we react to an incident?
 
 - in IT, we often can install backups
   - Not being able to react/recover from incidents