Jusletter IT

Privacy by Design (PbD) gewinnt zunehmend an Bedeutung und fordert im Wesentlichen die Berücksichtigung von Privatsphäreschutz und Datenschutz bereits während der Entwicklung eines Systems und nicht erst dann, wenn dieses schließlich eingesetzt wird. Dasselbe gilt für die Berücksichtigung der Informationssicherheit (Security) des Systems. Dies klingt ziemlich einleuchtend und einfach; es stellt sich allerdings die Frage, was ein solches Vorgehen in der Praxis bedeutet. Mit dieser Frage beschäftigt sich der vorliegende Beitrag.

Es wird ein auf Scrum basierender Softwareentwicklungsprozess vorgestellt, der systematische Mechanismen zur Umsetzung von Security- und Privacy-Anforderungen beinhaltet. Scrum ist ein leichtgewichtiges Framework zur Lösung komplexer Probleme, um produktiv und kreativ ein bestmögliches Produkt zu liefern. Das Framework beruht auf der empirischen Prozesskontrolle, d.h. produzierte Artefakte werden nicht als gegeben angesehen, sondern stets einem iterativen Verbesserungsprozess unterzogen.¹ Weitere Grundlagen zu Scrum können in der an der jeweiligen Stelle angeführten Literatur und in zahlreichen weiteren Quellen nachgelesen werden und werden als Basis der nachfolgenden Ausführungen vorausgesetzt.

In der Konzeption des Prozesses wurde auf verschiedenen Ansätzen aufgebaut, die den Gebieten Security by Design bzw. Secure Coding zuzuordnen sind und jeweils referenziert sind. Die daraus abgeleiteten Konzepte wurden darüber hinaus um die Berücksichtigung von Privacy by Design erweitert. Der so konzipierte Prozess dient im Projekt «ePartizipation – Authentifizierung bei demokratischer Online-Beteiligung» als Grundlage für die Entwicklung des Demonstrators. Erste Erfahrungen mit dem Prozess werden in Kapitel 4 diskutiert. Im vorliegenden Beitrag soll überwiegend auf die Privacy-Aspekte des Prozesses eingegangen werden.

PbD «bedeutet, dass der Schutz der Privatsphäre und der Datenschutz in den gesamten Technologie-Lebenszyklus integriert werden, vom frühen Entwurfsstadium bis zu deren Einführung, Nutzung und letztendlichen Außerbetriebnahme.»² Wie in dieser knappen und treffenden Definition der Europäischen Kommission deutlich wird, ist es das Kernelement des Prinzips PbD, den Schutz der Privatsphäre und den Datenschutz nicht auf ein bereits entwickeltes System aufzusetzen, sondern bereits im Entwicklungsprozess des Systems in das System «einzubauen». In der künftigen Datenschutzgrundverordnung (DSGVO) wird «data protection by design» zu einem Grundprinzip des Datenschutzes erhoben, sodass «both at the time of the determination of the means for processing and at the time of the processing itself» angemessene technische und organisatorische Maßnahmen getroffen werden müssen, um die Anforderungen der Verordnung zu erfüllen und die Rechte der Betroffenen zu wahren.³ PbD kann mit «eingebauter Datenschutz»⁴ oder «Datenschutz durch Technik»⁵ übersetzt werden, hier wird aber dem englischen Terminus der Vorzug gegeben.

Das Konzept PbD geht bereits auf die 1990er-Jahre zurück und ist eng mit der Person Ann Cavoukian verbunden, der ehemaligen Datenschutzbeauftragten der kanadischen Provinz Ontario, die sieben Grundprinzipien von PbD postulierte.⁶ Bei diesen handelt es sich allerdings nur um abstrakte Vorgaben, die nichts über ihre Umsetzung aussagen und denen Mechanismen zur Integration von Datenschutz in den Entwicklungsprozess eines Systems fehlen.⁷

Zahlreiche Publikationen haben sich in den letzten Jahren mit der datenschutzgerechten Gestaltung von Systemen beschäftigt, manche auch, ohne dies als PbD zu bezeichnen.⁸ All diese Publikationen machen zweierlei deutlich: Erstens ist es die Einhaltung einiger weniger Grundprinzipien, die PbD ausmacht, allen voran das Prinzip der Datenminimierung. Die folgende Liste von Privacy-Strategien stammt von Hoepman⁹ und findet sich auch im bereits zitierten Papier der ENISA¹⁰:

• MINIMISE: The amount of personal data that is processed should be restricted to the minimal amount possible.
• HIDE: Any personal data, and their interrelationships, should be hidden from plain view.
• SEPARATE: Personal data should be processed in a distributed fashion, in separate compartments whenever possible.
• AGGREGATE: Personal data should be processed at the highest level of aggregation and with the least possible detail in which it is (still) useful.
• INFORM: Data subjects should be adequately informed whenever personal data is processed.
• CONTROL: Data subjects should be provided agency over the processing of their personal data.
• ENFORCE: A privacy policy compatible with legal requirements should be in place and should be enforced.
• DEMONSTRATE: Be able to demonstrate compliance with the privacy policy and any applicable legal requirements.

Diese Strategien können in zwei Gruppen eingeteilt werden: Die vier erstgenannten sind datenorientiert, die anderen prozessorientiert.

Zweitens kann wohl kein einfacher, allgemein anwendbarer Standardprozess definiert werden, um diese Grundsätze im Entwicklungsprozess eines Systems zuverlässig umzusetzen. Dies muss jeweils individuell erfolgen, indem unter Berücksichtigung des Zwecks und der gewünschten Funktionalität des jeweiligen Systems geeignete Strategien, Design Patterns und Technologien (Privacy-enhancing Technologies, PETs) im System implementiert werden. Dies kann als «Privacy Engineering» bezeichnet werden und erfordert u.E. Experten – «Privacy Engineers» –, die technische Kenntnisse und Kenntnisse des Datenschutzes haben, einschließlich «weicher» Faktoren, wie das Wissen über Good Practice, Design Patterns, häufige Fehler, aktuelle Bedrohungen und Angriffsmethoden etc. Dies schlägt eine Brücke zu den Security-Experten, eine Profession, die bereits wesentlich länger etabliert ist und sich auch bereits länger mit der praktischen Umsetzung von Security by Design befasst, für das die in diesem Kapitel dargestellte Zielsetzung analog zu sehen ist.¹¹ Es zeigt sich, dass Security by Design und Privacy by Design einander überschneiden und nicht strikt getrennt betrachtet werden können.

Der nachfolgend präsentierte Entwicklungsprozess ist ein Prozess, in dem inkrementell ein Softwareprodukt entwickelt wird. Die Darstellung konzentriert sich dabei auf den Prozess und die Prozessbeteiligten. Die Behandlung der Frage, wie und woraus Security-Anforderungen abgeleitet werden und wie aus den genannten Privacy-Strategien Privacy-Anforderungen abgeleitet werden, würde den Rahmen sprengen. Zu dieser Frage sei auf andere Publikationen verwiesen.¹² Zu betonen ist auch, dass Privacy und Security by Design nur dann effektiv umgesetzt werden kann, wenn es bereits beim Entwurf der Softwarearchitektur berücksichtigt wird.

Wie gezeigt wurde, existiert PbD als Konzept bereits sehr lange, hat aber in die Praxis der Softwareentwicklung noch wenig Eingang gefunden. Dies wird, wie erwähnt, in Form eines Standardprozesses, dessen Einhaltung automatisch ein datenschutzfreundliches Endprodukt garantiert, auch gar nicht möglich sein. Vielmehr muss PbD unter Berücksichtigung der Spezifika der jeweiligen Software individuell umgesetzt werden. Ein Softwareentwicklungsprozess, der dies sowohl in Bezug auf Privacy als auch in Bezug auf Security gewährleisten soll, wird im Folgenden vorgeschlagen. Dabei handelt es sich um einen iterativen, agilen Entwicklungsprozess, der auf dem Scrum-Framework basiert.

Scrum sieht keine standardisierte Methode vor, um Privacy- und Security-Anforderungen umzusetzen. Abbildung 1 zeigt unseren Prozess, der mittels Scrum definiert wurde, und in welchen Phasen welche Maßnahmen gesetzt werden, um diese Anforderungen dennoch zu berücksichtigen. Die Entwicklung erfolgt in einer Anzahl (je nach Bedarf) an Iterationen – auch als Sprints bezeichnet – mit der Dauer von 2-3 Wochen. Das Ergebnis eines jeden Sprints ist jeweils ein um Funktionalität erweitertes, lauffähiges und getestetes Produkt (oder Inkrement). Innerhalb eines Sprints werden die Scrum-typischen Phasen durchlaufen. Zusätzlich gibt es ein Backlog Refinement Meeting (oder auch als Backlog Grooming bezeichnet)¹³ vor dem ersten Sprint Planning und später jeweils optional während der Sprints. Zusätzlich gibt es dedizierte Privacy- und Security-Sprints, die sich besonders intensiv mit der Umsetzung von Privacy und Security beschäftigen. Diese können auch unter Zuhilfenahme spezieller Privacy- und Security-Teams erfolgen. Ein zentrales Security-Team sieht auch Kumar¹⁴ vor.

Mit dem in diesem Kapitel beschriebenen Prozess soll die Qualität der Software hinsichtlich Privacy und Security erhöht werden. Dies umfasst die Reduktion der Wahrscheinlichkeit einer Kompromittierung des Systems. Außerdem soll die ständige Begleitung durch Datenschutzexperten die Akzeptanz der Plattform erhöhen. Privacy- und Security-Anforderungen werden einfacher vergleich- und priorisierbar und dadurch immanent adressiert. Nicht zuletzt sollen einfach zu verstehende Maßnahmen Entwickler hinsichtlich Privacy und Security sensibilisieren und somit das Verständnis für diese Schwerpunkte nachhaltig erhöhen.

Sind Privacy- und Security-Anforderung funktional, so werden sie als Product Backlog Items (PBI) dem Product Backlog hinzugefügt. PBI werden von den Product Ownern (PO) gepflegt und während der Backlog Refinement- und Planning Meetings mit dem Team überarbeitet. PBI werden zum besseren Verständnis in natürlicher Sprache als User Stories¹⁵ mittels Satzschablone formuliert und lassen erkennen, welche Rolle, welches Ziel und welchen Nutzen der Benutzer am System hat, z.B. Als Bürger möchte ich mich mit Bürgerkarte anmelden, um zu verhindern, dass jemand anders an meiner Stelle abstimmt. Zu jeder User Story werden Akzeptanzkriterien definiert. Sofern möglich, werden diese gleich als Story Tests¹⁶ mittels Satzschablone strukturiert erfasst – z.B. Verifiziere, dass der Nutzer sich auf dem Portal mittels Bürgerkarte anmelden kann.

Privacy- und Security Anforderungen fallen oftmals in die Kategorie nicht-funktionale Anforderungen. In Fachkreisen werden drei Methoden diskutiert, wie diesen begegnet wird. Schließlich soll eine Kombination dieser Methoden angestrebt werden:

Story Tests sind der primäre Weg, um nicht-funktionale Anforderungen abzubilden und eignen sich vor allem, wenn diese nicht wiederkehrend sind – z.B. Verifiziere, dass der Benutzer nach fünf aufeinanderfolgenden fehlgeschlagenen Anmeldeversuchen gesperrt ist.

User Stories sind in erster Linie dazu gedacht, Anforderungen mit Geschäftswert abzubilden, können jedoch auch eingesetzt werden, um nicht-funktionale Anforderungen zu modellieren. Betrifft eine Anforderung nicht alle PBI, oder ist sie zu groß als dass sie als Story Test erfasst werden kann, wird eine technische User Story¹⁷ dafür geschrieben – z.B. Als IT-Security-Mitarbeiter möchte ich die Anzahl an nicht erfolgreichen Authentifizierungsversuchen beschränken, um Brute-Force-Attacken zu verhindern. Ein Vorteil dieser Methode ist, dass Security und Privacy für die PO explizit sichtbar, priorisierbar und vergleichbar gemacht wird. SAFECode¹⁸ beschreibt einen Katalog an generischen technischen User Stories, die helfen die Sicherheit des Systems zu erhöhen.

Die Definition of Done (DoD)¹⁹ ist eine Checkliste, die festlegt, welche Eigenschaften eine User Story erfüllen muss, um sie als abgeschlossen anzusehen. Sie wird vom Entwicklungsteam gemeinsam mit den PO erarbeitet und ist einem stetigen Änderungsprozess unterworfen. Hat die nicht-funktionale Anforderung globale Relevanz, kann sie in die DoD mitaufgenommen werden – z.B. Persönliche Daten eines Nutzers dürfen von anderen Benutzern nicht eingesehen werden. So wird gewährleistet, dass die Anforderung später nicht gebrochen wird.

OWASP beschreibt vier generelle User Stories, sogenannte Evil User Stories. Nutznießer ist nicht der Benutzer, sondern ein potentieller Angreifer. Evil User Stories richten den Fokus auf die Kompromittierung des Systems.²⁰ Analog dazu antizipieren Misuse oder Abuse Stories unerwünschtes Verhalten, das die Systemfunktionalität zu missbrauchen sucht. Der Grundgedanke ist, dass das Schreiben sicherer Software auch das Wissen um den Missbrauch der Systemfunktionalität voraussetzt.²¹ Beide Varianten werden in Zusammenarbeit mit Privacy- und Security-Experten definiert und unter dem Begriff Evil User Stories zusammengefasst. Sie bieten eine weitere Möglichkeit, Privacy und Security im Product Backlog explizit sichtbar zu machen.

Bei jedem Check-In prüft der Continuous-Integration-Server automatisch mittels statischer Code-Analyse-Tools Änderungen des Quellcodes auf Einhaltung der (Secure) Coding Guidelines und gibt den Entwicklern Rückmeldung über etwaige Verstöße. Dies kann beispielsweise auch beinhalten, dass vor dem Zugriff auf bestimmte Daten (z.B. personenbezogen Daten) diese stets entschlüsselt und nach Verwendung wieder verschlüsselt werden.

So weit als möglich werden auch Privacy- und Security-Tests durch den Einsatz entsprechender Scanner und Fuzzer automatisiert – z.B. Prüfen auf Anfälligkeit gegenüber Cross Site Scripting (XSS).

Vor Abschluss einer User Story werden alle damit verbundenen Änderungen am Quellcode einem kurzen Review unterzogen. Ziel ist es, den Code auf Verstöße gegen Security Best Practices zu prüfen (Buffer Overflows etc.). Andererseits liegt das Augenmerk auch auf dem Schutz der Privatsphäre und personenbezogener Daten. Die Prüfung muss sich nicht zwingend auf den Quellcode, sondern kann sich auch auf beliebige Artefakte beziehen. Ziel ist unter anderem, die Einhaltung der oben aufgezählten Privacy-Strategien zu gewährleisten. Reviews können mittels Review-Tools semi-automatisch erfolgen. Am Ende eines Sprints müssen alle bestehenden Änderungen am Code geprüft worden sein.

Scrum sieht vor, dass die Fähigkeiten innerhalb des Entwicklungsteams konvergieren. In der Praxis ist dies gerade auf den Gebieten Privacy und Security nicht möglich. Analyse, Planung und Umsetzung entsprechender Maßnahmen erfordern i.d.R. Spezialwissen, weshalb je ein Security- und ein Privacy-Team außerhalb des Entwicklungsteams dafür vorgesehen sind:

Beide Teams sind als zentrale Instanzen zu verstehen, die auch mehr als ein Scrum Team unterstützen können. Dies eignet sich vor allem bei Projekten mit verteilten Teams. In Security- und Privacy-Sprints werden Evil User Stories von diesen Teams übernommen. Wird die Velocity des Entwicklungsteams bestimmt, so muss der Anteil der extern vergebenen Tätigkeiten klar ersichtlich sein und herausgerechnet werden. Dies ist wichtig, um die Kapazität des Entwicklungsteams für künftige Sprint Plannings zu bestimmen.

Folgende neue Rollen ergeben sich dadurch:

• Security-Experten und Tester: Als Mitglieder des Security Teams leisten sie Hilfestellung oder übernehmen Aufgaben im Bereich Security (z.B. Risikoanalyse, Threat Modeling, Security Testing, Code Reviews mit Fokus auf Security und Secure Coding).
• Privacy-Experten: Als Mitglieder des Privacy Teams kümmern sie sich um die Themen Datenschutz, Datensicherheit und Privatsphäreschutz. Sie unterstützen das Entwicklungsteam im Bereich Privacy (z.B. Risikoanalyse, Threat Modeling, Privacy Testing, Privacy Reviews).

Die Teams werden durch einen Privacy Representative (PR) bzw. einen Security Representative (SR) vertreten. Sie haben eine ganzheitliche Sicht auf Entwicklung und Infrastruktur bezüglich Security, Risikomanagement bzw. Datenschutz, Datensicherheit und Privatsphäreschutz. Das qualifiziert sie als zusätzliche PO für das Entwicklungsteam, d.h. sie dürfen unter Absprache mit den anderen PO, für ihre Bereiche relevante PBI und/oder Akzeptanzkriterien definieren, erweitern und priorisieren. Es gibt jedoch weiterhin nur ein Product Backlog mit eindeutiger Priorisierung.

Darüber hinaus hat ein Representative folgende Aufgaben: Er vertritt sein Team in den Scrum Meetings, koordiniert die Mitglieder des jeweiligen Teams (während des Sprints werden Tasks zuerst dem SR zugewiesen, der die Tasks weiter an seine Teammitglieder verteilt), führt die sofortige Risikoanalyse und das Threat Modeling während des Backlog Refinement und Planning Meetings für kleine User Stories durch, fordert und plant periodische Sprints in seinem Bereich, berücksichtigt die Ergebnisse des Sprints des jeweiligen Bereichs im Product Backlog, priorisiert die User Stories in Absprache mit den anderen PO, verpflichtet sich zur Teilnahme an den Backlog Refinement-, Planning-, Review- und Retrospective Meetings und nimmt optional bei den Daily Scrums teil.

Der SR fordert die Implementierung von Security Best Practices und der Maßnahmen zur Gewährleistung der Sicherheit und fordert kritische Software/Framework-Updates. Ein PR hat zusätzlich die Gewährleistung der Compliance (Datenschutzrecht, ggf. Normen etc.) und die Umsetzung von PbD-Prinzipien und der Maßnahmen zu deren Gewährleistung zu verantworten.

Im Projekt ePartizipation wird der soeben beschriebene Prozess angewandt, allerdings in einer vereinfachten Form, da sowohl das Team als auch die zu entwickelnde Software verhältnismäßig klein sind. Die Entwicklung läuft erst seit wenigen Monaten, doch bisher erweist sich der Prozess als praxistauglich und gut umsetzbar. Privacy- und Security-relevante (technische) User Stories finden ihren Weg in das Product Backlog. Deren Aufwand wird gemeinsam im Sprint Planning mit klassischen User Stories in Story Points geschätzt. Dies erhöht objektiv automatisch die Vergleich- und Priorisierbarkeit bei gleichzeitiger zunehmender Sensibilisierung des Entwicklungsteams für Privacy und Security. Letzteres wird vor allem deutlich durch viele einschlägige Rückfragen des Entwicklungsteams an die Representatives während der Sprint Plannings und Backlog Refinement Meetings. Als Konsequenz zeigt sich, dass während der Daily Scrums die Anwesenheit der Representatives nicht immer erforderlich ist. Dies wird vor allem in regulären Sprints so gelebt. In Privacy- und Security Sprints ist eine ständige Koordination zwischen den Representatives bzw. den externen Teams und dem Entwicklungsteam durch die Daily Scrums weiterhin notwendig.

Obwohl die Existenz mehrerer PO als potenzielles Problem identifiziert wurde, zeigt sich kein Interessenkonflikt zwischen den Representatives, die formal die Rolle eines PO bekleiden, und dem traditionellen PO. Um Konflikte zu vermeiden, wäre es allerdings denkbar, die Representatives lediglich als Stakeholder mit besonderen Pflichten und nicht als PO einzustufen.

Die bisherigen Praxiserfahrungen mit dem beschriebenen Prozess sind somit äußerst positiv. Aufgrund der erst kurzzeitigen Anwendung des Prozesses in einem einzelnen Projekt, in dem überdies Entwickler tätig sind, die großes Interesse an den Themen Privacy und Security haben, können allerdings keine allgemeinen Aussagen über die generelle Umsetzbarkeit und Eignung des präsentierten Prozesses abgeleitet werden. Mit dieser Publikation sollen daher auch andere animiert werden, den Prozess oder Elemente davon in der Praxis einzusetzen, sodass einerseits den Konzepten Privacy und Security by Design Vorschub geleistet wird und andererseits weitere wertvolle Erfahrungen mit dem Einsatz des vorgestellten Prozessmodells gesammelt werden.

Das Projekt ePartizipation wird finanziert im Sicherheitsforschungs-Förderprogramm KIRAS vom Bundesministerium für Verkehr, Innovation und Technologie.