87 lines
20 KiB
TeX
87 lines
20 KiB
TeX
|
\documentclass[../review_1.tex]{subfiles}
|
||
|
|
\graphicspath{{\subfix{../img/}}}
|
||
|
|
\begin{document}
|
||
|
|
|
||
|
|
\chapter{Anforderungen}
|
||
|
|
\noindent Im folgenden Kapitel werden die funktionalen und die nicht-funktionalen Anforderungen an das zu entwickelnde System beschrieben. Diese Anforderungen grenzen den Projektumfang eindeutig ein und legen fest, welche Eigenschaften das zu entwickelnde System haben soll. Dafür wird die \textbf{MuSCoW}-Methode verwendet, welche einführend kurz erläutert wird.
|
||
|
|
|
||
|
|
\section{Priorisierung der Anforderungen}\thispagestyle{fancy}
|
||
|
|
Um Anforderungen zu strukturieren und nach Wichtigkeit zu priorisieren, wird in der Regel ein System zur Klassifizierung der Eigenschaften verwendet. Hier wurde eine Priorisierung nach der \textbf{MuSCoW}-Methode vorgenommen:
|
||
|
|
\begin{description}
|
||
|
|
\item{\textbf{Must}:} Diese Anforderungen sind unbedingt erforderlich und nicht verhandelbar. Sie sind erfolgskritisch für das Projekt.
|
||
|
|
\item{\textbf{Should}:} Diese Anforderungen sollten umgesetzt werden, wenn alle Must-Anforderungen trotzdem erfüllt werden können.
|
||
|
|
\item{\textbf{Could}:} Diese Anforderungen können umgesetzt werden, wenn die Must- und Should-Anforderungen nicht beeinträchtigt werden. Sie haben geringe Relevanz und sind eher ein \glqq Nice to have\grqq.
|
||
|
|
\item{\textbf{Won't}:} Diese Anforderungen werden im Projekt nicht explizit umgesetzt, werden aber eventuell für die Zukunft vorgemerkt.
|
||
|
|
\end{description}
|
||
|
|
|
||
|
|
\section{Funktionale Anforderungen}
|
||
|
|
% Sie beschreiben das Systemverhalten durch Spezifikation der erwarteten Input-/Output-Beziehungen
|
||
|
|
% --> Was soll umgesetzt werden?
|
||
|
|
|
||
|
|
Funktionale Anforderungen legen konkret fest, was das System können soll. Hier wird unter anderem beschrieben, welche Funktionen das System bieten soll. Die folgende Tabelle zeigt diese funktionalen Anforderungen.
|
||
|
|
|
||
|
|
\begin{longtable} [h] {p{1cm} p{4cm} p{7cm} l}
|
||
|
|
\textbf{ID} & \textbf{Name} & \textbf{Beschreibung} & \textbf{MuSCoW} \\ \toprule \endhead
|
||
|
|
F01 & Lokale Administration & Das System muss lokal per Command-Line-Interface administriert werden können. & Must \\
|
||
|
|
F02 & Angriffsarten & Das System muss die Folgen der aufgelisteten (D)DoS-Angriffe abmildern können: \begin{itemize} \setlength{\parskip}{-2pt}
|
||
|
|
\item SYN-Flood
|
||
|
|
\item SYN-FIN Attack
|
||
|
|
\item SYN-FIN-ACK Attack
|
||
|
|
\item TCP-Small-Window Attack
|
||
|
|
\item TCP-Zero-Window Attack
|
||
|
|
\item UDP-Flood
|
||
|
|
\end{itemize}
|
||
|
|
Dabei ist vorausgesetzt, dass das Ziel eines Angriffes eine einzelne Station in einem Netzwerk ist und kein Netzwerk von Stationen. Es sind also direkte Angriffe auf einzelne Server, Router, PC, etc. gemeint. & Must \\
|
||
|
|
F03 & Keine zusätzliche Angriffsfläche & Besonders darf das System den unter ,,Angriffsarten'' spezifizierten Angriffen keine zusätzliche Angriffsfläche bieten, d.h. es darf es auch nicht durch Kenntnis der Implementierungsdetails möglich sein, das System mit diesen Angriffen zu umgehen. & Must \\
|
||
|
|
F04 & L3/ L4 Protokolle & Das System muss mit gängigen L3/ L4 Protokollen klarkommen. & Must \\
|
||
|
|
F05 & Modi & Passend zum festgestellten Angriffsmuster muss das System eine passende Abwehrstrategie auswählen und ausführen. & Must \\
|
||
|
|
F06 & Position & Das System soll zwischen dem Internet-Uplink und dem zu schützenden System oder einer Menge von Systemen platziert werden. & Must \\
|
||
|
|
F07 & Weiterleiten von Paketen & Das System muss legitime Pakete vom externen Netz zum Zielsystem weiterleiten können. & Must \\
|
||
|
|
F08 & Installation und Deinstallation & Das System muss durch Befehle in der Kommandozeile zu installieren und zu deinstallieren sein. Hilfsmittel hierzu sind: Installationsanleitung, Installationsskript, Meson und Ninja. & Must \\
|
||
|
|
F09 & Mehrere Angriffe nacheinander und zeitgleich & Das System muss mehreren Angriffen nacheinander und zeitgleich standhalten, hierbei muss berücksichtigt werden, dass auch verschiedene Angriffsarten und Muster zur gleichen Zeit erkannt und abgewehrt werden müssen. & Must \\
|
||
|
|
F10
|
||
|
|
|
||
|
|
& IPv4 & Das System muss mit IPv4-Verkehr zurechtkommen. & Must \\
|
||
|
|
F11 & Hardware & Das System soll nicht Geräte- bzw. Rechnerspezifisch sein. & Should \\
|
||
|
|
F12 & Zugriff & Der Zugriff auf das lokale System soll per SSH oder Ähnlichem erfolgen, um eine Konfiguration ohne Monitor zu ermöglichen. & Should \\
|
||
|
|
F13 & Betrieb & Das System soll auf Dauerbetrieb ohne Neustart ausgelegt sein. & Should \\
|
||
|
|
F14 & Privacy & Das System soll keine Informationen aus der Nutzlast der ihm übergebenen Pakete lesen oder verändern. & Should \\
|
||
|
|
F15 & Konfiguration & Der Administrator soll die Konfiguration mittels Konfigurationsdateien ändern können. & Can \\
|
||
|
|
F16 & Abrufen der Statistik & Der Administrator soll Statistiken über das Verhalten des Systems abrufen können. & Can \\
|
||
|
|
F17 & Starten und Stoppen des Systems & Der Administrator soll das System starten und stoppen können. & Can \\
|
||
|
|
F18 & Informieren des Anwenders & Der Anwender soll über Angriffe informiert werden. & Can \\
|
||
|
|
F19 & Administration über graphische Oberfläche & Das System soll über eine graphische Oberfläche administriert werden können. & Can \\
|
||
|
|
F20 & IPv6 & Das System soll mit IPv6-Verkehr zurechtkommen können & Can \\
|
||
|
|
F21 & Weitere Angriffsarten & Das schützt weder vor anderen außer den genannten DoS-Angriffen (siehe F02 \glqq Angriffsarten\grqq)-insbesondere nicht vor denjenigen, welche auf Anwendungsebene agieren-, noch vor anderen Arten von Cyber-Attacken, die nicht mit DoS in Verbindung stehen.
|
||
|
|
So bleibt ein Intrusion Detection System weiterhin unerlässlich. & Won't \\
|
||
|
|
F22 & Anzahl der zu schützenden Systeme & Das System wird nicht mehr als einen Server, Router, PC, etc. vor Angriffen schützen. & Won't \\
|
||
|
|
F23 & Fehler des Benutzers & Das System soll nicht vor Fehlern geschützt sein, da es durch eine nutzungsberechtigte Person am System ausgeführt wird. So sollen beispielsweise Gefährdungen, welche aus fahrlässigem Umgang des Administrators mit sicherheitsrelevanten Softwareupdates resultieren, durch das zu entwickelnde System nicht abgewehrt werden. & Won't \\
|
||
|
|
F24 & Softwareupdates & Das System soll keine Softwareupdates erhalten und soll nicht gewartet werden. & Won't \\
|
||
|
|
F25 & Router-/Firewall-Ersatz & Das System soll nicht als Router oder als Firewall-Ersatz verwendet werden. & Won't \\
|
||
|
|
F26 & Hardware-Ausfälle & Das System soll keine Hardwareausfälle (zum Beispiel auf den Links) beheben. & Won't \\
|
||
|
|
F27 & Fehler in Fremdsoftware & Das System kann nicht den Schutz des Servers bei Fehlern in Fremdsoftware garantieren. & Won't \\
|
||
|
|
\bottomrule
|
||
|
|
\end{longtable} %fehlt: Pakete weiterleiten, Pakete verwerfen
|
||
|
|
|
||
|
|
\section{Nichtfunktionale Anforderungen}
|
||
|
|
% beschreiben qualitative, aber auch quantitative Faktoren des zu entwickelnden Zielsystems
|
||
|
|
% --> Wie sollen die funktionalen Anforderungen umgesetzt werden?
|
||
|
|
|
||
|
|
Nichtfunktionale Anforderungen gehen über die funktionalen Anforderungen hinaus und beschreiben, wie gut das System eine Funktion erfüllt. Hier sind zum Beispiel Messgrößen enthalten, die das System einhalten soll. Im folgenden werden diese nichtfunktionalen Anforderungen beschrieben.
|
||
|
|
|
||
|
|
\begin{longtable}[ht] { p{1cm} p{4cm} p{7cm} l }
|
||
|
|
\textbf{ID} & \textbf{Name} & \textbf{Beschreibung} & \textbf{MuSCoW} \\ \toprule \endhead
|
||
|
|
NF01 & Betriebssystem & Die entwickelte Software muss auf einer Ubuntu 20.04 LTS Installation laufen. DPDK muss in Version 20.11.1 vorliegen und alle Abhängigkeiten erfüllt sein. & Must \\
|
||
|
|
NF02 & Verfügbarkeit & Die Verfügbarkeit des Systems soll bei mindestens 98\% liegen. Verfügbarkeit heißt hier, dass das System in der Lage ist, auf legitime Verbindungsanfragen innerhalb von 10 ms zu reagieren. & Must \\
|
||
|
|
NF03 & Datenrate & Die anvisierte Datenrate, welche vom externen Netz durch das zu entwickelnde System fließt, muss bei mindestens 20 Gbit/s liegen. & Must \\
|
||
|
|
NF04 & Paketrate & Die anvisierte Paketrate, welche vom zu entwickelnden System verarbeitet werden muss, muss bei mindestens 30 Mpps liegen. & Must \\
|
||
|
|
NF05 & Transparenz & Der Anwender soll das Gefühl haben, dass die Middlebox nicht vorhanden ist. & Should \\
|
||
|
|
NF06 & Abwehrrate SYN-Flood & Die für die Angriffe anvisierten Abwehrraten sind für die SYN-Flood, SYN-FIN und SYN-FIN-ACK jeweils 100\%. & Should \\
|
||
|
|
NF07 & False Positive & Der maximale Anteil an fälschlicherweise nicht herausgefiltertem und nicht verworfenem illegitimen Traffic, bezogen auf das Aufkommen an legitimem Traffic, soll 10\% im Angriffsfall und 5\% im Nicht-Angriffsfall nicht überschreiten. & Should \\
|
||
|
|
NF08 & False Negative & Der maximale Anteil an fälschlicherweise nicht verworfenem bösartigem Traffic, bezogen auf das Gesamtaufkommen an bösartigem Traffic, soll 5\% nicht überschreiten. & Should \\
|
||
|
|
NF09 & Round Trip Time & Die Software soll die Round-Trip-Time eines Pakets um nicht mehr als 10 ms erhöhen. & Should \\
|
||
|
|
\bottomrule
|
||
|
|
|
||
|
|
\end{longtable}
|
||
|
|
\end{document}
|