Update Infrastructure.yml

corrected typo, changed formatting, added TOTP, changed sentences

Author: louwersj

data/Infrastructure.yml

@@ -1,23 +1,22 @@
 ---
 Infrastructure Hardening:
   The cluster is hardened:
-    risk: Using default configurations for a cluster enviroment leads to potential risks.
-    measure: Harden cluster enviroments according to best practices.
+    risk: Using default configurations for a cluster environment leads to potential risks.
+    measure: Harden cluster environments according to best practices.
     difficultyOfImplementation:
       knowledge: 4
       time: 3
       resources: 2
     usefulness: 4
     level: 2
-    implementation: 
+    implementation:
       - <a href='https://www.cisecurity.org/cis-benchmarks/'>CIS Kubernetes Bench for Security</a>
       - <a href='https://www.cisecurity.org/cis-benchmarks/'>CIS Docker Bench for Security</a>
       - "For example for Containers: Deny running containers as root, deny using advanced privileges, deny mounting of the hole filesystem, ..."
     samm2: o-environment-management|A|1
   Applications are running in virtualized environments:
-    risk: Through a vulnerability in one service on a server, the attacker gains access
-      to other services.
-    measure: Application are running in virtualized envirnoments
+    risk: Through a vulnerability in one service on a server, the attacker gains access to other services running on the same server.
+    measure: Applications are running in a dedicated and isolated virtualized environments.
     difficultyOfImplementation:
       knowledge: 3
       time: 3
@@ -26,8 +25,7 @@ Infrastructure Hardening:
     level: 2
     samm2: o-environment-management|A|1
   Checking the sources of used libraries:
-    risk: Application and system libraries can have implementation flaws or deployment
-      flaws.
+    risk: Application and system libraries can have implementation flaws or deployment flaws.
     measure: Each libraries source is checked to have a trusted source.
     difficultyOfImplementation:
       knowledge: 3
@@ -37,11 +35,8 @@ Infrastructure Hardening:
     level: 2
     samm: SA1-A
     samm2: o-environment-management|A|1
-  Segmentated networks for virtual environments:
-    risk: Virtual environments in default settings are able to access other virtual
-      environments on the network stack. By using virtual machines, it is often possible
-      to connect to other virtual machines. By using docker, one bridge is used by
-      default so that all containers on one host can communicate with each other.
+  Segmented networks for virtual environments:
+    risk: Virtual environments in default settings are able to access other virtual environments on the network stack. By using virtual machines, it is often possible to connect to other virtual machines. By using docker, one bridge is used by default so that all containers on one host can communicate with each other.
     measure: The communication between virtual environments is regulated.
     difficultyOfImplementation:
       knowledge: 3
@@ -50,17 +45,14 @@ Infrastructure Hardening:
     usefulness: 5
     level: 1
     dependsOn: []
-    implementation: 
+    implementation:
       - istio
       - bridges
       - firewalls
     samm2: o-environment-management|A|1
   Infrastructure as Code:
-    risk: No tracking of changes in systems might lead to errors in the configuration.
-      In additions, it might lead to unauthorized changes. An examples is jenkins.
-    measure: Systems are setup by code. A full enviorement can be provisioned. In
-      addition, software like Jenkins 2 can be setup and configured in in code too.
-      The code should be stored in a version control system.
+    risk: No tracking of changes in systems might lead to errors in the configuration. In additions, it might lead to unauthorized changes. An examples is jenkins.
+    measure: Systems are setup by code. A full environment can be provisioned. In addition, software like Jenkins 2 can be setup and configured in in code too. The code should be stored in a version control system.
     difficultyOfImplementation:
       knowledge: 3
       time: 5
@@ -97,8 +89,7 @@ Infrastructure Hardening:
     samm2: o-environment-management|A|1
   Microservice-Architecture:
     risk: Monolithic applications are hard to test.
-    measure: A microservice-architecture helps to have small components, which are
-      easy to test.
+    measure: A microservice-architecture helps to have small components, which are more easy to test.
     difficultyOfImplementation:
       knowledge: 4
       time: 5
@@ -108,13 +99,8 @@ Infrastructure Hardening:
     samm: SA2
     samm2: o-environment-management|A|1
   Production near environments are used by developers:
-    risk: In case an errors occurs in production, the developer need to be able to
-      create a production near environment on a local development environment.
-    measure: Usage of infrastructure as code helps to create a production near environment.
-      The developer needs to be trained in order to setup a local develipment environment.
-      In addition, it should be possible to create production like test data. Often
-      peronal identifiable information is anonymised in order to comply with data
-      protection laws.
+    risk: In case an errors occurs in production, the developer need to be able to create a production near environment on a local development environment.
+    measure: Usage of infrastructure as code helps to create a production near environment. The developer needs to be trained in order to setup a local development environment. In addition, it should be possible to create production like test data. Often personal identifiable information is anonymized in order to comply with data protection laws.
     difficultyOfImplementation:
       knowledge: 3
       time: 3
@@ -127,35 +113,32 @@ Infrastructure Hardening:
     samm: SA1
     samm2: o-environment-management|A|1
   Role based authentication and authorization:
-    risk: Everyone is able to get unauthorized access to information on systems or
-      to modify information unauthorized on systems.
-    measure: The usage of a (role based) access control helps to restrict system access
-      to authorized users.
+    risk: Everyone is able to get unauthorized access to information on systems or to modify information unauthorized on systems.
+    measure: The usage of a (role based) access control helps to restrict system access to authorized users.
     difficultyOfImplementation:
       knowledge: 2
       time: 3
       resources: 1
     usefulness: 3
     level: 3
-    implementation: Verzeichnisdienst, Plugins
+    implementation: Directory Service, Plugins
     dependsOn:
     - Defined deployment process
     - Defined build process
     samm2: o-environment-management|A|1
   2FA:
-    risk: One factor authentication is simple to bruteforce
+    risk: One factor authentication is more vulnerable to brute force attacks and is considered less secure.
     measure: Two factor authentication for all privileged accounts on systems and applications
     difficultyOfImplementation:
       knowledge: 3
       time: 2
       resources: 3
     usefulness: 4
     level: 3
-    implementation: Smartcard, YubiKey, SMS
+    implementation: Smartcard, YubiKey, SMS, TOTP
     samm2: TODO
   Simple access control for systems:
-    risk: Attackers a gaining access to interal systems and application interfaces
-    measure: All internal systems are using simple authentication
+    risk: Attackers a gaining access to internal systems and application interfaces measure: All internal systems are using simple authentication
     difficultyOfImplementation:
       knowledge: 3
       time: 3
@@ -168,11 +151,8 @@ Infrastructure Hardening:
     samm: EH1-B
     samm2: o-environment-management|A|1
   Usage of a chaos monkey:
-    risk: Due to manuel changes on a system, they are not replaceable anymore. In
-      case of a crash it might happen that a planned redudant system is unavailable.
-      In addation, it is hard to replay manual changes.
-    measure: A randomized peridically shutdown of systems makes sure, that nobody
-      will perform manuall changes to a system.
+    risk: Due to manuel changes on a system, they are not replaceable anymore. In case of a crash it might happen that a planned redundant system is unavailable. In addition, it is hard to replay manual changes.
+    measure: A randomized periodically shutdown of systems makes sure, that nobody will perform manual changes to a system.
     difficultyOfImplementation:
       knowledge: 3
       time: 5
@@ -182,9 +162,7 @@ Infrastructure Hardening:
     samm2: o-environment-management|A|1
   Usage of security by default for components:
     risk: Components (images, libraries, applications) are not hardened.
-    measure: Hardening of components is important, specially for image on which other
-      teams base on. Hardening should be performed on the operation system and on
-      the services inside (e.g. Nginx or a Java-Application).
+    measure: Hardening of components is important, specially for image on which other teams base on. Hardening should be performed on the operation system and on the services inside (e.g. Nginx or a Java-Application).
     difficultyOfImplementation:
       knowledge: 4
       time: 3
@@ -197,7 +175,7 @@ Infrastructure Hardening:
     - Defined build process
     samm2: o-environment-management|A|1
   Usage of test and production environments:
-    risk: Security tests are not running reculary because test environments are missing
+    risk: Security tests are not running regularly because test environments are missing
     measure: A production and a production like envirnoment is used
     difficultyOfImplementation:
       knowledge: 3
@@ -208,10 +186,9 @@ Infrastructure Hardening:
     dependsOn:
     - Defined deployment process
     samm2: o-environment-management|A|1
-  Versioning:
+  versioning:
     risk: Changes to production systems can not be undone.
-    measure: Versioning of artifacts related to production environments. For example
-      Jenkins configuration, docker images, system provisioning code.
+    measure: versioning of artifacts related to production environments. For example Jenkins configuration, docker images, system provisioning code.
     difficultyOfImplementation:
       knowledge: 3
       time: 3
@@ -222,10 +199,8 @@ Infrastructure Hardening:
     - Defined deployment process
     samm2: o-environment-management|A|1
   Virtual environments are limited:
-    risk: Denail of service (intenenally by an attacker or uninteninally by a bug)
-      on one service effects other services
-    measure: All virtual envirnoments are using resource limits on hard disks, memory
-      and CPU
+    risk: Denial of service (internally by an attacker or unintentionally by a bug) on one service effects other services
+    measure: All virtual environments are using resource limits on hard disks, memory and CPU
     difficultyOfImplementation:
       knowledge: 2
       time: 2
@@ -235,4 +210,4 @@ Infrastructure Hardening:
     dependsOn:
     - Applications are running in virtualized environments
     samm2: o-environment-management|A|1
-...
+...