Feature/md2pdf Worked on issue (#31)

.gitignore

@@ -0,0 +1,3 @@
+node_modules/
+_book/
+

000 - Introduction.md

@@ -10,7 +10,7 @@ This document is helping you to secure your containerized environment and keep i
 
 There are often misunderstandings of what the security impacts - negative or positive - are supposed to be when using Docker.
 
-Docker as any other containerization technology doesn't solve application security problems. It doesn't help doing input validation and it doesn't provide protecting against SQL injection. For application security risks OWASP provides a lot of other useful documents, starting from the OWASP Top 10 over the [https://www.owasp.org/index.php/OWASP_Proactive_Controls OWASP Proactive Controls] to the [https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project OWASP Application Security Verification standard] -- just to name a few.
+Docker as any other containerization technology doesn't solve application security problems. It doesn't help doing input validation and it doesn't provide protecting against SQL injection. For application security risks OWASP provides a lot of other useful documents, starting from the OWASP Top 10 over the [OWASP Proactive Controls](https://www.owasp.org/index.php/OWASP_Proactive_Controls) to the [OWASP Application Security Verification standard]([https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project) -- just to name a few.
 
 Container Security is mostly about system and network security and a secure architectural design.
 
@@ -22,7 +22,7 @@ Looking at it from the perspective of the classical world, especially in system
 
 Apart from these technical areas there are two non-technical points:
 
-* Docker with its 5 years is a relatively new technology. Subtracting the time for maturing and adoption the time span is even shorter. Every new technology needs time until the knowledge of the technology and their best practices becomes common knowledge.
+* Docker is not a new technology anymore but subtracting the time for maturing and adoption, its time span is shorter. Every technology needs time until the knowledge of the technology and their best practices becomes common knowledge.
 * While container solutions might offer benefits for the developer, the technology is not simple from the security perspective. Not being simple is what makes security more difficult, a.k.a. the _KISS principle_ -- keep it simple and stupid.
 
 This is what this document is trying to help you with: It provides you with the knowledge to avoid common pitfalls in the system and network area and it tries to get a handle on the complexity.
@@ -31,4 +31,12 @@ This is what this document is trying to help you with: It provides you with the
 
 In order to achieve this, this document first does an analysis of the threats caused by the technology. This is the basis for the ten points to follow.
 
+Each of those ten points has paragraphs in the following order:
 
+  * introduction,
+  * outline of threat scenarios,
+  * recommendation how to prevent the aforementioned threats,
+  * technical hint how to identify whether you might a problem here
+  * and eventually lists references (split in commercial and non-commercial ones) 
+
+It is mostly agnostic to any orchestration framework or any other specific product (OS, programming language).

001 - Threats.md

@@ -5,6 +5,9 @@ The classical approach how to secure an environment is looking at it from the at
 
 Those vectors will help you to define what needs to be protected. With this definition one can put security controls in place to provide a baseline protection and beyond. This is what the ten controls in the following chapters are about.
 
+The following image gives an overview of threats in docker.
+![threat-overview](assets/threats.png)
+
 
 ### Threat 1: Container Escape (System)
 
@@ -35,17 +38,17 @@ This again has the same first vector as the one mentioned before. With his shell
 ### Threat 6: Resource Starvation
 
 The underlying vector is due to a security condition from another container
-running on the same host. The security condition could be either to the
+running on the same host. The security condition could be due to the
 fact that the other container is eating up resources which could be CPU cycles,
 RAM, network or disk-I/O.
 
 It could also be that the container has a host file system mounted which the
-attacker has been filling up which causes problem on the host which in turn
+attacker has been filling up which causes problems on the host which in turn
 affects other containers.
 
 ### Threat 7: Host compromise
 
-Whereas the previous threat the attacker managed indirectly over the host to affect
+Whereas in the previous threat the attacker managed indirectly over the host to affect
 another / other containers, here the attacker has compromised the host -- either through
 another container or through the network.
 
@@ -56,7 +59,7 @@ The CD pipeline could involve several hops where the mini operating system image
 been passed from one step to the next until it reaches the deployment.
 
 Every hop is a potential attack surface for the attacker. If an attacker manages
-to get foot into one step and there's no integrity check whether what will be
+to get a foothold into one step and there's no integrity check whether what will be
 deployed is what should be deployed there is the threat that on behalf of the
 attacker images with his malicious payloads are being deployed.
 

CONTRIBUTING.md

@@ -0,0 +1,27 @@
+
+## Contributions / participation
+
+is always welcome!
+
+Note please the following:
+
+* One PR per feature or bug fix or improvement. Please do not mix issues.
+* Document your PR in the commit message
+* To lower the bar: For a few points being not yet complete we have dev branches like D06_dev, D07_dev. If your input is important but not complete or needs more or less polishing or amendments before being merged to main those branches are the ones you should issue use your PRs against.
+* If your PR is a WIP, please mark it accordingly. Remove that when you think you're done.
+
+## Document Structure
+
+For an amendment or if you want to fill in blanks for one of the ten points please follow the document structure:
+
+  * Introduction
+  * Examples of threat scenarios
+  * Recommendation how to prevent the aforementioned threats
+  * Technical hints how to identify whether you might have a problem here
+  * References (split in commercial and non-commercial ones)
+
+Try to be as non-specific with respect to orchestration frameworks or any other product (OS, programming language).
+
+
+For questions just open an issue.
+

D00 - Overview.md

@@ -2,15 +2,15 @@
 
 | Title | Description |
 | -- | -- |
-| D01 - Secure User Mapping | Often the main security advantage of Docker is neglected: The application within the container runs with administrative privileges: root. This violates the least privilege principle and gives an attacker better chances further extending his activities if he manages to break out of the application into the container. From the host perspective the application should never run as root. |
-| D02 - Patch Management Strategy | The host, the containment technology, the orchestration solution and the minimal operating system images in the container will have security bugs. Once publicly known it is vital for your security posture to address the bugs. For all domains mentioned you need to decide when you apply regular and emergency patches. |
-| D03 - Network Separation and Firewalling | You properly need to design your network upfront. Management interfaces from the orchestration tool as well as network services are crucial and need to be protected on a network level. Also make sure that all other network based microservices are only exposed to the legitimate consumer of this microservice and not to the whole network. |
+| D01 - Secure User Mapping | Most often the application within the container runs with the default administrative privileges: root. This violates the least privilege principle and gives an attacker better chances further extending his activities if he manages to break out of the application into the container. From the host perspective the application should never run as root. |
+| D02 - Patch Management Strategy | The host, the containment technology, the orchestration solution and the minimal operating system images in the container will have security bugs. Once publicly known it is vital for your security posture to address those bugs in a timely fashion. For all those components mentioned you need to decide when you apply regular and emergency patches before you put those into production. |
+| D03 - Network Segmentation and Firewalling | You properly need to design your network upfront. Management interfaces from the orchestration tool and especially network services from the host are crucial and need to be protected on a network level. Also make sure that all other network based microservices are only exposed to the legitimate consumer of this microservice and not to the whole network. |
 | D04 - Secure Defaults and Hardening | Depending on your choice of host and container operating system and orchestration tool you have to take care that no unneeded components are installed or started. Also all needed components need to be properly configured and locked down. |
-| D05 - Maintain Security Contexts | Mixing production containers on one host with other stages of undefined or less secure containers may open a backdoor to your production. Also mixing e.g. frontend with backend services on one host may have a negative security impact. |
-| D06 - Protect Secrets | Authentication and authorization of a microservice against a peer or a third party requires secrets to be provided. Also for an attacker those secrets potentially provide access to your data. Any passwords, tokens, private keys or certificates need to be protected as good as possible. |
-| D07 - Resource Protection | As all containers share the same physical CPU, disks, memory and networks those physical resources need to be protected so that a single container running out of control -- deliberately or not -- doesn't affect any other container's resources. |
-| D08 - Container Image Integrity and Origin | The minimal operating system in the container runs your code and needs to be fully trustworthy, starting from the origin up until the deployment. You need to make sure that all transfers as well as the images at rest are secure.  |
-| D09 - Follow Immutable Paradigm | Often container images don't need to write into their filesystem or a mounted filesystem, once set up and deployed. In those cases you have a extra security benefit if you start the containers in read-only mode. |
-| D10 - Logging | For your container image, orchestration tool and host you need to log all security relevant events on a system and API level. All logs should be remote, they should contain a common timestamp and they should be tamper proof. Your application should also provide remote logging, not into the container.
+| D05 - Maintain Security Contexts | Mixing production containers on one host with other stages of undefined or less secure containers may open a backdoor to your production. Also mixing e.g. frontend with backend services on one host may have negative security impacts. |
+| D06 - Protect Secrets | Authentication and authorization of a microservice against a peer or a third party requires secrets to be provided. For an attacker those secrets potentially enable him to access more of your data or services. Thus any passwords, tokens, private keys or certificates need to be protected as good as possible. |
+| D07 - Resource Protection | As all containers share the same physical CPU, disks, memory and networks. Those physical resources need to be protected so that a single container running out of control -- deliberately or not -- doesn't affect any other container's resources. |
+| D08 - Container Image Integrity and Origin | The minimal operating system in the container runs your code and needs to be trustworthy, starting from the origin up until the deployment. You need to make sure that all transfers and images at rest haven't been tampered with.  |
+| D09 - Follow Immutable Paradigm | Often container images don't need to write into their filesystem or a mounted filesystem, once set up and deployed. In those cases you have an extra security benefit if you start the containers in read-only mode. |
+| D10 - Logging | For your container image, orchestration tool and host you need to log all security relevant events on a system and API level. All logs should be remote, they should contain a common timestamp and they should be tamper proof. Your application should also provide remote logging.