Im Lieferantenfragebogen steht eine Zeile: „Zertifikat nach ISO 27001: ja / nein“. Unsere Antwort lautet nein. Conimex IT besteht aus 5 Personen in Belgrad, und wir waren nie nach ISO 27001 zertifiziert, der internationalen Norm für das Management der Informationssicherheit. Was wir Ihnen bieten, ist eine kurze Liste von Gewohnheiten, die Sie einzeln nachprüfen können. Code und Server laufen auf Ihren Namen. Jede Person hat ein eigenes Konto. Echte Daten landen nie auf einem Testserver. Backups entstehen täglich, und wir spielen sie gezielt zurück. Und wenn wir ein Problem finden, hören Sie von mir, bevor die Behebung beginnt.
Dieser Beitrag geht jede Gewohnheit einzeln durch, zeigt, wo ein Zertifikat uns schlägt, und endet mit Fragen, die Sie jedem kleinen Dienstleister stellen können. Auch uns.
Warum kleine Softwaredienstleister selten ein Zertifikat nach ISO 27001 haben
Der einfachste Grund zuerst: Unsere Kunden haben nie danach gefragt. Das Zertifikat taucht im Einkauf auf, in formalen Ausschreibungen und Lieferantenformularen, und zwar meist, bevor sich irgendjemand ansieht, wie ein Dienstleister tatsächlich arbeitet.
Die Zertifizierung selbst ist kein Formular, das man an einem Nachmittag ausfüllt. Man baut ein Managementsystem auf, dokumentiert es und durchläuft dann ein Audit in zwei Stufen. Für ein kleines Unternehmen dauert das etwa 6 Monate. Danach folgt jedes Jahr ein Überwachungsaudit und alle 3 Jahre die Rezertifizierung. Bezahlt wird das bei einem Team unserer Größe vor allem mit der Zeit des Gründers. Bisher hat kein Kunde das von uns verlangt.
Die aktuelle Fassung ist ISO/IEC 27001:2022. Ihr Anhang A enthält 93 Maßnahmen in 4 Gruppen: organisatorische, personenbezogene, physische und technologische. Eine Ausgabe 2026 gibt es nicht. In diesem Jahr geändert hat sich eine andere Norm, ISO 9001:2026 für Qualitätsmanagement. Was dort neu ist, haben wir in unserem Beitrag zu den Änderungen in ISO 9001:2026 zusammengefasst.
Was NIS2 von Ihnen als Auftraggeber wirklich verlangt
NIS2 ist die Richtlinie der EU zur Cybersicherheit für wesentliche und wichtige Einrichtungen. Artikel 21 zählt die Maßnahmen auf, die diese Einrichtungen treffen müssen. Eine davon ist die Sicherheit der Lieferkette, also die Sicherheit der Beziehungen zu den unmittelbaren Anbietern und Diensteanbietern.
Spannend wird es in Absatz 3. Dort steht, dass die Einrichtungen „die spezifischen Schwachstellen der einzelnen unmittelbaren Anbieter und Diensteanbieter sowie die Gesamtqualität der Produkte und der Cybersicherheitspraxis ihrer Anbieter und Diensteanbieter, einschließlich der Sicherheit ihrer Entwicklungsprozesse, berücksichtigen“.
ISO 27001 kommt in diesem Text nicht vor. Die Richtlinie verlangt, dass Sie sich ansehen, was Ihr Dienstleister tut. Ein Zertifikat ist ein Weg, das zu belegen. Eine nachprüfbare Beschreibung der gelebten Praxis ist ein anderer.
Wie wir arbeiten und wie Sie es prüfen
Code, Server und Konten laufen auf Ihren Namen
Am liebsten liegt bei uns alles auf Kundenseite: das Repository mit dem Code, das Hostingkonto, die Domain und die Konten in den App Stores. Endet die Zusammenarbeit, ändern Sie die Zugänge. Herausgeben müssen wir nichts, weil nichts bei uns liegt.
Manche Kunden haben dafür noch keine technische Struktur. Dann führen wir die Konten über unser Firmenkonto, bis der Kunde bereit ist, sie zu übernehmen.
So prüfen Sie es: Fragen Sie bei jedem Konto, wem es gehört. Und fragen Sie sich, ob Sie den Dienstleister morgen aussperren könnten, ohne ihn vorher zu fragen.
Jede Person hat ein eigenes Konto
Bei uns teilt niemand einen Login für Code oder Server. Die meisten Konten verlangen 2FA, also zusätzlich zum Passwort einen Code vom Smartphone. Ein gestohlenes Passwort allein reicht dann nicht aus. Passwörter und Zugangsschlüssel liegen in der App Passwörter von Apple, nicht in Chatnachrichten.
So prüfen Sie es: Lassen Sie sich die Benutzerliste im Repository und beim Hosting zeigen. Pro Person sollte dort ein Name stehen, und es darf kein gemeinsames Konto namens „dev“ geben.
Echte Daten bleiben im Produktivsystem
Testumgebungen arbeiten bei uns immer mit erfundenen Daten. Echte Kundendatensätze werden nie auf den Laptop eines Entwicklers oder auf einen Testserver kopiert. Die Festplatten unserer Arbeitsrechner sind verschlüsselt, und jede Person im Team sowie jeder externe Mitarbeiter unterschreibt eine Vertraulichkeitsvereinbarung.
So prüfen Sie es: Fragen Sie, woher die Daten auf dem Testserver stammen. Eine schlechte Antwort lautet: „Wir haben die Produktivdatenbank kopiert und ein paar Namen geändert.“
Tägliche Backups, gezielt zurückgespielt
Die Datenbank wird einmal am Tag gesichert. Bei mehreren Projekten, nicht bei allen, spielen wir einmal im Monat absichtlich ein Backup zurück, um zu sehen, ob die Wiederherstellung wirklich funktioniert. Ein Backup, das nie zurückgespielt wurde, ist für mich eine Hoffnung. Ein Backup ist es noch nicht.
So prüfen Sie es: Fragen Sie, wann der Dienstleister zuletzt ein Backup wiederhergestellt hat und wie lange das gedauert hat.
Ein zweiter Entwickler liest jede Änderung
Unser Ziel ist ein unabhängiges Code Review für jede Änderung. Es soll kein Code ins Projekt gelangen, den nur sein Autor gesehen hat. Wie wir Code Reviews organisieren, beschreiben wir in einem eigenen Beitrag. Ein typischer Fund ist eine fehlende Berechtigungsprüfung, also eine Stelle, an der niemand kontrolliert, ob der Nutzer diese Aktion überhaupt ausführen darf.
Wir geben uns große Mühe, Entwickler nicht ständig in Projekte hinein und wieder heraus zu tauschen. Warum uns das so wichtig ist, steht in unserem Beitrag darüber, was passiert, wenn ein Entwickler ausfällt.
So prüfen Sie es: Lassen Sie sich eine bereits übernommene Änderung zeigen, zusammen mit den Kommentaren aus dem Review.
Bei einem Problem hören Sie zuerst von uns
Wenn wir ein Sicherheitsproblem finden, sage ich es dem Kunden selbst und sofort. Erst danach beginnen wir mit der Behebung. Nicht nach dem Patch und nicht im Monatsbericht. Sie können über Ihr eigenes Risiko nicht entscheiden, wenn Ihr Dienstleister still für Sie entscheidet.
Die EU hat denselben Instinkt für Hersteller von Produkten ins Gesetz geschrieben. Nach dem Cyber Resilience Act und seiner Meldepflicht geht bei einer aktiv ausgenutzten Schwachstelle innerhalb von 24 Stunden eine Frühwarnung an die Behörden.
So prüfen Sie es: Fragen Sie nach dem letzten Sicherheitsproblem, das der Dienstleister gefunden hat, und wann der Kunde davon erfahren hat. Lautet die Antwort „Wir hatten noch nie eins“, fragen Sie weiter.
Die ungeschützten Adminrouten im Code eines anderen Teams
Vor einiger Zeit haben wir eine Anwendung übernommen, die ein anderes Team gebaut hatte und die bereits im Betrieb war. Dabei fanden wir Adminrouten, also die Adressen hinter dem Adminbereich, ganz ohne Schutz. Wer die Adresse kannte oder erriet, kam hinein. Das öffnete die Tür zu Datendiebstahl und echtem finanziellem Schaden. Gestohlen wurde zum Glück nichts.
Mit der Behebung haben wir in dem Moment begonnen, in dem wir die Lücke gesehen haben. Die Routen zu schließen war der einfache Teil. Wichtiger war etwas anderes: Wir haben die automatisierten Tests so geändert, dass sie genau diesen Fall prüfen. Eine ungeschützte Adminroute lässt seitdem den Build scheitern, bevor sie noch einmal ins Produktivsystem gelangt.
Ich glaube nicht, dass sich die Sicherheit eines Dienstleisters an einer makellosen Bilanz zeigt. Sie zeigt sich daran, was er an dem Tag tut, an dem er eine Lücke findet.
Wo ein Zertifikat uns überlegen wäre
Ein Zertifikat macht Software nicht sicher. Es erzwingt aber Regelmäßigkeit, und genau die ist die Schwachstelle kleiner Teams. An drei Stellen merken wir das:
- Penetrationstests. Dabei versucht ein externes Team gezielt, in die Anwendung einzubrechen. Zwei unserer Projekte hatten einen solchen Test, eines davon für eine Bank. Solche Tests regelmäßig bei jedem Projekt durchzuführen, ist für ein Team unserer Größe schwer.
- Entzug von Zugängen. Am Ende eines Projekts entferne ich die Zugänge, oder der Kunde tut es selbst, je nach Kunde. Unsere Regel lautet: höchstens 2 Wochen. Für einen ehemaligen Dienstleister ist das eine lange Zeit mit einem Schlüssel in der Hand. Wenn Ihnen eine kürzere Frist wichtig ist, schreiben Sie sie in den Vertrag.
- Updates von Abhängigkeiten. Kritische Sicherheitsupdates für Bibliotheken und Pakete spielen wir sofort ein. Alles andere aktualisieren wir routinemäßig alle 6 Monate. Diese Routine ist eine Untergrenze und kein Ziel, und an diesem Punkt würden wir am liebsten nachschärfen.
Damit ist die Entscheidung für Sie recht einfach. Wenn Ihre Einkaufsrichtlinien ein Zertifikat nach ISO 27001 verlangen, ohne Ausnahme, dann sind wir nicht Ihr Dienstleister, und daran ändert dieser Beitrag nichts. Verlangen Ihre Regeln dagegen, die tatsächliche Praxis eines Lieferanten zu bewerten, und genau das fordert NIS2, dann lässt sich die Liste oben an einem Nachmittag prüfen.
Fragen an jeden Dienstleister ohne ISO 27001
- Wem gehören das Repository, das Hostingkonto und die Domain, und könnten Sie dem Dienstleister den Zugang ohne seine Hilfe entziehen?
- Hat jede Person ein eigenes Konto, und welche Konten verlangen 2FA?
- Wo werden Passwörter und Zugangsschlüssel aufbewahrt?
- Verlassen echte Daten jemals das Produktivsystem?
- Wann wurde zuletzt ein Backup zurückgespielt, und bei welchem Projekt?
- Wer prüft den Code, bevor er übernommen wird?
- Wie schnell werden Zugänge entfernt, wenn jemand das Projekt verlässt?
- Wer informiert Sie, wenn ein Sicherheitsproblem gefunden wird, und wie schnell?
- Hatte eines der Projekte schon einen Penetrationstest, und was hat er gefunden?
Unsere Antworten stehen in diesem Beitrag. Kann ein Dienstleister die meisten dieser Fragen in einem kurzen Gespräch nicht beantworten, erfahren Sie dadurch mehr, als ein Zertifikat Ihnen sagen würde.
Bevor Sie unterschreiben
Wir entwickeln individuelle Webanwendungen und mobile Apps mit Laravel, React und React Native, für Kunden in der EU und in den USA. Gern führen wir Ihr Sicherheitsteam oder Ihren Einkauf vor der Unterschrift durch jede dieser Gewohnheiten. Wie das in echten Projekten aussieht, zeigen unsere Fallstudien.
Steht bei Ihnen eine Lieferantenprüfung an? Dann schreiben Sie uns an [email protected], und wir gehen Ihren Fragebogen gemeinsam mit Ihnen durch.