Heute, am 256. Tag des Jahres, ist der Tag des Programmierers. Dieser Tag kommt im Gegensatz zu anderen besonderen Feiertagen, wie zum Beispiel dem Tag des Systemadministrators, nicht aus den USA, sondern aus Russland und wurde im Jahr 2009 von der russischen Regierung sogar ganz offiziell per Dekret als beruflicher Gedenktag anerkannt. Ob Programmierer in Russland am heutigen Tag in Anlehnung an ihre US-amerikanischen Administratoren-Kollegen mit einem Stück Medovik geehrt werden, wissen wir leider nicht. Was wir aber sehr gut kennen, sind die Anforderungen, die Informationssicherheit und Datenschutz an die Software-Entwicklung stellen. Deren Wichtigkeit sowie die einzelnen Anforderungen fassen wir im Folgenden zusammen.
Was ist eigentlich Entwicklung?
Die Frage mag trivial erscheinen, führt aber in Fachkreisen unter anderem bei der Zertifizierung eines Informationssicherheits-Managementsystems (ISMS) nach ISO/IEC 27001 regelmäßig zu Diskussionen. Die Normen ISO/IEC 27000 und ISO/IEC 27001 schweigen sich zu einer konkreten Definition aus. Die Norm ISO/IEC 27002 gibt lediglich den Hinweis, dass Entwicklung nicht zwingend die Erstellung einer neuen Anwendung bedeuten muss, sondern bereits vorliegt, wenn in bestehenden Anwendungen zum Beispiel Skripte erstellt werden.
Am weitesten verbreitet ist die Auffassung, dass Entwicklung dann vorliegt, wenn entweder eine neue Anwendung erstellt wird oder einer bestehenden Anwendung wesentliche Funktionalitäten hinzugefügt werden, die vorher nicht vorhanden waren und von denen potenziell Risiken für die Verfügbarkeit, Integrität oder Vertraulichkeit von Informationen ausgehen können. Entwicklung umfasst nach dieser Auffassung also beispielsweise auch VBA-Skripte, welche in Office-Programmen umfangreiche erweiterte Funktionen bereitstellen. Sie umfasst jedoch nicht die bloße Änderung von Systemparametern innerhalb bestehender Funktionalitäten, wie zum Beispiel bei der Parametrierung von Fertigungstechnik.
Software als Qualitätsmerkmal von Produkten
Jeder ist im Alltag darauf angewiesen, dass Software die Verfügbarkeit, Integrität und Vertraulichkeit von Informationen sicherstellt, auch da, wo es zunächst nicht offensichtlich ist. Bei der Nutzung von Anwendungen wie Social Media, Messengern oder Office-Produkten ist der Bezug offensichtlich und auch das Bewusstsein für Informationssicherheitsaspekte mehr oder weniger vorhanden. Etwas anders sieht es schon bei IoT-Geräten (Internet of Things) aus. Dass das „smarte“ Türschloss nicht durch Unbefugte aus der Ferne entriegelt werden kann und Spielzeug keine Audiomitschnitte aus dem Kinderzimmer in eine chinesische Cloud überträgt, sehen die meisten Endverbraucher wohl – leider oft viel zu sorglos – als gegeben an. Aber Hand aufs Herz: Wer hat beim Aufdrehen des Wasserhahns schon einmal darüber nachgedacht, dass das Wasser ohne sichere Software vielleicht nicht bedenkenlos trinkbar wäre?
Informationssicherheit und Datenschutz bewegen sich bei der Software-Entwicklung im Spannungsfeld mit hohem Innovationsdruck und Kosteneffizienz. Gleichzeitig differenzieren sich mittlerweile auch bislang rein analoge Produkte gegenüber dem Kunden vor allem durch Software-Features. Somit verwundert es nicht, dass Entwickler die gefragtesten aller IT-Fachkräfte am Arbeitsmarkt sind – laut einer Studie des Bitkom e.V. sogar noch mehr als die ebenfalls händeringend gesuchten Systemadministratoren.
Personalsicherheit bei Entwicklern
Neben der Sicherstellung einer geeigneten fachlichen Qualifikation kann es je nach Kritikalität der Anwendungen, für deren Entwicklung eine Stelle zu besetzen ist, angemessen sein, Bewerber einer Sicherheitsüberprüfung zu unterziehen. Hierbei setzt jedoch die DSGVO enge Leitplanken, welche unbedingt beachtet werden müssen und die wir bereits in unserem Blogartikel „Informationssicherheits-Anforderungen an Systemadministratoren“ Systemadministrators beschrieben haben. Sofern eine Sicherheitsüberprüfung nicht branchenspezifisch gesetzlich oder regulatorisch vorgegeben ist, dürfte diese in der Praxis wohl auch durch die knappe Verfügbarkeit von Entwicklern eingeschränkt sein.
Der von Entwicklern erstellte Code ist geistiges Eigentum. Es kann empfehlenswert sein, unter Hinzuziehung fachanwaltlicher Beratung den Umgang mit diesem Eigentum bereits im Arbeitsvertrag klar zu regeln, wie zum Beispiel die zu nutzenden Repositorien und die Sicherstellung der Verfügbarkeit bei Beendigung des Arbeitsverhältnisses.
Entwicklungs-, Test- und Produktivumgebungen
Die in den verschiedenen Lebenszyklusphasen der Software genutzten Umgebungen müssen logisch wirksam voneinander getrennt sein. Eine wirksame Trennung schließt nicht nur ein, dass die Zugangsberechtigungen auf die Umgebungen technisch getrennt verwaltbar sind, sondern dass diese auch tatsächlich nach dem Least-Privilege-Prinzip gesteuert werden. Insbesondere Entwicklungsumgebungen bieten Angreifern – internen wie externen – im Vergleich zu Produktivumgebungen ein deutlich höheres Potential zum Ausspähen, Entwenden, Manipulieren oder auch Unbrauchbarmachen von Code.
Die Zugangsberechtigungen sollten daher so weit wie möglich eingeschränkt und eine starke Authentifizierung in Kraft sein. Ähnlich wie für Administrator-Accounts kann daher in Erwägung gezogen werden, hinsichtlich der zu nutzenden Authentifizierungsfaktoren zugunsten der Sicherheit Abstriche bei der Skalierbarkeit in Kauf zu nehmen. Die gängigen Repository-Plattformen ermöglichen zum Beispiel eine starke und je nach Plattform auch passwortlose Mehrfaktor-Authentifizierung.
Software-Tests mit personenbezogenen Daten
Software-Tests mit personenbezogenen Daten sind eine Gratwanderung. Zum einen sind sie oft unumgänglich, um aussagekräftige Testergebnisse für eine funktionsfähige Produktiv-Version der Anwendung zu erhalten. Zum anderen lauern hier sehr viele Fallstricke, deren Nichtbeachtung erhebliche Compliance-Risiken generieren.
Zum Grundverständnis: bei der Verarbeitung personenbezogener Daten in Produktivsystemen und in Testsystemen handelt es sich jeweils um separate Verarbeitungstätigkeiten, da jeweils ein anderer Zweck zugrunde liegt. Werden personenbezogene Daten, die für die produktive Nutzung in der gleichen oder sogar einer gänzlich anderen Anwendung erhoben wurden, einfach ohne weitere Prüfungen für Testzwecke genutzt, ist dies ein eindeutiger Verstoß gegen den Grundsatz der Zweckbindung nach Art. 5 Abs. 1 lit. b DSGVO und damit unzulässig.
Unproblematisch wäre die Verwendung anonymisierter personenbezogener Daten. Die Anforderungen an eine hinreichende Anonymisierung werden jedoch regelmäßig unterschätzt.
Nach Möglichkeit sollten daher fiktive Daten verwendet werden. Sowohl für die Anonymisierung echter personenbezogener Daten als auch für die Generierung von Testdaten sind leistungsstarke Tools am Markt vorhanden. Dennoch ist es nach wie vor oft notwendig, echte, nicht anonymisierte personenbezogene Daten für Testzwecke zu verwenden, da eben nur diese genau jene „Spezialfälle“ enthalten, die später bei der produktiven Anwendung zu Fehlern führen würden.
Dabei ist genau zu begründen, warum das Testziel nur mit der gewählten Art und Umfang personenbezogener Daten erreicht werden kann. Auch muss nachgewiesen werden, wie nach Art. 32 DSGVO in der Testumgebung die Sicherheit der Verarbeitung risikobasiert gewährleistet wird. Zudem muss sichergestellt sein, dass die betroffene Person ihre Rechte auch für die Testdaten wirksam ausüben kann. Um die genannten Aspekte darzustellen, eignet sich regelmäßig eine Datenschutzfolgenabschätzung nach Art. 35 DSGVO.
Anspruchsvoll ist in der Praxis auch eine präzise und transparente Information der betroffenen Person nach Art. 13. Abs. 3 DSGVO bzw. Art. 14 Abs. 4 DSGVO. Diese ist erst möglich, sobald das Testszenario konkret beschrieben werden kann. Eine „präventive“ Information für mögliche künftige Tests scheidet damit aus. Die betroffenen Personen – und zwar nur diese – müssen also präzise und transparent informiert werden, sobald deren personenbezogene Daten für Testzwecke genutzt werden. Dies setzt ein sehr gut funktionierendes Datenschutz-Managementsystem voraus.
Nach Testende fällt der Verarbeitungszweck weg und die Daten sind daher unverzüglich zu löschen. Auch hierfür stehen Tools zur Verfügung, welche automatisiert die Wiederherstellbarkeit des Personenbezuges faktisch unmöglich machen und zur Einhaltung von Nachweispflichten entsprechende Löschprotokolle generieren.
Privacy by Design & Default
Nach Art. 25 DSGVO muss eine Anwendung technisch von vorherein so gestaltet werden, dass insbesondere die Grundsätze aus Art. 5 DSGVO eingehalten werden. Dabei wird oft nur berücksichtigt, dass die Anwendung möglichst wenige personenbezogene Daten verarbeitet, was jedoch zu kurz greift. Wird Privacy by Design ganzheitlich umgesetzt, werden auch die anderen Grundsätze und die Anforderungen der DSGVO zu berücksichtigen sein. Dies ermöglicht dem Anwender wiederum ein effizientes Datenschutzmanagement, zum Beispiel mittels Automatisierung von Funktionen zur Umsetzung von Betroffenenrechten oder Löschprozessen zur Speicherbegrenzung. Dies reduziert nicht nur Datenschutzrisiken, sondern kann das Datenschutzmanagement auch erheblich kostengünstiger gestalten. Gute Gründe, den Datenschutzbeauftragten bei Eigenentwicklung oder Beschaffung von Software von vornherein einzubeziehen. Glücklicherweise erkennen insbesondere Software-Anbieter aus dem europäischen Raum in jüngster Zeit ein hohes Datenschutzniveau als Differenzierungsmerkmal gegenüber dem Wettbewerb.
Sicherheit im Entwicklungsprozess
Das alte Paradigma, dass der Informationssicherheitsbeauftragte eines Unternehmens als Stakeholder in die Steuerung von Entwicklungsprojekte einbezogen werden sollte, ist angesichts kürzer werdender Release-Zyklen, der Vielzahl gleichzeitig stattfindender Entwicklungsprojekte und der für die Beurteilung der Code-Sicherheit erforderlichen, tiefgehenden Fachkenntnis schon längst überholt.
Zeitgemäße DevSecOps-Ansätze integrieren das Code-Security-Knowhow direkt in die DevOps-Teams, um Code-Sicherheit mit kurzen Release-Zyklen zu vereinbaren. Angesichts knapper Entwicklerressourcen sind automatisierte Sicherheitstest unerlässlich dafür, diesen Ansatz zu skalieren. Automatisierung ist dabei Entlastung und nicht als Ersatz für qualifiziertes Fachpersonal.
Der sichere Entwicklungsprozess hat Schnittstellen zu zahlreichen anderen Informationssicherheitsaspekten. Dies ist unter anderem das Berechtigungsmanagement in Verbindung mit einer angemessenen Aufgabentrennung. Die Berechtigungen für Code-Freigabe sollten so vergeben werden, dass vor der Freigabe ein objektiver Test stattfinden kann. Peer Checks können ein Mittel sein, diesen Ansatz mit begrenzten personellen Ressourcen umzusetzen, weichen jedoch gleichzeitig den Ansatz des agilen Projektmanagements auf, nach dem ein Entwicklungsteam ohne Beteiligung weiterer Teams Produktinkremente liefern soll. Um die Integrität des freizugebenden Codes sicherzustellen, muss ein sicheres Schlüsselmanagement für die beim Code Signing genutzten kryptographischen Schlüssel sichergestellt werden.
Ausgelagerte Entwicklung
Wenn Entwicklungstätigkeiten an externe Dienstleister ausgelagert werden, sollten folgende Punkte beachtet werden, um die damit verbundenen Risiken zu beherrschen.
Im Dienstleistervertrag klar geregelt werden sollten die geistigen Eigentumsrechte am Programmcode sowohl während der Entwicklung als auch nach Produktivsetzung. Betrachtet werden sollte auch das Verfügbarkeitsrisiko für den Fall, dass der Entwicklungsdienstleister irgendwann nicht mehr existent sein sollte, Quellcode jedoch noch für Weiterentwicklungen benötigt wird. Hierfür kann es sich anbieten, vertraglich die Hinterlegung bei einer unabhängigen dritten Partei zu vereinbaren.
Definiert werden sollten auch die Meilensteine und zugehörige Abnahmekriterien. Bei Anwendung klassischer Projektmanagement-Methoden anhand des Wasserfall-Modells ist dies noch vergleichsweise simpel in Form eines Lastenhefts mit klar definierten, einzelnen Anforderungen zu regeln. Bei der Software-Entwicklung finden jedoch oft agile Frameworks Anwendung, in denen sich die einzelnen Anforderungen an das Produkt während des Entwicklungsprozesses ändern können. Am Beispiel der Nutzung von Scrum als Projektmanagement-Framework sollten etwa zumindest das Produktziel und die Definition of Done vertraglich so klar wie möglich geregelt werden.
Das eigene Unternehmen ist bei ausgelagerten Tätigkeiten weiterhin für eine wirksame Umsetzung von Informationssicherheitsmaßnahmen verantwortlich. Zum einen sollten daher bereits frühzeitig im Auswahlprozess die durch den Dienstleister getroffenen Informationssicherheitsmaßnahmen detailliert abgefragt werden. Eine sehr gute Orientierung hierfür bietet der IT-Grundschutz-Baustein CON.8: Software-Entwicklung des BSI. Zum anderen sollte je nach Vertragsmacht ein Auditrecht des eigenen Unternehmens zur Wirksamkeitskontrolle der Sicherheitsmaßnahmen vereinbart werden.
Wenn im Rahmen der Entwicklungstätigkeit durch den Dienstleister personenbezogene Daten, zum Beispiel zu den oben genannten Testzwecken, verarbeitet werden, handelt es sich regelmäßig um eine Auftragsverarbeitung nach Art. 28 DGVO, welche mit einem Auftragsverarbeitungsvertrag zu regeln ist.
Fazit
Eine schnelle und trotzdem sichere Software-Entwicklung ist mittlerweile für viele Firmen ein entscheidendes Erfolgskriterium, für die das Thema bislang nicht auf der Tagesordnung stand. Informationssicherheit und Datenschutz können dabei insbesondere für europäische Anbieter als Differenzierungsmerkmal relevant sein. Es kann sich daher lohnen, diesen Beitrag als Ausgangsquelle für weitere Recherchen zu nutzen.
Zum Autor
Benjamin Günther ist Berater für Managementsysteme. Bei der migosens GmbH liegt sein Schwerpunkt auf der Implementierung von Managementsystemen, vorrangig von Informationssicherheitsmanagementsystemen nach ISO27001. Darüber hinaus verfügt er über langjährige Berufserfahrung im Qualitätsmanagement und ist Qualitätsmanagementbeauftragter für die Norm ISO 9001.
