FAQ: Softwaresicherheit

Lokad ist in erster Linie ein supply chain Spezialist und unser primäres Ziel ist es, überlegene supply chain Entscheidungen durch technologische Genialität zu liefern. Das heißt, wir bearbeiten täglich wichtige finanzielle Daten, daher hat die Sicherheit unserer Software-Plattform höchste Priorität und wird von uns mit äußerster Ernsthaftigkeit behandelt. Anstatt Sicherheit als nachträglichen Gedanken, der durch Bürokratie abgehandelt wird, anzugehen, sind wir fest von einem prinzipientreuen Ansatz überzeugt, der Planung und Proaktivität betont – belegt durch unsere spezifischen Entscheidungen im Software-Design, bei der Personalbesetzung und den Schulungen.

Zielgruppe: Die IT-Abteilung
Zuletzt geändert: 21. September 2023

Sicherheitsprinzipien

Eine der schädlichsten Illusionen in Kreisen von Unternehmenssoftware ist die Vorstellung, dass Sicherheit mit Hilfe von Checklisten zur Einhaltung von Vorschriften, Zertifizierungen und, allgemeiner, allen möglichen bürokratischen Routinetätigkeiten angegangen werden kann. Leider befindet sich das Kleingedruckte in Sicherheitsbelangen ständig im Wandel. Probleme entstehen, wenn böswillige Akteure Software oder Menschen (oder beides) ausnutzen. Sicherheit kann daher nur durch die sinnvolle Anwendung allgemeiner Prinzipien angegangen werden.

Sicherer durch Design

Wir glauben, dass Design einer der am wenigsten geschätzten Aspekte der Softwaresicherheit ist. Hierbei umfasst Design die grundlegenden Entscheidungen, die zur Entwicklung der Software getroffen wurden. Die Designentscheidungen, die ein Unternehmen trifft, haben enorme Auswirkungen auf die Sicherheit, insbesondere was die Angriffsfläche betrifft. Durch ein sinnvolles Softwaredesign hat Lokad ganze Klassen von Sicherheitsproblemen eliminiert. Zum Beispiel nutzt Lokad keine SQL-Datenbank – sondern einfachen Blob-Speicher – als streng passive Speicherschicht. Diese Wahl allein verhindert ganze Gruppen von Sicherheitsproblemen, wie SQL-Injektionsangriffe, da es schlichtweg keine SQL-Datenbank gibt, die angegriffen werden könnte. Ebenso sind all unsere Persistenzschichten nur zum Anhängen bestimmt. Das ist wie Versionskontrolle, bei der Änderungen dem vorhandenen Datensatz hinzugefügt werden, anstatt die gesamten Daten zu überschreiben. Alle Änderungen sind nachvollziehbar und können rückgängig gemacht werden. Dieser Schritt erschwert das Löschen jeglicher Daten (durch jedermann, einschließlich Angreifer) erheblich, ebenso wie Manipulationen an Lokads Protokollen.

Die meisten Anbieter von Unternehmenssoftware erkennen nicht an, dass grundlegende Designentscheidungen das Fundament ihrer Softwareprodukte sind. Infolgedessen sind ihre Sicherheitsprobleme unendlich. Zum Beispiel, wenn Konfigurierbarkeit – fast immer ein Muss für Unternehmenssoftware – durch eine Programmiersprache für den allgemeinen Zweck (wie Python oder JavaScript) bereitgestellt wird, werden zwangsläufig Sicherheitsprobleme auftreten. Dies liegt daran, dass es nahezu unmöglich ist, eine Programmiersprache für den allgemeinen Zweck vollständig abzusichern. Im Gegensatz dazu hat Lokad die bewusste Designentscheidung getroffen, jegliche Konfigurierbarkeit durch eine DSL (domänenspezifische Programmiersprache) namens Envision zu kanalisieren. Envision ist viel sicherer, weil es – per Design – nicht die Fähigkeit besitzt, direkt mit dem Betriebssystem (OS) und dessen Untersystemen, wie dem Dateisystem, zu interagieren.

Sicherer durch Kultur

Keine Technologie und schon gar kein Prozess kann Software sicher machen, wenn den Menschen die Sorgfalt fehlt. Daher versuchen wir unser Bestes, um Lokad – sowohl seine Technologien als auch seine Prozesse – zu etwas zu machen, woran echte Fürsorge besteht. Im Kontext von Unternehmenssoftware ist dies schwierig, da das Objekt des Interesses abstrakt und von den individuellen Perspektiven und Motivationen der Menschen losgelöst ist¹.

Erstens stimmt Lokad, so weit es menschlich möglich ist, seine Marketingbotschaften mit der Realität seines Geschäfts in Einklang. Wir tun dies, unabhängig davon, ob es uns Zustimmung oder Kritik einbringt. Dies steht in starkem Gegensatz zu vielen Anbietern von Unternehmenssoftware, die unvernünftige (und oft fantasievolle) öffentliche Behauptungen aufstellen ². Wenn Letzteres geschieht, hören scharfsinnige Mitarbeiter – die in der Lage sind, die Diskrepanz zwischen der Realität des Geschäfts und dem, was der Außenwelt kommuniziert wird, zu erkennen – auf, sich zu kümmern. Diese Gleichgültigkeit führt zu Selbstzufriedenheit, woraufhin Sicherheitsprobleme folgen. Oft verlassen diese Mitarbeiter das Unternehmen und hinterlassen die “leichtgläubigen” – diejenigen, die die Diskrepanz nicht erkennen. Leichtgläubigkeit, ebenso wie Gleichgültigkeit, ist im Hinblick auf Sicherheit keine erwünschte Eigenschaft.

Zweitens fördert Lokad unter seinen Mitarbeitern eine Mischung aus Neugier und gesundem Skeptizismus in Bezug auf alle Aspekte unseres Geschäfts, sowohl technische als auch nicht-technische, einschließlich der Sicherheit. Dies schafft Flexibilität bei der Überarbeitung und Aktualisierung von Praktiken, da die Mitarbeiter geschult und ermutigt werden, sich einzubringen. Diese Plastizität ist nützlich, um böswillige Akteure zu antizipieren, da bekannt ist, dass diese ständig immer kreativere Angriffsweisen entwickeln. Glücklicherweise ist diese Denkweise für supply chain Zwecke ebenfalls sehr wünschenswert, da abweichendes Verhalten – auch wenn es nicht unbedingt kriminell ist – in der supply chain allgegenwärtig ist³.

Sicherer durch Schulung

Wir schulen aktiv all unsere Mitarbeiter, um Cyberbedrohungen besser zu verstehen und zu mindern. Anders als Design und Kultur ist die Sicherheitsschulung weitgehend ein Top-Down-Prozess. Obwohl Bottom-Up-Denken seinen Platz hat, ist diese Art von Schulung inhärent anfällig gegenüber den meisten Risiken der Computersicherheit. Einfach ausgedrückt, selbst wenn Menschen darauf geschult werden, etwas nicht zu tun, kann Lokad nicht davon ausgehen, dass niemand jemals etwas tun wird ⁴. Daher verfolgen wir einen strengeren Ansatz. Im Rahmen unserer Schulungen raten wir von USB-Flash-Laufwerken und anderen USB-Geräten ab, die Maschinen kompromittieren könnten. Wir stellen sicher, dass, wann immer möglich, die Zwei-Faktor-Authentifizierung verwendet wird. Wir schulen unsere Mitarbeiter so, dass sie an ihren Arbeitsplätzen mit so wenig Privilegien wie möglich arbeiten. Wir sorgen dafür, dass jeder weiß, wie Social Engineering funktioniert, welches auch die klügsten Menschen täuschen kann.

Allgemeiner konzentriert sich die Sicherheitsschulung darauf, das Bewusstsein dafür zu schärfen, wie Software und Prozesse von böswilligen Akteuren umfunktioniert und korrumpiert werden können. Angesichts des Ausbildungsumfangs, der Fertigkeiten und des Know-hows, die erforderlich sind, um solch ausgefeilte Angriffe zu verhindern, hat Lokad im Vergleich zu den meisten ähnlich großen Unternehmen in diesem Bereich generell nur sehr wenige Praktikanten. Kurz gesagt, wir setzen lieber langfristig auf ein stabiles, hochqualifiziertes Team.

Häufig gestellte Fragen (FAQ)

1. Praktiken

1.1 Haben Sie Sicherheitsgarantie?

Ja. Sicherheitsgarantie ist ein Überbegriff für verschiedene Praktiken wie Sicherheitshärtung, Sicherheitstests und Schwachstellenmanagement. Bei Lokad wird die Sicherheitshärtung in erster Linie durch Design angegangen. Durch spezifische Designentscheidungen eliminieren wir ganze Klassen von Schwachstellen, was wiederum den Bedarf an Härtungsmaßnahmen überflüssig macht. Zum Beispiel verlässt sich Lokad nicht auf eine “programmatische” Speicherschicht – wie etwa eine relationale Datenbank – sondern auf einen einfachen Key-Value Store. Dies eliminiert alle SQL-Injektionsvektoren. Darüber hinaus werden Sicherheitstests durch eine Vielzahl von Methoden angegangen; einige automatisiert und einige manuell, wie etwa Penetrationstests durch Dritte. Für das Schwachstellenmanagement haben wir ein Bug-Bounty-Programm und einen weitgehend automatisierten Release-Management-Prozess, um sicherzustellen, dass Fehler schnell behoben werden können.

1.2 Sind Sie ISO 27001 (ISMS) und/oder SOC 2 konform?

Nein. Wir sind fest davon überzeugt, dass diese Zertifizierungen Ablenkungen sind, die Softwareunternehmen weniger sicher machen. Diese Compliance-Prozesse betonen eine bürokratische Denkweise, die dem, was zur Sicherung von Software erforderlich ist, völlig widerspricht. Zum Beispiel erfordern diese Zertifizierungen die Erstellung von Papierkram und die Einrichtung von Ausschüssen. Offen gesagt ist die Vorstellung, dass Papierkram und Ausschüsse etwas Wesentliches zur Softwaresicherheit beitragen, höchst umstritten und wird von Lokad keinesfalls akzeptiert.

In Softwarekreisen wird Sicherheit in der Regel dadurch erreicht, dass weniger getan wird, nicht mehr; indem die Anstrengungen von Softwareingenieuren genutzt werden, die sich auf Softwaresicherheit spezialisiert haben, anstatt zusätzliche Teams von Nicht-Spezialisten zu schaffen. Als illustratives Beispiel seien einige der schwerwiegendsten Katastrophen der Cybersicherheit genannt, wie Heartbleed oder Log4Shell. Diese Katastrophen hätten wahrscheinlich vermieden werden können, wenn die tausenden von “zertifizierten” Softwareunternehmen es vorgezogen hätten, den Drittcodes – oft die eigentliche Ursache der Probleme – gründlich zu prüfen, anstatt willkürlich kommerzielle Gütesiegel anzustreben.

Insgesamt sind wir der Meinung, dass diese Zertifizierungen Marketingtricks sind, die Unternehmen in ein falsches Sicherheitsgefühl wiegen (sowohl im übertragenen als auch im wörtlichen Sinne).

1.3 Befolgen Sie die OWASP-Praktiken?

Ja. OWASP bietet durch seine Leitfäden eine umfangreiche Checkliste gegen Schwachstellen, die häufig in Software gefunden werden. Diese umfangreiche, hochwertige Zusammenstellung nutzen Lokad-Ingenieure, um unsere Software vor allen von OWASP identifizierten Problemen zu schützen. Allerdings eliminiert Lokad durch seine Designentscheidungen weitgehend ganze Klassen von gängigen Schwachstellen, die von OWASP hervorgehoben werden. Zum Beispiel:

Passwortverwaltung: Durch die Delegierung der Authentifizierung über SSO-Funktionalität (Single Sign-On, wie von Lokad empfohlen) muss Lokad Passwörter nicht mehr “verwalten”, wodurch die gesamte passwortbezogene Checkliste hinfällig wird.

Protokollierung: Das von Lokad übernommene Event-Sourcing-Design protokolliert alles aus Notwendigkeit. Wenn eine Aktion nicht protokolliert wird, dann hat sie aus Sicht des Systems nie stattgefunden. Dies macht den Großteil der Protokollierungs-Checkliste hinfällig.

Datenbanksicherheit: Die Persistenzschicht von Lokad enthält keine relationale Datenbank, sondern nur zwei nicht-programmatische Komponenten; nämlich eine Ereignisquelle und einen Key-Value Store. Diese Designentscheidung macht die gesamte Datenbank-Checkliste hinfällig.

Allgemeiner bevorzugen wir es, wenn möglich, fehleranfällige ingenieurtechnische Designmuster zu vermeiden, die überhaupt erst die Notwendigkeit solcher Checklisten schaffen.

1.4 Sind Sie DSGVO-konform?

Ja. Allerdings erfordert supply chain Optimierung – wie von Lokad geliefert – keine personenbezogenen Daten. Wir betrachten personenbezogene Daten eher als Belastung denn als Vorteil. Daher empfehlen wir unseren Kunden dringend, uns keine personenbezogenen Daten zu übermitteln. Diese Empfehlung ist in der Regel Bestandteil unserer vertraglichen Vereinbarungen. Da wir keine personenbezogenen Daten in Obhut haben und daher nicht verarbeiten, entfallen weitgehend Bedenken und Protokolle zum Schutz derselben, wie z. B. die DSGVO oder ähnliche Vorschriften.

1.5 Erfüllen alle Drittanbieterdienste/-lösungen (die Zugang zu persönlich identifizierbaren Informationen (PII) beinhalten) in Lokads Lösung die Anforderungen des Datenschutzbeauftragten (DPO)?

Ja. Allerdings, wie in Praktiken 1.4 erwähnt, erfordert supply chain Optimierung – wie von Lokad geliefert – keine personenbezogenen Daten. Daher empfehlen wir unseren Kunden dringend, uns keine personenbezogenen Daten zu übermitteln.

Es sei angemerkt, dass Lokads Lösung nur eine sehr kurze Liste von Drittanbietern umfasst, die Zugang zu PII-Daten haben. Ab Januar 2023 beschränkt sich diese Liste auf Microsoft Azure.

1.6 Befolgen Sie bewährte Sicherheitspraktiken?

Ja. Das heißt, wir treffen vernünftige Entscheidungen, da es keine branchenweite Übereinstimmung darüber gibt, was die “besten Sicherheitspraktiken” in der Software sind. Aufgrund seiner Natur befindet sich Softwaresicherheit in einem Zustand ständiger Weiterentwicklung, angepasst an ein Umfeld, das von geschickten neuen Bedrohungen und Angriffsvektoren geprägt ist. Daher überlassen wir nicht kategorisch die Definition der besten Sicherheitspraktiken Dritten. Stattdessen definieren wir, was für unsere Kunden am besten ist. Dies ermöglicht es uns, gute Praktiken dort zu übernehmen, wo sie verfügbar sind, ohne starr weniger empfehlenswerte zu befolgen, nur weil sie beliebt sind. All dies mündet in aktuellen, durchsetzbaren und effektiven Sicherheitspraktiken.

1.7 Führen Sie regelmäßig Penetrationstests durch?

Ja. Wir führen sowohl geplante als auch ungeplante Penetrationstests durch. Die geplanten werden in der Regel von unseren Großkunden finanziert, die – gemäß der mit ihnen unterzeichneten vertraglichen Vereinbarung – spezialisierte Unternehmen zur Durchführung von Penetrationstests ihrer wichtigen Softwareanbieter, zu denen auch Lokad gehört, beauftragen können. Es besteht in der Regel eine gewisse Abstimmung zwischen Lokads Engineering-Team und diesen Sicherheitsspezialisten. Die ungeplanten Tests sind in der Regel Teil unseres offenen öffentlichen Bug-Bounty-Programms, bei dem freiberufliche Sicherheitsspezialisten versuchen können, eine Schwachstelle in unserem System zu finden, die potenziell für einen Exploit ausgenutzt werden könnte.

1.8 Führen Sie regelmäßig externe Audits durch?

Nein. Allerdings sind wir gerne bereit, ein externes Audit durchzuführen, sofern der Vorgang vom Kunden finanziert wird. Viele unserer Großkunden haben in unseren vertraglichen Vereinbarungen entsprechende Bestimmungen für solche Audits. Ab Januar 2023 haben die von den Kunden durchgeführten Penetrationstests jedoch nicht genügend Probleme aufgedeckt, um solche Audits zu rechtfertigen.

1.9 Haben Sie einen Business Continuity Plan?

Ja. Die größte Eventualität, der sich Lokad gestellt hat, ist das hypothetische Erliegen des Unternehmens selbst. Lokad operiert als SaaS-Lösung, jedoch enthalten einige unserer Großkunden in ihren vertraglichen Vereinbarungen Bestimmungen, die es ihnen erlauben, vollständige Schnappschüsse unseres Codebases anzufordern. Diese Schnappschüsse werden bei einer vereinbarten Drittpartei in Treuhand hinterlegt, sodass der Kunde im Fall eines Betriebsstopps von Lokad automatisch Zugang zum in Treuhand befindlichen Codebase erhält und eine großzügige Lizenz zur Neuerstellung seiner eigenen Instanz des Lokad-Dienstes bekommt.

1.10 Haben Sie einen Krisenkommunikationsplan?

Ja. Für jeden Kunden haben wir einen festgelegten Ansprechpartner innerhalb dessen Organisation. Auf unserer Seite gibt es mindestens zwei Mitarbeiter bei Lokad – einen Hauptansprechpartner und einen Ersatz (typischerweise zwei unserer Supply Chain Scientist) – die dafür zuständig sind, dem Kunden dringende Nachricht(en) mitzuteilen. In der Praxis stellen die überwiegende Mehrheit der Krisen, denen wir begegnen, keine Software-Sicherheitsprobleme dar, sondern Probleme in der supply chain – Notfälle, die Lokad anhand der vom Kunden bereitgestellten Daten identifiziert. Im Falle eines Sicherheitsvorfalls wird dieser Kanal genutzt, um sicherzustellen, dass unsere Kunden zeitnah informiert werden.

1.11 Wie stellen Sie sicher, dass die IT-Systeme des Kunden sicher bleiben?

Wir empfehlen dringend, dass Lokad keinen Zugriff auf die IT-Systeme unserer Kunden hat; das IT-System des Kunden sollte lediglich Daten zu und von Lokad übertragen. Dieser Ansatz soll die Möglichkeit mindern, dass ein Sicherheitsvorfall bei Lokad auf das IT-System des Kunden übergreift. Darüber hinaus empfehlen wir ebenfalls dringend die Verwendung eines SSO (Single Sign-On)-Verfahrens, da es das hypothetische Szenario ausschließt, dass ein zur Zugriffsgewährung auf Lokad verwendetes Passwort abgefangen wird (irgendwie) und später zur Kompromittierung eines der IT-Systeme des Kunden verwendet wird.

1.12 Wie sichern Sie Ihr Netzwerk?

Unser Design folgt einer Zero-Trust-Architektur, was bedeutet, dass zu jedem Zeitpunkt lediglich den richtigen Personen der Zugriff auf Daten gestattet wird. Allein durch die Anwesenheit in unserem Netzwerk erhält man keinen automatischen Status oder Privilegien (dieser Punkt wird in Authentication 2.1 ausführlicher behandelt). Daher achten wir zwar auf Netzwerksicherheit, stellen jedoch als erste Maßnahme sicher, dass die Angriffsfläche, die mit unseren Netzwerken verbunden ist, so klein wie möglich gehalten wird.

Lokad nutzt zwei bemerkenswerte Netzwerke. Das erste ist Microsoft Azure, das zur Bereitstellung unserer Lösung verwendet wird. Die Sicherheit des Microsoft-Azure-Netzwerks wird vollständig an Microsoft delegiert. Wir nutzen keine “advanced” Netzwerkfunktionen – wie sie von Microsoft Azure angeboten werden – über grundlegende Load Balancer hinaus.

Das zweite ist das lokale Netzwerk unseres Hauptsitzes in Paris. Die Sicherheit des lokalen Netzwerks wird intern vom Engineering-Team von Lokad verwaltet. Unser lokales Netzwerk beherbergt keine Komponente oder kein System, das zur Produktionsumgebung beiträgt.

1.13 Garantieren Sie, dass alle Komponenten (einschließlich solcher von Drittanbietern) und Werkzeuge (einschließlich Open-Source-Anwendungen), die in der Lösung integriert sind, rechtlich für die Entwicklungs- und Produktionsnutzung gültig sind?

Ja. Im Vergleich zu den meisten Anbietern von Unternehmenssoftware hat Lokad nur sehr wenige Abhängigkeiten. Alle unsere wesentlichen Abhängigkeiten sind vertrauenswürdige und weit verbreitete Open-Source-Projekte (z. B. .NET von Microsoft, React von Facebook). Dies macht unseren internen Prüfungsprozess in diesem speziellen Punkt zu einem unkomplizierten Vorgang.

1.14 Wie managen Sie wesentliche organisatorische und prozessuale Änderungen in Bezug auf die Sicherheit?

Da Lokad von Anfang an sinnvolle Sicherheitsdesign-Entscheidungen und -Praktiken übernommen hat, ist es selten, dass eine Änderung – gleich welcher Größenordnung (klein oder groß) – die Sicherheit beeinträchtigt (selbst hypothetisch). In der gesamten Geschichte von Lokad gab es nur 3 Ereignisse, die aus sicherheitstechnischer Sicht als wirklich bedeutend angesehen werden können: die Migration zu Microsoft Azure im Jahr 2010; die Einführung der delegierten Authentifizierung im Jahr 2012 (sowohl für Kunden als auch für Mitarbeiter); und intern bei Lokad die Migration von der Google-Authentifizierung zu Microsoft Azure AD im Jahr 2022.

Für jedes dieser Ereignisse wurde die Migration mehrere Monate im Voraus vom Software-Engineering-Team von Lokad vorbereitet. Relevante Schulungsmaterialien und Trainingssitzungen wurden vor der geplanten Änderung implementiert, um die Einsatzbereitschaft aller Lokad-Mitarbeiter sicherzustellen. Schließlich haben wir nach jedem Migrationsereignis dafür gesorgt, dass der vorherige “Pfad” eliminiert wurde, wie es die Standardpraxis bei Lokad ist.

Ab Januar 2023 haben wir keine bevorstehenden wesentlichen Änderungen geplant. Sollte eine solche Änderung eingeführt werden, würden wir nahezu sicher in ähnlicher Weise vorgehen.

1.15 Wie managen Sie das Ende eines Vertrags?

Unsere Vereinbarungen detaillieren den Kündigungsprozess am Ende eines Vertrags, wie mit dem Kunden vereinbart. Der Kündigungsprozess endet mit der endgültigen Löschung der Kundendaten. Da dieser Kündigungsprozess selbst ein Sicherheitsrisiko darstellt, wird dieser Punkt mit jedem Kunden individuell besprochen und kann daher je nach Fall leicht variieren. Aus sicherheitstechnischer Sicht könnte ein böswilliger Akteur versuchen, sich als Kunde auszugeben, um eine vorzeitige Vertragsbeendigung auszulösen (und somit den Betrieb des Kunden zu stören). Um dem entgegenzuwirken, würden Lokad und der Kunde gemeinsam bestreben, einen vertraglich festgelegten Prozess zu etablieren, der nicht trivial anfällig für einen Social-Engineering-Angriff ist. Dieser Prozess umfasst in der Regel schriftliche Bestätigungen und eine obligatorische Verzögerung.

1.16 Was ist Lokads Lizenzstrategie, das zugehörige Kostenmodell und das jährliche Wartungskostenmodell?

Lokad berechnet in der Regel eine monatliche Pauschalgebühr, die mit den Betriebskosten der Plattform verbunden ist, zuzüglich einer monatlichen Pauschalgebühr für den von den Supply Chain Scientist, die für den Kunden zuständig sind (d. h. die von Lokad bereitgestellten Ingenieure), erbrachten Service. Das Kleingedruckte wird im Dienstleistungsvertrag zwischen dem Kunden und Lokad verhandelt und detailliert. Diese beiden Gebühren stellen ein “all-inclusive”-Paket mit Lokad dar. Es gibt keine zusätzlichen Wartungsgebühren, Lizenzgebühren, Gebühren für Drittanbieter-Integrator(en), Drittanbieter-Berater etc. Das Paket kommt mit Begrenzungen hinsichtlich Umfang und Skalierung, die gemeinsam als Teil der vertraglichen Vereinbarung für den Service ausgehandelt werden.

1.17 Können Sie Lokads Geschäftsbedingungen für die Lizenz(en), Dienstleistung(en), Unterstützung, Wartung und Schulungen bereitstellen?

Ja, auf Kundenwunsch können wir eine vertragliche Vorlage bereitstellen, die eine “Baseline”-Vereinbarung darstellt. Allerdings variieren die Situationen erheblich, abhängig von der Größenordnung der supply chain Initiative, den betroffenen Ländern und dem Umfang der von Lokad erwarteten Dienstleistungen. Daher ziehen wir es, wenn möglich, vor, ein erstes Gespräch mit einem potenziellen Kunden zu führen, um die Details der in Betracht gezogenen supply chain Initiative zu klären. Dies hilft uns, den relevantesten vertraglichen Rahmen für die jeweilige Situation zu gestalten.

1.18 Bieten Sie Schulungen (präsenz / E-Training) an?

Ja, Lokad bietet sowohl Vor-Ort- als auch Fernschulungen an. Das Kleingedruckte dieser Sitzungen wird als Teil der Vertragsvereinbarung verhandelt. Weiterhin verfügt Lokad über umfangreiche öffentliche technische Dokumentation und eine detaillierte Reihe öffentlicher supply chain lectures. Diese Vorlesungen behandeln Lokads Technologie und supply chain Perspektive.

1.19 Entspricht Lokads System den relevanten gesetzlichen/lokalen Standards (z. B. ISO)?

Ja, Lokad arbeitet gemäß den relevanten Standards. Allerdings liefert Lokad eine prädiktive Optimierung der supply chain und steuert die Abläufe somit nicht direkt. Unser Einfluss ist weitgehend indirekt, typischerweise durch die Optimierung der Ressourcenallokation. Daher sind die ISO-Standards hier nicht relevant (d. h. sie gelten nicht für Lokad).

1.20 Ist auf Netzwerkebene – beispielsweise an Firewalls, Proxy-Geräten und/oder im Netzwerk als separate Lösungen – ein Malware-Schutz integriert?

Siehe Practices 1.12

1.21 Beinhaltet der Softwareentwicklungsprozess eine integrierte Bedrohungsbewertung?

Ja. Dies ist der Hauptgrund, warum wir Sicherheitsbedenken “by design” angehen. Indem wir ganze Klassen von Bedrohungen bereits in der Entwurfsphase eliminieren, halten wir die Gesamteinschätzung von Bedrohungen überschaubar. Die Bedrohungsbewertung umfasst auch “supply chain attacks”. Dies ist ein weiterer Grund, weshalb wir großen Wert darauflegen, die Anzahl der Abhängigkeiten von Drittanbietern in unserem Software-Stack zu minimieren, da jede Abhängigkeit inhärent die Angriffsfläche vergrößert.

1.22 Wird der Vorfallmanagementprozess mindestens jährlich geübt?

Ja. Es gibt viele verschiedene Arten von Vorfällen. Einer der häufigsten ist, dass das Kundenunternehmen selbst kompromittiert wird. Im Falle von Ransomware führt dies manchmal dazu, dass die Lokad-Daten versehentlich zum einzigen noch zugänglichen Datensatz werden. Bei Identitätsdiebstahl kann es manchmal zu Versuchen kommen, über gestohlene Zugangsdaten Zugriff auf das Lokad-Konto zu erlangen. Das Kleingedruckte der verschiedenen Vorfallmanagement-Prozesse wird gemeinsam mit dem Kundenunternehmen festgelegt und in der Regel von dem bei Lokad verantwortlichen Supply Chain Scientist betreut (für Kunden, die sich für ein Managed Account entscheiden).

1.23 Wird die Risiko- und Bedrohungskartierung mindestens jährlich überprüft?

Ja, obwohl diese Überprüfungen in der Regel regelmäßig im Laufe des Jahres durchgeführt werden. Solche Überprüfungen werden häufig durch bedeutende Ereignisse angestoßen, wie etwa bemerkenswerte Sicherheitsverletzungen in der Softwarebranche.

1.24 Wird die Risikobewertung auch auf unterstützende Funktionen angewendet, die die Verfügbarkeit, Qualität und/oder Sicherheit der Lösung beeinträchtigen könnten?

Ja. Allerdings ist die Lokad-Plattform im Wesentlichen ein Monolith, der auf keine “unterstützenden Funktionen” angewiesen ist, abgesehen von einigen grundlegenden Kernkomponenten wie dem Blob Storage und Linux-VMs, wie sie von Microsoft Azure bereitgestellt werden.

1.25 Werden dedizierte Systemkonten – mit nur den erforderlichen Zugriffsrechten – für den Betrieb von Systemprozessen erstellt?

Ja, dedizierte Systemkonten mit den entsprechenden Zugriffsrechten werden für den Betrieb von Systemprozessen verwendet. Lokad nutzt Daemons in Form von systemd-Diensten, die stets als Benutzer mit so wenigen Privilegien wie möglich laufen.

Obwohl Lokad keine SQL-Datenbank verwendet, nutzt die Plattform ein rollenbasiertes System, um die Zugriffsrechte für geplante und ausgelöste Prozesse festzulegen. Diese Prozesse werden als “userland” und nicht als “system” Prozesse klassifiziert.

1.26 Gibt es einen formalisierten Risiko-Governance-Plan, der von der Geschäftsführung genehmigt wurde und die Anforderungen des Enterprise Risk Management-Programms definiert?

Ja, wir haben einen formalisierten Risiko-Governance-Plan, der von der Geschäftsführung genehmigt wurde.

Dieser Plan umreißt die Anforderungen und Richtlinien für unser Enterprise Risk Management (ERM)-Programm. Er ist darauf ausgelegt, Risiken im gesamten Unternehmen in strukturierter und konsistenter Weise zu identifizieren, zu bewerten, zu managen und zu überwachen.

Unser Risiko-Governance-Plan wird regelmäßig überprüft und aktualisiert, um sicherzustellen, dass er relevant bleibt und mit unseren organisatorischen Zielen sowie dem sich wandelnden Risikoumfeld im Einklang steht. Zudem werden die Implementierung und Wirksamkeit des ERM-Programms regelmäßig der Geschäftsführung und relevanten Stakeholdern berichtet, um eine kontinuierliche Überwachung und Unterstützung zu gewährleisten.

1.27 Gibt es ein von der Geschäftsführung genehmigtes physisches Sicherheitsprogramm, das an die Beteiligten kommuniziert wurde, und wurde ein Verantwortlicher zur Pflege und Überprüfung zugewiesen?

Ja, wir haben ein umfassendes physisches Sicherheitsprogramm, das von der Geschäftsführung genehmigt wurde. Dieses Programm wurde gründlich an alle relevanten Beteiligten kommuniziert, um Bewusstsein und Einhaltung sicherzustellen.

Zusätzlich haben wir einen Verantwortlichen benannt, der dafür zuständig ist, das Programm zu pflegen, zu aktualisieren und regelmäßig zu überprüfen, um dessen Effektivität und Relevanz sicherzustellen. Dieser Verantwortliche arbeitet mit verschiedenen Teams und Abteilungen zusammen, um auf auftretende physische Sicherheitsbedenken zu reagieren, und stellt sicher, dass das Programm den Best Practices und unseren organisatorischen Zielen entspricht.

1.28 Werden Bewertungen der physischen und umweltbedingten Gefahren durchgeführt, bevor der Standort oder die Örtlichkeit einer Einrichtung, in der Systeme betrieben werden, festgelegt wird?

Ja, Bewertungen der physischen und umweltbedingten Gefahren sind ein integraler Bestandteil unseres Entscheidungsprozesses, wenn es darum geht, den Standort oder die Örtlichkeit einer Einrichtung für unsere Systeme festzulegen. Da unsere Systeme in Microsoft Azure-Rechenzentren untergebracht sind, profitieren wir von Microsofts strengen Auswahl- und Bewertungsprozessen. Microsoft Azure führt umfangreiche Bewertungen potenzieller Risiken, einschließlich physischer und umweltbedingter Gefahren, durch, bevor eines ihrer Rechenzentren errichtet wird. Ihr Auswahlprozess umfasst unter anderem die Analyse von Faktoren wie Naturkatastrophenpotenzial, Zugänglichkeit, Infrastrukturstabilität und mehr.

Durch die Nutzung der Azure-Rechenzentren sind wir zuversichtlich, dass diese Bewertungen umfassend durchgeführt wurden, um die höchsten Sicherheitsstandards in Bezug auf physische Sicherheit und Umweltresilienz für unsere Systeme zu gewährleisten.

1.29 Gibt es ein dokumentiertes internes Compliance- und Ethikprogramm?

Ja, obwohl wir nicht daran glauben, dass „Ethik“ von oben nach unten durchgesetzt werden kann. Eine derartige Vorgehensweise führt zwangsläufig zu unerwünschten Ergebnissen, die den ursprünglichen Zielen widersprechen.

Bekanntermaßen hatte Enron einen schriftlichen Ethikkodex. Dieser Kodex betonte Respekt, Integrität, Kommunikation und Exzellenz. Der Enron-Skandal, der 2001 ans Licht kam, zeigte, dass das Unternehmen in massive Bilanzfälschungen verwickelt war, was – offensichtlich – im Widerspruch zu den im Ethikkodex festgelegten Prinzipien stand. Es bestand daher eine vollständige Diskrepanz zwischen Enrons bekundeter, schriftlicher Ethik und den tatsächlich gelebten Geschäftspraktiken sowie der Unternehmenskultur.

Daher konzentriert sich Lokad darauf, sicherzustellen, dass die Mitarbeiter die Möglichkeit haben, sich aufrichtig um unsere Kunden zu kümmern. „Machen wir die richtigen Dinge?“ ist eines unserer Mantras. Compliance und Ethik sind unserer Ansicht nach das Nebenprodukt einer angemessenen Unternehmenskultur und nicht das Ergebnis eines bestimmten Programms.

1.30 Gibt es eine interne Abteilung für Audit, Risikomanagement oder Compliance oder eine ähnliche Management-Aufsichtsinstanz, die für die Verfolgung der Behebung offener regulatorischer oder Compliance-Probleme verantwortlich ist?

Ja. Obwohl Lokad nicht groß genug ist, um eine eigenständige Abteilung für interne Audits, Risikomanagement oder Compliance zu unterhalten, priorisieren wir diese Bereiche eindeutig. Wir haben dafür ausgewiesene Personen mit Fachkenntnissen in diesen Domänen, die speziell mit der Handhabung und Überwachung dieser kritischen Verantwortlichkeiten betraut sind.

Diese Personen berichten direkt an die oberste Managementebene von Lokad, wodurch sichergestellt wird, dass die Lösung aller noch offenen regulatorischen oder Compliance-Fragen mit höchster Priorität behandelt und auf der höchsten Ebene unserer Organisation die notwendige Aufsicht erhält.

1.31 Gibt es eine kabellose Richtlinie bzw. ein Programm, das vom Management genehmigt, den entsprechenden Beteiligten mitgeteilt und einem Verantwortlichen zur Pflege und Überprüfung zugewiesen wurde?

Ja, Lokad verfügt über eine klar definierte kabellose Richtlinie, die vom Management genehmigt und allen relevanten Beteiligten zur Einhaltung mitgeteilt wurde. Diese Richtlinie unterscheidet zwischen zwei unabhängigen und isolierten Wi‑Fi-Netzwerken: einem, das ausschließlich für Mitarbeiter bestimmt ist, und einem speziell für Gäste. Diese Unterscheidung stellt sicher, dass unsere primären Abläufe sicher bleiben, selbst wenn wir Gästen oder Besuchern Konnektivität bereitstellen.

Es ist jedoch wichtig zu beachten, dass unsere primäre Verbindungsart über Ethernet erfolgt, da diese aufgrund ihrer überlegenen Leistung und erhöhten Sicherheit Priorität genießt. Die Wi‑Fi-Netzwerke sind in erster Linie dafür vorgesehen, Meetings zu ermöglichen und in bestimmten Szenarien Flexibilität zu bieten.

Darüber hinaus haben wir einen Verantwortlichen für diese Richtlinie benannt, der für deren Wartung und regelmäßige Überprüfung zuständig ist, um sicherzustellen, dass sie stets aktuell und effektiv bleibt, um den sich entwickelnden Anforderungen und Herausforderungen gerecht zu werden.

2. Authentifizierung

2.1 Erzwingen Sie die Authentifizierung für alle Zugriffe?

Ja. Der Zugriff auf Kundendaten und/oder wesentliche Funktionen der Lösung erfordert eine vorherige Authentifizierung. Allerdings sind aus praktischen Gründen einige Kontaktpunkte nicht authentifizierungspflichtig. Beispielsweise erfordert der Zugriff auf die Login-Webseite keine vorherige Authentifizierung (da die Authentifizierung genau den Zweck dieser Login-Webseite bildet).

Insgesamt erfordern nur sehr wenige technische Endpunkte keine Authentifizierung, und diese sind typischerweise Teil der Instrumentierung der Plattform (z. B. ein Endpunkt, der ausschließlich überprüft, ob eine Maschine erreichbar ist). Es sei darauf hingewiesen, dass nicht authentifizierte Endpunkte keinerlei sensible Daten preisgeben – geschweige denn tatsächliche Kundendaten.

2.2 Erfordern Sie, dass alle Fernzugriffe gesichert sind? Erzwingen Sie HTTPS für Webverbindungen?

Ja. Die Sicherung von Fernzugriffen bedeutet, dass die richtige Authentifizierung, die entsprechende Autorisierung sowie die Verschlüsselung des Transportkanals selbst gewährleistet werden – all dies setzen wir konsequent um. Diese Bestimmung gilt gleichermaßen für Kundenanwender und Lokad-Mitarbeiter. Selbst für das Engineering-Team bei Lokad gibt es keinen “ungesicherten lokalen Zugriff” auf unsere Produktionssysteme. Wir nutzen keinerlei Art von Netzwerk-“Lokalität” als Sicherheitsumgehung.

2.3 Bieten Sie SSO (Single Sign-On) an? Unterstützen Sie Active Directory (AD)?

Ja. Wir bieten SSO (Single Sign-On) über das SAML-Protokoll an. Active Directory unterstützt SAML und kann für den Zugriff auf Lokad genutzt werden.

2.4 Unterstützen Sie die Zwei-Faktor-Authentifizierung, wie EZToken, Google Authenticator oder Microsoft Authenticator?

Ja. Die Zwei-Faktor-Authentifizierung wird durch delegierte Authentifizierung via SAML erreicht. Über SAML verwaltet Lokad weder den ersten noch den zweiten Authentifizierungsfaktor, da dieser Prozess delegiert wird.

2.5 Unterstützen Sie das OAuth2-Authentifizierungsprotokoll?

Standardmäßig unterstützt Lokad das SAML-Authentifizierungsprotokoll. Dieses Protokoll wird von den wichtigsten föderierten Identitätssystemen, wie Microsoft Office 365 oder Google Workspace, unterstützt. Die Herausforderung bei der Unterstützung von OAuth2 besteht darin, dass OAuth2 eigentlich kein „Authentifizierungsprotokoll“ ist, sondern ein Satz sehr umfangreicher Richtlinien zur Entwicklung von „Authentifizierungsprotokollen“, die in Dutzenden von Weisen variieren können.

Folglich stellen wir fest, dass die verschiedenen OAuth2-Implementierungen, die im Bereich der Unternehmenssoftware existieren, weitgehend inkompatibel sind. Daher können wir – falls OAuth2 vertraglich als zwingende Voraussetzung festgelegt ist – eine spezifische Variante von OAuth2 unterstützen. Allerdings erfordert diese Vereinbarung dedizierte Ressourcen, um die Kompatibilität mit der von der Kundenfirma betriebenen OAuth2-Variante sicherzustellen.

2.6 Unterstützen Sie die LDAP-Integration?

Ja, durch eine Middleware-Brücke, die SAML über LDAP legt. Allerdings unterstützen die meisten föderierten Identitätssysteme, die LDAP unterstützen, auch SAML. Daher empfehlen wir, SAML direkt zu verwenden.

2.7 Erzwingen Sie die Zwei-Faktor-Authentifizierung?

Für Lokad-Mitarbeiter, ja. Für die Mitarbeiter des Kunden empfehlen wir diese stark, können sie jedoch letztlich nicht erzwingen (da die Authentifizierung in der Regel über SSO delegiert wird). Diese Angelegenheit obliegt der IT-Abteilung unseres Kunden, nicht uns.

2.8 Können Sie eine minimale Passwortkomplexität erzwingen?

Ja, aber nur in begrenztem Umfang. In puncto Softwaresicherheit gilt die Verpflichtung zu minimaler Passwortkomplexität inzwischen weitgehend als schlechte Praxis. Endanwender reagieren (und das auch erwartungsgemäß) negativ auf zu strenge Anforderungen an die Passwortkomplexität, was das allgemeine Sicherheitsniveau beeinträchtigt. Darüber hinaus betrachten wir derartige Passwortanforderungen als “Bloatware”, welche die Komplexität eines sicherheitskritischen Softwarebestandteils (Passwortverwaltung) erhöhen und dadurch diesem (sowie der Gesamtlösung) unangemessene Risiken aussetzen. Siehe https://www.sans.org/blog/nist-has-spoken-death-to-complexity-long-live-the-passphrase/

Wir empfehlen dringend, SSO anstelle von herkömmlichen Passwörtern/Strategien zu verwenden. Durch SSO ist es nicht notwendig, ein Lokad-eigenes Passwort einzuführen.

2.9 Können Sie geplante Passwortwechsel erzwingen?

Das könnten wir, tun es aber nicht. Ähnlich wie bei der minimalen Passwortkomplexität (siehe Authentication 2.8) gilt geplante Passwortrotation mittlerweile weitgehend als schlechte Praxis in der Softwaresicherheit. Endanwender reagieren (und das auch erwartungsgemäß) schlecht auf geplante Passwortwechsel. Die Sicherheit kann sogar beeinträchtigt werden, da Mitarbeiter oft nur geringfügige Änderungen an Passwörtern vornehmen (um die mit häufigen Wechseln verbundene kognitive Belastung zu reduzieren). Wie bei der minimalen Passwortkomplexität betrachten wir auch die Passwortrotation als “Bloatware”, die die Komplexität eines sicherheitskritischen Softwarebestandteils (Passwortverwaltung) erhöht und diesen (sowie die Gesamtlösung) unangemessenen Risiken aussetzt. Siehe https://www.sans.org/blog/time-for-password-expiration-to-die/

2.10 Hashen und salzen Sie Passwörter?

Ja. Wir verwenden scrypt als unsere Passwort-Hashing-Funktion. Grundsätzlich empfehlen wir dringend, SSO anstelle traditioneller Passwörter/Strategien zu verwenden. Durch SSO ist es nicht notwendig, ein Lokad-eigenes Passwort einzuführen.

2.11 Ermöglicht Lokads Lösung die Verwendung von CAPTCHA nach einer bestimmten Anzahl von Authentifizierungsfehlern?

Ja, allerdings erfolgt dies über Authentifizierungsdelegation (via SSO). Obwohl CAPTCHAs ein wertvoller Ansatz zur Minderung einiger Angriffsvektoren sind, zählen sie zu jenen Softwarekomponenten, die am besten vollständig außerhalb des Anwendungsbereichs einer supply chain optimization Lösung wie der von Lokad verbleiben. Zudem ist der Mehrwert von CAPTCHAs im Kontext von Unternehmenssoftware weniger eindeutig als bei B2C-Software, insbesondere Freeware.

2.12 Haben Sie eine allgemeine Sicherheitsrichtlinie für Passwörter? Gibt es einen Prozess zu deren Durchsetzung?

Ja. Unsere allgemeine Sicherheitsrichtlinie für Passwörter lautet “keine Passwörter”. Wir empfehlen dringend SSO, wodurch die Notwendigkeit entfällt, Passwörter speziell für Lokad einzuführen.

2.13 Zentralisieren Sie die Benutzerverwaltung?

Ja. Lokad verfügt über eine eigene zentrale Benutzerverwaltung für die von uns betriebene Lösung. Dieses Teilsystem wurde von Lokad implementiert und deckt auch die Zugriffe der Lokad-Mitarbeiter ab – einschließlich unserer Engineering-Teams.

2.14 Erlauben Sie generische/geteilte Benutzerkonten?

Nein. Lokad erzwingt eine Eins-zu-Eins-Beziehung zwischen Mitarbeitern und Benutzern (wie dies von der Lokad-Plattform gesehen wird). Wir raten dringend von der Nutzung geteilter Benutzerkonten ab. Tatsächlich ist dies einer der Gründe, warum wir nicht pro Benutzer abrechnen, um unseren Kunden keinen Anreiz zu geben, Benutzerkonten unter ihren Mitarbeitern zu teilen. Es gibt jedoch einige Fälle, in denen es akzeptabel ist, ein Benutzerkonto zu haben, das keinem entsprechenden Mitarbeiter zugeordnet ist. Dies tritt typischerweise beim clientseitigen “robot upload” Service auf, der für das Übertragen von Daten zu Lokad zuständig ist. Im Rahmen unserer RBAC (Role-Based Access Control) haben wir eine dedizierte Rolle (genannt “uploader”), die für diesen speziellen Anwendungsfall minimale Rechte bietet.

2.15 Bieten Sie sichere VPN-Verbindungen an?

Nein. Die Verbindungen der Endanwender erfolgen über verschlüsselte Kanäle (in der Regel TLS).

2.16 Erlauben Sie den Benutzern, sich von mehreren Geräten aus einzuloggen?

Ja, innerhalb gewisser Grenzen. Im Allgemeinen liegt das obere Limit bei 6 Geräten pro Benutzer (wir berechnen keine zusätzlichen Kosten für die Nutzung mehrerer Geräte). Jede Sitzung ist auf eine einzelne IP-Adresse beschränkt. Lokad behält sich jedoch das Recht vor, dieses Limit zu ändern, um potenziellen Bedrohungen und/oder Missbrauch entgegenzuwirken.

2.17 Verfügt die Lösung über die Möglichkeit, einen Benutzer gewaltsam zu sperren und/oder abzumelden (falls er als bösartig angesehen wird)?

Ja. Diese Funktion erfordert “Owner”-Zugriffsrechte innerhalb des Lokad-Kontos.

2.18 Meldet das System einen inaktiven Benutzer nach einer bestimmten Leerlaufzeit automatisch ab?

Ja, obwohl “Inaktivität” nicht der entscheidende Faktor ist. Lokad meldet Benutzer nach einer festgelegten Zeitspanne automatisch ab. Benutzer können die Abmeldung nicht verzögern, indem sie “aktiv” bleiben; sobald die festgelegte Zeit erreicht ist, müssen sie sich erneut authentifizieren.

2.19 Ist die Nutzung geteilter Konten und/oder Zugangsdaten verboten, und wird die Einhaltung dieser Richtlinien überwacht?

Ja. Siehe Authentication 2.14.

2.20 Werden Benutzer-IDs und Passwörter über getrennte Medien (z. B. E-Mail und Telefon) kommuniziert/verteilt?

Ja, wir legen großen Wert auf die Sicherheit der Benutzeranmeldeinformationen und stellen sicher, dass diese in einer Weise kommuniziert werden, die den Best Practices entspricht. Intern greifen unsere Systeme auf Azure Active Directory für die Benutzerauthentifizierung zu. Bei der Verteilung von Benutzer-IDs und ersten Passwörtern folgt Azure Active Directory seinen standardmäßigen Mustern, die mit Blick auf Sicherheit entwickelt wurden. Zudem erzwingen wir die Zwei-Faktor-Authentifizierung für unser Azure AD, wodurch dem Authentifizierungsprozess eine zusätzliche Sicherheitsebene hinzugefügt wird.

Extern wird für Kundenmitarbeiter, die auf unsere Systeme zugreifen, dringend die Verwendung von Single Sign-On (SSO) und föderierten Identitätssystemen empfohlen. Diese Systeme unterstützen von Haus aus die Best Practices im Credential Management und stellen sicher, dass Anmeldeinformationen auf sichere Weise kommuniziert werden, häufig unter Nutzung getrennter Kommunikationskanäle oder Methoden für Benutzer-IDs und Authentifizierungsmechanismen.

Es ist anzumerken, dass wir – sofern das Ziel ein hohes Sicherheitsniveau ist – keine Ein-Faktor-Authentifizierung empfehlen, weder für interne noch für externe Benutzer.

2.21 Werden inaktive Benutzer-IDs nach festgelegten Inaktivitätszeiträumen deaktiviert und gelöscht?

Ja, wir verwalten und überwachen die Benutzer-IDs aktiv, um die Sicherheit zu gewährleisten. Für Lokad-Mitarbeiter schreibt unsere Richtlinie vor, dass alle Zugriffsrechte an ihrem letzten Arbeitstag widerrufen werden, sodass es keinen Zugriff nach Beendigung des Arbeitsverhältnisses gibt.

Für unsere Kunden plädieren wir für den Einsatz von Single Sign-On (SSO) und föderierten Identitätssystemen. Dieser Ansatz rationalisiert das Zugriffsmanagement. Beispielsweise wird der Zugriff auf Lokad gleichzeitig beendet, wenn ein Kunde einen Mitarbeiter aus seinem Identitätssystem entfernt. Diese Methode verbessert nicht nur die Sicherheit, sondern sorgt auch für Effizienz in der Benutzerverwaltung.

Hinweis: Die Details zur Beendigung von Benutzerzugriffen sind in unseren vertraglichen Vereinbarungen mit jedem Kunden festgehalten. Lokad erkennt ausdrücklich die potenziellen operativen Auswirkungen einer verfrühten Deaktivierung eines Kontos an und ergreift aktive Maßnahmen, um solchen Szenarien vorzubeugen. Um unbeabsichtigte Störungen zu vermeiden, werden die Bedingungen für die Beendigung des Benutzerzugriffs entweder im Vertrag oder in einem gemeinsam vereinbarten Verfahren explizit festgelegt, sodass Lokads Sicherheitsmaßnahmen den betrieblichen Anforderungen unserer Kunden entsprechen.

3. Autorisierung

3.1 Bietet die Lösung fein granulare Zugriffsrechte?

Ja. Die Lokad-Lösung umfasst ein granuläres RBAC (Role-Based Access Control) Teilsystem. Dies ermöglicht es dem Kunden, zu steuern, welche “Projects” und “Files” im Lokad-Konto zugänglich sind (und von wem). Das RBAC verfügt über eine eigene Web-Benutzeroberfläche (Dashboard) und steht allen Benutzern mit der Bezeichnung “Owner” im Lokad-Konto zur Verfügung. Weitere Informationen finden Sie in unserer Dokumentation zu Benutzerrollen und Berechtigungen.

3.2 Ermöglicht die Lösung es dem Kunden, den Zugriff gemäß dem Prinzip der minimalen Rechte (Least Privilege, PoLP) zu konfigurieren?

Ja. Die Lokad-Lösung umfasst ein granuläres RBAC (Role-Based Access Control) Teilsystem, das zur Umsetzung des PoLP verwendet werden kann. Allerdings geht Lokad – insbesondere durch Envision (die DSL der Lösung) – in Bezug auf dieses Prinzip weit über die meisten Unternehmenssoftwares hinaus.

Durch Envision hat Lokad ganze Suiten von Systemprivilegien eliminiert, die für supply chain optimization schlichtweg irrelevant sind. Was verbleibt, ist schlank, aber dennoch umfangreich konfigurierbar. Ebenso beseitigt das eigens entwickelte Dateisystem von Lokad ganze Gruppen unnötiger Systemprivilegien.

3.3 Erzwingen Sie Zugriffsrechte nach dem Prinzip der minimalen Rechte?

Ja, wenngleich letztlich unsere Kunden darüber entscheiden, was als das “minimal akzeptable” Privileg gilt. Lokad kann nicht einseitig festlegen, wer von einer “Owner”-Bezeichnung im Kundenpersonal profitiert. Allerdings können wir in dieser Hinsicht beratend zur Seite stehen. In der Praxis klären wir für unsere “managed” Kunden – also jene, die von Lokads Team of Supply Chain Scientists unterstützt werden – (schriftlich) die gewünschte Organisation sowie die zugehörigen Zugriffsrechte.

3.4 Verfügt die Lösung über die Fähigkeit, ein bestimmtes Element im System vor bestimmten Benutzern zu verbergen?

Ja. Dies ist eine Form der Umsetzung des PoLP und wird in den Antworten 3.1, 3.2 und 3.3 behandelt.

3.5 Haben Sie eine Klassifizierung für Daten (Sensitivitätsstufen) implementiert, und werden die Kontrollen entsprechend dieser Klassifizierung angepasst?

Ja. Als integriertes Element beschränkt Lokad standardmäßig alle administrativen Daten (wie etwa die Liste der Benutzer mit einem Konto) auf die “Owners” des Kontos. Diese Bezeichnung stellt das höchste und privilegierteste Element des RBAC (Role-Based Access Control) dar. Alle weiteren Daten innerhalb des Lokad-Kontos können anhand einer benutzerdefinierten Sensitivitätsklassifizierung segmentiert werden. Diese Klassifizierung kann sowohl auf die Originaldaten (wie vom Kunden hochgeladen) als auch auf die transformierten Daten (als Ergebnis von Datentransformationen innerhalb der Lokad-Plattform) angewendet werden.

Für weitere Informationen zu Zugriffskontrollen und Bezeichnungen siehe bitte die Antworten 3.1, 3.2 und 3.3.

3.6 Kann die Lösung Benutzer/Rollen/Transaktionen in Echtzeit autorisieren oder blockieren?

Ja, allerdings bedarf der Begriff “in Echtzeit” im Kontext eines verteilten Computersystems (wie der Lokad-Lösung) einer Klarstellung. Aktualisierungen im RBAC (Role-Based Access Control) erfolgen synchron, das heißt, die Änderungen werden innerhalb weniger Sekunden (in der Regel weniger) aktiv. Es gibt keine spürbaren Verzögerungen (wie beispielsweise eine Wartezeit von einer Stunde oder einem Tag).

Was das Unterbrechen von Transaktionen betrifft, ist dies nicht relevant, da Lokad keine transaktionale Datenbank besitzt. Allerdings kann Lokad lang andauernde asynchrone Operationen (bei Lokad als “Project runs” bezeichnet) unterbrechen. Wenn eine Unterbrechung ausgelöst wird, stellt dies sofort (synchron) sicher, dass die Verarbeitung das System nicht beeinträchtigt, etwa durch Überschreiben von Dateien. Das Anhalten der Verarbeitung erfolgt jedoch asynchron und tritt in der Regel innerhalb von 20 Sekunden in Kraft.

3.7 Beschränkt die Lösung den Zugriff auf personenbezogene Daten (PII) ausschließlich auf Benutzer mit der entsprechenden Berechtigung?

Ja, obwohl die Lösung nicht dazu gedacht ist, irgendwelche PII-Daten zu speichern (abgesehen von den Authentifizierungskennungen der Mitarbeiter, die Zugriff auf die Lösung haben). Dies gilt sowohl für Lokad als auch für den Kunden. Innerhalb der Lösung haben nur Mitarbeiter mit der Bezeichnung “Owner” Zugriff auf die Benutzerliste. Für Zwecke der supply chain-Optimierung benötigt Lokad PII-Daten nicht (noch profitiert es davon), und wir haben vertragliche Bestimmungen in dieser Hinsicht (erklärt in Practices 1.4 & Practices 1.5).

Weitere Informationen zu Zugriffskontrollen und Bezeichnungen finden Sie in den Antworten 3.1, 3.2 und 3.3.

3.8 Erlaubt die Lösung, dass Suchfilter für personenbezogene Daten (PII) Wildcard-Suchen ausschließen?

Ja. Allerdings kann ein Benutzer mit der Bezeichnung “Owner” innerhalb eines Lokad-Kontos auf alle Benutzer zugreifen (einschließlich des Kundenpersonals), die berechtigt sind, auf das Konto zuzugreifen. Lokad kann diese Fähigkeit nicht einschränken, da unsere Kunden in vollem Umfang die Liste der Benutzer auf ihrem eigenen Konto überprüfen müssen.

3.9 Ist das System mit WAF (Web Application Firewall) Technologie ausgestattet?

Nein. WAF ist ein von Natur aus gefährliches Design, da es das Sicherheitsprinzip der “minimalen Berechtigung” verletzt: Eine Komponente erhält enorme Privilegien, um als “man in the middle” zu agieren. Dies macht die WAF selbst zu einem wichtigen Ziel für Angreifer und vergrößert die Angriffsfläche der Plattform erheblich. Lokad überwacht jedoch seinen Webverkehr und ungewöhnliche Benutzerverhalten auf unserer eigenen Plattform genau. Diese Fähigkeiten sind jedoch Teil der Plattform selbst und werden daher nicht an isolierte, privilegierte Drittanbietersoftwarekomponenten delegiert.

Siehe auch Employees 6.6.

3.10 Ist das Netzwerk mit IPS (Intrusion Prevention System) Technologie ausgestattet?

Nein. IPS ist ein von Natur aus gefährliches Design, da es das Sicherheitsprinzip der “minimalen Berechtigung” verletzt: Eine Komponente erhält enorme Privilegien, um als “man in the middle” zu agieren. Dadurch wird IPS selbst zu einem Hauptziel für Angreifer und vergrößert die Angriffsfläche der Plattform erheblich. Um die Lokad-Plattform gegen Eindringversuche zu härten, beginnt unser Design damit, die Angriffsfläche zu minimieren. Wir sind der Meinung, dass es viel sicherer ist, Einbruchsmöglichkeiten von vornherein auszuschließen, anstatt zu versuchen, diese nachträglich zu „verhindern“.

Siehe auch Employees 6.6.

3.11 Nutzt der Dienst DoS (Denial-of-Service) Schutztechnologie?

Ja. Lokad nutzt ReCaptcha, nginx-Rate-Limits und eigene spezifische Komponenten (wie z. B. frühzeitiges Scheitern, wenn die Authentifizierung ungültig ist).

3.12 Wird der gesamte administrative Zugriff auf die Produktionsumgebung über Jump Hosts oder Bastion-Server durchgeführt?

Ja. Wir haben ein System, das im Wesentlichen “Teleport” ähnelt. Dieses bietet nicht nur vollständige Nachvollziehbarkeit aller Zugriffe, sondern erleichtert auch den sicheren Entzug von Zugriffsrechten für Mitarbeiter.

3.13 Gibt es einen klaren Autorisierungsprozess zur Gewährung administrativer Zugriffe (und einen, der eine zuverlässige Prüfspur erzeugt)?

Ja. Siehe Logging and Monitoring 5.1 und 5.11.

3.14 Gibt es einen systematischen und regelmäßigen Überprüfungsprozess der Zugriffsrechte (durchgeführt von einer autorisierten Person), bei dem administrative Zugriffsrechte mit allen geänderten Rollen und Aufgaben abgeglichen werden?

Ja. Es gibt zwei Ebenen administrativer Zugriffsrechte.

Erste Ebene: die administrativen Rechte zur Unterstützung der Infrastruktur von Lokad. Diese Rechte werden von der IT-Abteilung von Lokad vergeben und überwacht.

Zweite Ebene: die administrativen Zugriffsrechte innerhalb jedes Lokad-Kontos. Diese Rechte werden vom Supply Chain Scientist, der für das Konto verantwortlich ist, vergeben und überwacht – für unsere verwalteten Konten. Alternativ werden diese Rechte vom Kundenunternehmen selbst vergeben und überwacht, wenn das Konto nicht direkt von Lokad/einem Supply Chain Scientist verwaltet wird.

3.15 Folgt Ihre Zugriffsbeschränkungspolitik dem Prinzip der “minimalen Berechtigung”, bei dem nur der notwendige und genehmigte Datenverkehr zugelassen wird?

Ja. Wir wenden das Prinzip der minimalen Berechtigung (PoLP) auf alle Zugriffsebenen unserer Infrastruktur an, einschließlich des Netzwerkverkehrs. Der Grad der Zugangsbeschränkungen variiert je nach Anwendungsfall. So ist beispielsweise für manche Zugriffe nur ein spezifischer, authentifizierter Benutzer von einer bestimmten IP-Adresse zugelassen. In anderen Szenarien kann von überall auf den Inhalt zugegriffen werden, wie es bei unserem CDN (Content Delivery Network) der Fall ist.

Siehe auch Authorization 3.3.

3.16 Sind ausgehende Verbindungen aus der Produktionsumgebung eingeschränkt?

Nein, ausgehende Verbindungen aus der Produktionsumgebung sind nicht allgemein eingeschränkt. Zwar haben einige spezialisierte Server, wie Load Balancer, ausgehende Einschränkungen, aber die Mehrheit unserer Server nicht.

Unsere Produktions-VMs benötigen den Zugriff auf mehrere externe APIs. Ein großer Teil dieser APIs wird von Microsoft Azure gehostet, mit einigen Ausnahmen wie letsencrypt.org. Wir haben festgestellt, dass das Führen einer strengen Whitelist von IP-Adressen Komplexitäten mit sich bringen würde, die die Vorteile aufwiegen könnten. Das Beschränken ausgehender Verbindungen mag zwar begrenzte Sicherheitsvorteile bieten, könnte aber auch Komplikationen einführen, die die Sicherheit unserer Produktionsumgebung potenziell untergraben.

3.17 Gibt es eine besetzte Kommunikationsmöglichkeit (z. B. E-Mail, Webformular, Telefon usw.), die Kunden/Klienten rund um die Uhr (24/7/365) zur Meldung von Sicherheitsvorfällen zur Verfügung steht?

Ja, wir haben den security.txt Standard implementiert, um die Meldung von Sicherheitsvorfällen zu erleichtern.

Der security.txt Ansatz ist ein weit verbreitetes Muster in der Websicherheit, bei dem eine spezifische Textdatei auf der Website platziert wird. Diese Textdatei erläutert, wie Sicherheitslücken gemeldet werden können.

Unsere security.txt Datei finden Sie unter https://www.lokad.com/.well-known/security.txt, und sie beschreibt den aktuellen Prozess zur Meldung von Sicherheitsvorfällen. Dies stellt sicher, dass jeder – sei es ein Kunde, Klient oder Sicherheitsforscher – leicht die entsprechenden Kontaktdaten und Richtlinien zur Meldung von Sicherheitsbedenken bei uns finden kann.

Bitte beachten Sie, dass der in der “security.txt” beschriebene Prozess überarbeitet werden kann, die aktuellsten und genauesten Informationen jedoch immer unter diesem Endpunkt verfügbar sein werden. Wir stellen sicher, dass die in der Datei genannten Kommunikationskanäle, sei es E-Mail, Webformular oder ein anderes Medium, besetzt sind und 24/7/365 zur schnellen Bearbeitung von Sicherheitsmeldungen zur Verfügung stehen.

4. Datenverwaltung

4.1 Wo hosten und verarbeiten Sie die Daten?

Unsere SaaS (Software as a Service) Plattform wird zu 100% auf Microsoft Azure gehostet; genauer gesagt, befindet sie sich im Microsoft Azure Rechenzentrum Europe North (mit Sitz in Dublin). Unsere Backups werden im Microsoft Azure Rechenzentrum Europe West (mit Sitz in Amsterdam) gespeichert. Im Falle eines größeren Rechenzentrumsausfalls haben wir Notfallpläne, um die Plattform nach Dublin zu migrieren. Seit unserer Migration zu Microsoft Azure im Jahr 2010 sind wir noch nie mit dieser Situation konfrontiert worden. Alle Daten unserer Kunden befinden sich in Europa und werden dies auch im Falle eines größeren Rechenzentrumsausfalls bleiben.

4.2 Wem gehören die Daten?

Unsere Kunden bleiben die alleinigen Eigentümer aller Daten, die sie zu Lokad hochladen. Unsere Kunden bleiben auch die alleinigen Eigentümer aller Daten, die sie über ihr Lokad-Konto auf der Lokad-Plattform generieren. Lokad verwendet die Daten der Kunden intern nicht für andere Zwecke, außer für jene, die direkt zu den Aufgaben beitragen, die unsere Kunden uns übertragen haben. Lokad verkauft keinen Zugang zu den Daten unserer Kunden an Dritte. Lokad teilt den Zugang zu Kundendaten nicht, außer mit den wenigen Hosting-Anbietern, die direkt zu der jeweiligen Aufgabe beitragen (z. B. durch das Mieten virtueller Maschinen von einer Cloud-Computing-Plattform, um die Berechnungen wie von unseren Kunden angefordert auszuführen).

4.3 Wird das Datenbankmanagement intern oder extern durchgeführt?

Das Datenmanagement der Lokad-Lösung wird von den Engineering-Teams von Lokad durchgeführt. Wie bereits erwähnt, beinhaltet die Kernplattform von Lokad keine transaktionale Datenbank (siehe Authorization 3.6), da stattdessen ein Event-Store verwendet wird. Dieser Event-Store wird vollständig von Lokad implementiert und betrieben.

4.4 Verfügt die Lösung über die Möglichkeit, zwischen einer RDBMS-Datenbank (PostgreSQL, Oracle, MySQL) und einer NoSQL-Datenbank (Cosmos) zu wechseln?

Theoretisch ja, aber dies ist hinfällig, da die Lokad-Lösung keine RDBMS verwendet. Die Datenspeicherungsschicht der Lokad-Lösung nutzt einen Event-Store und einen Key-Value-Store. Dieser Ansatz unterscheidet sich erheblich vom CRUD-Design (Create-Read-Update-Delete), wie es in Unternehmenssoftware üblich ist. Da Lokad eine SaaS-Lösung ist, übernehmen wir die volle Verantwortung für die Datenspeicherung und die zukunftsgerichtete Kompatibilität (um sicherzustellen, dass ältere Daten zugänglich bleiben).

4.5 Sind Dritte an der Ausführung der Lösung beteiligt?

Ja, insbesondere die zugrunde liegende Cloud-Computing-Plattform, die Lokad verwendet – Microsoft Azure. Die Liste der Dritten, die an der Ausführung der Lösung beteiligt sind, ist sehr kurz und beschränkt sich auf die Infrastruktur auf niedriger Ebene. Lokad nutzt keine Dritten zur Entwicklung, Administration oder zum Betrieb der eigenen Lösung. Insbesondere sind sowohl unsere Engineering-Teams als auch unser technischer Support intern.

4.6 Trennen Sie die Schichten (Netzwerke, Server und Anwendungen)?

Ja, jedoch wird das Management der Netzwerke und Server auf niedriger Ebene der zugrunde liegenden Cloud-Computing-Plattform, die Lokad verwendet – Microsoft Azure – delegiert. Daher liegt die Trennung der Netzwerk- und Server-Schichten größtenteils außerhalb des von Lokad verwalteten Bereichs. Innerhalb der Lokad-Lösung schränken wir die Privilegien der Anwendungsschichten jedoch streng ein, sodass diese ihre eigene Infrastruktur nicht administrieren können (z. B. haben die Anwendungsschichten keinen Schreibzugriff auf das DNS-Management).

4.7 Haben Sie einen Prozess, der die dauerhafte Löschung von Daten sicherstellt?

Ja, obwohl es mehrere Wochen dauern kann, bis alle Schritte abgeschlossen sind. Der Prozess umfasst die Erstellung einer formellen schriftlichen Anfrage – gestellt von einer autorisierten Person innerhalb der Kundenorganisation – um die entsprechenden Daten dauerhaft löschen zu lassen. In der Praxis sind spezifische Bestimmungen für solche Anfragen im Vertragsabkommen zwischen Lokad und seinen Kunden enthalten. Die Daten werden zunächst aus unserem primären Produktionssystem und anschließend aus unserem Backup-System gelöscht. Letzterer Schritt ist der Grund für die relative “Langsamkeit” der Operation. Dies ist eine Designentscheidung, da die Daten, sobald sie aus unserem primären System gelöscht wurden, nicht mehr zugänglich sind (außer über außergewöhnliche Notfallwiederherstellungsprozesse).

Standardmäßig stellt die Lokad-Lösung sicher, dass alle Standard-Löschoperationen Soft Deletes sind (d. h. keine dauerhaften Löschungen). Dieses Design ist notwendig, um ganze Klassen von Sicherheitsproblemen zu vermeiden, wie etwa das versehentliche Löschen von Daten durch einen Mitarbeiter des Kunden oder das böswillige Löschen durch einen Angreifer. Außerdem ist ein absichtlich langsamer Prozess zur dauerhaften Löschung erforderlich, um Social-Engineering-Angriffe zu entschärfen, wie zum Beispiel in einem Szenario, in dem ein Angreifer einen Mitarbeiter eines Kunden imitiert.

4.8 Verfügt die Lösung über die Möglichkeit, Daten soft zu löschen?

Ja. Die Lokad-Lösung verwendet ein Event-Sourcing-Design. Dadurch ist standardmäßig alles versioniert, sowohl die Benutzereinträge als auch die Änderungen am Dateisystem von Lokad. Somit sind alle softwareseitigen Löschvorgänge Soft Deletes, die nachvollzogen und bei Bedarf rückgängig gemacht werden können.

4.9 Bieten Sie direkten Datenbankzugriff an?

Ja, insofern als dass auf das Dateisystem – einen Teil der Lokad-Lösung – über Protokolle wie FTPS und SFTP zugegriffen werden kann. Dieser Zugriff ist umfassend, da alle Daten, die entweder als Eingaben verwendet oder als Ausgaben erzeugt werden, in diesem Dateisystem gespeichert sind.

Da Lokad jedoch keine transaktionale Datenbank besitzt, gibt es keine zugrundeliegende Datenbank, die “zugänglich” gemacht werden könnte. Das nächstliegende Äquivalent in der Lokad-Architektur ist unser Event-Store, und wir bieten keinen direkten Zugriff auf den Event-Stream an. Allerdings könnten vertragliche Vereinbarungen getroffen werden, falls ein Kunde spezifische Extraktionen aus diesem Event-Stream anfordert (vorausgesetzt, es liegt ein gültiger Anwendungsfall vor).

4.10. Wie integriert die Lösung externe Daten?

Die Lösung kann mehrere Protokolle zur Integration externer Daten nutzen, insbesondere FTPS und SFTP. Eine Web-Benutzeroberfläche steht ebenfalls zur Verfügung, um Dateien manuell hochzuladen. Die Lokad-Lösung kann alle vernünftig tabellarischen Daten integrieren. Weitere Informationen zu den externen Datenintegrationsfähigkeiten von Lokad finden Sie unter Go to IT Perspective on Lokad 2.15.

4.11 Verfügt das System über die Fähigkeit, Change Data Capture (CDC) aus Echtzeit-Datenströmen zu verarbeiten?

Ja, sofern eine spezifische vertragliche Vereinbarung mit dem Kunden besteht. Change Data Capture ist ein Software-Design-Muster – kein spezifischer Datenstandard oder Datentransferprotokoll – und die Erwartungen an “Echtzeit” können von Sub-Millisekunden-Latenzen bis zu Sub-Minuten reichen. Funktionen in diesem Bereich müssen aus supply chain Perspektive bewertet werden. Nach unserer Erfahrung sind Echtzeit-Datenströme selten relevant, um supply chain Probleme anzugehen.

4.12 Können alle Daten innerhalb der Lösung exportiert werden?

Ja, alle über das Dateisystem innerhalb des Lokad-Kontos zugänglichen Daten können über Protokolle wie FTPS oder SFTP exportiert werden.

4.13 Bietet die Lösung Werkzeuge zum Exportieren von Daten?

Ja, die Lokad-Lösung bietet eine DSL (domänenspezifische Sprache) namens Envision, die speziell für Supply Chain Analytics entwickelt wurde. Envision bietet umfangreiche Möglichkeiten, die Daten innerhalb des Lokad-Kontos neu zu formatieren.

4.14 Welches Format haben die exportierten Daten?

Die Lokad-Plattform unterstützt alle gängigen tabellarischen Formate, einschließlich CSV und XLS (Microsoft Excel). Die Plattform bietet zahlreiche Optionen hinsichtlich des Formats von Zahlen, Daten, Trennzeichen, Textkodierung, Headern usw.

4.15 Verfügt die Lösung über eine Transparent Data Encryption (TDE) für personenbezogene Daten (PII) in mobiler und Backend-Speicherung?

Transparente Datenverschlüsselung wird sowohl im Backend-Speicher von Lokad (durch Azure Storage-Verschlüsselung für ruhende Daten) als auch auf von Lokad bereitgestellten Geräten (durch BitLocker) verwendet. Lokad speichert keine PII auf Geräten, bei denen TDE nicht aktiviert ist.

4.16 Sind alle Passwörter und Geheimnisse, die in der Anwendung verwendet werden, verschlüsselt und nicht im Klartext im Quellcode, in Konfigurationsdateien, Build-Parametern usw. zugänglich?

Ja. Alle plattformbezogenen Geheimnisse werden in Key Vault gespeichert, einem von Microsoft Azure angebotenen Dienst. Die Benutzerpasswörter werden intern mit Salz versehen und gemäß Standardpraktiken mit Scrypt gehasht.

4.17 Verfügt die Lösung über die Fähigkeit, Datei-Uploads basierend auf Dateityp und Größe einzuschränken und nach bösartigem Inhalt zu scannen?

Ja, in gewissem Umfang. Bezüglich der Dateigröße erfordert die Supply Chain Optimierung häufig die Verarbeitung großer Dateien. Diese Dateigrößen spiegeln die Extraktion der historischen Geschäftsdaten wider, die wir letztlich verarbeiten (z. B. historische Verkaufsaufträge). Angesichts dieser Realität unterstützt die Lokad-Plattform Dateigrößen von bis zu 100GB.

Bezüglich des Dateityps haben wir eine Whitelist bekannter Erweiterungen und erwarteter Formate. Im Falle eines gültigen Anwendungsfalls könnte dieser Parameter angepasst werden. Diese Anpassung würde in unserer vertraglichen Vereinbarung berücksichtigt.

Bezüglich der Fähigkeit, nach bösartigem Inhalt zu scannen, verfügt Lokad nicht über diese Funktion. Unsere Lösung legt den Schwerpunkt auf das Teilen von plattform-generierten Inhalten. Darüber hinaus stellt das von uns gewählte Design sicher, dass die innerhalb von Lokad erzeugten Dateien sicher sind, selbst wenn die Eingabedateien es nicht sind. Im Gegenteil, durch sein Design wird das Teilen von von Nutzern hochgeladenen Inhalten über Lokad entwertet.

4.18 Was ist der empfohlene Aufbewahrungszeitraum für Daten?

Lokad ist SaaS, daher tragen wir die Verantwortung, den geeigneten Aufbewahrungszeitraum für Daten zu wählen, und diese Dauer variiert je nach Datentyp. Transaktionale historische Daten, die vom Kunden über die Datenextraktions-Pipeline an Lokad übermittelt werden, werden typischerweise für die Dauer des Lokad-Dienstes aufbewahrt. Tatsächlich lohnt es sich in der Regel, historische Daten über beliebig lange Zeiträume aufzubewahren (außerhalb der Grenzen des Lokad-Dienstes). Am anderen Ende des Spektrums stehen die Instrumentierungsdaten, die die feinkörnige Leistung unserer Plattform widerspiegeln. Diese Daten sind nur nützlich, um unerwartete Verlangsamungen innerhalb der Plattform zu beheben. Diese Daten sind äußerst detailliert und werden in der Regel nicht länger als einige Wochen aufbewahrt.

4.19 Stellen Sie eine Dokumentation der Datenstruktur zur Verfügung?

Ja, als Teil des “Joint Procedure Manual”. Es sei darauf hingewiesen, dass Lokad, im Gegensatz zu den meisten Unternehmenssoftwares, keine relationale Datenbank verwendet. Stattdessen nutzen wir ein Event-Sourcing-Paradigma. Die interessierenden Datenstrukturen (für das Kundenunternehmen) befinden sich jedoch nicht im Event Store, sondern in den Flat Files, die durch Envision-Skripte innerhalb der Lokad-Plattform erzeugt werden. Diese Flat Files sind so konzipiert, dass sie den spezifischen Anforderungen des Kundenunternehmens entsprechen. Die Dokumentation dieser Dateien ist im “Joint Procedure Manual” enthalten – eines der Ergebnisse einer typischen Lokad-Initiative.

4.20 Ist die Segmentierung von Daten anderer Kunden Teil des Systemdesigns?

Ja, obwohl Lokad eine Multi-Tenant-Anwendung ist, werden die Daten bereits auf Design-Ebene zwischen den Tenants, d. h. Kundenkonten, getrennt. Diese Partitionierung ist ein zentrales Element unseres Backend-Designs. Dieses Design verhindert Programmierfehler, die dazu führen könnten, dass die Daten eines Tenants einem anderen Tenant zugänglich gemacht werden, während alltägliche Funktionen innerhalb der Plattform weiterentwickelt werden. Der primäre zugrunde liegende Speicher, den Lokad verwendet – Blob Storage von Microsoft Azure – ermöglicht diese Art von strikter Partitionierung auf Design-Ebene.

4.21 Werden effektive Maßnahmen ergriffen, um sicherzustellen, dass keine Kundendaten in Entwicklungs- und Testumgebungen verwendet werden?

Ja, standardmäßig hat das Software-Engineering-Team keinen direkten Zugriff auf Kundendaten. Wir haben umfangreiche “Mock”-Datenumgebungen und “Mock”-Datensätze entwickelt, damit das Software-Engineering-Team reibungslos arbeiten kann, ohne Zugriff auf Kundendaten zu haben. Lokad nutzt intern auch seine eigene Plattform für Datenauswertungszwecke (z. B. zur Analyse des feinkörnigen Verbrauchs von Cloud-Computing-Ressourcen, die von Microsoft Azure bezogen werden). Diese “Dogfooding”-Praxis stellt sicher, dass Lokad auch über einen reichlichen Vorrat nicht-kritischer Daten für Entwicklungs- und Testzwecke verfügt.

Allerdings haben wir eine spezielle, eingeschränkte Pipeline entwickelt, um für Diagnosezwecke minimale (nur lesbare) Fragmente von Kundendaten zuzugreifen. Diese Pipeline gewährleistet automatisch eine strikte und vollautomatisierte Minimierung der abgerufenen Daten. Außerdem sorgt diese Pipeline automatisch für die Löschung der Daten am Ende des Diagnosevorgangs. Siehe 4.22 für weitere Details zu dieser eingeschränkten Pipeline.

4.22 Falls die Entwicklung oder das Testen einen begrenzten Einsatz von Kundendaten erfordert, gibt es einen definierten Prozess, um die sichere und vollständige Vernichtung der Daten in Entwicklungs- und Testumgebungen zu gewährleisten?

Ja, wir haben eine spezielle (nur lesbare) Datenpipeline entwickelt, die für die Ausnahmeverwendung von Kundendaten zu Diagnosezwecken – in der Regel für Leistungstests – vorgesehen ist. Diese Datenpipeline ist nur für einen eingeschränkten Teil des Software-Engineering-Teams zugänglich.

Diese Datenpipeline wurde so entwickelt, dass sie automatisch das Fragment der Kundendaten minimiert, das für die jeweilige Diagnose abgerufen wird. Diese Fähigkeit ermöglicht es uns, mit dem zu arbeiten, was typischerweise nur einen sehr kleinen Bruchteil der ursprünglichen Daten (wie im Kundenkonto vorhanden) ausmacht. Darüber hinaus entfällt für das Engineering-Team die Notwendigkeit, manuell auszuwählen, welche Daten abgerufen werden sollen.

Abschließend löscht diese Datenpipeline die abgerufenen Daten automatisch am Ende des Diagnosevorgangs.

4.23 Sind alle physischen Standorte der Kundendaten bekannt und dokumentiert, einschließlich Backup- und Hochverfügbarkeits-Systeme?

Ja. Alle Kundendaten werden in den physisch gesicherten Rechenzentren von Microsoft Azure, einschließlich Backups, gespeichert. Wir speichern Kundendaten nicht lokal (d. h. auf Lokads Gelände) und auch nicht auf den Geräten der Mitarbeiter.

4.24 Ist der Zugang zu physischen Serverstandorten auf Mitarbeiter beschränkt, die diesen Zugang zur Ausführung ihrer Arbeit benötigen?

Ja, wenngleich die Daten der Lokad-Kunden in den sicheren Rechenzentren von Microsoft Azure gespeichert werden – einem Standort, zu dem Lokad keinen physischen Zugang hat. Die Standorte der Microsoft-Rechenzentren sind öffentlich bekannt, und die Wahl der Rechenzentren durch Lokad ist öffentlich dokumentiert.

4.25 Wird die Primary Account Number (PAN) nur gespeichert, wenn sie für legitime Geschäftszwecke unbedingt erforderlich ist?

Lokad empfängt, speichert oder verwaltet keine Kunden-PANs.

Die PAN (Primary Account Number) bezieht sich in der Regel auf die Hauptnummer einer Kredit- oder Debitkarte. Es ist die Zahlenfolge, die auf der Vorderseite einer Karte geprägt oder gedruckt ist und zur eindeutigen Identifizierung des mit der Karte verknüpften Bankkontos verwendet wird.

Um Zahlungen abzuwickeln, verlassen wir uns ausschließlich auf Drittparteien, die die PANs für uns verwalten. Es ist jedoch zu beachten, dass die Mehrheit der von Lokad empfangenen Transaktionen per Überweisung ausgeführt wird, wodurch das Problem der Verwaltung von PANs vollständig ausgeschlossen wird.

Wir haben einige PANs – für die eigenen Karten von Lokad – die wir sicher verwalten, gemäß den Vorgaben der Banken.

4.26 Werden unverschlüsselte Primary Account Numbers (PANs) niemals über Endnutzer-Messaging-Technologien (zum Beispiel: per E-Mail, Instant Messaging und Chat) versendet?

Ja, unverschlüsselte PANs (Primary Account Numbers) werden niemals über unsichere Kanäle wie E-Mail versendet. Lokad stellt auf seiner Plattform einen integrierten sicheren Kommunikationskanal zur Verfügung, der eine überlegene Alternative zur Übertragung sensibler Materialien darstellt. Wir empfehlen diesen Kanal, wann immer die Nutzung eines unsicheren Kanals ein erhebliches Geschäftsrisiko darstellt.

Hinweis: Durch Design empfängt, speichert oder verwaltet Lokad keine Kunden-PANs. Daher gibt es keine unverschlüsselten PAN-Übertragungen.

Siehe auch die Speicherung von PANs

4.27 Haben Sie einen Vertrag mit Ihrem Cloud-Computing-Dienstleister bzw. Ihren Cloud-Computing-Dienstleistern, und enthält dieser Vertrag Klauseln bezüglich der Informationssicherheitsvorkehrungen des Cloud-Dienstleisters?

Ja, Lokad hat mit Microsoft für Azure-Cloud-Computing-Dienste einen Enterprise Agreement (EA) abgeschlossen. Das Enterprise Agreement umfasst in der Regel verschiedene Geschäftsbedingungen in Bezug auf die Nutzung der Dienste, einschließlich Zusagen zur Sicherheit der Cloud-Umgebung.

Microsoft Azure legt als einer der führenden Cloud-Dienstleister großen Wert auf Sicherheit. Azure verfügt über ein umfassendes Set an Sicherheitsfunktionen und -praktiken zum Schutz von Daten in der Cloud, die oft in den vertraglichen Vereinbarungen mit Unternehmenskunden zum Ausdruck kommen.

Obwohl wir die spezifischen Details unserer vertraglichen Vereinbarung nicht öffentlich preisgeben können, sind wir nach mehr als einem Jahrzehnt der Zusammenarbeit mit Microsoft überzeugt, dass diese Vereinbarung unseren Sicherheitsanforderungen und -standards entspricht.

4.28 Sind Subunternehmer in die Verarbeitung der Kundendetails/-daten eingebunden?

Nein, Lokad vergibt die Verarbeitung von Kundendetails oder -daten nicht an Subunternehmer. Bezüglich der Lokad-Plattform kaufen wir Rechenressourcen – hauptsächlich virtuelle Maschinen und Blob-Speicher – von Microsoft Azure, aber darüber hinaus sind keine Dritten in Bezug auf Kundendaten involviert.

Was die Erbringung der professionellen Dienstleistungen von Lokad betrifft, so erhalten nur festangestellte Lokad-Mitarbeiter (in diesem Fall die Supply Chain Scientists) Zugriff auf Kundendetails oder -daten. Lokad hat gelegentlich einige Praktikanten (wenn auch deutlich weniger als bei den meisten vergleichbaren Unternehmen) für langfristige Praktika, aber sie arbeiten unter der direkten und strengen Aufsicht eines Senior Supply Chain Scientist.

Hinweis: Praktikanten unterliegen denselben Vertraulichkeitsvereinbarungen wie festangestellte Supply Chain Scientists.

5. Protokollierung und Überwachung

5.1 Bieten Sie Zugriffsprotokolle an (Benutzer, Datum, letztes Verbindungsdatum usw.)?

Ja. Lokad stellt Zugriffsprotokolle als CSV-Dateien zur Verfügung. Derzeit können diese Protokolle beim Lokad-Support angefordert werden. Die Protokollauswertung wird im Lokad-Konto an einem Ort abgelegt, der nur für Benutzer mit der Bezeichnung “Owner” zugänglich ist. Wir planen, eine direktere Zugriffsmöglichkeit – über eine dedizierte Web-Oberfläche – für die vollständige Prüfspur einzuführen, die bereits im Backend der Lokad-Plattform existiert.

5.2 Zentralisieren Sie die Protokolle aller Komponenten in der Lösung?

Ja. Das Event Sourcing-Design von Lokad zentralisiert nicht nur die Protokolle, sondern alle Zustandsänderungen, die in der Lösung auftreten. Die Protokolle, zusammen mit anderen Zustandsänderungen, werden in einer kleinen Sammlung von Event-Streams zentralisiert, die vom gleichen Event Store verwaltet werden. Intern werden die Protokolle, die den Zustand der Lösung nicht beeinflussen, von denen getrennt, die dies tun.

Aus rein technischer Sicht gibt es einige leistungsbezogene Protokolle, die absichtlich nicht im Event Store zentralisiert werden. Diese Protokolle beinhalten feinkörnige Leistungsmaße, wie sie von Lokads interner Performance-Profiling-Instrumentierung erzeugt werden (z. B. wie viele Millisekunden für jeden Funktionsaufruf während der Ausführung eines Envision-Skripts aufgewendet werden). Diese Leistungsprotokolle enthalten nichts, was als “sicherheitsrelevantes” Material einzustufen ist.

5.3 Protokollieren Sie Änderungen und Vorgänge in der Anwendung? Verfolgen Sie alle Transaktionen?

Ja. Aufgrund des Event Sourcing-Designs von Lokad wird alles notwendigerweise protokolliert. Tatsächlich ist die Lösung selbst die Summe der in der Lösung aufgezeichneten Ereignisse. Daher ist die Protokollierung ein grundlegender Aspekt der Architektur der Lösung. Dieses Event Sourcing-Design verhindert das versehentliche Weglassen eines Protokolls, das eine Zustandsänderung widerspiegelt. In einem solchen Event Sourcing-Framework gibt es keine Transaktionen, zumindest nicht im üblichen Sinne einer transaktionalen Datenbank (z. B. MySQL, Oracle usw.). Diese Transaktionen werden durch Ereignisse ersetzt, die alle mit einer Zustandsänderung verbundenen Informationen enthalten.

5.4 Normalisieren Sie die Protokollformate der verschiedenen Komponenten zu forensischen Zwecken?

Ja. Die “Logs” sind aus einer Prüf- und/oder Sicherheits-Perspektive die Umwandlungen der zugrunde liegenden Ereignisse. Die Ereignisse sind technisch serialisierte Objekte. Um Protokolle zu erhalten, konvertiert und kompiliert die Lokad-Lösung diese Ereignisse in CSV-Dateien. Wir normalisieren Datumsformate, Zahlenformate und Benutzerkennungen, die bei der CSV-Auswertung verwendet werden.

5.5 Bieten Sie Log-Exporte an Dritte über ein Abfrageprotokoll an?

Ja, im Rahmen einer vertraglichen Vereinbarung mit dem Kunden.

5.6 Verfolgen Sie alle Ausnahmen, die in Ihrer Lösung auftreten?

Ja. Das Event Sourcing-Design von Lokad ermöglicht es uns, alle in unserer Lösung auftretenden Ausnahmen zu verfolgen und die Bedingungen, die zur Entstehung des Problems geführt haben, reproduzieren zu können. Sobald diese identifiziert wurden, beseitigt das Lokad-Engineering-Team alle festgestellten Ausnahmen. Wir haben spezielle Tools für diesen Zweck entwickelt und führen eine sehr begrenzte Liste ungelöster Ausnahmen.

5.7 Verfügt die Lösung über die Fähigkeit, die Gesundheit der verschiedenen Komponenten/Dienste in Echtzeit zu überwachen?

Ja. Unsere Subsysteme wurden mit Monitoring-Endpunkten für Gesundheitsprüfungen entwickelt. Wir verfügen über Monitoring-Tools, die – ab Januar 2023 – ausschließlich den Engineering-Teams von Lokad zugänglich sind und kontinuierlich die von diesen Monitoring-Endpunkten bereitgestellten Informationen konsolidieren.

Wie bereits erwähnt, ist “in Echtzeit” bei verteilten Systemen ein recht vager Begriff. Für Zwecke der Systemgesundheitsüberwachung liegt die erwartete Latenz in etwa zwischen wenigen Sekunden und einer Minute.

5.8 Verfügt die Lösung über die Fähigkeit, Überwachungstools von Drittanbietern zu integrieren? Unterstützt die Lösung SNMP oder JMX oder die Möglichkeit, SNMP- und JMX-Ereignisse an Überwachungslösungen von Drittanbietern zu senden?

Ja, im Rahmen einer dedizierten vertraglichen Vereinbarung.

5.9 Verfügt die Lösung über die Möglichkeit, Batch-Jobs zu überwachen, die nicht planmäßig gestartet wurden, und deren Beendigung zu überwachen?

Ja. Die Lokad-Lösung verfügt über einen eigenen internen Job-Scheduler (genannt “Runflow”), der lang laufende Aufgaben innerhalb der Lokad-Plattform orchestriert – typischerweise die Ausführung von Envision-Skripten. Dieser Scheduler kann über eine Web-Benutzeroberfläche konfiguriert werden, um einen Zeitplan und einen Ausführungszeitrahmen für jede Job-Sequenz festzulegen.

5.10 Verfügt die Lösung über die Fähigkeit, proaktive Warnungen zu erzeugen? Besitzt sie die Fähigkeit, Fehler zu korrelieren und zu analysieren, um dann proaktive Maßnahmen zu ergreifen?

Ja. Runflow, der Job-Scheduler der Lösung, kann den Kunden/Lokad darüber informieren, dass eine laufende Ausführungssequenz sich verspätet. Die Warnung kann noch vor Abschluss der Sequenz gesendet werden. Die Lokad-Lösung bietet umfangreiche Möglichkeiten über Envision (seine DSL), um Situationen zu analysieren und selbst zu diagnostizieren, um proaktive Maßnahmen zu ergreifen. Obwohl die Lokad-Plattform diese Fähigkeit bereitstellt, erfordert es dennoch einen Ingenieur, der – über Envision – die eigentliche Logik implementiert, da die supply chain situations, die als “Fehler” gelten, variieren können.

5.11 Verfügt die Lösung über Möglichkeiten zur Aufbewahrung von Audit-Daten? Werden die Daten in einer MIS-Datenbank archiviert und bereinigt, um die Benutzeraktivität zu auditieren?

Ja. Durch sein Event-Sourcing-Design bewahrt die Lokad-Lösung eine umfangreiche Prüfspur auf; weit größer als das, was durch konventionellere Designs erzielt wird, die typischerweise eine transaktionale Datenbank anstelle eines Event-Stores nutzen. Die Lokad-Lösung isoliert kein Management Information System (MIS) als separates Subsystem. Tatsächlich ist der Ereignisstrom die Prüfspur. Allgemeiner behält Lokad die Produktionsdaten für die Dauer des Dienstes mit dem Kunden. Nach Beendigung des Dienstes, die von den vertraglich vereinbarten Bedingungen abhängt, werden die Kundendaten bereinigt, obwohl die endgültige Löschung im Backup-System einige Monate nach Vertragsende erfolgen kann.

5.12 Integriert Ihr System einen Selbstüberwachungsmechanismus (technisch und funktional)?

Ja, die Lokad-Plattform integriert mehrere Selbstüberwachungsmechanismen auf verschiedenen Ebenen.

Die cloud-gehostete Plattform wird von Lokads Software-Engineering-Teams überwacht. Da die Lokad-Plattform mandantenfähig ist, erfolgt diese Überwachung überwiegend mit einer “System”-Denkweise, die sicherstellt, dass die Fähigkeiten der Plattform (einschließlich ihres Leistungsprofils) den Standards entsprechen. Zu diesem Zweck haben wir unsere eigene Instrumentierungsschicht entwickelt. Die “funktionale” Überwachung ist in der Regel kundenspezifisch, da sie von den spezifischen Anforderungen der gegebenen supply chain abhängt. Diese Überwachung wird in der Regel von den Teams der supply chain scientists (den von Lokad bereitgestellten Ingenieuren) gemäß vertraglicher Vereinbarung durchgeführt.

Lokads supply chain scientists spezialisieren sich typischerweise auf eine bestimmte Klasse von Kundenkonten (z. B. Luft- und Raumfahrt). Sie entwickeln maßgeschneiderte Überwachungsinstrumente mithilfe des Lokad-Kontos. Diese Überwachung stellt sicher, dass die von Lokad gelieferten Zahlen korrekt sind, nicht nur im technischen Sinne, sondern auch aus der geschäftlichen Perspektive des Kunden.

5.13 Werden Protokolle zeitnah und systematisch überprüft und analysiert, um Anomalien und Hinweise auf Sicherheitsverletzungen zu erkennen?

Ja. Die Überprüfung der laufenden Aktivitäten der Lokad-Plattform gehört zu unserer täglichen Routine. Das Design unserer Plattform erleichtert diesen Prozess.

Siehe auch Logging and Monitoring 5.2.

5.14 Werden Log-Management-Systeme von Personen verwaltet, die nicht in die Administration der anderen Systeme eingebunden sind (d.h. Trennung der Aufgaben)?

Ja. Die Überwachung der Protokolle und der allgemeinen Aktivitäten der Plattform erfolgt durch Supply Chain Scientists, während die allgemeine Administration unserer Infrastruktur von bestimmten Mitarbeitern in unserer IT-Abteilung durchgeführt wird.

5.15 Werden Anwendungs-Level-Schwachstellenscans periodisch und systematisch durchgeführt?

Ja, obwohl solche Scans nur einen sehr kleinen Teil unserer Sicherheitsprozesse ausmachen. Siehe Employees 6.6.

5.16 Gibt es einen definierten Prozess für die periodische Überprüfung der wirksamen Firewall-Regeln?

Ja, unsere Produktionsmaschine arbeitet mit sehr strengen Regeln, wie der Öffnung einer sehr begrenzten Anzahl von Ports (konfiguriert über Microsoft Azure). Die Konfiguration unserer Infrastruktur erfolgt skriptbasiert, und ihre Weiterentwicklung folgt unserem üblichen Code-Review-Prozess. Diese Praxis erleichtert nicht nur die periodischen Überprüfungen, sondern verringert auch den Bedarf, die Regeln manuell zu überprüfen.

5.17 Ist das Netzwerk mit IDS (Intrusion Detection System)-Technologie ausgestattet?

Nein. IDS ist ein inhärent riskantes Design, da es das Sicherheitsprinzip des “Least Privilege” verletzt: Einer Komponente werden enorme Privilegien gewährt, um als “Man-in-the-Middle” zu agieren. Dies macht das IDS selbst zu einem bevorzugten Ziel für Angreifer und erweitert die Angriffsfläche der Plattform erheblich. Lokad überwacht jedoch seinen Webverkehr und abnormales Nutzerverhalten auf der eigenen Plattform genau. Diese Fähigkeiten sind Teil der Plattform und werden daher nicht privilegierten, isolierten Softwarekomponenten von Drittanbietern übertragen.

Siehe auch Employees 6.6.

6. Mitarbeiter

6.1 Haben die Mitarbeiter NDAs (Geheimhaltungsvereinbarungen)?

Ja, alle Lokad-Mitarbeiter unterliegen einer NDA-Klausel in ihren Arbeitsverträgen.

6.2 Nehmen die Mitarbeiter an Sicherheitsbewusstseins- und Sicherheitsschulungen teil?

Ja, Sicherheitsbewusstsein und Sicherheitsschulungen werden Lokad-Mitarbeitern angeboten, die mit vertraulichen Daten und/oder technischen Systemen in Kontakt stehen, die mit vertraulichen Daten in Berührung kommen. Für weitere Informationen zu diesem Punkt ist der Vortrag Cybersecurity for Supply Chain den supply chain scientists gewidmet – den Personen, die mit vertraulichen Kundendaten arbeiten.

6.3 Wer hat bei Lokad Zugang zu den Kundendaten?

Der Kunde definiert explizit eine Liste von Nutzern, die Zugang zu seinem Lokad-Konto haben. Diese Nutzer können, abhängig von ihren im Lokad-Konto konfigurierten Zugriffsrechten, Zugriff auf verschiedene Klassen der Kundendaten erhalten. Innerhalb der Lokad-Lösung gibt es eine Web-Anwendung, die der Verwaltung von Berechtigungen gewidmet ist (genannt “Hub”).

Auf Seiten von Lokad gibt es für jedes Kundenkonto eine kurze Liste von Mitarbeitern, die Zugang haben. An erster Stelle steht diese Liste der supply chain scientists (die von Lokad bereitgestellten Ingenieure), die die supply chain Optimierungslösung implementieren und warten. Von diesen supply chain scientists wird erwartet, dass sie täglich auf die Kundendaten zugreifen. Intern beschränkt Lokad den Zugriff auf Kundenkonten ausschließlich auf die supply chain scientists, die diesen Konten zugewiesen wurden. D.h., Supply Chain Scientist A kann nicht auf Kundenkonto B zugreifen, sofern A nicht explizit zur Verwaltung dieses Kontos zugewiesen wurde (wie mit dem Kunden vereinbart).

Zweitens enthält diese Liste das Engineering-Team, das für die Systemadministration unserer Plattform zuständig ist. Als Faustregel gilt, dass direkter Zugriff auf Kundendaten selten vorkommt und auf die Untersuchung von Situationen beschränkt ist, die entweder von den Kunden selbst oder von ihren unterstützenden supply chain scientists gemeldet werden. Lokad teilt den Zugang zu Kundendaten nicht mit Dritten, mit Ausnahme der Cloud-Computing-Plattform.

6.4 Wie sichern Sie die Arbeitsplätze der Mitarbeiter?

Abgesehen vom Software-Engineering-Team arbeiten Lokad-Mitarbeiter ohne administrative Privilegien auf den von der Firma bereitgestellten Geräten. Alle Arbeitsplätze sind mit einer Vollplattenverschlüsselung konfiguriert, um gegen Datendiebstahl zu schützen, der durch den Verlust, Diebstahl oder die Übergabe der Hardware an Dritte (z. B. für Reparaturen) entstehen könnte.

Die Arbeitsplätze unserer Mitarbeiter enthalten nicht die Daten unserer Kunden. Je nach Aufgabe kann ein Mitarbeiter einige Excel-Tabellen auf seinen Rechner herunterladen – beispielsweise für eine Präsentation –, aber unsere Richtlinie ist es, sämtliche Kundendaten strikt in der Cloud zu sichern.

6.5 Wie sichern Sie die Smartphones der Mitarbeiter?

Lokad-Mitarbeiter verfügen nicht über firmeneigene Smartphones. Unkritische Daten, wie Kalender-Erinnerungen, können über persönliche (nicht von der Firma ausgestellte) Geräte übertragen werden, aber Smartphones enthalten, wie auch Arbeitsplätze, nicht die Daten unserer Kunden.

6.6 Verwenden Sie ein Antivirenprogramm?

Ja, unsere Arbeitsplätze verfügen über Microsoft Defender, entsprechend der Microsoft Windows 10+ Konfigurationen. Wir verwenden kein anderes Antivirenprogramm neben Microsoft Defender, aber unserer Meinung nach richten diese Art von Tools oft mehr Schaden als Nutzen an (im Hinblick auf die Computersicherheit). Als anekdotischer Beweis gilt der SolarWinds-Hack von 2020 als eine der größten Katastrophen in der Computersicherheit aller Zeiten, verursacht durch eine Software, die eigentlich die Sicherheit verbessern sollte. Allgemein erfordern nahezu alle Softwareprodukte, die für Sicherheitszwecke bestimmt sind, sehr hohe Systemprivilegien. Infolgedessen werden diese Softwareprodukte zu eigenen Angriffsvektoren. Unsere Sichtweise in Bezug auf Computersicherheit ist, dass weniger mehr ist und dass das Hinzufügen sehr komplexer Technologien zu unserer Applikationslandschaft diese fast zwangsläufig weniger, nicht sicherer, macht.

6.7 Werden die Softwareentwickler regelmäßig darin geschult, Bedrohungsbewertungsmethoden, sichere Codierungsstandards, bekannte Sicherheits-Checklisten und Frameworks anzuwenden?

Ja. Allerdings spiegeln die meisten bekannten Checklisten vor allem Architekturen wider, die von Natur aus “unsicher” sind. Wann immer möglich, bevorzugen wir es, die Ursache für Sicherheitslücken bereits in der Designphase zu beseitigen. Siehe auch Employees 6.2.

6.8 Enthalten alle Verträge mit Lokads Subunternehmern/externer Belegschaft eine Geheimhaltungsvereinbarung (NDA)? Deckt diese NDA auch Kundeninformationen ab?

Ja zu beidem, obwohl Lokad – zum Zeitpunkt der Erstellung – nicht auf Subunternehmer/eine externe Belegschaft angewiesen ist. Lokads Software-Engineering- und supply chain scientist Teams sind vollständig mit Mitarbeitern besetzt, die in direkter, unbefristeter Anstellung und unter der Aufsicht von Lokad stehen.

Sollte es jedoch für notwendig erachtet werden, mit einem Subunternehmer zusammenzuarbeiten, so unterläge dieser denselben IP (Intellectual Property)- und NDA-Bedingungen wie unsere festangestellten Mitarbeiter. Diese Vereinbarungen beinhalten Bestimmungen bezüglich Informationen über Lokads Kunden.

6.9 Wurde der gesamten externen Belegschaft von Lokad eine interne Informations- und Sicherheitseinweisung (und fortlaufende, relevante Schulungen) angeboten?

Lokad – zum Zeitpunkt der Erstellung – ist nicht auf Subunternehmer/eine externe Belegschaft angewiesen. Lokads Software-Engineering- und supply chain scientist Teams sind vollständig mit Mitarbeitern besetzt, die in direkter, unbefristeter Anstellung und unter der Aufsicht von Lokad stehen.

Sollte es jedoch für notwendig erachtet werden, mit einer externen Belegschaft zusammenzuarbeiten, wäre dies eine Voraussetzung. Alle Subunternehmer/externen Mitarbeiter würden denselben Sicherheitsprozessen und Schulungsanforderungen wie unsere festangestellten Mitarbeiter unterliegen.

Wie bereits erwähnt, ist Lokad derzeit nicht auf eine externe Belegschaft angewiesen, weshalb keine derartigen Schulungen stattfinden.

Siehe auch Employees 6.8

6.10 Enthalten alle Verträge mit Unternehmen, die Lokads externe Belegschaft bereitstellen (irgendein/e alle Auftragnehmer, Berater etc., die an der Erbringung von Lokads Dienstleistungen beteiligt sind), die Anforderung, dass externe Mitarbeiter einer Hintergrundüberprüfung unterzogen werden? Entsprechen diese Hintergrundüberprüfungen dem entsprechenden Zugriffslevel auf Informationen und der Kritikalität der Rolle des Mitarbeiters?

Lokad – zum Zeitpunkt der Erstellung – ist nicht auf Subunternehmer/eine externe Belegschaft angewiesen. Lokads Software-Engineering- und supply chain scientist Teams sind vollständig mit Mitarbeitern besetzt, die in direkter, unbefristeter Anstellung und unter der Aufsicht von Lokad stehen.

Sollte es jedoch für notwendig erachtet werden, mit einer externen Belegschaft zusammenzuarbeiten, wäre dies eine Voraussetzung. Alle Subunternehmer/externen Mitarbeiter würden denselben Sicherheitsprozessen, Hintergrundüberprüfungen und Schulungsanforderungen wie unsere festangestellten Mitarbeiter unterliegen.

Hinweis: Historisch betrachtet wurden viele der größten – und schlimmsten – Vorfälle, wie Cyber-Spionage, von Personen begangen, die untadelige Akten haben. Dies ist unter anderem der Grund, warum Lokad zögert, sich auf eine externe Belegschaft zu verlassen, und direkte, unbefristete Arbeitsverträge bevorzugt.

6.11 Werden die Administratorkonten am Ende der Beschäftigung automatisch deaktiviert oder gelöscht?

Ja. Alle Lokad-Mitarbeiter erhalten ihre Zugriffsrechte über einen föderierten Identitätsanbieter (Microsoft Azure Active Directory). Am Ende ihrer Beschäftigung, sofern zutreffend, wird dieser Zugang widerrufen, wodurch alle damit verbundenen administrativen Rechte automatisch deaktiviert werden.

Hinweis: Den meisten Lokad-Mitarbeitern werden nie administrative Rechte gewährt, da diese für die Ausführung ihrer Aufgaben nicht erforderlich sind.

6.12 Führen Sie kriminalpolizeiliche Hintergrundüberprüfungen bei allen Mitarbeitern durch, die Zugang zu sensiblen Daten, Finanzdaten, Bankdaten, Zahlungsverkehrsdaten etc. haben?

Ja, Hintergrundüberprüfungen werden strikt gemäß den Anforderungen der auszuführenden Tätigkeit durchgeführt.

Es sei darauf hingewiesen, dass Lokad keine Zahlungsverkehrsdaten intern verwaltet – dies wird von Drittanbietern übernommen. Daher haben Lokad-Mitarbeiter keinen Zugang zu Zahlungsverkehrsdaten unserer Kunden.

6.13 Welche Vorsichtsmaßnahmen trifft Lokad, um sicherzustellen, dass unbefugtes Personal keinen Zugang zu den Arbeitsräumlichkeiten erhält?

Auf Gebäudebene operiert Lokad in einem Bürogebäude, das rund um die Uhr (vierundzwanzig Stunden am Tag, sieben Tage die Woche) von Kameras und einem vor Ort anwesenden Sicherheitspersonal überwacht wird.

Auf Büroebene verfügen Lokads Räumlichkeiten über eigene, gesicherte Zugangspunkte, die unabhängig von denen des Gebäudes sind. Diese letzte Schicht verhindert, dass Mitarbeiter anderer Unternehmen im Gebäude Zugang zu Lokads Büros erhalten.

Hinweis: Alle außergewöhnlichen Besucher (wie Kunden, potenzielle Kandidaten etc.) müssen von Lokad-Mitarbeitern persönlich empfangen und zum Betreten der Räumlichkeiten freigegeben werden.

6.14 Sind Besucher in der Einrichtung erlaubt?

Wenn “facility” “der Ort bedeutet, an dem Kundendaten gespeichert und verarbeitet werden”, dann nein. Kundendaten werden in den Rechenzentren von Microsoft Azure gespeichert. Diese Rechenzentren sind nicht öffentlich zugänglich – Lokad selbst kann nicht darauf zugreifen.

Lokad empfängt gelegentlich Besuch in der Firmenzentrale. Unsere Büros sind nicht öffentlich zugänglich, aber es kommt gelegentlich zu Ausnahmen, beispielsweise bei Kundenbesuchen oder wenn Bewerber auf ein Vorstellungsgespräch warten. Solche Besuche werden im Voraus geplant und die Besucher werden während ihres gesamten Aufenthalts von Lokad-Mitarbeitern begleitet.

6.15 Werden Papierdokumente (und entnehmbare elektronische Medien, die Daten enthalten) über Nacht in sicheren, feuerfesten Schränken aufbewahrt?

Lokad arbeitet weder mit Papierdokumenten noch mit entnehmbaren elektronischen Medien. Da wir keine physischen Aufzeichnungen zur Speicherung haben, benötigt Lokad keine feuerfesten Schränke.

Obwohl wir gelegentlich ein Dokument ausdrucken (Lokad druckt, wenn überhaupt, sehr wenige Dokumente), steht neben dem Drucker auch ein Aktenvernichter. Die Standardrichtlinie von Lokad ist es, keine sensiblen Dokumente auszudrucken; sollte dies theoretisch notwendig sein, wird das gedruckte Dokument unmittelbar nach Gebrauch geschreddert.

6.16 Gibt es eine Clear-Desk-Richtlinie? Falls ja, in welchem Umfang?

Ja, Lokad arbeitet mit einer strikten Clear-Desk-Richtlinie. Diese Richtlinie wird von vornherein durch unser digitales Umfeld umgesetzt.

Abgesehen von einigen Dokumenten, die wir gesetzlich drucken müssen, oder gelegentlichen Dokumenten, die aus Notwendigkeit gedruckt werden (z. B. ein Poster für eine Messe, wobei selbst dies in der Regel ausgelagert wird), ist das Arbeitsumfeld von Lokad rein digital.

Somit haben die Mitarbeiter von Lokad am Ende des Tages nichts abzuräumen. Sobald die Computersitzung des Mitarbeiters gesperrt wurde – eine Richtlinie, die wir strikt durchsetzen – ist der betreffende Schreibtisch effektiv frei.

6.17 Wo landen Faxe und wer könnte darauf zugreifen?

Lokad hat nie ein Faxgerät besessen – weder physisch noch virtuell. Uns ist kein überzeugender Anwendungsfall bekannt, der uns dazu veranlassen würde, unsere Haltung zu dieser Technologie zu ändern.

6.18 Gibt es einen Prozess, um die Rückgabe von Bestandteilen (Computer, Mobiltelefone, Zugangskarten, Tokens, Smartcards, Schlüssel usw.) bei Beendigung zu überprüfen?

Ja, wir haben nicht nur einen entsprechenden Prozess etabliert, sondern auch eine IT-Asset-Management-Software im Einsatz, die diesen Vorgang unterstützt und die Anzahl an Verwaltungsfehlern minimiert.

Wir haben die Sicherheit von Lokad jedoch bewusst so gestaltet, dass sie nicht auf die rechtzeitige Rückgabe der Bestandteile angewiesen ist. Lokad geht davon aus, dass jegliche Bestandteile durchaus verloren gehen oder gestohlen werden können, unabhängig davon, wie diszipliniert und geschult unsere Mitarbeiter sind. In der Praxis geschieht dies zwar sehr selten, aber aus technischer Sicht treffen wir die entgegengesetzte Annahme. Aus diesem Grund können Bestandteile aus der Ferne deaktiviert werden. Zudem setzen wir, wann immer möglich, eine vollständige Festplattenverschlüsselung ein.

Allgemein wurde unser Arbeitsumfeld so konzipiert, dass keine dauerhafte Speicherung von Kundendaten auf Arbeitsstationen, Notebooks oder Mobiltelefonen erforderlich ist. Dieses Design verringert die Kritikalität der Bestandteile erheblich, falls unsere anderen Präventionsmaßnahmen versagen sollten.

6.19 Werden die Personalrichtlinien und/oder -verfahren von der Geschäftsführung genehmigt und den Beteiligten kommuniziert, und ist ein Verantwortlicher zur Pflege und Überprüfung benannt?

Ja, unsere Personalrichtlinien und -verfahren wurden formell von der Geschäftsführung genehmigt. Wir legen großen Wert auf klare Kommunikation, weshalb diese Richtlinien und Verfahren umfassend an alle relevanten Beteiligten weitergegeben wurden, um vollständiges Verständnis und Einhaltung sicherzustellen.

Darüber hinaus haben wir einen Verantwortlichen benannt, der für die kontinuierliche Pflege, Aktualisierung und regelmäßige Überprüfung der Richtlinien und Verfahren zuständig ist. So wird gewährleistet, dass unsere Praktiken stets aktuell, relevant und im Einklang mit den Industriestandards sowie unseren organisatorischen Zielen bleiben.

6.20 Gibt es persönliche (BYOD), also nicht firmeneigene, mobile Geräte, die von Personen in Ihrer Organisation genutzt werden und Zugriff auf Kundendaten haben?

Nein, Lokad erlaubt keinen Zugriff auf Kundendaten über persönliche (BYOD) mobile Geräte. Wir stellen unseren Mitarbeitern hochwertige, firmeneigene Hardware zur Verfügung, wodurch der Bedarf an persönlichen Geräten entfällt. Diese Regelung begegnet dem häufigen Szenario, dass Mitarbeiter auf eigene Geräte zurückgreifen, weil sie mit minderwertiger Firmenhardware unzufrieden sind.

Außerdem sind unsere betrieblichen Protokolle so gestaltet, dass selbst auf unseren firmeneigenen Geräten Kundendaten nicht dauerhaft gespeichert werden. Die gesamte Datenverarbeitung erfolgt innerhalb unserer cloudbasierten Plattform. Auf Mitarbeitergeräten wird Kundendaten (falls überhaupt abgerufen) nur flüchtig und in minimalen Segmenten verarbeitet, um maximale Sicherheit zu gewährleisten.

Anmerkungen