FAQ: Software-Sicherheit
Lokad ist in erster Linie ein Supply-Chain-Spezialist, und unser Hauptziel ist es, über technologische Raffinesse überlegene Supply-Chain-Entscheidungen zu treffen. Dennoch verarbeiten wir täglich wichtige Finanzdaten, weshalb die Sicherheit unserer Softwareplattform eine Priorität darstellt, die wir mit größter Ernsthaftigkeit behandeln. Anstatt Sicherheit als Nachgedanken zu betrachten, der durch Bürokratie geregelt werden soll, glauben wir fest an einen prinzipienbasierten Ansatz, der auf Planung und Proaktivität setzt - wie durch unsere spezifische Softwaregestaltung, Personalbesetzung und Schulungswahl belegt.
Zielgruppe: Die IT-Abteilung
Zuletzt geändert am: 21. September 2023

Sicherheitsprinzipien
Eine der schädlichsten Illusionen in Unternehmenssoftwarekreisen ist die Vorstellung, dass Sicherheit mit Compliance-Checklisten, Zertifizierungen und im Allgemeinen mit allerlei bürokratischer Arbeit angegangen werden kann. Leider sind die Feinheiten von Sicherheitsbedenken immer im Fluss. Probleme entstehen, wenn böswillige Akteure Software oder Personen (oder beides) ausnutzen. Sicherheit kann daher nur durch die vernünftige Anwendung allgemeiner Prinzipien angegangen werden.
Sicherer durch Design
Wir glauben, dass Design eines der am meisten unterschätzten Aspekte der Softwaresicherheit ist. Hier umfasst Design die grundlegenden Entscheidungen, die zur Entwicklung der Software getroffen wurden. Die Designentscheidungen, die ein Unternehmen trifft, haben massive Auswirkungen auf die Sicherheit, insbesondere die Angriffsfläche. Durch vernünftiges Softwaredesign hat Lokad ganze Klassen von Sicherheitsproblemen eliminiert. Lokad verwendet beispielsweise keine SQL-Datenbank, sondern einfachen Blob-Speicher, als rein passive Speicherschicht. Allein diese Wahl verhindert ganze Gruppen von Sicherheitsproblemen, wie SQL-Injektionsangriffe, da es einfach keine SQL-Datenbank zum Angreifen gibt. Ebenso sind alle unsere Persistenzschichten nur anhängend. Dies ist wie eine Versionskontrolle, bei der Änderungen am Ende der vorhandenen Daten hinzugefügt werden, anstatt die gesamten Daten zu überschreiben. Alle Änderungen werden nachverfolgt und können rückgängig gemacht werden. Dieser Schritt erschwert erheblich das Löschen von Daten (durch jeden, einschließlich Angreifer) sowie das Manipulieren der Protokolle von Lokad.
Die meisten Anbieter von Unternehmenssoftware erkennen nicht an, dass Kern-Designentscheidungen das Fundament ihrer Softwareprodukte sind. Als Ergebnis sind ihre Sicherheitsprobleme endlos. Wenn beispielsweise Konfigurierbarkeit - fast immer eine Anforderung an Unternehmenssoftware - durch eine allgemeine Programmiersprache (wie Python oder JavaScript) bereitgestellt wird, treten zwangsläufig Sicherheitsprobleme auf. Dies liegt daran, dass es nahezu unmöglich ist, eine allgemeine Programmiersprache vollständig abzusichern. Im Gegensatz dazu hat Lokad die bewusste Designentscheidung getroffen, die gesamte Konfigurierbarkeit durch eine DSL (domänenspezifische Programmiersprache) namens Envision zu kanalisieren. Envision ist viel sicherer, weil es - durch Design - nicht die Kapazität hat, direkt mit dem Betriebssystem (OS) und seinen Subsystemen wie dem Dateisystem zu interagieren.
Sicherer durch Kultur
Keine Technologie und sicherlich kein Prozess kann Software sicher machen, wenn sich die Menschen einfach nicht darum kümmern. Daher bemühen wir uns nach Kräften, Lokad - sowohl seine Technologien als auch seine Prozesse - zu etwas zu machen, um das sich echte Sorge lohnt. Im Kontext von Unternehmenssoftware ist dies schwierig, da das Interesse abstrakt ist und von den individuellen Perspektiven und Motivationen der Menschen abgekoppelt ist1.
Zunächst einmal stimmt Lokad, soweit menschenmöglich, seine Marketingbotschaften mit der Realität seines Geschäfts ab. Wir tun dies, ob es uns Zustimmung oder Kritik einbringt. Dies steht im krassen Gegensatz zu vielen Unternehmensanbietern, die unvernünftige (und oft phantastische) öffentliche Behauptungen aufstellen 2. Wenn letzteres geschieht, hören scharfe Mitarbeiter - die in der Lage sind, den Unterschied zwischen der Realität des Geschäfts und dem, was nach außen kommuniziert wird, zu erkennen - auf, sich zu kümmern. Diese Gleichgültigkeit fördert die Selbstzufriedenheit, und Sicherheitsprobleme folgen. Oft verlassen diese Mitarbeiter das Unternehmen, und zurück bleiben die “leichtgläubigen” - diejenigen, die den Unterschied nicht sehen. Leichtgläubigkeit ist, ebenso wie Gleichgültigkeit, keine wünschenswerte Eigenschaft im Hinblick auf Sicherheit.
Zweitens fördert Lokad unter seinen Mitarbeitern eine Mischung aus Neugierde und gesundem Skeptizismus in allen Bereichen unseres Geschäfts, sowohl technisch als auch nicht-technisch, einschließlich Sicherheit. Dies schafft Flexibilität bei der Überarbeitung und Aktualisierung von Praktiken, da Mitarbeiter geschult und ermutigt werden, beizutragen. Diese Plastizität ist nützlich, um böswillige Akteure vorauszusehen, da sie bekannt dafür sind, immer kreativere Angriffsmethoden zu entwickeln. Glücklicherweise ist diese Denkweise auch für die Supply Chain-Zwecke äußerst wünschenswert, da unerwünschtes Verhalten - obwohl nicht unbedingt kriminell - in der Supply Chain weit verbreitet ist 3.
Sicherer durch Schulung
Wir schulen aktiv unser gesamtes Personal, um Cyberbedrohungen besser zu verstehen und zu bekämpfen. Im Gegensatz zum Design und zur Kultur ist die Sicherheitsschulung größtenteils ein Top-Down-Prozess. Obwohl das Bottom-Up-Denken seinen Platz hat, ist diese Art von Schulung von Natur aus schwach gegen die meisten Computersicherheitsrisiken. Einfach ausgedrückt, selbst wenn die Menschen geschult sind, etwas nicht zu tun, kann Lokad nicht davon ausgehen, dass niemand jemals diese Handlung ausführen wird 4. Daher gehen wir strenger vor. Im Rahmen unserer Schulung entmutigen wir die Verwendung von USB-Flash-Laufwerken und anderen USB-Geräten, die die Maschinen gefährden könnten. Wir stellen sicher, dass die Zwei-Faktor-Authentifizierung immer verwendet wird, wenn möglich. Wir schulen unser Personal, mit so wenigen Berechtigungen wie möglich auf ihren Arbeitsstationen zu arbeiten. Wir stellen sicher, dass jeder darüber informiert ist, wie Social Engineering funktioniert, was selbst die klügsten Menschen täuschen kann.
Allgemeiner betrachtet konzentriert sich die Sicherheitsschulung darauf, das Bewusstsein dafür zu erhöhen, wie Software und Prozesse von böswilligen Akteuren zweckentfremdet und korrupt werden können. Angesichts des Umfangs der Schulung, der Fähigkeiten und des Know-hows, die erforderlich sind, um solche nuancierten Angriffe zu verhindern, hat Lokad im Allgemeinen sehr wenige Praktikanten im Vergleich zu den meisten Unternehmen ähnlicher Größe in diesem Bereich. Kurz gesagt, wir setzen lieber auf ein stabiles, hochqualifiziertes Team auf lange Sicht.
Häufig gestellte Fragen (FAQ)
1. Praktiken
1.1 Haben Sie Sicherheitsgarantie?
Ja. Sicherheitsgarantie ist ein Sammelbegriff für verschiedene Praktiken wie Sicherheitsverhärtung, Sicherheitstests und Schwachstellenmanagement. Sicherheitsverhärtung wird bei Lokad in erster Linie durch Design angegangen. Durch spezifische Designentscheidungen eliminieren wir ganze Klassen von Schwachstellen, was wiederum die Notwendigkeit der Verhärtung selbst beseitigt. Zum Beispiel verlässt sich Lokad nicht auf eine “programmatische” Speicherschicht - wie eine relationale Datenbank - sondern auf einen einfachen Schlüssel-Wert-Speicher. Dies eliminiert alle SQL-Injektionsvektoren. Darüber hinaus wird Sicherheitstests durch eine vielfältige Reihe von Methoden angegangen; einige automatisiert und einige manuell, wie Drittanbieter-Penetrationstests. Für das Schwachstellenmanagement haben wir ein Bug-Bounty-Programm und einen umfassend automatisierten Freigabeprozess, um sicherzustellen, dass Korrekturen schnell bereitgestellt 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 das Gegenteil von dem ist, was erforderlich ist, um Software sicher zu machen. Diese Zertifizierungen erfordern beispielsweise die Erstellung von Dokumenten und die Einsetzung von Ausschüssen. Offen gesagt ist die Idee, dass Dokumente und Ausschüsse etwas Substantielles für die Sicherheit von Software liefern, zutiefst umstritten und ist etwas, das Lokad keineswegs akzeptiert.
In Softwarekreisen wird Sicherheit in der Regel durch weniger erreicht, nicht durch mehr; durch die Nutzung der Bemühungen von Softwareingenieuren, die sich auf die Sicherheit von Software spezialisiert haben, und nicht durch die Schaffung zusätzlicher Teams von Nicht-Spezialisten. Als belegbare Evidenz betrachten Sie einige der schwerwiegendsten Cybersicherheitskatastrophen, wie Heartbleed oder Log4Shell. Diese Katastrophen hätten wahrscheinlich verhindert werden können, wenn die Tausenden von “zertifizierten” Softwareunternehmen sich dafür entschieden hätten, das Korrekturlesen des Drittanbietercodes - oft die Wurzel der Probleme - vor der Verfolgung willkürlicher kommerzieller Gütesiegel zu priorisieren.
Insgesamt glauben wir, dass diese Zertifizierungen Marketingtricks sind, die Unternehmen in ein falsches Sicherheitsgefühl (im übertragenen und wörtlichen Sinne) wiegen.
1.3 Befolgen Sie die OWASP-Praktiken?
Ja. OWASP bietet durch seine Leitfäden eine umfangreiche Checkliste gegen Schwachstellen, die in Software häufig vorkommen. Dies ist eine umfangreiche, hochwertige Zusammenstellung, die von Lokad-Ingenieuren genutzt wird, um unsere Software vor Problemen zu schützen, die von OWASP identifiziert wurden. Durch seine Designentscheidungen eliminiert Lokad jedoch weitgehend ganze Klassen von häufigen Schwachstellen, die von OWASP hervorgehoben werden. Zum Beispiel:
Passwortverwaltung: Durch die Delegation der Authentifizierung über die SSO-Funktionalität (Single Sign-On, etwas, das von Lokad empfohlen wird), muss Lokad keine Passwörter mehr “verwalten”, was die gesamte Checkliste im Zusammenhang mit Passwörtern obsolet macht.
Protokollierung: Das von Lokad übernommene Event-Sourcing-Design protokolliert aus Notwendigkeit alles. Wenn eine Aktion nicht protokolliert wird, 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 Schlüssel-Wert-Speicher. Diese Designentscheidung macht die Datenbank-Checkliste vollständig obsolet.
Im Allgemeinen bevorzugen wir es, fehleranfällige Designmuster zu vermeiden, die die Notwendigkeit solcher Checklisten überhaupt erst entstehen lassen.
1.4 Sind Sie GDPR-konform?
Ja. Die Supply-Chain-Optimierung - wie von Lokad bereitgestellt - erfordert jedoch keine personenbezogenen Daten. Wir betrachten personenbezogene Daten als Haftungsrisiko und nicht als Vermögenswert. Daher empfehlen wir unseren Kunden dringend, uns keine personenbezogenen Daten zu übermitteln. Diese Empfehlung ist in der Regel Bestandteil unserer Vertragsvereinbarungen. Indem wir keine personenbezogenen Daten in unserem Besitz haben und daher keine personenbezogenen Daten verarbeiten, eliminieren wir weitgehend Bedenken und Protokolle im Zusammenhang mit dem Schutz dieser Daten, wie z.B. der DSGVO oder ähnlichen Vorschriften.
1.5 Erfüllen alle Drittanbieterdienste/-lösungen (die Zugriff auf personenbezogene Daten (PII) beinhalten) in Lokads Lösung die Anforderungen des Datenschutzbeauftragten (DPO)?
Ja. Wie jedoch in Praktiken 1.4 angegeben, erfordert die Supply-Chain-Optimierung - wie von Lokad bereitgestellt - keine personenbezogenen Daten. Daher empfehlen wir unseren Kunden dringend, uns keine personenbezogenen Daten zu übermitteln.
Es sei darauf hingewiesen, dass Lokads Lösung eine sehr kurze Liste von Drittanbietern hat, die Zugriff auf PII-Daten haben. Stand Januar 2023 ist diese Liste auf Microsoft Azure beschränkt.
1.6 Befolgen Sie bewährte Sicherheitspraktiken?
Ja. Das heißt, wir treffen kluge Entscheidungen, da es keine branchenweite Einigung darüber gibt, was “die besten Software-Sicherheitspraktiken” sind. Software-Sicherheit existiert von Natur aus in einem Zustand ständiger Evolution, der sich an eine Umgebung anpasst, die mit geschickten neuen Bedrohungen und Angriffsvektoren gefüllt ist. Daher verlassen wir uns nicht kategorisch auf Dritte, was die besten Software-Sicherheitspraktiken sind. Stattdessen definieren wir, was für unsere Kunden am besten ist. Dies ermöglicht es uns, gute Praktiken aufzunehmen, wo sie verfügbar sind, ohne weniger ratsame Praktiken starr zu befolgen, nur weil sie beliebt sind. All dies führt zu aktuellen, durchsetzbaren und effektiven Software-Sicherheitspraktiken.
1.7 Führen Sie regelmäßig Penetrationstests durch?
Ja. Wir führen sowohl geplante als auch ungeplante Penetrationstests durch. Die geplanten Tests werden in der Regel von unseren großen Kunden finanziert, die gemäß der mit ihnen unterzeichneten Vertragsvereinbarung spezialisierte Unternehmen beauftragen können, Penetrationstests ihrer wichtigsten Softwareanbieter durchzuführen, zu denen auch Lokad gehört. In der Regel gibt es eine gewisse Koordination zwischen Lokads Entwicklungsteam und diesen Sicherheitsspezialisten. Die ungeplanten Tests sind in der Regel Teil unseres öffentlichen Bug-Bounty Programms, bei dem freiberufliche Sicherheitsspezialisten versuchen können, eine Schwachstelle in unserem System zu finden, die für einen potenziellen Angriff offen ist.
1.8 Führen Sie regelmäßig externe Audits durch?
Nein. Das gesagt, sind wir mehr als bereit, uns einem externen Audit zu unterziehen, wenn die Operation vom Kunden finanziert wird. Viele unserer großen Kunden haben Bestimmungen für solche Audits in unseren Vertragsvereinbarungen. Stand Januar 2023 haben die von Kunden durchgeführten Penetrationstests jedoch nicht genügend Probleme aufgedeckt, um solche Audits zu rechtfertigen.
1.9 Haben Sie einen Business Continuity Plan?
Ja. Das größte Risiko, dem Lokad begegnet ist, ist die hypothetische Einstellung des Unternehmens selbst. Lokad fungiert als SaaS-Lösung, jedoch haben einige unserer großen Kunden Bestimmungen in ihren Vertragsvereinbarungen, um vollständige Snapshots unseres Codebasis anfordern zu können. Diese Snapshots werden bei einem vereinbarten Dritten in Verwahrung genommen, so dass im Falle einer Einstellung des Betriebs von Lokad der Kunde automatisch Zugriff auf den in Verwahrung genommenen Codebasis und eine genehmigende Lizenz zur Neuerstellung ihrer eigenen Instanz des Lokad-Dienstes erhält.
1.10 Haben Sie einen Krisenkommunikationsplan?
Ja. Für jeden Kunden haben wir einen identifizierten Ansprechpartner innerhalb ihrer Organisation. Auf unserer Seite gibt es mindestens zwei Mitarbeiter bei Lokad - einen Hauptverantwortlichen und einen Vertreter (in der Regel zwei unserer Supply Chain Scientists) - die dafür zuständig sind, dem Kunden dringende Nachrichten zu übermitteln. In der Praxis sind die meisten Krisen, mit denen wir konfrontiert sind, keine Software-Sicherheitsprobleme, sondern Lieferkettenprobleme - Notfälle, die Lokad basierend auf den Daten identifiziert, die uns vom Kunden zur Verfügung gestellt werden. Im Falle eines Sicherheitsvorfalls wird dieser Kanal genutzt, um sicherzustellen, dass unsere Kunden rechtzeitig informiert werden.
1.11 Wie stellen Sie sicher, dass die IT-Systeme des Kunden sicher sind?
Wir empfehlen nachdrücklich, dass Lokad keinen Zugriff auf die IT-Systeme unserer Kunden haben sollte; das IT-System des Kunden sollte nur Daten von Lokad abrufen und senden. Dieser Ansatz soll die Möglichkeit eines Sicherheitsvorfalls bei Lokad, der sich auf das IT-System des Kunden ausbreitet, minimieren. Darüber hinaus empfehlen wir dringend die Verwendung eines SSO (Single Sign-On)-Prozesses, da dies das hypothetische Szenario eliminiert, dass ein Passwort, das zur Anmeldung bei Lokad verwendet wird, abgefangen wird (auf irgendeine Weise) und später verwendet wird, um eines der IT-Systeme des Kunden zu kompromittieren.
1.12 Wie sichern Sie Ihr Netzwerk?
Unser Design basiert auf einer Zero-Trust-Architektur, was bedeutet, dass nur die richtigen Personen zu jedem Zeitpunkt auf Daten zugreifen dürfen. Allein die Anwesenheit in unserem Netzwerk gewährt keinen automatischen Status oder Privilegien (dieser Punkt wird in Authentifizierung 2.1 erläutert). Daher stellen wir sicher, dass die Angriffsfläche, die mit unseren Netzwerken verbunden ist, so klein wie möglich ist.
Lokad verwendet 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 von Microsoft delegiert. Wir verwenden keine “fortgeschrittenen” Netzwerkfunktionen - wie die von Microsoft Azure angebotenen - über einfache Lastenausgleicher hinaus.
Das zweite ist das lokale Netzwerk unseres Hauptsitzes in Paris. Die Sicherheit des lokalen Netzwerks wird intern von Lokads Engineering-Team verwaltet. Unser lokales Netzwerk beherbergt keine Komponente oder System, die zur Produktionsumgebung beiträgt.
1.13 Garantieren Sie, dass alle Komponenten (einschließlich Drittanbieter) und Tools (einschließlich Open-Source) in der Lösung rechtlich für die Entwicklung und Produktion gültig sind?
Ja. Lokad hat im Vergleich zu den meisten Enterprise-Softwareanbietern sehr wenige Abhängigkeiten. Alle unsere Hauptabhängigkeiten sind glaubwürdige und weit verbreitete Open-Source-Projekte (z. B. .NET von Microsoft, React von Facebook). Dies macht unseren internen Prüfprozess zu diesem spezifischen Punkt zu einer unkomplizierten Angelegenheit.
1.14 Wie verwalten Sie größere Änderungen in Organisation und Prozessen in Bezug auf Sicherheit?
Da Lokad von Anfang an vernünftige Sicherheitsdesignentscheidungen und -praktiken übernommen hat, ist es selten, dass eine Änderung jeglicher Größenordnung (geringfügig oder bedeutend) die Sicherheit beeinträchtigt (auch hypothetisch). In der gesamten Geschichte von Lokad gab es nur 3 Ereignisse, die aus Sicherheitssicht wirklich signifikant betrachtet werden könnten: die Migration zu Microsoft Azure im Jahr 2010; die Einführung der delegierten Authentifizierung im Jahr 2012 (für Kunden und Mitarbeiter gleichermaßen); 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 Monate im Voraus von Lokads Softwareentwicklungsteam vorbereitet. Entsprechende Schulungsmaterialien und Schulungssitzungen wurden vor der geplanten Änderung implementiert, um die Einsatzbereitschaft aller Lokad-Mitarbeiter sicherzustellen. Schließlich haben wir nach jedem Migrationsereignis sichergestellt, dass der vorherige “Pfad” beseitigt wurde, wie es bei Lokad üblich ist.
Stand Januar 2023 haben wir keine bevorstehenden größeren Änderungen geplant. Wenn eine solche Änderung eingeführt würde, würden wir höchstwahrscheinlich in ähnlicher Weise vorgehen.
1.15 Wie verwalten Sie das Vertragsende?
Unsere Vereinbarungen enthalten den Kündigungsprozess am Ende eines Vertrags, wie mit dem Kunden vereinbart. Der Kündigungsprozess endet mit der endgültigen Löschung der Daten des Kunden. Da dieser Kündigungsprozess an sich ein Sicherheitsrisiko darstellt, wird dieser Punkt mit jedem Kunden diskutiert und kann daher je nach Fall geringfügig variieren. Aus Sicherheitssicht könnte ein böswilliger Akteur versuchen, den Kunden zu imitieren, um eine vorzeitige Vertragsbeendigung auszulösen (und die Geschäftsabläufe des Kunden zu stören). Um dies zu verhindern, würden Lokad und der Kunde gemeinsam bemüht sein, einen vertraglich durchgesetzten Prozess zu übernehmen, der nicht trivial anfällig für einen Social-Engineering-Angriff ist. Dieser Prozess beinhaltet 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, sowie eine monatliche Pauschalgebühr, die mit dem von den Supply Chain Scientists, die dem Kunden gewidmet sind, erbrachten Service verbunden ist (d. h. den von Lokad bereitgestellten Ingenieuren). Der Kleingedruckte wird im Servicevertrag zwischen dem Kunden und Lokad verhandelt und detailliert. Diese beiden Gebühren repräsentieren ein “all-inclusive” Paket mit Lokad. Es gibt keine zusätzlichen Wartungsgebühren, Lizenzgebühren, Drittanbieter-Integratoren, Drittanbieter-Berater usw. Das Paket enthält Grenzen im Umfang und Umfang, die im Rahmen der vertraglichen Vereinbarung für den Service gemeinsam verhandelt werden.
1.17 Können Sie die Geschäftsbedingungen von Lokad für die Lizenz(en), den Service, den Support, die Wartung und Schulungen bereitstellen?
Ja, auf Anfrage des Kunden können wir eine Vertragsvorlage bereitstellen, die eine “Baseline”-Vereinbarung darstellt. Die Situationen variieren jedoch erheblich je nach Umfang der Supply-Chain-Initiative, den anwendbaren Ländern und dem Umfang der von Lokad erwarteten Dienstleistungen. Daher bevorzugen wir es, wenn möglich, mit einem potenziellen Kunden in einem ersten Gespräch zu klären, welche spezifischen Aspekte der Supply-Chain-Initiative in Betracht gezogen werden. Dies hilft uns, das relevanteste vertragliche Rahmenwerk für die Situation zu erstellen.
1.18 Bieten Sie Schulungen an (vor Ort/e-Schulungen)?
Ja, Lokad bietet sowohl Schulungen vor Ort als auch Fernschulungen an. Der Kleingedruckte dieser Sitzungen wird im Rahmen der Vertragsvereinbarung verhandelt. Darüber hinaus verfügt Lokad über umfangreiche öffentliche technische Dokumentationen und eine ausführliche Reihe von öffentlichen Supply-Chain-Vorlesungen. Diese Vorlesungen behandeln die Technologie und die Supply-Chain-Perspektive von Lokad.
1.19 Erfüllt das System von Lokad relevante rechtliche/lokale Standards (z. B. ISO)?
Ja, Lokad arbeitet in Übereinstimmung mit relevanten Standards. Lokad liefert jedoch eine predictive Optimierung der Supply Chain, und daher kontrolliert Lokad die Operationen nicht direkt. Unser Einfluss ist weitgehend indirekt, in der Regel durch die Optimierung der Ressourcenallokation. Daher sind die ISO-Standards hier nicht relevant (d. h. nicht auf Lokad anwendbar).
1.20 Gibt es einen Malware-Schutz auf Netzwerkebene, z. B. auf Firewalls, Proxy-Geräten und/oder im Netzwerk als separate Lösungen?
Siehe Praktiken 1.12
1.21 Enthält der Softwareentwicklungsprozess eine integrierte Bedrohungsanalyse?
Ja. Dies ist der Hauptgrund, warum wir die Sicherheitsbedenken “von Anfang an” angehen. Indem wir ganze Klassen von Bedrohungen in der Designphase eliminieren, halten wir die Gesamtbedrohungsanalysepraxis überschaubarer. Die Bedrohungsanalyse umfasst auch “Supply-Chain-Angriffe”. Dies ist ein weiterer Grund, warum wir so großen Wert darauf legen, die Anzahl der Drittanbieterabhängigkeiten in unserem Software-Stack zu minimieren, da jede Abhängigkeit inherently die Angriffsfläche erhöht.
1.22 Wird der Vorfallmanagementprozess mindestens einmal jährlich geprobt?
Ja. Es gibt viele verschiedene Arten von Vorfällen. Einer der häufigsten ist, dass das Kundenunternehmen selbst gehackt wird. Im Falle von Ransomware führt dies manchmal dazu, dass die Lokad-Daten versehentlich der einzige Datensatz sind, auf den noch zugegriffen werden kann. Bei Identitätsdiebstahl führt dies manchmal zu Versuchen, auf das Lokad-Konto mit gestohlenen Anmeldedaten zuzugreifen. Der Kleingedruckte der verschiedenen Vorfallmanagementprozesse wird gemeinsam mit dem Kundenunternehmen festgelegt und in der Regel vom Supply Chain Scientist bei Lokad überwacht, der für das Konto zuständig ist (für Kunden, die sich für ein betreutes Konto entscheiden).
1.23 Wird die Risiko- und Bedrohungskartierung mindestens einmal 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 in der Regel durch bedeutende Ereignisse vorangetrieben, wie z. B. bemerkenswerte Sicherheitsverletzungen in der Softwarebranche.
1.24 Wird die Risikobewertung auch für unterstützende Funktionen durchgeführt, die die Verfügbarkeit, Qualität und/oder Sicherheit der Lösung beeinträchtigen könnten?
Ja. Die Lokad-Plattform ist jedoch im Wesentlichen ein Monolith, der nicht auf “unterstützende Funktionen” angewiesen ist, abgesehen von einigen grundlegenden Funktionen wie dem Blob Storage und den Linux-VMs, die von Microsoft Azure bereitgestellt werden.
1.25 Werden dedizierte Systemkonten - mit nur den erforderlichen Zugriffsrechten - für die Ausführung von Systemprozessen erstellt?
Ja, dedizierte Systemkonten mit angemessenen Zugriffsrechten werden für die Ausführung von Systemprozessen verwendet. Lokad verwendet Daemons in Form von systemd-Services, die immer als Benutzer mit möglichst wenigen Rechten ausgeführt werden.
Obwohl Lokad keine SQL-Datenbank verwendet, nutzt die Plattform ein rollenbasiertes System, um Zugriffsrechte für geplante und ausgelöste Prozesse festzulegen. Diese Prozesse werden als “userland” und nicht als “system” Prozesse kategorisiert.
1.26 Gibt es einen formalisierten Risikomanagementplan, der von der Geschäftsleitung genehmigt wurde und die Anforderungen des Enterprise Risk Management Programms definiert?
Ja, wir haben einen formalisierten Risikomanagementplan, der von der Geschäftsleitung genehmigt wurde.
Dieser Plan umreißt die Anforderungen und Richtlinien für unser Enterprise Risk Management (ERM) Programm. Es ist darauf ausgelegt, Risiken im Unternehmen strukturiert und konsistent zu identifizieren, zu bewerten, zu managen und zu überwachen.
Unser Risikomanagementplan wird regelmäßig überprüft und aktualisiert, um sicherzustellen, dass er relevant bleibt und mit unseren organisatorischen Zielen und der sich entwickelnden Risikolandschaft übereinstimmt. Darüber hinaus werden die Umsetzung und Wirksamkeit des ERM-Programms regelmäßig der Geschäftsleitung und den relevanten Interessengruppen gemeldet, um eine kontinuierliche Überwachung und Unterstützung sicherzustellen.
1.27 Gibt es ein von der Geschäftsleitung genehmigtes physisches Sicherheitsprogramm, das den Beteiligten mitgeteilt wurde und wurde ein Verantwortlicher benannt, um es aufrechtzuerhalten und zu überprüfen?
Ja, wir haben ein umfassendes physisches Sicherheitsprogramm, das von der Geschäftsleitung genehmigt wurde. Dieses Programm wurde gründlich an alle relevanten Beteiligten kommuniziert, um Bewusstsein und Einhaltung sicherzustellen.
Darüber hinaus haben wir einen Verantwortlichen benannt, der für die Aufrechterhaltung, Aktualisierung und regelmäßige Überprüfung des Programms verantwortlich ist, um dessen Wirksamkeit und Relevanz sicherzustellen. Dieser Verantwortliche arbeitet mit verschiedenen Teams und Abteilungen zusammen, um aufkommende physische Sicherheitsbedenken anzugehen und sicherzustellen, dass das Programm mit bewährten Praktiken und unseren organisatorischen Zielen übereinstimmt.
1.28 Werden Bewertungen der physischen und Umweltrisiken durchgeführt, bevor der Standort oder das Gelände einer Einrichtung festgelegt wird, in der Systeme untergebracht sind?
Ja, Bewertungen der physischen und Umweltrisiken sind ein integraler Bestandteil unseres Entscheidungsprozesses bei der Festlegung des Standorts oder Geländes einer Einrichtung für unsere Systeme. Da unsere Systeme in den Rechenzentren von Microsoft Azure untergebracht sind, profitieren wir von Microsofts rigorosem Standortauswahl- und Bewertungsprozess. Microsoft Azure führt umfangreiche Bewertungen potenzieller Risiken durch, einschließlich physischer und Umweltrisiken, bevor eines ihrer Rechenzentren eingerichtet wird. Ihr Auswahlprozess beinhaltet die Analyse von Faktoren wie dem Potenzial für Naturkatastrophen, der Zugänglichkeit, der Stabilität der Infrastruktur und mehr.
Durch die Nutzung der Rechenzentren von Azure sind wir zuversichtlich, dass diese Bewertungen umfassend durchgeführt wurden, um die höchsten Maßstäbe für 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 glauben, dass “Ethik” in einer Top-Down-Manier durchgesetzt werden kann. Ein solcher Ansatz führt zwangsläufig zu unerwünschten Ergebnissen, die den ursprünglichen Zielen zuwiderlaufen.
Berühmt geworden ist Enron durch einen schriftlichen Verhaltenskodex. Dieser Kodex betonte Respekt, Integrität, Kommunikation und Exzellenz. Der Enron-Skandal, der 2001 ans Licht kam, enthüllte, dass das Unternehmen in massive Bilanzbetrug verwickelt war, was offensichtlich im Widerspruch zu den in ihrem Verhaltenskodex festgelegten Grundsätzen stand. Es bestand also eine vollständige Diskrepanz zwischen den von Enron proklamierten, schriftlichen Ethikrichtlinien und den tatsächlichen Geschäftspraktiken und der Unternehmenskultur.
Daher konzentriert sich Lokad darauf, sicherzustellen, dass Mitarbeiter die Möglichkeit haben, sich wirklich um unsere Kunden zu kümmern. “Tun wir die richtigen Dinge?” ist eines unserer Mantras. Compliance und Ethik sind unserer Ansicht nach Nebenprodukte einer angemessenen Unternehmenskultur, nicht das Ergebnis eines bestimmten Programms.
1.30 Gibt es eine interne Revision, Risikomanagement- oder Compliance-Abteilung oder eine ähnliche Managementüberwachungsfunktion, die für die Verfolgung der Lösung ausstehender regulatorischer oder Compliance-Probleme verantwortlich ist?
Ja. Obwohl Lokad nicht groß genug ist, um eine eigenständige Abteilung für interne Revisionen, Risikomanagement oder Compliance zu haben, legen wir zweifellos Wert auf diese Bereiche. Wir haben speziell ausgewiesene Personen mit Fachkenntnissen in diesen Bereichen, die speziell damit beauftragt sind, diese kritischen Verantwortlichkeiten zu übernehmen und zu überwachen.
Diese Personen berichten direkt an die oberste Führungsebene von Lokad, um sicherzustellen, dass die Lösung ausstehender regulatorischer oder Compliance-Probleme mit höchster Priorität behandelt wird und auf der höchsten Ebene unserer Organisation die erforderliche Überwachung erhält.
1.31 Gibt es ein von der Geschäftsleitung genehmigtes drahtloses Richtlinien- oder Programm, das den geeigneten Beteiligten mitgeteilt wurde und ein Verantwortlicher benannt wurde, um es aufrechtzuerhalten und zu überprüfen?
Ja, Lokad verfügt über eine klar definierte drahtlose Richtlinie, die von der Geschäftsleitung genehmigt und an alle relevanten Beteiligten kommuniziert wurde, um die Einhaltung sicherzustellen. Diese Richtlinie unterscheidet zwischen zwei unabhängigen und isolierten Wi-Fi-Netzwerken: einem für Mitarbeiter und einem speziell für Gäste. Die Unterscheidung gewährleistet, dass unsere Hauptbetriebe sicher bleiben, auch wenn wir Konnektivität für Gäste oder Besucher bereitstellen.
Es ist jedoch wichtig zu beachten, dass unsere primäre Verbindung über Ethernet erfolgt, da dies aufgrund seiner überlegenen Leistung und erhöhten Sicherheit priorisiert wird. Die Wi-Fi-Netzwerke sind hauptsächlich für Besprechungen vorgesehen und bieten Flexibilität in bestimmten Szenarien.
Darüber hinaus haben wir einen Verantwortlichen für die Richtlinie benannt, der für deren Pflege und regelmäßige Überprüfung verantwortlich ist, um sicherzustellen, dass sie auf dem neuesten Stand bleibt und sich wirksam mit den sich entwickelnden Anforderungen und Herausforderungen auseinandersetzt.
2. Authentifizierung
2.1 Erzwingen Sie die Authentifizierung für alle Zugriffe?
Ja. Der Zugriff auf Clientdaten und/oder jede wesentliche Funktion der Lösung erfordert eine vorherige Authentifizierung. Einige Kontaktpunkte unterliegen jedoch aus Notwendigkeit keiner Authentifizierung. Beispielsweise erfordert der Zugriff auf die Login-Webseite keine vorherige Authentifizierung (da die Authentifizierung der Sinn dieser Login-Webseite ist).
Insgesamt erfordern nur sehr wenige technische Endpunkte keine Authentifizierung, und sie sind in der Regel Teil der Instrumentierung der Plattform (z. B. ein Endpunkt, der nur verwendet wird, um zu überprüfen, ob eine Maschine aktiv ist). Es sei darauf hingewiesen, dass nicht authentifizierte Endpunkte keine sensiblen Daten offenlegen, geschweige denn tatsächliche Clientdaten.
2.2 Erfordern Sie, dass alle Remote-Zugriffe gesichert sind? Erzwingen Sie HTTPS für Webverbindungen?
Ja. Die Sicherung von Remote-Zugriffen bedeutet die richtige Authentifizierung, die richtige Autorisierung und die Verschlüsselung des Transportkanals selbst - all dies setzen wir durch. Diese Bestimmung gilt sowohl für Client-Benutzer als auch für Lokad-Mitarbeiter. Selbst für das Entwicklungsteam bei Lokad gibt es keinen “ungesicherten lokalen Zugriff” auf unsere Produktionssysteme. Wir verwenden keine 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 verwendet werden, um auf Lokad zuzugreifen.
2.4 Unterstützen Sie die Zwei-Faktor-Authentifizierung wie EZToken, Google Authenticator oder Microsoft Authenticator?
Ja. Die Zwei-Faktor-Authentifizierung wird durch die delegierte Authentifizierung über SAML erreicht. Durch SAML verwaltet Lokad weder den ersten Authentifizierungsfaktor noch den zweiten, da dieser Prozess delegiert ist.
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 tatsächlich kein “Authentifizierungsprotokoll” ist, sondern eine Reihe sehr umfangreicher Richtlinien zur Entwicklung von “Authentifizierungsprotokollen”, die sich in dutzenden von Möglichkeiten unterscheiden können.
Als Ergebnis beobachten wir, dass die verschiedenen OAuth2-Implementierungen, die im Bereich der Unternehmenssoftware existieren, tendenziell weitgehend inkompatibel sind. Daher können wir, wenn OAuth2 eine absolute Anforderung ist, gemäß vertraglicher Vereinbarung eine spezifische Variante von OAuth2 unterstützen. Diese Vereinbarung erfordert jedoch dedizierte Ressourcen, um die Kompatibilität mit der OAuth2-Variante sicherzustellen, die vom Kundenunternehmen betrieben wird.
2.6 Unterstützen Sie die LDAP-Integration?
Ja, über eine Middleware-Brücke, die SAML über LDAP schichtet. Die Mehrheit der föderierten Identitätssysteme, die LDAP unterstützen, unterstützen auch SAML. Daher empfehlen wir die direkte Verwendung von SAML.
2.7 Erzwingen Sie die Zwei-Faktor-Authentifizierung?
Für Lokad-Mitarbeiter ja. Für die Mitarbeiter des Kunden empfehlen wir dies dringend, können es letztendlich jedoch nicht erzwingen (da die Authentifizierung in der Regel über SSO delegiert wird). Diese Angelegenheit liegt in den Händen der IT-Abteilung unseres Kunden, nicht in unseren.
2.8 Können Sie eine minimale Passwortkomplexität durchsetzen?
Ja, aber nur in begrenztem Umfang. Was die Software-Sicherheit betrifft, wird die Vorgabe einer minimalen Passwortkomplexität jetzt weitgehend als schlechte Praxis anerkannt. Endbenutzer reagieren schlecht (und vorhersehbar) auf übermäßig strenge Anforderungen an die Passwortkomplexität, was dazu führt, dass das Gesamtniveau der Sicherheit leidet. Darüber hinaus betrachten wir solche Passwortanforderungen als “Bloatware”, die die Komplexität eines sicherheitskritischen Softwareteils (Passwortverwaltung) erhöhen und sie (sowie die Gesamtlösung) unnötigen Risiken aussetzen. Siehe https://www.sans.org/blog/nist-has-spoken-death-to-complexity-long-live-the-passphrase/
Wir empfehlen dringend die Verwendung von SSO anstelle von traditionellen Passwörtern/Strategien. Durch SSO ist es nicht erforderlich, ein spezielles Passwort für Lokad einzuführen.
2.9 Können Sie geplante Passwortrotationen durchsetzen?
Wir könnten, tun es aber nicht. Ähnlich wie bei minimaler Passwortkomplexität (siehe Authentifizierung 2.8) wird die geplante Passwortrotation jetzt weitgehend als schlechte Software-Sicherheitspraxis anerkannt. Endbenutzer reagieren schlecht (und vorhersehbar) auf geplante Passwortrotationen. Die Sicherheit kann sogar geschwächt werden, da Mitarbeiter oft nur geringfügige Änderungen an Passwörtern vornehmen (um die kognitive Belastung durch häufige Rotationen zu verringern). Wie bei minimaler Passwortkomplexität betrachten wir Passwortrotation als “Bloatware”, die die Komplexität eines sicherheitskritischen Softwareteils (Passwortverwaltung) erhöht und sie (sowie die Gesamtlösung) unnötigen 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-Hash-Funktion. Im Allgemeinen empfehlen wir dringend die Verwendung von SSO anstelle der Verwendung traditioneller Passwörter/Strategien. Durch SSO ist es nicht erforderlich, ein spezielles Passwort für Lokad einzuführen.
2.11 Ermöglicht die Lösung von Lokad CAPTCHA nach einer festgelegten Anzahl von Authentifizierungsfehlern?
Ja, jedoch über die Authentifizierungsdelegation (über SSO). Während CAPTCHAs ein wertvoller Ansatz sind, um einige Angriffsvektoren zu mildern, gehören sie zu den Softwarekomponenten, die am besten vollständig außerhalb des Bereichs einer Supply-Chain-Optimierungslösung wie Lokad bleiben. Darüber hinaus ist der Mehrwert von CAPTCHAs im Kontext von Unternehmenssoftware weniger klar als bei B2C-Software, insbesondere Freeware.
2.12 Haben Sie eine allgemeine Sicherheitsrichtlinie für Passwörter? Haben Sie einen Prozess zu ihrer Durchsetzung?
Ja. Unsere allgemeine Sicherheitsrichtlinie für Passwörter lautet “keine Passwörter”. Wir empfehlen dringend SSO, was die Notwendigkeit beseitigt, Passwörter speziell für Lokad einzuführen.
2.13 Zentralisieren Sie das Benutzermanagement?
Ja. Lokad verfügt über ein zentrales Benutzermanagement für die von uns betriebene Lösung. Dieses Subsystem wurde von Lokad implementiert und deckt auch die Zugriffe von Lokad-Mitarbeitern ab, einschließlich unserer Entwicklungsteams.
2.14 Erlauben Sie generische/gemeinsame Benutzerkonten?
Nein. Lokad erzwingt eine 1-zu-1-Beziehung zwischen Mitarbeitern und Benutzern (wie sie von der Lokad-Plattform gesehen werden). Wir raten dringend von der Verwendung gemeinsamer Benutzerkonten ab. Tatsächlich ist einer der Gründe, warum wir pro Benutzer nicht berechnen, 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 keinen entsprechenden Mitarbeiter hat. Dies geschieht typischerweise für den clientseitigen “Robot-Upload”-Dienst, der für das Übertragen von Daten an Lokad zuständig ist. Im Rahmen unserer RBAC (Rollenbasierte Zugriffskontrolle) haben wir eine dedizierte Rolle (genannt “Uploader”), die minimale Rechte für diesen speziellen Anwendungsfall bietet.
2.15 Bieten Sie sichere VPN-Verbindungen an?
Nein. Die Verbindungen der Endbenutzer erfolgen über verschlüsselte Kanäle (typischerweise TLS).
2.16 Erlauben Sie Benutzern, sich von mehreren Geräten aus anzumelden?
Ja, innerhalb von Grenzen. Im Allgemeinen liegt das obere Limit bei 6 Geräten pro Benutzer (wir berechnen keine Gebühren 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 bestimmten potenziellen Bedrohungen und/oder Missbrauch entgegenzuwirken.
2.17 Hat die Lösung die Möglichkeit, einen Benutzer zwangsweise zu sperren und/oder auszuloggen (wenn er als bösartig angesehen wird)?
Ja. Diese Funktion erfordert “Owner”-Zugriffsrechte innerhalb des Lokad-Kontos.
2.18 Loggt das System einen inaktiven Benutzer automatisch nach einer festgelegten Zeit der Inaktivität aus?
Ja, wobei “Inaktivität” nicht der entscheidende Faktor ist. Lokad loggt Benutzer automatisch nach einer festgelegten Zeit aus. Benutzer können das Ausloggen nicht verzögern, indem sie “aktiv” sind; sobald die festgelegte Zeit erreicht ist, müssen sich Benutzer erneut authentifizieren.
2.19 Ist die Verwendung von gemeinsamen Konten und/oder Zugriffsberechtigungen verboten, und wird die Einhaltung dieser Richtlinien überwacht?
Ja. Siehe Authentifizierung 2.14.
2.20 Werden Benutzer-IDs und Passwörter über separate Medien (z. B. E-Mail und Telefon) kommuniziert/verteilt?
Ja, wir legen Wert auf die Sicherheit von Benutzeranmeldeinformationen und stellen sicher, dass sie auf eine Weise kommuniziert werden, die den bewährten Verfahren entspricht. Intern nutzen unsere Systeme Azure Active Directory zur Benutzerauthentifizierung. Wenn Benutzer-IDs und anfängliche Passwörter verteilt werden, folgt Azure Active Directory seinen Standardmustern, die mit Sicherheit im Hinterkopf entworfen sind. Darüber hinaus setzen wir die Zwei-Faktor-Authentifizierung für unser Azure AD durch, um dem Authentifizierungsprozess eine zusätzliche Sicherheitsebene hinzuzufügen.
Extern empfehlen wir den Mitarbeitern von Kunden, die sich mit unseren Systemen verbinden, die Verwendung von Single Sign-On (SSO) und föderierten Identitätssystemen nachdrücklich. Diese Systeme unterstützen von Natur aus bewährte Verfahren im Credential Management und stellen sicher, dass Anmeldeinformationen auf sichere Weise kommuniziert werden, oft unter Einbeziehung separater Kommunikationskanäle oder -methoden für Benutzer-IDs und Authentifizierungsmechanismen.
Es sei darauf hingewiesen, dass wir die Ein-Faktor-Authentifizierung, sei es für interne oder externe Benutzer, nicht empfehlen, wenn das Ziel darin besteht, einen hohen Sicherheitsstandard aufrechtzuerhalten.
2.21 Werden inaktive Benutzer-IDs nach definierten Zeiträumen der Inaktivität deaktiviert und gelöscht?
Ja, wir verwalten und überwachen 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, um sicherzustellen, dass ehemalige Mitarbeiter nach Beendigung ihres Arbeitsverhältnisses keinen Zugriff mehr haben.
Für unsere Kunden befürworten wir die Verwendung von Single Sign-On (SSO) und föderierten Identitätssystemen. Dieser Ansatz vereinfacht das Zugriffsmanagement. Wenn ein Kunde beispielsweise einen Mitarbeiter aus seinem Identitätssystem entfernt, wird der Zugriff auf Lokad gleichzeitig beendet. Dieser Ansatz verbessert nicht nur die Sicherheit, sondern gewährleistet auch Effizienz im Benutzermanagement.
Hinweis: Die Einzelheiten zur Beendigung des Benutzerzugriffs sind in unseren Vertragsvereinbarungen mit jedem Kunden detailliert festgelegt. Lokad erkennt nachdrücklich das potenzielle operative Risiko einer vorzeitigen Deaktivierung eines Kontos an und ergreift aktive Maßnahmen, um solche Szenarien zu vermeiden. Um unbeabsichtigte Unterbrechungen zu vermeiden, sind die Bedingungen für die Beendigung des Benutzerzugriffs explizit festgelegt, entweder im Vertrag oder in einem gemeinsam vereinbarten Verfahren, um sicherzustellen, dass die Sicherheitsmaßnahmen von Lokad mit den betrieblichen Anforderungen unserer Kunden übereinstimmen.
3. Autorisierung
3.1 Bietet die Lösung fein granulierte Zugriffsrechte?
Ja. Die Lokad-Lösung umfasst ein granulares RBAC (rollenbasiertes Zugriffskontrollsystem). Dies ermöglicht es dem Kunden, zu steuern, auf welche “Projekte” und “Dateien” im Lokad-Konto zugegriffen werden kann (und von wem). Das RBAC verfügt über eine eigene webbasierte Benutzeroberfläche (Dashboard). Es steht allen Benutzern mit der Bezeichnung “Eigentümer” innerhalb des Lokad-Kontos zur Verfügung. Weitere Informationen finden Sie in unserer Dokumentation zu Benutzerrollen und -berechtigungen.
3.2 Ermöglicht die Lösung dem Kunden, den Zugriff gemäß dem Prinzip des geringsten Privilegs (PoLP) zu konfigurieren?
Ja. Die Lokad-Lösung umfasst ein granulares RBAC (rollenbasiertes Zugriffskontrollsystem), das zur Umsetzung des PoLP verwendet werden kann. Durch Envision (die DSL der Lösung) geht Lokad jedoch viel weiter als die meisten Unternehmenssoftware in Bezug auf dieses Prinzip.
Durch Envision hat Lokad ganze Gruppen von Systemberechtigungen eliminiert, die für die Optimierung der Supply Chain einfach irrelevant sind. Was bleibt, ist zwar vereinfacht, aber dennoch weitgehend konfigurierbar. Ebenso eliminiert das maßgeschneiderte Dateisystem, das von Lokad angeboten wird, ganze Gruppen von unnötigen Systemberechtigungen.
3.3 Werden Zugriffsrechte mit dem geringsten Privileg durchgesetzt?
Ja, obwohl was als “mindestens akzeptables” Privileg gilt, letztendlich von unseren Kunden entschieden wird. Lokad kann nicht einseitig festlegen, wer von einer Bezeichnung als “Eigentümer” im Personal unseres Kunden profitiert. Wir können jedoch in dieser Hinsicht Anleitung geben. In der Praxis klären wir für unsere “betreuten” Kunden - die von Lokads Team von Supply Chain Scientists unterstützt werden - die gewünschte Organisation und die entsprechenden Zugriffsrechte (schriftlich).
3.4 Hat die Lösung die Möglichkeit, eine bestimmte Entität im System vor ausgewählten Benutzern zu verbergen?
Ja. Dies ist eine Form der PoLP-Implementierung und wird in den Antworten 3.1, 3.2 und 3.3 behandelt.
3.5 Gibt es eine Klassifizierung für Daten (Sensitivitätsstufen) und werden die Steuerungen entsprechend dieser Klassifizierung angepasst?
Ja. Als integriertes Element beschränkt Lokad standardmäßig alle administrativen Daten (wie die Liste der Benutzer mit einem Konto) auf die “Eigentümer” des Kontos. Diese Bezeichnung ist die höchste und privilegierteste des RBAC (rollenbasiertes Zugriffskontrollsystem). Alle anderen Daten im Lokad-Konto können gemäß einer benutzerdefinierten Sensitivitätsklassifizierung segmentiert werden. Diese benutzerdefinierte Klassifizierung kann sowohl auf die ursprünglichen Daten (wie vom Kunden hochgeladen) als auch auf die transformierten Daten (das Ergebnis von Datenverarbeitungen innerhalb der Lokad-Plattform) angewendet werden.
Für weitere Informationen zu Zugriffskontrollen und Bezeichnungen siehe Antworten 3.1, 3.2 und 3.3.
3.6 Kann die Lösung Benutzer/Rollen/Transaktionen in Echtzeit autorisieren oder blockieren?
Ja, obwohl “in Echtzeit” im Kontext eines verteilten Computersystems (wie der Lokad-Lösung) näher erläutert werden muss. Aktualisierungen des RBAC (rollenbasiertes Zugriffskontrollsystem) erfolgen synchron, was bedeutet, dass Aktualisierungen innerhalb weniger Sekunden aktiv werden (in der Regel weniger). Es gibt keine spürbaren Verzögerungen (wie eine einstündige oder eintägige Wartezeit).
Was die Unterbrechung von Transaktionen betrifft, ist dies nicht relevant, da Lokad keine transaktionale Datenbank hat. Lokad kann jedoch lang laufende asynchrone Operationen unterbrechen (bei Lokad als “Projektdurchläufe” bezeichnet). Wenn eine Unterbrechung ausgelöst wird, stellt sie sofort (synchron) sicher, dass die Verarbeitung das System nicht beeinträchtigt, z. B. durch Überschreiben von Dateien. Das Stoppen 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) nur auf Benutzer mit der richtigen Berechtigungsstufe?
Ja, obwohl die Lösung nicht dazu gedacht ist, PII-Daten zu speichern (über die Authentifizierungsidentifikatoren der Mitarbeiter mit Zugriff auf die Lösung hinaus). Dies gilt sowohl für Lokad als auch für den Kunden. Innerhalb der Lösung haben nur Mitarbeiter mit der Bezeichnung “Eigentümer” Zugriff auf die Liste der Benutzer. Für die Zwecke der Optimierung der Lieferkette benötigt Lokad keine (oder profitiert nicht von) PII-Daten, und wir haben vertragliche Bestimmungen zu diesem Zweck (erläutert in Praktiken 1.4 & Praktiken 1.5).
Für weitere Informationen zu Zugriffskontrollen und Bezeichnungen siehe Antworten 3.1, 3.2 und 3.3.
3.8 Erlaubt die Lösung die Suche nach personenbezogenen Daten (PII) mit Suchfiltern, die Platzhalter-Suchen verbieten?
Ja. Ein Benutzer mit der Bezeichnung “Eigentümer” innerhalb eines Lokad-Kontos kann jedoch auf alle Benutzer (einschließlich Mitarbeiter des Kunden) zugreifen, die berechtigt sind, auf das Konto zuzugreifen. Lokad kann diese Fähigkeit nicht einschränken, da unsere Kunden in der Lage sein müssen, die Liste der Benutzer mit Zugriff auf ihr eigenes Konto vollständig zu überprüfen.
3.9 Ist das System mit WAF (Web Application Firewall) -Technologie ausgestattet?
Nein. WAF ist ein inhärent gefährliches Design, da es das Sicherheitsprinzip der “geringsten Rechte” verletzt: Ein Komponente erhält enorme Rechte, um als “Man in the Middle” zu agieren. Dies macht die WAF selbst zu einem Hauptziel für Angreifer und erweitert die Angriffsfläche der Plattform erheblich. Lokad überwacht jedoch seinen Webverkehr genau und ungewöhnliches Benutzerverhalten auf unserer eigenen Plattform. Diese Fähigkeiten sind jedoch Teil der Plattform selbst und werden daher nicht an privilegierte isolierte Softwarekomponenten delegiert.
Siehe auch Mitarbeiter 6.6.
3.10 Ist das Netzwerk mit IPS (Intrusion Prevention System) -Technologie ausgestattet?
Nein. IPS ist ein inhärent gefährliches Design, da es das Sicherheitsprinzip der “geringsten Rechte” verletzt: Ein Komponente erhält enorme Rechte, um als “Man in the Middle” zu agieren. Dies macht das IPS selbst zu einem Hauptziel für Angreifer und erweitert die Angriffsfläche der Plattform erheblich. Um die Lokad-Plattform gegen Eindringen abzusichern, beginnt unser Design damit, die Angriffsfläche zu minimieren. Wir glauben, dass es viel sicherer ist, Eintrittspfade durch Design zu eliminieren, anstatt zu versuchen, sie nachträglich zu “verhindern”.
Siehe auch Mitarbeiter 6.6.
3.11 Nutzt der Dienst DoS (Denial-of-Service) -Schutztechnologie?
Ja. Lokad nutzt ReCaptcha, nginx-Ratenlimits und unsere eigenen spezifischen Komponenten (wie 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 ähnlich wie ‘Teleport’ ist. Dies bietet nicht nur eine vollständige Rückverfolgbarkeit aller Zugriffe, sondern erleichtert auch den sicheren Widerruf von Zugriffsrechten für Mitarbeiter.
3.13 Gibt es einen klaren Autorisierungsprozess zur Gewährung von administrativem Zugriff (und einen, der eine zuverlässige Audit-Trail erzeugt)?
Ja. Siehe Logging und Überwachung 5.1 und 5.11.
3.14 Gibt es einen systematischen und regelmäßigen Zugriffsrechtsüberprüfungsprozess (durch eine autorisierte Person), bei dem administrative Zugriffsrechte gegen alle geänderten Rollen und Aufgaben überprüft werden?
Ja. Es gibt zwei Ebenen von administrativen Zugriffsrechten.
Erste Ebene: die administrativen Rechte zur Unterstützung der Infrastruktur von Lokad. Diese Rechte werden von der IT-Abteilung von Lokad gewährt und überwacht.
Zweite Ebene: die administrativen Zugriffsrechte innerhalb jedes Lokad-Kontos. Diese Rechte werden von dem Supply Chain Scientist, der für das Konto zuständig ist, gewährt und überwacht - für unsere verwalteten Konten. Alternativ werden diese Rechte von der Kundenfirma selbst gewährt und überwacht, wenn das Konto nicht direkt von Lokad/einem Supply Chain Scientist verwaltet wird.
3.15 Folgt Ihre Zugriffsbeschränkungsrichtlinie dem Prinzip der “geringsten Rechte”, bei dem nur notwendiger und genehmigter Datenverkehr zugelassen ist?
Ja. Wir wenden das Prinzip der geringsten Rechte (PoLP) auf alle Zugriffsebenen unserer Infrastruktur an, einschließlich Netzwerkverkehr. Die Strenge der Zugriffsbeschränkungen variiert je nach Anwendungsfall. Zum Beispiel ist für einige Zugriffe nur ein bestimmter authentifizierter Benutzer von einer bestimmten IP-Adresse zugelassen. In anderen Szenarien kann jeder überall zugreifen, wie es bei den Inhalten unseres CDN (Content Delivery Network) der Fall ist.
Siehe auch Autorisierung 3.3.
3.16 Sind ausgehende Verbindungen aus der Produktionsumgebung eingeschränkt?
Nein, ausgehende Verbindungen aus der Produktionsumgebung sind nicht universell eingeschränkt. Während einige spezialisierte Server wie Lastenausgleicher ausgehende Beschränkungen haben, haben die meisten unserer Server dies nicht.
Unsere Produktions-VMs benötigen Zugriff auf mehrere externe APIs. Ein Großteil dieser APIs wird von Microsoft Azure gehostet, mit einigen Ausnahmen wie letsencrypt.org. Wir haben festgestellt, dass die Aufrechterhaltung einer rigorosen Whitelist von IP-Adressen Komplexitäten einführen könnte, die die Vorteile aufheben könnten. Die Beschränkung ausgehender Verbindungen könnte begrenzte Sicherheitsvorteile bieten, aber auch Komplikationen einführen, die die Sicherheit unserer Produktionsumgebung potenziell untergraben könnten.
3.17 Steht eine besetzte Form der Kommunikation (z. B. E-Mail, Webformular, Telefon usw.) Kunden/Klienten rund um die Uhr an 365 Tagen im Jahr zur Verfügung, um Sicherheitsvorfälle zu melden?
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 enthält Informationen dazu, wie Sicherheitslücken gemeldet werden können.
Unsere security.txt
-Datei befindet sich unter https://www.lokad.com/.well-known/security.txt und enthält den aktuellen Prozess zur Meldung von Sicherheitsvorfällen. Dadurch wird sichergestellt, dass jeder, sei es ein Kunde, ein Klient oder ein Sicherheitsforscher, die relevanten Kontaktinformationen und Richtlinien zur Meldung von Sicherheitsbedenken leicht finden kann.
Bitte beachten Sie, dass, obwohl der in der ‘security.txt’ beschriebene Prozess überarbeitet werden kann, die aktuellsten und genauesten Informationen immer an diesem Endpunkt verfügbar sein werden. Wir stellen sicher, dass die in der Datei genannten Kommunikationskanäle, sei es per E-Mail, Webformular oder einem anderen Medium, rund um die Uhr besetzt und verfügbar sind, um Sicherheitsberichte zeitnah zu bearbeiten.
4. Datenmanagement
4.1 Wo werden die Daten gehostet und verarbeitet?
Unsere SaaS (Software as a Service) Plattform wird zu 100% auf Microsoft Azure gehostet; genauer gesagt, sie wird im Microsoft Azure Rechenzentrum Europe North (mit Sitz in Dublin) gehostet. Unsere Backups werden im Microsoft Azure Rechenzentrum Europe West (mit Sitz in Amsterdam) gespeichert. Im Falle eines größeren Ausfalls eines Rechenzentrums haben wir Notfallpläne, um die Plattform nach Dublin zu migrieren. Seit unserer Migration zu Microsoft Azure im Jahr 2010 haben wir diese Situation nie erlebt. Alle Daten unserer Kunden befinden sich in Europa, wo sie auch im Falle eines größeren Ausfalls eines Rechenzentrums verbleiben werden.
4.2 Wem gehören die Daten?
Unsere Kunden bleiben die alleinigen Eigentümer aller Daten, die sie bei 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 seiner Kunden nicht intern für Zwecke, die nicht direkt zu den Aufgaben beitragen, die unsere Kunden uns zur Durchführung übertragen haben. Lokad verkauft den Zugriff auf die Daten seiner Kunden nicht an Dritte. Lokad teilt den Zugriff auf Kundendaten nicht, außer für die wenigen Hosting-Anbieter, die direkt zur Aufgabe beitragen (z. B. das Mieten von virtuellen Maschinen von einer Cloud-Computing-Plattform, um die von unseren Kunden angeforderten Berechnungen durchzuführen).
4.3 Wird das Datenbankmanagement intern oder extern gehandhabt?
Das Datenmanagement von Lokad wird von den Entwicklungsteams von Lokad durchgeführt. Wie bereits erwähnt, enthält die Kernplattform von Lokad keine transaktionale Datenbank (siehe Autorisierung 3.6), da Lokad stattdessen ein Ereignisspeicher verwendet. Dieser Ereignisspeicher wird vollständig von Lokad implementiert und betrieben.
4.4 Hat die Lösung die Möglichkeit, zwischen RDBMS-Datenbanken (PostgreSQL, Oracle, MySQL) und Non-SQL-Datenbanken (Cosmos) zu wechseln?
Theoretisch ja, aber dies ist irrelevant, da die Lokad-Lösung keine RDMBS verwendet. Die Datenspeicherschicht der Lokad-Lösung nutzt einen Ereignisspeicher und einen Schlüssel-Wert-Speicher. Dieser Ansatz unterscheidet sich erheblich vom CRUD (Create-Read-Update-Delete)-Design, das in Unternehmenssoftware üblich ist. Da Lokad eine SaaS-Lösung ist, übernehmen wir die volle Verantwortung für die Datenspeicherung und die Vorwärtskompatibilität (um sicherzustellen, dass ältere Daten weiterhin 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 Drittanbieter, die an der Ausführung der Lösung beteiligt sind, ist sehr kurz und beschränkt sich auf die Infrastrukturhosting auf niedrigerer Ebene. Lokad verwendet keine Drittanbieter zur Entwicklung, Verwaltung oder Betrieb seiner eigenen Lösung. Insbesondere sind sowohl unsere Entwicklungsteams als auch unsere technischen Supportteams intern.
4.6 Trennen Sie die Schichten (Netzwerke, Server und Anwendungen)?
Ja, jedoch wird das Low-Level-Management von Netzwerken und Servern an die zugrunde liegende Cloud-Computing-Plattform delegiert, die Lokad verwendet - Microsoft Azure. Somit liegt die Trennung der Netzwerk- und Serverebenen größtenteils außerhalb des von Lokad verwalteten Perimeters. Innerhalb der Lokad-Lösung beschränken wir stark die Rechte, die den applikativen Schichten gewährt werden, sodass sie ihre eigene Infrastruktur nicht verwalten können (z. B. haben die applikativen Schichten keinen Schreibzugriff auf die Verwaltung von DNS).
4.7 Haben Sie einen Prozess, um die dauerhafte Löschung von Daten sicherzustellen?
Ja, obwohl es mehrere Wochen dauern kann, um alle Schritte abzuschließen. Der Prozess beinhaltet die Erstellung einer formellen schriftlichen Anfrage - ausgestellt von einer autorisierten Partei innerhalb der Kundenorganisation - um die entsprechenden Daten dauerhaft zu löschen. In der Praxis sind spezifische Bestimmungen für solche Anfragen in die Vertragsvereinbarung zwischen Lokad und seinen Kunden aufgenommen. Die Daten werden zuerst aus unserem primären Produktionssystem gelöscht und dann aus unserem Backup-System. Die letzte Phase ist der Grund für die relative “Langsamkeit” des Vorgangs. Dies ist eine Designentscheidung, da die Daten, sobald sie aus unserem primären System gelöscht sind, nicht mehr abgerufen werden können (außer über außergewöhnliche Disaster-Recovery-Prozesse).
Standardmäßig stellt die Lokad-Lösung sicher, dass alle Standardlöschvorgänge Soft Deletes sind (d. h. keine dauerhaften Löschungen). Dieses Design ist notwendig, um ganze Klassen von Sicherheitsproblemen zu vermeiden, wie z. B. versehentliches Löschen von Daten durch einen Mitarbeiter des Kunden oder böswilliges Löschen durch einen Angreifer. Auch ein absichtlich langsamer Prozess der dauerhaften Löschung ist erforderlich, um Social-Engineering-Angriffe zu mildern, wie z. B. ein Szenario, in dem ein Angreifer sich als Mitarbeiter eines Kunden ausgibt.
4.8 Hat die Lösung die Kapazität, Daten soft zu löschen?
Ja. Die Lokad-Lösung verwendet ein Event-Sourcing-Design. Daher ist standardmäßig alles versioniert, sowohl die Benutzereingaben als auch die Änderungen am Dateisystem von Lokad. Somit sind alle Softwarelöschungen Soft Deletes, und diese können bei Bedarf nachverfolgt und rückgängig gemacht werden.
4.9 Bieten Sie direkten Datenbankzugriff an?
Ja, in dem Sinne, dass das Dateisystem - 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 produziert werden, in diesem Dateisystem gespeichert sind.
Da Lokad jedoch keine transaktionale Datenbank hat, gibt es keine zugrunde liegende Datenbank, die “zugänglich” gemacht werden könnte. Das Äquivalent in der Lokad-Architektur ist unser Ereignisspeicher, und wir bieten keinen direkten Zugriff auf den Ereignisstrom an. Es könnten jedoch Bestimmungen in der Vertragsvereinbarung getroffen werden, wenn ein Kunde spezifische Extraktionen aus diesem Ereignisstrom anfordern würde (sofern es einen gültigen Anwendungsfall gibt).
4.10. Wie integriert die Lösung externe Daten?
Die Lösung kann mehrere Protokolle nutzen, um externe Daten zu integrieren, insbesondere FTPS und SFTP. Eine webbasierte Benutzeroberfläche steht auch zur manuellen Dateiübertragung zur Verfügung. Die Lokad-Lösung kann beliebige tabellarische Daten integrieren. Weitere Informationen zu den externen Integrationsmöglichkeiten von Lokad finden Sie unter Gehe zu IT-Perspektive zu Lokad 2.15.
4.11 Hat das System die Kapazität, Änderungsdaten aus Echtzeit-Datenfeeds zu verarbeiten?
Ja, unter der Voraussetzung einer spezifischen vertraglichen Vereinbarung mit dem Kunden. Die Erfassung von Änderungsdaten ist ein Software-Designmuster - kein spezifischer Datenstandard oder Datenübertragungsprotokoll - und die Erwartungen an “Echtzeit” können von Sub-Millisekunden-Latenzen bis zu Sub-Minuten-Latenzen variieren. Funktionen in diesem Bereich müssen aus einer Supply-Chain-Perspektive bewertet werden. In unserer Erfahrung sind Echtzeit-Datenfeeds selten relevant für die Lösung von Supply-Chain-Problemen.
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 Tools zum Exportieren von Daten?
Ja, die Lokad-Lösung bietet eine DSL (domänenspezifische Sprache) namens Envision, die für die Analyse der Lieferkette entwickelt wurde. Envision bietet umfangreiche Möglichkeiten, die Daten innerhalb des Lokad-Kontos neu zu formatieren.
4.14 In welchem Format werden die exportierten Daten sein?
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, Textcodierung, Überschriften usw.
4.15 Bietet die Lösung Transparente Datenverschlüsselung (TDE) von personenbezogenen Daten (PII) in mobilen und Back-End-Speichern?
Transparente Datenverschlüsselung wird sowohl im Back-End-Speicher von Lokad (durch Azure Storage-Verschlüsselung für ruhende Daten) als auch auf von Lokad ausgegebenen Geräten (durch BitLocker) verwendet. Lokad speichert keine PII auf Geräten ohne aktiviertes TDE.
4.16 Sind alle Passwörter und Geheimnisse, die in der Anwendung verwendet werden, verschlüsselt und im Quellcode, in Konfigurationsdateien, Build-Parametern usw. nicht im Klartext zugänglich?
Ja. Alle auf Plattformebene verwendeten Geheimnisse werden im Key Vault gespeichert, einem von Microsoft Azure angebotenen Dienst. Die Benutzerpasswörter werden intern gesalzen und mit Scrypt gehasht gemäß den Standardpraktiken.
4.17 Hat die Lösung die Möglichkeit, Datei-Uploads basierend auf Dateityp und -größe zu beschränken und nach bösartigem Inhalt zu scannen?
Ja, in begrenztem Umfang. In Bezug auf die Dateigröße erfordert die Optimierung der Lieferkette häufig die Verarbeitung großer Dateien. Diese Dateigrößen spiegeln die Extraktion der historischen Geschäftsdaten wider, die wir letztendlich verarbeiten (z. B. historische Verkaufsaufträge). Angesichts dieser Realität unterstützt die Lokad-Plattform Dateigrößen von bis zu 100 GB.
In Bezug auf den Dateityp 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 sich in unserer Vertragsvereinbarung widerspiegeln.
In Bezug auf die Fähigkeit, nach bösartigem Inhalt zu scannen, verfügt Lokad nicht über diese Funktion. Unsere Lösung betont das Teilen von plattformgeneriertem Inhalt. Darüber hinaus stellt das von uns angenommene Design sicher, dass die innerhalb von Lokad generierten Dateien sicher sind, auch wenn die Eingabedateien es nicht sind. Umgekehrt betont die Lokad-Lösung durch ihr Design das Teilen von vom Benutzer hochgeladenem Inhalt über Lokad nicht.
4.18 Was ist die empfohlene Datenspeicherungsdauer?
Lokad ist SaaS, daher tragen wir die Verantwortung für die Auswahl der geeigneten Datenspeicherungsdauer, und diese variiert je nach Art der Daten. Transaktionshistorische Daten, die vom Kunden über die Datenextraktionspipeline an Lokad übermittelt werden, werden in der Regel für die Dauer des Lokad-Dienstes aufbewahrt. Tatsächlich lohnt es sich in der Regel, historische Daten für beliebig lange Zeiträume aufzubewahren (außerhalb der Grenzen des Lokad-Dienstes). Am anderen Ende des Spektrums befinden sich die Instrumentierungsdaten, die die feingranulare Leistung unserer Plattform widerspiegeln. Diese Daten sind nur nützlich zur Fehlerbehebung unerwarteter Verlangsamungen innerhalb der Plattform. Diese Daten sind äußerst granular und werden in der Regel nicht länger als einige Wochen aufbewahrt.
4.19 Bieten Sie eine Dokumentation der Datenstruktur an?
Ja, im Rahmen des “Gemeinsamen Verfahrenshandbuchs”. Es sollte beachtet werden, dass Lokad im Gegensatz zu den meisten Unternehmenssoftwarelösungen keine relationale Datenbank verwendet. Stattdessen verwenden wir ein Event-Sourcing-Paradigma. Die für das Kundenunternehmen interessanten Datenstrukturen befinden sich jedoch nicht in der Ereignisquelle, sondern in den durch Envision-Skripte innerhalb der Lokad-Plattform erstellten Flachdateien. Diese Flachdateien sind so konzipiert, dass sie den spezifischen Anforderungen des Kundenunternehmens entsprechen. Die Dokumentation für diese Dateien ist im “Gemeinsamen Verfahrenshandbuch” enthalten - das ist 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-App ist, werden Daten auf Designebene zwischen Mandanten, d.h. Kundenkonten, getrennt. Diese Partitionierung ist ein integraler Bestandteil unseres Backend-Designs. Dieses Design verhindert Programmierfehler, die die Daten eines Mandanten einem anderen Mandanten aussetzen würden, während gleichzeitig alltägliche Funktionen innerhalb der Plattform weiterentwickelt werden. Der primäre zugrunde liegende Speicher, den Lokad verwendet - Blob Storage von Microsoft Azure - ermöglicht eine solche strikte Partitionierung auf Designebene.
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, um dem Software-Engineering-Team ein reibungsloses Arbeiten ohne Zugriff auf Kundendaten zu ermöglichen. Lokad verwendet intern auch seine eigene Plattform für Datenverarbeitungszwecke (z. B. Analyse des feingranularen Verbrauchs von Cloud-Computing-Ressourcen, die von Microsoft Azure erhalten wurden). Diese Praxis des “Dogfooding” stellt sicher, dass Lokad auch über eine reichliche Menge an unkritischen Daten für Entwicklungs- und Testzwecke verfügt.
Wir haben jedoch eine spezielle eingeschränkte Pipeline entwickelt, um minimale (nur-Lese-) Fragmente von Kundendaten zu Diagnosezwecken abzurufen. Diese Pipeline gewährleistet automatisch eine strenge und vollständig automatisierte Minimierung der abgerufenen Daten. Diese Pipeline gewährleistet auch automatisch die Löschung der Daten am Ende des Diagnosevorgangs. Weitere Details zu dieser eingeschränkten Pipeline finden Sie unter 4.22.
4.22 Wenn die Entwicklung oder Tests eine begrenzte Verwendung von Kundendaten erfordern, gibt es einen definierten Prozess zur sicheren und vollständigen Vernichtung der Daten in Entwicklungs- und Testumgebungen?
Ja, wir haben eine spezielle (nur-Lese-) Datenpipeline entwickelt, die der außergewöhnlichen Verwendung von Kundendaten zu Diagnosezwecken - in der Regel Leistungstests - gewidmet ist. Diese Datenpipeline ist nur für einen eingeschränkten Teil des Software-Engineering-Teams zugänglich.
Diese Datenpipeline wurde entwickelt, um automatisch das Fragment der Kundendaten zu minimieren, das für die Diagnose von Interesse ist. Diese Funktion ermöglicht es uns, in der Regel mit einem sehr kleinen Bruchteil der ursprünglichen Daten zu arbeiten (wie sie im Kundenkonto zu finden sind). Darüber hinaus entfällt die Notwendigkeit für das Engineering-Team, manuell auszuwählen, welche Daten abgerufen werden sollen.
Schließlich löscht diese Datenpipeline automatisch die abgerufenen Daten am Ende des Diagnosevorgangs.
4.23 Sind alle physischen Standorte der Kundendaten bekannt und dokumentiert, einschließlich Backup- und Hochverfügbarkeitssysteme?
Ja. Alle Kundendaten werden in den physisch gesicherten Rechenzentren von Microsoft Azure gespeichert, einschließlich Backups. Wir speichern keine Kundendaten lokal (d.h. in den Räumlichkeiten von Lokad) und Kundendaten werden auch nicht auf den Geräten der Mitarbeiter gespeichert.
4.24 Ist der Zugriff auf physische Serverstandorte auf Mitarbeiter beschränkt, die ihn zur Ausübung ihrer Arbeit benötigen?
Ja, obwohl die Daten der Kunden von Lokad in den sicheren Rechenzentren von Microsoft Azure gespeichert sind - einem Ort, zu dem Lokad keinen physischen Zugriff hat. Der physische Standort der Rechenzentren von Microsoft ist öffentlich bekannt, und die Wahl der Rechenzentren von Lokad ist öffentlich dokumentiert.
4.25 Wird die Primärkontonummer (PAN) nur gespeichert, wenn dies für legitime Geschäftszwecke unbedingt erforderlich ist?
Lokad empfängt, speichert oder verwaltet keine Client-PANs.
Die PAN (Primary Account Number) bezieht sich in der Regel auf die Hauptnummer auf einer Kreditkarte oder einer Debitkarte. Es handelt sich um 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.
Zur Abwicklung von Zahlungen verlassen wir uns ausschließlich auf Dritte, die PANs für uns verwalten. Es sei jedoch darauf hingewiesen, dass der Großteil der von Lokad erhaltenen Transaktionen über Überweisungen abgewickelt wird, was das Problem der Verwaltung von PANs vollständig beseitigt.
Wir haben einige PANs - für die eigenen Karten von Lokad -, die wir sicher verwalten, unter Beachtung der von den Banken selbst bereitgestellten Richtlinien.
4.26 Werden unverschlüsselte Primärkontonummern (PANs) niemals über Endbenutzer-Messaging-Technologien gesendet (zum Beispiel per E-Mail, Instant Messaging und Chat)?
Ja, unverschlüsselte PANs (Primary Account Numbers) werden niemals über unsichere Kanäle wie E-Mail gesendet. Lokad bietet einen integrierten sicheren Kommunikationskanal auf seiner Plattform, der eine überlegene Alternative für die Übermittlung sensibler Materialien darstellt. Wir empfehlen diesen Kanal, wenn die Verwendung eines unsicheren Kanals ein erhebliches Geschäftsrisiko darstellt.
Hinweis: Lokad empfängt, speichert oder verwaltet ausdrücklich keine Client-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(n) abgeschlossen und enthält dieser Vertrag Klauseln zu den Informationssicherheitsvereinbarungen des Cloud-Computing-Dienstleisters?
Ja, Lokad hat einen Enterprise-Vertrag (EA) mit Microsoft für Azure-Cloud-Computing-Dienste abgeschlossen. Der Enterprise-Vertrag enthält in der Regel verschiedene Bedingungen in Bezug auf die Nutzung der Dienste, einschließlich Verpflichtungen zur Sicherheit der Cloud-Umgebung.
Microsoft Azure, als einer der führenden Cloud-Service-Anbieter, legt großen Wert auf Sicherheit. Azure verfügt über eine umfassende Reihe von Sicherheitsfunktionen und -praktiken, um Daten in der Cloud zu schützen, und diese spiegeln sich oft in ihren Vertragsvereinbarungen mit Unternehmenskunden wider.
Während wir die spezifischen Details unseres Vertrags öffentlich nicht offenlegen können, sind wir nach mehr als einem Jahrzehnt der Zusammenarbeit mit Microsoft zufrieden, dass dieser Vertrag unseren Sicherheitsanforderungen und -standards entspricht.
4.28 Sind Unterauftragnehmer an der Verarbeitung der Kundendaten beteiligt?
Nein, Lokad vergibt die Verarbeitung von Kundendaten nicht an Unterauftragnehmer. In Bezug auf die Plattform von Lokad kaufen wir jedoch Rechenressourcen - hauptsächlich virtuelle Maschinen und Blob-Speicher - von Microsoft Azure, aber abgesehen davon sind keine Drittanbieter an der Verarbeitung von Kundendaten beteiligt.
Was die Bereitstellung der professionellen Dienstleistungen von Lokad betrifft, haben nur Vollzeitmitarbeiter von Lokad (in diesem Fall die Supply Chain Scientists) Zugriff auf Kundendetails oder -daten. Lokad hat gelegentlich einige Praktikanten (obwohl viel weniger als die meisten vergleichbaren Unternehmen) für Langzeitpraktika, aber sie arbeiten unter der direkten und strengen Aufsicht erfahrener Supply Chain Scientists.
Hinweis: Praktikanten unterliegen denselben Vertraulichkeitsvereinbarungen wie Vollzeit-Supply-Chain-Scientists.
5. Protokollierung und Überwachung
5.1 Bieten Sie Zugriffsprotokolle (Benutzer, Datum, letztes Verbindungsdatum usw.) an?
Ja. Lokad stellt Zugriffsprotokolle im CSV-Format bereit. Zu diesem Zeitpunkt können diese Protokolle vom Support-Personal von Lokad angefordert werden. Die Protokollextraktion wird im Lokad-Konto an einem Ort platziert, der nur für Benutzer mit der Bezeichnung “Eigentümer” zugänglich ist. Wir planen, eine direktere Zugriffsmethode - über eine dedizierte Web-Schnittstelle - auf den vollständigen Prüfpfad einzuführen, der bereits im Backend der Lokad-Plattform vorhanden ist.
5.2 Zentralisieren Sie die Protokolle aller Komponenten in der Lösung?
Ja. Das ereignisgesteuerte Design von Lokad zentralisiert nicht nur die Protokolle, sondern auch alle Zustandsänderungen, die in der Lösung auftreten. Die Protokolle sowie andere Zustandsänderungen werden mit einer kleinen Sammlung von Ereignisströmen zentralisiert, die vom gleichen Ereignisspeicher 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 Ereignisspeicher zentralisiert sind. Diese Protokolle umfassen feinkörnige Leistungsmessungen, wie sie beispielsweise von der internen Leistungsprofilierungsinstrumentierung von Lokad erstellt 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 “sicherheitsrelevante” Materialien qualifiziert wäre.
5.3 Protokollieren Sie Änderungen und Vorgänge, die in der Anwendung durchgeführt werden? Verfolgen Sie alle Transaktionen?
Ja. Aufgrund des ereignisgesteuerten Designs von Lokad wird alles aus Notwendigkeit protokolliert. Tatsächlich ist die Lösung selbst die Summe der innerhalb der Lösung aufgezeichneten Ereignisse. Daher ist die Protokollierung ein grundlegender Aspekt der Architektur der Lösung. Dieses ereignisgesteuerte Design verhindert das versehentliche Auslassen eines Protokolls, das eine Zustandsänderung widerspiegelt. Unter einem solchen ereignisgesteuerten Rahmen 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 Informationen enthalten, die mit einer Zustandsänderung verbunden sind.
5.4 Normalisieren Sie die Protokollformate der verschiedenen Komponenten zu forensischen Zwecken?
Ja. Die “Protokolle”, aus Sicht der Überprüfung und/oder Sicherheit, sind die Transformationen 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, Nummernformate und Benutzerkennungen, die in der CSV-Extraktion verwendet werden.
5.5 Bieten Sie Protokollexporte an Dritte über ein Abfrageprotokoll an?
Ja, unter der Voraussetzung einer vertraglichen Vereinbarung mit dem Kunden.
5.6 Verfolgen Sie alle Ausnahmen, die in Ihrer Lösung ausgelöst werden?
Ja. Das ereignisgesteuerte Design von Lokad ermöglicht es uns, alle in unserer Lösung ausgelösten Ausnahmen zu verfolgen und die Bedingungen zu reproduzieren, die zum Problem geführt haben. Sobald identifiziert, beseitigt das Entwicklungsteam von Lokad alle beobachteten Ausnahmen. Wir haben spezielle Tools für diesen spezifischen Zweck entwickelt und halten einen sehr begrenzten Rückstand an nicht behobenen Ausnahmen.
5.7 Hat die Lösung die Möglichkeit, die Gesundheit der verschiedenen Komponenten/Dienste in Echtzeit zu überwachen?
Ja. Unsere Teilsysteme wurden mit Überwachungsendpunkten zur Gesundheitsprüfung entwickelt. Wir verfügen über Überwachungstools, die nur - ab Januar 2023 - den Entwicklungsteams bei Lokad zugänglich sind und kontinuierlich die Informationen konsolidieren, die von diesen Überwachungsendpunkten bereitgestellt werden.
Wie bereits erwähnt, ist “in Echtzeit” bei verteilten Systemen recht vage. Für Zwecke der Systemüberwachung liegt die erwartete Latenzzeit zwischen wenigen Sekunden und einer Minute (ungefähr).
5.8 Hat die Lösung die Möglichkeit, Tools von Drittanbietern zur Überwachung zu integrieren? Unterstützt die Lösung SNMP oder JMX oder die Fähigkeit, SNMP- und JMX-Ereignisse an Überwachungslösungen von Drittanbietern zu senden?
Ja, unter der Voraussetzung einer dedizierten vertraglichen Vereinbarung.
5.9 Hat die Lösung die Fähigkeit, Batch-Jobs zu überwachen, die nicht wie geplant gestartet wurden, und deren Beendigung zu überwachen?
Ja. Die Lokad-Lösung verfügt über einen eigenen internen Job-Scheduler (genannt “Runflow”), um lang laufende Aufgaben innerhalb der Lokad-Plattform zu orchestrieren - typischerweise die Ausführung von Envision-Skripten. Dieser Scheduler kann über eine webbasierte Benutzeroberfläche konfiguriert werden, um einen Zeitplan und einen Ausführungszeitrahmen für jede Jobsequenz festzulegen.
5.10 Hat die Lösung die Möglichkeit, proaktive Warnungen zu generieren? Kann sie Fehler korrelieren und analysieren und dann proaktive Maßnahmen ergreifen?
Ja. Runflow, der Job-Scheduler der Lösung, kann den Kunden/Lokad alarmieren, dass eine laufende Ausführungssequenz sich verzögert. Der Alarm kann vor Abschluss der Sequenz gesendet werden. Die Lokad-Lösung bietet umfangreiche Möglichkeiten durch Envision (ihre DSL), um Situationen zu analysieren und selbst zu diagnostizieren, um proaktiv zu handeln. Obwohl die Lokad-Plattform diese Funktion bietet, erfordert sie immer noch einen Ingenieur, der - über Envision - die tatsächliche Logik implementiert, da die Supply-Chain-Situationen, die als “Fehler” gelten, variieren können.
5.11 Hat die Lösung Funktionen zur Aufbewahrung von Prüfungsdaten? Werden die Daten archiviert und in eine MIS-Datenbank zur Überprüfung der Benutzeraktivität überführt?
Ja. Durch ihr ereignisgesteuertes Design bewahrt die Lokad-Lösung eine umfangreiche Prüfspur auf; viel größer als das, was durch gängigere Designs erreicht wird, die in der Regel eine transaktionale Datenbank anstelle eines Ereignisspeichers verwenden. Die Lokad-Lösung isoliert kein Management Information System (MIS) als separates Teilsystem. Tatsächlich ist der Ereignisstrom die Prüfspur. Allgemeiner gesagt behält Lokad die Produktionsdaten für die Dauer des Dienstes beim Kunden. Bei Dienstbeendigung, die von den verhandelten vertraglichen Bedingungen abhängt, werden die Kundendaten gelöscht, 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 cloudbasierte Plattform wird von den Softwareentwicklungsteams von Lokad überwacht. Da die Lokad-Plattform mehrmandantenfähig ist, erfolgt diese Überwachung weitgehend mit einem “System”-Ansatz, der sicherstellt, dass die Fähigkeiten der Plattform (einschließlich ihres Leistungsprofils) den Standards entsprechen. Wir haben unsere eigene Instrumentierungsschicht für diesen Zweck entwickelt. Die “funktionale” Überwachung ist in der Regel kundenspezifisch, da sie von den spezifischen Merkmalen der jeweiligen 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.
Die Supply Chain Scientists von Lokad spezialisieren sich in der Regel auf eine bestimmte Klasse von Kundenkonten (z. B. Luft- und Raumfahrt). Sie entwickeln maßgeschneiderte Überwachungsinstrumente unter Verwendung des Lokad-Kontos. Diese Überwachung umfasst die Sicherstellung, dass die von Lokad gelieferten Zahlen korrekt sind, nicht nur im technischen Sinne, sondern auch aus der Geschäftsperspektive des Kunden.
5.13 Werden Protokolle zeitnah und systematisch überprüft und analysiert, um Anomalien und Hinweise auf Verstöße zu erkennen?
Ja. Die Überprüfung der laufenden Aktivitäten der Lokad-Plattform ist Teil unserer täglichen Routine. Das Design unserer Plattform erleichtert diesen Prozess.
Siehe auch Protokollierung und Überwachung 5.2.
5.14 Werden Protokollverwaltungssysteme von Personen verwaltet, die nicht in die Verwaltung der anderen Systeme involviert sind (d. h. Aufgabentrennung)?
Ja. Die Überwachung der Protokolle und der allgemeinen Aktivitäten der Plattform wird von Supply Chain Scientists durchgeführt, während die allgemeine Verwaltung unserer Infrastruktur von spezifischen Mitarbeitern in unserer IT-Abteilung durchgeführt wird.
5.15 Werden regelmäßig und systematisch Schwachstellen-Scans auf Anwendungsebene durchgeführt?
Ja, obwohl solche Scans nur einen sehr kleinen Teil unserer Sicherheitsprozesse ausmachen. Siehe Mitarbeiter 6.6.
5.16 Gibt es einen definierten Prozess für die regelmäßige Überprüfung der wirksamen Firewall-Regeln?
Ja, unsere Produktionsmaschine verfügt über sehr strenge Regeln, wie z. B. das Öffnen einer sehr begrenzten Anzahl von Ports (konfiguriert durch Microsoft Azure). Die Konfiguration unserer Infrastruktur ist skriptgesteuert, und ihre Entwicklung folgt unserem üblichen Codeüberprüfungsprozess. Diese Praxis erleichtert nicht nur regelmäßige Überprüfungen, sondern verringert auch die Notwendigkeit, die Regeln manuell zu überprüfen.
5.17 Ist das Netzwerk mit IDS (Intrusion Detection System) -Technologie ausgestattet?
Nein. IDS ist ein inhärent gefährliches Design, da es das Sicherheitsprinzip der “geringsten Rechte” verletzt: Ein Komponente erhält enorme Rechte, um als “Man in the Middle” zu agieren. Dies macht das IDS selbst zu einem Hauptziel für Angreifer und erweitert die Angriffsfläche der Plattform erheblich. Lokad überwacht jedoch seinen Webverkehr genau und ungewöhnliches Benutzerverhalten auf unserer eigenen Plattform. Diese Fähigkeiten sind jedoch Teil der Plattform selbst und werden daher nicht an privilegierte isolierte Softwarekomponenten delegiert.
Siehe auch Mitarbeiter 6.6.
6. Mitarbeiter
6.1 Haben Mitarbeiter NDAs (Geheimhaltungsvereinbarungen)?
Ja, alle Lokad-Mitarbeiter unterliegen einer Geheimhaltungsklausel in ihren Arbeitsverträgen.
6.2 Werden Mitarbeiter in Sicherheitsbewusstsein und Sicherheit geschult?
Ja, Lokad-Mitarbeiter, die mit vertraulichen Daten und/oder Engineering-Systemen in Kontakt stehen, erhalten Schulungen zum Sicherheitsbewusstsein und zur Sicherheit. Weitere Informationen zu diesem Punkt finden Sie in der Vorlesung Cybersecurity für die Lieferkette, die sich an Supply Chain Scientists richtet - die Personen, die vertrauliche Kundendaten verarbeiten.
6.3 Wer hat Zugriff auf die Kundendaten bei Lokad?
Der Kunde definiert explizit eine Liste von Benutzern, die Zugriff auf sein Lokad-Konto haben. Diese Benutzer können je nach ihren Zugriffsrechten, die im Lokad-Konto konfiguriert sind, auf verschiedene Klassen der Kundendaten zugreifen. Es gibt eine Webanwendung innerhalb der Lokad-Lösung, die der Verwaltung von Berechtigungen gewidmet ist (namens “Hub”).
Auf Seiten von Lokad gibt es für jedes Kundenkonto eine kurze Liste von Mitarbeitern, die Zugriff haben. Diese Liste umfasst in erster Linie die 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 Daten des Kunden zugreifen. Intern beschränkt Lokad den Zugriff auf Kundenkonten nur auf die Supply Chain Scientists, die diesen Konten zugewiesen sind. D.h., Supply Chain Scientist A kann nicht auf Kundenkonto B zugreifen, es sei denn, A wurde ausdrücklich damit beauftragt, dieses Konto zu verwalten (wie mit dem Kunden vereinbart).
Zweitens umfasst diese Liste das Engineering-Team, das für die Systemadministration unserer Plattform zuständig ist. Im Allgemeinen ist der direkte Zugriff auf Kundendaten selten und auf die Untersuchung von Situationen beschränkt, die entweder von den Kunden selbst oder von ihren unterstützenden Supply Chain Scientists gemeldet wurden. Lokad teilt den Zugriff auf die Kundendaten nicht mit Dritten, mit Ausnahme der Cloud-Computing-Plattform.
6.4 Wie sichern Sie die Mitarbeiterarbeitsplätze?
Mit Ausnahme des Software-Engineering-Teams arbeiten Lokad-Mitarbeiter ohne administrative Rechte an ihren vom Unternehmen bereitgestellten Geräten. Alle Arbeitsplätze sind mit Vollverschlüsselung konfiguriert, um vor Datenverlust durch den Verlust, Diebstahl oder die Weitergabe an Dritte (z.B. zur Reparatur) zu schützen.
Die von unseren Mitarbeitern verwendeten Arbeitsplätze enthalten keine Daten unserer Kunden. Je nach Aufgabe kann ein Mitarbeiter einige Excel-Tabellen auf seinen Rechner herunterladen - zum Beispiel für eine Präsentation - aber unsere Richtlinie ist es, alle Kundendaten strikt in der Cloud sicher aufzubewahren.
6.5 Wie sichern Sie Mitarbeiter-Smartphones?
Lokad-Mitarbeiter haben keine dienstlich bereitgestellten Smartphones. Nicht kritische Daten, wie Kalendererinnerungen, können über persönliche (nicht dienstlich bereitgestellte) Geräte übertragen werden, aber Smartphones enthalten, wie Arbeitsplätze, keine Daten unserer Kunden.
6.6 Verwenden Sie ein Antivirenprogramm?
Ja, unsere Arbeitsplätze verfügen über Microsoft Defender, gemäß den Microsoft Windows 10+ Setups. Neben Microsoft Defender haben wir kein weiteres Antivirenprogramm, aber unsere Einstellung ist, dass diese Art von Tool tendenziell mehr Schaden als Nutzen anrichtet (in Bezug auf die Computersicherheit). Als beispielhafter Beweis gilt der SolarWinds-Hack von 2020 als eine der größten Computersicherheitskatastrophen aller Zeiten, und er wurde durch eine Software verursacht, die eigentlich die Sicherheit verbessern sollte. Im Allgemeinen erfordern fast alle für Sicherheitszwecke vorgesehenen Softwareprodukte recht hohe Systemrechte. Als Folge werden diese Softwareprodukte zu ihren eigenen Angriffsvektoren. Unsere Perspektive zur Computersicherheit ist, dass weniger mehr ist und dass das Hinzufügen sehr komplexer Technologien in unsere Anwendungslandschaft sie fast immer unsicherer macht, nicht sicherer.
6.7 Werden die Softwareentwickler regelmäßig in der Verwendung von Bedrohungsbeurteilungsmethoden, sicheren Codierungsstandards, bekannten Sicherheitschecklisten und Frameworks geschult?
Ja. Die meisten bekannten Checklisten spiegeln jedoch hauptsächlich Architekturen wider, die “von Natur aus unsicher” sind. Wenn möglich bevorzugen wir es, die Quelle von Sicherheitsfallen bereits in der Designphase zu beseitigen. Siehe auch Mitarbeiter 6.2.
6.8 Enthalten alle Verträge mit den Subunternehmern/externen Mitarbeitern von Lokad eine Geheimhaltungsvereinbarung (NDA)? Deckt diese NDA Kundendaten ab?
Ja, obwohl Lokad - zum Zeitpunkt des Verfassens - nicht auf Subunternehmer/externes Personal angewiesen ist. Die Software-Engineering- und Supply Chain Scientist-Teams von Lokad werden vollständig von Personen unter direkter, fester Anstellung und Aufsicht von Lokad besetzt.
Wenn Lokad jedoch der Ansicht wäre, dass es notwendig ist, mit einem Subunternehmer zusammenzuarbeiten, würden sie denselben IP- (Intellectual Property) und NDA-Bedingungen wie unsere festen Mitarbeiter unterliegen. Diese Vereinbarungen enthalten Bestimmungen bezüglich Informationen über die Kunden von Lokad.
6.9 Wurde dem gesamten externen Personal von Lokad eine interne Informations- und Sicherheitseinweisung (und laufende relevante Schulungen) erteilt?
Lokad - zum Zeitpunkt des Verfassens - verlässt sich nicht auf Subunternehmer/externes Personal. Die Software-Engineering- und Supply Chain Scientist-Teams von Lokad werden vollständig von Personen unter direkter, fester Anstellung und Aufsicht von Lokad besetzt.
Wenn Lokad jedoch der Ansicht wäre, dass es notwendig ist, mit externem Personal zusammenzuarbeiten, wäre dies eine Anforderung. Alle Subunternehmer/externen Mitarbeiter würden denselben Sicherheitsprozessen und Schulungsanforderungen wie unsere festen Mitarbeiter unterliegen.
Wie bereits erwähnt, verlässt sich Lokad derzeit nicht auf externes Personal, daher findet keine solche Schulung statt.
Siehe auch Mitarbeiter 6.8
6.10 Erfordern alle Verträge mit Unternehmen, die das externe Personal von Lokad bereitstellen (alle Auftragnehmer, Berater usw., die an der Erbringung der Dienstleistungen von Lokad beteiligt sind), dass die externen Mitarbeiter durch Hintergrundüberprüfungen überprüft werden? Entspricht die Art dieser Hintergrundüberprüfungen dem entsprechenden Informationszugriffsniveau und der Bedeutung der Rolle des Mitarbeiters?
Lokad - zum Zeitpunkt des Verfassens - verlässt sich nicht auf Subunternehmer/externes Personal. Die Software-Engineering- und Supply Chain Scientist-Teams von Lokad werden vollständig von Personen unter direkter, fester Anstellung und Aufsicht von Lokad besetzt.
Wenn Lokad jedoch der Ansicht wäre, dass es notwendig ist, mit externem Personal zusammenzuarbeiten, wäre dies eine Anforderung. Alle Subunternehmer/externen Mitarbeiter würden denselben Sicherheitsprozessen, Hintergrundüberprüfungen und Schulungsanforderungen unterliegen wie unsere festangestellten Mitarbeiter.
Hinweis: Historisch gesehen werden viele der größten - und schlimmsten - Vorfälle, wie z.B. Cyber-Spionage, von Personen begangen, die makellose Aufzeichnungen haben. Aus diesem und anderen Gründen zögert Lokad, sich auf externes Personal zu verlassen, und bevorzugt stark direkte, unbefristete Arbeitsverträge.
6.11 Werden die Administratorkonten automatisch deaktiviert oder gelöscht, wenn das Arbeitsverhältnis endet?
Ja. Alle Lokad-Mitarbeiter erhalten ihre Zugriffsrechte über einen föderierten Identitätsanbieter (Microsoft Azure Active Directory). Am Ende ihres Arbeitsverhältnisses werden diese Zugriffe gegebenenfalls widerrufen, wodurch automatisch alle zugehörigen Administrationsrechte deaktiviert werden.
Hinweis: Den meisten Lokad-Mitarbeitern werden niemals Administrationsrechte gewährt, da diese für die Ausführung ihrer Aufgaben nicht erforderlich sind.
6.12 Führen Sie kriminelle Hintergrundüberprüfungen bei allen Mitarbeitern durch, die Zugriff auf sensible Daten, Finanzdaten, Bankdaten, Zahlungskartendaten usw. haben?
Ja, Hintergrundüberprüfungen werden streng in Übereinstimmung mit den Anforderungen der ausgeführten Tätigkeit durchgeführt.
Es sei darauf hingewiesen, dass Lokad keine Zahlungskartendaten intern verwaltet - dies wird von Dritten verwaltet. Daher haben die Lokad-Mitarbeiter keinen Zugriff auf Zahlungskartendaten unserer Kunden.
6.13 Welche Vorkehrungen trifft Lokad, um sicherzustellen, dass nicht autorisiertes Personal keinen Zugang zu den Räumlichkeiten hat, in denen die Arbeit durchgeführt wird?
Auf Gebäudeebene betreibt Lokad ein Bürogebäude, das von einer 24/7 (vierundzwanzig Stunden am Tag, sieben Tage die Woche) Überwachung durch Dritte profitiert, mit Sicherheitspersonal vor Ort.
Auf Büroebene verfügen die Lokad-Räumlichkeiten über eigene sichere Zugangspunkte, unabhängig von denen des Gebäudes selbst. Diese letzte Ebene verhindert, dass Mitarbeiter anderer Unternehmen im Gebäude Zugang zu den Lokad-Büros erhalten.
Hinweis: Außergewöhnliche Besucher (wie z.B. Kunden, potenzielle Kandidaten usw.) müssen von Lokad-Mitarbeitern physisch begrüßt und zum Betreten der Räumlichkeiten berechtigt werden.
6.14 Sind Besucher in der Einrichtung zugelassen?
Wenn “Einrichtung” bedeutet “der Ort, an dem die 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 begrüßt jedoch gelegentlich Besucher in seinem Hauptsitz. Unsere Büros sind nicht öffentlich zugänglich, aber es treten gelegentlich außergewöhnliche Umstände auf, wie z.B. Besuche von Kunden, Bewerber, die auf ein Vorstellungsgespräch warten, usw. Solche Besuche werden im Voraus geplant, und die Besucher werden während ihres Aufenthalts in unseren Büros jederzeit von Lokad-Mitarbeitern begleitet.
6.15 Werden Papierdatensätze (und herausnehmbare elektronische Medien mit Daten) über Nacht in sicheren feuerfesten Schränken aufbewahrt?
Lokad arbeitet nicht mit Papierdatensätzen, noch arbeitet es mit herausnehmbaren elektronischen Medien. Da wir keine physischen Aufzeichnungen zur Aufbewahrung haben, benötigt Lokad keine feuerfesten Schränke.
Obwohl wir gelegentlich ein Dokument drucken können (Lokad druckt sehr wenige Dokumente, wenn überhaupt), haben wir auch einen Aktenvernichter neben dem Drucker. Die Standardrichtlinie von Lokad besteht darin, kein sensibles Dokument zu drucken, aber wenn es theoretisch getan werden müsste, besteht unsere Standardrichtlinie auch darin, das gedruckte Dokument sofort nach Gebrauch zu vernichten.
6.16 Gibt es eine klare Schreibtischrichtlinie? Wenn ja, in welchem Umfang?
Ja, Lokad arbeitet mit einer klaren Schreibtischrichtlinie, die fest verankert ist. Diese Richtlinie wird “by design” durch unsere digitale Umgebung durchgesetzt.
Mit Ausnahme einiger Dokumente, die wir gesetzlich verpflichtet sind zu drucken, oder gelegentlicher Dokumente, die aus Notwendigkeit gedruckt werden (z.B. ein Poster für eine Messe, obwohl auch dies in der Regel ausgelagert würde), ist die Arbeitsumgebung von Lokad strikt digital.
Somit haben Lokads Mitarbeiter am Ende des Tages nichts zu aufräumen. Sobald die Computersitzung des Mitarbeiters gesperrt wurde - eine Richtlinie, die wir strikt durchsetzen - ist der betreffende Schreibtisch effektiv aufgeräumt.
6.17 Wo kommen Faxe an und wer hätte Zugriff darauf?
Lokad hat noch nie ein Faxgerät besessen - sei es physisch oder virtuell. Wir kennen keinen zwingenden Anwendungsfall, um unsere Haltung zu dieser Technologie zu ändern.
6.18 Gibt es einen Prozess zur Überprüfung der Rückgabe von Bestandteilen (Computer, Mobiltelefone, Zugangskarten, Token, Smartcards, Schlüssel usw.) bei Beendigung?
Ja, wir haben nicht nur einen Prozess, sondern auch eine IT-Asset-Management-Software, um diese Bemühungen zu unterstützen und die Anzahl von Verwaltungsfehlern zu minimieren.
Wir haben jedoch die Sicherheit von Lokad bewusst so konzipiert, dass sie nicht von der rechtzeitigen Rückgabe der Bestandteile abhängt. Lokad geht davon aus, dass alle Bestandteile eine faire Chance haben, verloren oder gestohlen zu werden, unabhängig davon, wie diszipliniert und geschult unsere Mitarbeiter sein mögen. In der Praxis passiert dies sehr selten, aber aus ingenieurtechnischer Sicht treffen wir die entgegengesetzte Annahme. Aus diesem Grund können Bestandteile remote deaktiviert werden. Darüber hinaus wenden wir bei Bedarf eine vollständige Laufwerksverschlüsselung an.
Allgemeiner gesagt wurde unsere Arbeitsumgebung 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äventiven Maßnahmen versagen sollten.
6.19 Sind die Personalrichtlinien und/oder -verfahren des Personalwesens von der Geschäftsleitung genehmigt und den Beteiligten mitgeteilt, und ist ein Verantwortlicher benannt, um sie aufrechtzuerhalten und zu überprüfen?
Ja, unsere Personalrichtlinien und -verfahren wurden formell von der obersten Geschäftsleitung genehmigt. Wir legen großen Wert auf klare Kommunikation, und daher wurden diese Richtlinien und Verfahren gründlich an alle relevanten Beteiligten verbreitet, um ein vollständiges Verständnis und Einhaltung sicherzustellen.
Darüber hinaus haben wir einen Verantwortlichen benannt, der für die laufende Wartung, Aktualisierung und regelmäßige Überprüfung der Richtlinien und Verfahren verantwortlich ist. Dies gewährleistet, dass unsere Praktiken aktuell, relevant und im Einklang sowohl mit Branchenstandards als auch mit unseren Unternehmenszielen bleiben.
6.20 Werden von Personen, die mit Ihrer Organisation verbunden sind, persönliche (BYOD) mobile Geräte anstelle von firmeneigenen Geräten verwendet, die Zugriff auf Kundendaten haben?
Nein, Lokad gestattet keinen Zugriff auf Kundendaten auf persönlichen (BYOD) mobilen Geräten. Wir stellen unseren Mitarbeitern hochwertige, firmeneigene Hardware zur Verfügung, um den Bedarf an persönlichen Geräten zu beseitigen. Diese Bestimmung bezieht sich auf das häufige Szenario, in dem Mitarbeiter aufgrund von Unzufriedenheit mit minderwertiger Unternehmenshardware auf ihre eigenen Geräte zurückgreifen.
Darüber hinaus sind unsere Betriebsprotokolle so konzipiert, dass selbst auf unseren firmeneigenen Geräten Kundendaten nicht dauerhaft gespeichert werden. Die gesamte Datenverarbeitung erfolgt in unserer Cloud-Plattform. Auf Mitarbeitergeräten werden Kundendaten (falls überhaupt abgerufen) vorübergehend und nur in minimalen Segmenten verarbeitet, um maximale Sicherheit zu gewährleisten.
Anmerkungen
-
In der Videospielbranche sind viele, wenn nicht die meisten Mitarbeiter wirklich leidenschaftlich für Videospiele; nicht nur für diejenigen, die vom Arbeitgeber entwickelt wurden, sondern für den Markt als Ganzes. Viele dieser Mitarbeiter “machen nur ihren Job” nicht; sie sind emotional in das Ergebnis ihrer Arbeit investiert. Im Gegensatz dazu ist der Standardzustand der Mitarbeiter von Unternehmenssoftware, offen gesagt, immense Langeweile. Menschen dazu zu bringen, sich für ein Stück Unternehmenssoftware zu interessieren, ist ein mühsamer Kampf, aber ein notwendiger. ↩︎
-
Prognosetechnologien, eine Schlüsselkomponente von Supply-Chain-Optimierungslösungen, neigen besonders zu spektakulären Übertreibungen, sowohl in Bezug auf die Prognosegenauigkeit als auch auf positive Ergebnisse für die Kundenunternehmen. Siehe Top 10 Lügen von Prognoseanbietern ↩︎
-
Epistemische Korruption ist eine faszinierende Klasse von Sicherheitsproblemen. Sie degradiert Software nicht durch Code, sondern durch die Verbreitung falscher oder schädlicher Überzeugungen unter den Spezialisten, die die Entwicklung der Software lenken. Siehe Adversariale Marktforschung für Unternehmenssoftware ↩︎
-
Selbst die zuverlässigsten Menschen sind gelegentlich erschöpft, krank, gestresst. Das alte Sprichwort besagt, dass jedes (Computer-)System, das auf menschliche Zuverlässigkeit angewiesen ist, unzuverlässig ist. ↩︎