\documentclass[a4paper]{article}
\usepackage{ngerman}
\usepackage{graphicx}

\title{NetSec 1.~"Ubungsblatt}
\author{Carl-Friedrich L"ubeck, 2101543\\
Florian Forster, 2099894\\
Sebastian Harl, 21095050}

\begin{document}
\maketitle

\section*{Aufgabe 1}
\begin{itemize}
\item[\bf a] Lehrstuhl
 \begin{itemize}
 \item {\bf Confidentiality}: Da bei der Kommunikation mit Kunden, externen
 Mitarbeitern o.~"A. vertrauliche Daten ausgetauscht werden, muss die
 Kommunikation gesch"utzt werden.
 \item {\bf Data Integrity}: Es sollte nicht m"oglich sein Forschungsergebnisse
 (unbemerkt) zu verf"alschen, die Buchhaltung zu manipulieren, etc.
 \item {\bf Controlled Access}: Lehrstuhlfremde Personen sollen/d"urfen keinen
 Zugriff auf Forschungsergebnisse, Gesch"aftsbeziehungen und
 Finanzinformationan haben.
 \end{itemize}

\item[\bf b] Arztpraxis
 \begin{itemize}
 \item {\bf Confidentiality}: Patientendaten sollten, etwa beim Austausch mit
 dem Haus- bzw. Allgemeinarzt, auch nur wirklich den beabsichtigten Personen
 zug"anglich sein.
 \item {\bf Accountability}: Im Zweifelsfall sollte nachvollziehbar sein,
 {\bf wer} bestimmte Daten erhoben hat.
 \item {\bf Controlled Access}: Selbstverst"andlich sollten Patientendaten auch
 nicht wildfremden Personen zur Verf"ugung stehen.
 \end{itemize}

\item[\bf c] Zu Hause
 \begin{itemize}
 \item {\bf Confidentiality}: Mein Nachbar soll WLAN-Traffic nicht einfach
 mitlesen, der Netzbetreiber E-Mails nicht mitsniffen k"onnen.
 \item {\bf Controlled Access}: Ohne g"ultiges Login soll kein Zugriff auf
 Daten und Funktionen der Systeme m"oglich sein.
 \end{itemize}
\end{itemize}

{\it Zu {\bf c}}: So lange kein physikalischer Zugang zu den Systemen
existiert, ist die Einhaltung dieser Ziele nicht unwahrscheinlich. Da ich
physikalischen Zugang als ausreichend unwahrscheinlich einsch"atze, sind keine
entsprechenden Anstrengungen unternommen worden. 

\section*{Aufgabe 2}
\begin{tabular}{l|l|l}
 & Ereignis & Beteiligte \\
 \hline
 a & Erstellung der Software & Hersteller \\
 b & m"ogliche Attacken auf das System & Cracker? {\it Fehlt hier nicht ein Verb?} \\
 c & Erkennung/Entdeckung der Attacken & Hersteller, ggf. Anwender \\
 d & Analyse der Attacken & Hersteller, ggf. Anwender \\
 e & Erstellung einer Aktualisierung der Software & Hersteller, ggf. Hacker \\
 f & Verbreitung der Aktualisierung & Hersteller, ggf. Anwender
\end{tabular}

\subsection*{Teilaufgabe a}
Entwickler m"ussen {\bf m"ogliche} Attacken voraussehen und m"oglichst
vorbeugen. Wenn trotzdem ein Angriffspunkt gefunden wird, liegt es an ihnen den
Angriff zu analysieren und den Fehler zu beheben. Der Entwickler muss sich also
deutlich l"anger um das System k"ummern, als die Entwicklungsphase dauert.

\subsection*{Teilaufgabe b}
Zwar ist der Entwickler nicht ganz machtlos: Er kann beispielsweise eine
Big-Endian-Platform w"ahlen, weil die meisten auf Buffer-Overflows basierenden
Exploids fuer Little-Endian geschrieben werden. Das kann ihm die Schar der an
sich ungef"ahrlichen (aber nervigen) Script-Kiddies vom Hals halten. Gegen
einen "`richtigen"' Cracker hilft das nat"urlich nicht.

Einen klaren Vorteil hat der Angreifer: Er kann sich den Ort des Geschehens und
den Zeitpunkt w"ahlen und braucht an sich nur einen Fehler des Entwicklers
finden. So bald das Produkt also ver"offentlicht wurde, befindet sich der
Entwickler ununterbrochen (mehr oder minder) in der Defensive.

\section*{Aufgabe 3}
\includegraphics[width=12cm]{Attacktree.pdf}

\end{document}
