Risikobewertung für IT-Projekte: Vorlage und Tipps für die Zusammenarbeit mit Entwicklungsteams

Damit Ihre Anforderungen an Sicherheitsmaßnahmen und Data Compliance bereits zu Beginn von IT-Projekten von den Entwicklungsteams berücksichtigt werden, benötigen Sie eine Risikobewertung, die sprachlich zur IT passt. In diesem Beitrag teile ich mit Ihnen eine Vorlage, die von IT-Leitern oder Projektverantwortlichen auszufüllen ist und die als Grundlage für die gemeinsame Risikoanalyse dient.

Außerdem gebe ich Ihnen praktische Tipps, wie Sie das Entwicklungsteam stärker für Sicherheit sensibilisieren, sodass es schon ab dem Kick-off-Meeting die Anforderungen des Informationssicherheitsbeauftragten und des Datenschutzbeauftragten berücksichtigt. Viele Entwickler haben ein anderes Sicherheitsverständnis und schätzen sichere Prozesse aus meiner Erfahrung oft zu wenig.

Beispiel eines Formulares für die Risikobewertung von IT-Projekte

Wenn Sie einen Prozess für neue Systeme und Weiterentwicklungen etablieren, wird sich die IT-Abteilung daran gewöhnen, Sicherheitsanforderungen bereits bei Kick-Off eines Projekts zu berücksichtigen. Hier finden Sie die Kernfragen, die einer meiner Kunden seinen Entwicklungsteams stellt. Sie müssen sie an die Geschäftsprozesse und die gesetzlichen Anforderungen Ihrer Branche anpassen. Nach der Verwendung bei den ersten beiden Projekten hat sich eine sicherheitsbewusstere Kultur bei dem IT-Leiter und den Teamleitern etabliert.

Der erste Teil befasst sich mit Schutzmaßnahmen und Arten von Daten, da diese Aspekte für Entwickler leicht verständlich sind. Er gibt Ihnen einen klaren Überblick über das Ziel, die verwendeten sensiblen Daten und die Architektur des IT-Projekts. Damit sind Sie auf die Risikobewertung gut vorbereitet. Um eine detaillierte Risikobewertung zu erstellen, die nicht nur den Auditor zufriedenstellt, sondern auch die Systeme und Geschäftsprozesse schützt, sollten Sie gemeinsam mit dem Projektverantwortlichen sitzen und ihn anleiten, damit wichtige Bedrohungen nicht übersehen werden.

Hier können Sie die Vorlage herunterladen

Angaben zum Projekt

• Identifikationsnummer:
• Bezeichnung:
• Auftraggeber:
• Product Owner/Projektleiter:

Beschreibung der Architektur

• Ziel des Systems: kurze Beschreibung des neuen bzw. geänderten Geschäftsprozesses
• Diagramm der Server auf der Produktion (normalerweise in DMZ) und Verbindungen zu Datenbanken, E-Mail-Servern und anderen internen und externen Diensten
• Code und Funktion der beteiligten Systeme und Microservices: Beispiele sind Backend, Frontend, Load Balancer, Zahlungsanbieter und Apache Servers

Schutzmaßnahmen

• Wie wurden diese Systeme abgesichert/geschützt? Hier werden die Nutzung einer Firewall zwischen den Servern, regelmäßige Backups und Berechtigungen für den Zugang zu Backoffice-Funktionen erläutert. Es können die unterschiedlichen Benutzergruppen aufgelistet werden.
• Welche Netzwerkprotokolle werden verwendet? Hier wird beschrieben, wo HTTPS, SSH, HTTP und andere Protokolle zum Einsatz kommen.
• Welche Authentifizierungsmethoden finden Anwendung? Hier wird die Nutzung von Two-Factor-Authentifizierung, lokalen Benutzern und Passwörtern sowie Benutzern auf dem Active Directory beschrieben. Auch die Nutzung von SSH-Zertifikaten kann benannt werden.
• Wie erfolgt die Benutzerverwaltung und wer ist dafür zuständig?
• Welche Berechtigungsgruppen werden zu welchem Zweck eingerichtet?
• Welche Datenübertragungen und -übernahmen (Schnittstellen) finden Anwendung und welche Sicherheitsmaßnahmen werden implementiert? Anhand des Architektur-Diagramms werden alle Verbindungen zwischen den Maschinen inklusive der Browser der Kunden und der internen und externen Mitarbeiter aufgelistet. Bei E-Mails muss geklärt werden, ob personenbezogene Informationen das Rechenzentrum des Unternehmens verlassen, da E-Mails von Dritten gelesen werden können.
• Werden präventive Sicherheitsmaßnahmen, z. B. Backups und Notfallmaßnahmen, ergriffen? Hier werden Backups (Periodizität und enthaltene Daten), Zugangsbeschränkungen und Verantwortliche für die Wiederherstellung des Systems beschrieben.
• Wer ist verantwortlich für das regelmäßige Testen der Wiederherstellung des Systems aus dem Backup?
• Wie oft wird das Testing der Wiederherstellung des Systems aus dem Backup durchgeführt?
• Sind Änderungen (Daten, Konfiguration etc.) nachvollziehbar dokumentiert? Hier geht es um die Nutzung von Repositories für die Konfiguration und das Auditing bei Änderungen von Benutzern, Passwörtern und Berechtigungen. Aber auch die Konfigurationswerte der Datenbanken.
• Werden Kontrollen/Stichprobenprüfungen durchgeführt und wenn ja, wo, wann und von wem? Hier wird beschreiben, wer prüft, dass die Berechtigungen zu den Aufgaben der Mitarbeiter abgepasst wurden, dass die Sicherheitsmaßnahmen im System umgesetzt wurden und dass die Backups gemacht wurden.
• Gibt es kompensierende Kontrollhandlungen, die eine Risikoerkennung frühzeitig ermöglichen? Hier werden Monitoring-Tools, der Umfang der Protokolle und deren Speicherort beschrieben.
• Anlagen wie Netzwerkplan und Berechtigungskonzept

Klassifizierung der Daten

• Welche Arten von Daten werden verarbeitet? Hier werden im Allgemeinen nicht personenbezogene Daten beschrieben, während alle Felder mit persönlichen Daten aufgelistet werden.

• Wie kritisch sind die Daten für andere Geschäftsprozesse der Firma?

• Wie kritisch ist es aus Sicht des Kunden, wenn Daten unbeabsichtigt öffentlich gemacht werden, entwendet, geändert oder gelöscht werden?

• Werden die personenbezogenen Daten in anderen Systemen gespeichert?

• Kann die Funktion des Systems ohne die Verarbeitung personenbezogener Daten erfüllt werden? Durch den Einsatz verteilter Systeme oder Entwürfe für datenarme Systeme lassen sich IT-Anwendungen ohne sensible Daten entwickeln. Wie das funktioniert, beschreibe ich später in diesem Beitrag.

• Folgende Datenarten werden erhoben und verarbeitet:

  • Personenbezogene Daten (Kunden-/Mitarbeiterdaten)
  • Geschäftliche, sensible Informationen
  • Öffentliche Daten

Zugriffe zu den Systemen

Standorte der IT-Systeme

• DMZ: Geschütztes Netzwerk mit Zugriff aus dem LAN u. aus Internet
• Internes Netzwerk
• Extern gehostete Systeme: Beschreibung des Data-Centers oder public Cloud

Detaillierte Risikobewertung

Bemerkung: In der Regel wird dieser Teil von IT-Mitarbeitern nur oberflächlich ausgefüllt. Deshalb müssen Sie die Risiken zusammen mit dem technischen Projektleiter noch einmal analysieren und ggf. weitere Schutzmaßnahmen anfordern.

_Diese Risiken müssen sowohl mit dem Auftraggeber als auch mit dem Datenschutzbeauftragter und Informationssicherheitsbeauftragter abgestimmt werden. Und diese Maßnahmen müssen im Projektplan berücksichtigt werden. Idealerweise ist, wenn das Entwicklungsteam Ihnen Nachweise der Umsetzung gibt. Aber in der Regel reicht es schon, das Team sich der Risiken bewusst zu machen.

Kommentare zur Freigabe

Das Projekt wurde vorab geprüft und wird vorbehaltlich, unter Realisierung der umzusetzenden Maßnahmen,

• freigegeben
• nicht freigegeben

Erfolgen nach dem Zeitpunkt der Risikobewertung nachträglich technische Änderungen, ist die Risikobewertung erneut durchzuführen.

Unterschriften

Es bringt nichts, von Bußgeldern zu reden

Besser ist es, sich auf sicherheitsrelevante Situationen zu fokussieren, die dem Alltag eines Produkt-Owners, eines IT-Leiters oder eines Team-Leads nahekommen. Im Falle eines Datenleaks von Kunden-, Mitarbeiter-, Lieferanten- oder anderen personenbezogenen Daten drohen der Firma Bußgelder von bis zu 4 % des gesamten weltweit erzielten Jahresumsatzes. Diese Bedrohung ist jedoch zu abstrakt und ihre Eintrittswahrscheinlichkeit im Vergleich zu einem Ausfall oder einer nicht vorsätzlichen Korruption von Daten in der Produktion zu gering.

Entwickler kennen sich mit Sicherheitstechniken aus, jedoch nicht mit sicheren Prozessen

Wenn man mit dem Entwicklungsteam redet, muss man eine sprachliche Brücke zwischen der IT-Sicherheit, mit der es vertraut ist, und den Sicherheitsanforderungen der Organisation schlagen. Verschlüsselungsverfahren, Techniken, um Ausfälle zu vermeiden, Authentifizierung- und Autorisierungsmethoden, Audit-Tools und Netzwerksmonitoring sind erfahrenen Entwicklern bekannt. Risikoanalysen, die Schätzung von Verlusten aufgrund von Sicherheitsvorfällen und Prozesse, um gesetzliche Anforderungen zu erfüllen, werden jedoch selten erlernt. Auch der Umgang mit Geheimnissen wie Passwörtern und privaten Schlüsseln erfolgt nicht in einem sicheren Prozess.

Deswegen muss man sich im Kick-off-Meeting oder in der Vorlage auf Schutzmaßnahmen, Architektur und sensible Daten der Systeme fokussieren. Es ist gut, zu nennen, wie viel Stress das Team bei einem Ausfall in der Produktion hat und welchen Aufwand das Team hat, wenn ein Ransomware-Angriff passiert und alle Server neu eingerichtet werden müssen. Diese Themen führen zu mehr Bewusstsein für sicherheitsrelevante Themen und wirken sich dauerhaft und nachhaltig auf den Deployment- und Entwicklungsprozess aus.

Später können Sie auf Basis all dieser Informationen eine detaillierte Risikobewertung des Projekts durchführen.

Moderne IT-Architekturen können die Kosten für Sicherheitsmaßnahmen deutlich senken

Man muss nach datenarmen Systemen fragen, die keine personenbezogenen Daten enthalten, oder die Verlagerung kritischer Features auf ein anderes System in Betracht ziehen, damit IT-Architekten andere Designkonzepte betrachten. Hier ist es wichtig, dem IT-Architekten zu vermitteln, dass weniger sensible Daten einen geringeren Aufwand auf der Seite der IT-Sicherheit bedeuten. Dies führt zu geringeren Kosten für das Unternehmen.

Seit 2011 bietet die Mikroservice-Architektur ein neues Design-Paradigm für Anwendungen an, mit dem sich verteilte Systeme bauen lassen. Wenn nur einige Teile personenbezogene Daten oder geschäftskritische Funktionen enthalten, kann sich das IT-Team auf diese Teile konzentrieren und entsprechende Sicherheitsmaßnahmen und Prozesse umsetzen. Das vereinfacht beispielsweise den Schutz vor Datenlecks, die Korruption von Daten aufgrund von Bugs oder die Vermeidung von Ausfällen.

Bei vielen IT-Architekten ist jedoch noch das Konzept der Monolithen verbreitet, bei denen alle Funktionen und Daten in einer einzigen Anwendung liegen. Nach einigen Monaten werden die kleinen Teile riesig und Daten werden von einem Microservice zu anderen kopiert. Außerdem unterstützen gängige Frameworks für das Frontend von Systemen diese neue Architektur noch nicht. Trotzdem haben wir ein neues System für den Verkauf von Derivaten auf Erdölbasis entworfen und erfolgreich umgesetzt, das keine personenbezogenen Daten benötigt. Dies führte zu geringen Entwicklungskosten. In einem anderen Projekt haben wir gemeinsam mit der Rechtsabteilung eines Händlers festgestellt, dass das neue System die Anforderungen des Lieferkettengesetzes erfüllt, ohne dass personenbezogene Daten der Lieferanten erforderlich sind.

Stellen Sie technische Fragen

Eines Tages saßen wir mit einem Kollegen beim Mittagessen und waren begeistert, als uns der Informationssicherheitsbeauftragte eines deutschen Konzerns, Michael, fragte, warum wir noch ein Frontend-Framework, JQuery, verwendeten. Es gibt Plug-ins, die selten aktualisiert werden und seiner Meinung nach zu Sicherheitsvorfällen führen können. Er hatte recht und gleichzeitig wollte er hören, was ich als Architekt und mein Kollege als Teamleiter zu sagen hatten. Aufgrund von Michaels Interesse an unserer Arbeit waren wir motiviert, alle seine Anforderungen mit der gleichen Priorität wie die anderer Stakeholder zu berücksichtigen.

Wenn Sie keine technische Erfahrung haben, ist es schwierig, sich in IT-Themen einzuarbeiten. Alternativ können Sie mit einem erfahrenen Team-Lead oder Entwickler zusammenarbeiten, der nicht nur sicherheitsbewusst ist, sondern auch einen guten Ruf als hilfsbereiter Techniker hat. So können Sie die Compliance- und Sicherheitsanforderungen bei neuen Projekten durchsetzen. Sie führen die Risikoanalyse durch und berechnen die möglichen Verluste, während er Ihnen bei der Umsetzung der Maßnahmen hilft. Als ich mit Michael zusammengearbeitet habe, hat er mich zu jedem Kick-off-Meeting geschickt, damit ich als Vermittler zwischen ihm und dem IT-Team fungierte. Das war für alle Seiten gut, weil alle Sichtweisen integriert wurden.

Ihre Erfahrung

Wie gehen Sie vor, wenn Sie mit der IT-Abteilung über die Anforderungen neuer Projekte verhandeln müssen? Haben Sie ähnliche Erfahrungen mit Architekten, Projekt-Owner, IT-Leitern und Entwicklern gemacht? Wenn Sie nützliche Tipps haben, können Sie gern hier einen Kommentar schreiben.