Merge pull request #3 from HSR-Cheat-Sheets/dev

Dev

content/01-security_components.tex

@@ -1,32 +1,75 @@
 %! Licence = CC BY-NC-SA 4.0
 
-%! Author = gianfluetsch
+%! Author = gianfluetsch, mariuszindel
 %! Date = 19. Jan 2022
 %! Project = pfsec_summary
 
-\section{Sicherheitskomponenten}
+\section{Betty Bossi}
 
 \begin{center}
     \vspace{-8pt}
     \includegraphics[width=1.0\linewidth]{01-security_components/secure_architecture}
     \vspace{-8pt}
 \end{center}
 
+\subsection{Komponente}
+\subsubsection{User}
 \begin{itemize}
-    \item Firewall
-    \item WAF (Web Application Firewall)
-    \item IDS (Intrusion Detection System)
-    \item IPS (Intrusion Prevention System)
-    \item IAM (Identity Access Management)
-    \item OS Hardening
-    \begin{itemize}
-        \item Patching
-        \item Endpoint protection
-        \item Anti Virus (AV)
-        \item Host-based Firewall
-        \item Application white listing
-    \end{itemize}
-    \item Configure Logging
-    \item Configure Backups (on site and off site)
+    \item IAM $\rightarrow$ Unternehmen müssen heute auch aus Compliance-Gründen personenbezogene Daten konsistent speichern sowie ständig verfügbar und verlässlich bereithalten
+    \item Preventing parameter manipulation (CSRF $\rightarrow$ Cross-Site-Request-Forgery)
+    \item Preventing parameter manipulation (MITM $\rightarrow$ Man In The Middle))
 \end{itemize}
 
+
+\subsubsection{External FW}
+\begin{itemize}
+    \item Preventing DoS attack
+    \item Blacklisting IP addresses
+    \item Web forensic readiness (Unique ID)
+    \item Separating network DMZ / internal / external
+    \item WAF
+    \item IDS logging / IPS execution
+\end{itemize}
+
+\subsubsection{Internal FW}
+\begin{itemize}
+    \item Separating networks
+    \item WAF
+    \item IDS logging / IPS execution
+\end{itemize}
+
+\subsubsection{Server}
+\begin{itemize}
+    \item OS security $\rightarrow$ \textit{\nameref{subsec:os-hardening}}
+    \item Network security
+    \item Access Control of Server itself $\rightarrow$ \textit{\nameref{subsubsec:access-control}}
+    \item HW sec?
+\end{itemize}
+
+\newpage
+
+\subsection{Keywords - Basic security design principle}
+\begin{center}
+    \begin{tabular}{l c p{8cm}}
+        \hline
+        \bfseries{Keyword}                        &    \bfseries{System}              & \bfseries{Description}\\
+        \hline\hline
+        Economy of mechanism           &   ganzes System        &   KISS\\\hline
+        Fail-safe defaults             &   Applikation          &   Access Decision sollte bei Fehler in Safe\-State fallen\\\hline
+        Complete mediation             &   IAM                  &   Jeder Access sollte überprüft sein (keine Blindgänger im System)\\\hline
+        Open design                    &   Applikation          &   Keine verschleierung, keine Angriffsfläche auch wenn man es kennt\\\hline
+        Separation of privilege        &   IAM                  &   Normale Aufgaben sollten nicht mit dem Admin User getätigt werden.\\\hline
+        Least privilege                &   IAM                  &   Benutzer sollte nur Rechte auf Objekten haben, welche er für die Tätigkeit benötigt\\\hline
+        Least common mechanism         &   IAM                  &   Minimieren Sie die Anzahl der Mechanismen, die von mehreren Benutzern gemeinsam genutzt werden und auf die alle Benutzer angewiesen sind\\\hline
+        Psychological acceptability    &   ganzes System        &   Nutzer sollte von der Tätigkeit überzeugt sein (wieso das so gemacht wird)\\\hline
+        Isolation                      &   Application          &   System sollte in mehrerere Layer unterteilt werden und durch FW getrennt sein.\\\hline
+        Encapsulation                  &   Application          &   eigene Domain\\\hline
+        Modularity                     &   Application          &   Systeme als einzelne Module betrachten\\\hline
+        Layering                       &   ganzes System        &   Unterteilung in Layer \textit{\nameref{subsubsec:implementation-of-access-controls}}\\\hline
+        Least astonishment             &   Application          &   Benutzer sollte nicht über Reaktion des Systems überrascht sein\\\hline
+    \end{tabular}
+\end{center}
+
+
+
+

content/02-platform_security.tex

@@ -29,10 +29,10 @@ \subsubsection{Characteristics}
 
 \subsubsection{Key Characteristics}
 \begin{itemize}
-    \item Sie besteht aus einem \textbf{transparenten und kohärenten Überblick über Modelle, Grundsätze, Ausgangspunkte und Bedingungen}, die eine konkrete Auslegung der Informationssicherheitspolitik ermöglichen, ohne dass in der Regel konkrete Lösungen genannt werden. spezifische Lösungen zu sprechen.
+    \item Sie besteht aus einem \textbf{transparenten und kohärenten Überblick über Modelle, Grundsätze, Ausgangspunkte und Bedingungen}, die eine konkrete Auslegung der Informationssicherheitspolitik ermöglichen, ohne dass in der Regel von spezifischen Lösungen die Rede ist.
     \item Sie \textbf{reduziert ein komplexes Problem} auf Modelle, Prinzipien und Teilprobleme, die es zu verstehen gilt.
     \item Ziel ist eine gute Verständlichkeit zu erreichen, auch wenn das Problem sehr komplex ist
-    \item Die Modelle und Grundsätze \textbf{zeigen, wo Sie welche Art von Maßnahmen ergreifen, wann die Grundsätze anwendbar sind und wie sie mit anderen Grundsätzen mit anderen Prinzipien zusammenhängen}.
+    \item Die Modelle und Grundsätze \textbf{zeigen, wo Sie welche At von Maßnahmen ergreifen, wann die Grundsätze anwendbar sind und wie sie mit anderen Grundsätzen mit anderen Prinzipien zusammenhängen}.
 \end{itemize}
 
 \subsection{Basic Security Design Principles}

content/03-operating_system_security.tex

@@ -11,24 +11,24 @@ \subsection{Introduction}
 \subsubsection{Layers}
 \textit{User Applications and Utilities $\rightarrow$ Operating System Kernel $\rightarrow$ Physical Hardware}\\
 
-Das Vorhandensein von BIOS und möglicherweise anderem Code, der außerhalb des Betriebssystemkerns liegt und Betriebssystem-Kernel nicht sichtbar ist, aber beim Booten des Systems verwendet wird des Systems oder zur Unterstützung der Low-Level-Hardware-Steuerung verwendet wird, ist in den Schichten.
-Für jede dieser Layer müssen geeignete Hardening-Massnahmen ergriffen werden um angemessene Sicherheitsdienste bereitzustellen. Und jeder Layer ist anfällig für Angriffe von unten angreifbar, wenn die unteren Schichten nicht auch entsprechend gesichert sind.
+Das Vorhandensein von BIOS und möglicherweise anderem Code, der sich außerhalb des Betriebssystem-Kernels befindet und für den Betriebssystemkern größtenteils nicht sichtbar ist, aber beim Booten des Systems oder zur Unterstützung der Low-Level-Hardwarekontrolle verwendet wird, ist in den Schichten nicht dargestellt.
+Jede dieser Codeschichten muss durch geeignete Hardening-Massnahmen geschützt werden, um angemessene Sicherheitsdienste bereitzustellen. Und jede Schicht ist anfällig für Angriffe von unten, wenn die unteren Schichten nicht ebenfalls angemessen gesichert sind.
 
 \subsubsection{Strategies}
 \begin{enumerate}
-    \item White-list approved applications
+    \item \textbf{White-list approved applications}
     \begin{itemize}
         \item Was (welche Applikation) darf auf welchem Layer laufen $\rightarrow$ Whitelisting
     \end{itemize}
-    \item Patch third-party applications and operating system vulnerabilities
+    \item \textbf{Patch third-party applications and operating system vulnerabilities}
     \begin{itemize}
         \item Wann wird welcher Patch eingespielt, anhand möglicher Probleme etc. Strategie erstellen und umsetzen
     \end{itemize}
-    \item Restrict administrative privileges
+    \item \textbf{Restrict administrative privileges}
     \begin{itemize}
         \item Wirklich nur wenn nötig admin-Rechte vergeben oder Zeitbeschränkt admin-Rechte einrichten $\rightarrow$ Principle of Least Privileges
     \end{itemize}
-    \item Create a defense-in-depth system
+    \item \textbf{Create a defense-in-depth system}
 \end{enumerate}
 
 \subsubsection{Build and Deploy Process}
@@ -65,7 +65,7 @@ \subsubsection{System Security Planning}
     \vspace{-8pt}
 \end{center}
 
-\subsection{OS Hardening}
+\subsection{OS Hardening}\label{subsec:os-hardening}
 
 \subsubsection{Steps in OS Hardening}
 \begin{enumerate}
@@ -85,7 +85,7 @@ \subsubsection{Steps in OS Hardening}
     \end{itemize}
 \end{enumerate}
 
-\textcolor{red}{\textbf{Wenn zwischen Schritt 1 \& 2 schon jemand Zugriff auf das System hat und etwas schädliches einspielen könnte, kann man es gerade sein lassen $\rightarrow$ bereits kompromitiertes System.}}
+\textcolor{red}{\textbf{Wenn zwischen Schritt 1 \& 2 schon jemand Zugriff auf das System hat und etwas schädliches einspielen könnte, kann man es gerade sein lassen $\rightarrow$ bereits kompromittiertes System.}}
 
 \subsubsection{Application Configuration}
 \begin{itemize}
@@ -100,7 +100,7 @@ \subsubsection{Application Configuration}
 \subsubsection{Encryption Technology}
 \begin{itemize}
     \item Is a key enabling technology that may be used to secure data both in transit and when stored
-    \item Must be configured and appropriate cryptographic keys created, signed, and secured
+    \item Must be configured and appropriate cryptographic keys created, signed and secured
     \item If secure network services are provided using TLS or IPsec suitable public and private keys must be generated for each of them
     \item If secure network services are provided using SSH, appropriate server and client keys must be created
     \item Cryptographic file systems are another use of encryption
@@ -113,7 +113,7 @@ \subsubsection{Maintaining Security is continuous}
     \item Performing regular backups
     \item Recovering from security compromises
     \item Regularly testing system security
-    \item Using appropriate software maintenance processes to patch and update all critical software, and to monitor and revise configuration as needed
+    \item Using appropriate software maintenance processes to patch and update all critical software and to monitor and revise configuration as needed
 \end{itemize}
 
 \subsubsection{Logging as cornerstone}

content/04-access_control.tex

@@ -6,7 +6,7 @@
 
 \section{Access Control}
 
-\subsection{Different typos of access control}
+\subsection{Different types of access control}
 
 \subsubsection{Controlling access to assets}
 An access control is any hardware, software, or administrative policy or procedure that controls access to resources.
@@ -32,11 +32,11 @@ \subsubsection{Primary Access Control Types}
     \item \textbf{Preventive}
     \begin{itemize}
         \item A preventive control attempts to thwart or stop unwanted or unauthorized activity from occurring.
-        \item \textit{Examples}: fences, locks, biometrics, mantraps, lighting, alarm systems, separation of duties, job rotation, data classification, penetration testing, encryption, auditing, security cameras, smartcards, security policies, securityawareness training, antivirus software, firewalls, intrusion prevention systems (IPSs).
+        \item \textit{Examples}: fences, locks, biometrics, mantraps, lighting, alarm systems, separation of duties, job rotation, data classification, penetration testing, encryption, auditing, security cameras, smartcards, security policies, securityawareness training, antivirus software, firewalls, intrusion prevention systems (IPS).
     \end{itemize}
-    \item \textit{Detective}
+    \item \textbf{Detective}
     \begin{itemize}
-        \item  A detective control attempts to discover ordetect unwanted or unauthorized activity.
+        \item  A detective control attempts to discover or detect unwanted or unauthorized activity.
         \item Detective controls operate after the fact and can discover the activity only after it has occurred.
         \item \textit{Examples}: security guards, motion detectors, recording and review of events captured by security cameras, job rotation, mandatory vacations, audit trails, honeypots, intrusion detection systems (IDSs), supervision and reviews of users, incident investigations.
     \end{itemize}
@@ -72,11 +72,11 @@ \subsubsection{Other Types of Access Control}
     \end{itemize}
 \end{itemize}
 
-\subsubsection{Implementation of Access Controls}
+\subsubsection{Implementation of Access Controls}\label{subsubsec:implementation-of-access-controls}
 \begin{itemize}
     \item \textbf{Physical controls}
     \begin{itemize}
-        \item Physikalischer Präventivmassnahme, um z.B. nur einzelnen Personen Zutritt zum RZ gewähren
+        \item Physikalische Präventivmassnahme, um z.B. nur einzelnen Personen Zutritt zum RZ gewähren
         \item items you can physically touch. Physical mechanisms deployed to prevent, monitor, or detect direct contact with systems or areas within a facility.
         \item \textit{Examples}: guards, fences, motion detectors, locked doors, sealed windows, lights, cable protection, laptop locks, badges, swipe cards, guard dogs, video cameras, mantraps, alarms
     \end{itemize}
@@ -105,15 +105,15 @@ \subsubsection{Authorization Principles}
     \begin{itemize}
         \item Basic principle of access control is implicit deny
         \item Most authorization mechanisms use it.
-        \item The implicit deny principle ensures that access to an object is denied unless access has been explicitly granted to a subject.
+        \item The implicit deny principle ensures that access to an object (file) is denied unless access has been explicitly granted to a subject (user).
     \end{itemize}
     \item \textbf{Constrained Interface}
     \begin{itemize}
         \item Applications use constrained interfaces or restricted interfaces to restrict what users can do or see based on their privileges.
         \item Users with full privileges have access to all the capabilities of the application.
         \item A common method is to hide the capability if the user does not have permissions to use it.
     \end{itemize}
-    \item \textbf{content-Dependent Control}
+    \item \textbf{Content-Dependent Control}
     \begin{itemize}
         \item Restrict access to data based on the content within an object.
         \item Auf sensible/ persönliche Daten gibt es eine Access Control (oft bei Löhnen etc. so geregelt)
@@ -297,7 +297,7 @@ \subsubsection{Attribute-Based Access Control (ABAC)}
 \begin{itemize}
     \item Can define authorizations that express conditions on properties of both the resource and the subject
     \item Strength is its flexibility and expressive power
-    \item Main obstacle to its adoption in real systems has been concern abaout the performance impact of evaluating predicates on both resource and user properties for each access
+    \item Main obstacle to its adoption in real systems has been concern about the performance impact of evaluating predicates on both resource and user properties for each access
     \item Web services have been pioneering technologies through the introduction of the \textit{eXtensible Access Control Markup Language (XACML)}
     \item There is considerable interest in applying the model to cloud services
 \end{itemize}
@@ -379,8 +379,8 @@ \subsubsection{ABAC Trust Chain}
     \vspace{-8pt}
 \end{center}
 
-$subject \rightarrow Authentication \rightarrow Access Control Decision \rightarrow Access Control Enforcement \rightarrow$ object ist genau gleich wie bei der ACL Trust Chain\\
-$\rightarrow$ Allerdings gibt es zusätzliche Attribute\\
+$subject \rightarrow Authentication \rightarrow Access Control Decision \rightarrow Access Control Enforcement \rightarrow object$\\
+ist genau gleich wie bei der ACL Trust Chain $\rightarrow$ Allerdings gibt es zusätzliche Attribute\\
 
-Ein Vergleich von repräsentativen Vertrauensbeziehungen für die Verwendung von ACL und ABAC zeigt, dass es viel komplexere Vertrauensbeziehungen gibt, die erforderlich sind, damit ABAC richtig funktioniert. Ignoriert man die Gemeinsamkeiten in beiden Teilen, kann man feststellen dass bei ACLs die Root of Trust beim Objectowner liegt, der letztlich die Objektzugriffsregeln durchsetzt, indem er den Zugriff auf das Objekt durch Hinzufügen eines Benutzers zu einer ACL. 
+Ein Vergleich von repräsentativen Vertrauensbeziehungen für die Verwendung von ACL und ABAC zeigt, dass es viel komplexere Vertrauensbeziehungen gibt, die erforderlich sind, damit ABAC richtig funktioniert. Ignoriert man die Gemeinsamkeiten in beiden Teilen, kann man feststellen dass bei ACLs die Root of Trust beim ObjectOwner liegt, der letztlich die Objektzugriffsregeln durchsetzt, indem er den Zugriff auf das Objekt durch Hinzufügen eines Benutzers zu einer ACL regelt.
 

content/05-iam.tex

@@ -22,7 +22,7 @@ \subsubsection{Authentication}
 
 \subsubsection{Principle Propagation}
 \begin{minipage}{0.5\linewidth}
-    In a multi-tiered architecture, principal propagation is important. Whenever a principal (user or another application) is authenticated, a \textit{security context} is created. That context may be system or environment or even mechanism dependent. \textit{But that security context should contain reliable trustworthy identity data that corresponds to an authenticated principal}.\\
+    In a multi-tiered architecture, principal propagation is important. Whenever a principal (user or another application) is authenticated, a \textit{security context} is created. That context may be system, environment or even mechanism dependent. \textit{But that security context should contain reliable trustworthy identity data that corresponds to an authenticated principal}.\\
 
     During propagation, \textit{the security context is transferred from one trusted tier to the next trusted one}. Each server application can obtain the authenticated identification of the client principle from the security context. The use of the authenticated identity is necessary for the correct creation of accountability data and the correct application of authorization policies.\\
 \end{minipage}
@@ -40,12 +40,14 @@ \subsubsection{Principle Propagation}
     \vspace{-8pt}
 \end{center}
 
-\subsubsection{Access Control}
+\subsubsection{Access Control}\label{subsubsec:access-control}
 \begin{center}
     \includegraphics[width=.7\linewidth]{05-iam/access_control}
     \vspace{-8pt}
 \end{center}
 
+\newpage
+
 \paragraph{Options for Integration with centralized access control}
 \begin{center}
     \includegraphics[width=.7\linewidth]{05-iam/access_control2}