From aff06ff22625e30d11e3c01b6c19aac7988c38b7 Mon Sep 17 00:00:00 2001 From: Denis Renning Date: Fri, 11 Aug 2023 16:26:14 +0200 Subject: [PATCH] kat --- 03_Kern/kern.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/03_Kern/kern.tex b/03_Kern/kern.tex index 620f00d..f98b5f1 100644 --- a/03_Kern/kern.tex +++ b/03_Kern/kern.tex @@ -272,7 +272,7 @@ \subsubsection{} \subsection{Unzureichende Kategorisierung im Datensatz} \label{sec:Kategorisierung} -Ein großes Problem vieler Firewalls sind falsch-positive Meldungen. Hier löst die Firewall in der Annahme aus, dass ein Angriff vorliegt obwohl kein wirklicher Grund dafür vorliegt. Gründe dafür wurden bereits in Abschnitt~\ref{sec:rullog} (insbesondere Abbildung~\ref{fig.paranoia}) benannt. Falsch-positive sind aber kein alleiniges Problem der regelbasierten WAFs, auch trainierte Systeme können anfällig für dieses Verhalten sein. Für Betreiber und Nutzer von Anwendungen sind solche Meldungen unerwünscht. Im produktiven Einsatz einer WAF die mit dem CSIC2010-Datensatz trainiert wurde, würde bereits die Verwendung eines anderen Browsers (als den von Torrano-Giménez genutzten) zum \emph{False-Positive} führen, wenn die Firewall jede Abweichung vom (\emph{unbeaufsichtigt}) Erlerntem als Angriff interpretiert. Wird der Datensatz erweitert, könnten mit der Einführung weiterer Parameter Dateneinträge kategorisiert und spezifiziert werden und damit selektiv zum Einsatz kommen.\\ Beispielsweise erwähnt die Beschreibung der Anwendung in \cite{csic2010} dass Nutzer in der Anwendung registriert werden und Teile der Anwendung nur nach einem Login verfügbar sind. Ein Blick in die Daten zeigt eine Unterteilung in drei Bereiche: \\ +Ein großes Problem vieler Firewalls sind falsch-positive Meldungen. Hier löst die Firewall in der Annahme aus, dass ein Angriff vorliegt obwohl kein wirklicher Grund dafür vorliegt. Gründe dafür wurden bereits in Abschnitt~\ref{sec:rullog} (insbesondere Abbildung~\ref{fig.paranoia}) benannt. Falsch-positive sind aber kein alleiniges Problem der regelbasierten WAFs, auch trainierte Systeme können anfällig für dieses Verhalten sein. Für Betreiber und Nutzer von Anwendungen sind solche Meldungen unerwünscht. Im produktiven Einsatz einer WAF die mit dem CSIC2010-Datensatz trainiert wurde, würde bereits die Verwendung eines anderen Browsers (als den von Torrano-Giménez genutzten) zum \emph{False-Positive} führen, wenn die Firewall jede Abweichung vom (\emph{unbeaufsichtigt}) Erlerntem als Angriff interpretiert. Wird der Datensatz erweitert, könnten mit der Einführung weiterer Parameter Dateneinträge kategorisiert und spezifiziert werden und damit selektiv zum Einsatz kommen.\\ Beispielsweise erwähnt die Beschreibung der Anwendung in \cite{csic2010} dass Nutzer in der Anwendung registriert werden und Teile der Anwendung nur nach einem Login verfügbar sind. Ein Blick in die Daten zeigt eine Unterteilung in drei Bereiche und eine entsprechende Absicherung des Zugangs kann angenommen werden: \\ \begin{table}[h] \centering @@ -290,7 +290,7 @@ \subsection{Unzureichende Kategorisierung im Datensatz} \label{tab:csicsecarea} \end{table} -man in die CSIC2010-Daten chen ( +So ersichtlich wie in dieser Anwendung ist der Zustand ob ein Nutzer eingeloggt ist jedoch nicht immer und es sollte nicht davon ausgegangen werden das jede Anwendung dieses ähnlich abbildet. Die Anforderung eines URL-Pfades kann durchaus unterschiedliche Antworten erzeugen und das betrifft nicht nur den Fall der Authentifizierung. Eine Anfrage an YouTube sieht beispielsweise immer gleich aus (z.B.: \url{https://youtu.be/KTc3PsW5ghQ}) kann jedoch in Abhängigkeit von verschiedenen Variablen unterschiedliche Ergebnisse liefern (\emph{Authentifizierung, Geocoding, Einstellung zur Privatsphäre, etc.}). % Problem zu viele Falsch-Positive/Zuordnung:Framework/Status(Session) -> Anwendungsstatus (DeltaspikeClientId/SpringExecuteID) % möglichkeit anomalien nicht auf basis der Regeln sondern auf basis von abweichungen in der Anwendungsnutzung auszuwerten